Migrationsstrategie: Parallelbetrieb statt Big Bang
Eine Big-Bang-Migration aller Mandate auf einmal ist riskant und unnötig. Die belastbare Strategie ist gestaffelt: ein bis zwei Pilotmandate, dann eine kontrollierte Welle pro Monat. So bleibt die Kanzlei produktiv, Risiken sind isoliert, und das Team lernt im Realbetrieb.
Wichtig: PrimeBalance arbeitet neben DATEV, nicht statt DATEV. Mandantenstämme, Kontenrahmen (SKR03, SKR04, SKR49, IKR) und Vorjahresdaten bleiben dort, wo sie sind. PrimeBalance liest via DATEVconnect online, verarbeitet, prüft und schreibt im nativen DATEV-Format zurück. Das reduziert die Migrationskomplexität auf "Datenpipeline einrichten" statt "ganzes Buchführungssystem ablösen".
Phase 1: Vorbereitung (1–2 Tage)
Bevor irgendetwas verbunden wird, klären Sie diese Punkte. Sie verhindern 80 Prozent der typischen Migrationsprobleme.
- DATEVconnect online aktivieren — falls nicht ohnehin schon. Voraussetzung für die OAuth-Verbindung.
- Berater-Nummer und Mandantennummern dokumentieren — diese Identifier referenziert PrimeBalance unverändert.
- Verwendete Kontenrahmen pro Mandant erfassen (SKR03 ist häufig Default; SKR04 für IFRS-nahe Mandate; SKR49 für Vereine; IKR für Industrie).
- Belegtransfer-Konfiguration prüfen — wenn aktiv, kann sie zunächst weiterlaufen; PrimeBalance hängt parallel an die gleiche Pipeline.
- Berechtigungskonzept aktualisieren: PrimeBalance benötigt einen technischen Account mit Lese- und Schreibrechten auf die migrierten Mandate. Ein dedizierter Account vereinfacht die spätere Audit-Trail-Auswertung.
- Mandanten-Zustimmung für die Datenverarbeitung dokumentieren — Auftragsverarbeitungsvertrag (AVV) zwischen Kanzlei und PrimeBalance plus Information an die Mandanten.
- Migrations-Verfahrensdokumentation anlegen — Pflicht nach GoBD bei jedem Systemwechsel, auch beim Wechsel auf eine zusätzliche Verarbeitungsschicht.
Phase 2: Pilotmandate auswählen und verbinden (Tag 3–7)
Wählen Sie zwei bis drei Mandate, die typisch für Ihre Kanzlei sind, aber kein extremes Risikoprofil haben. Geeignet sind kleinere bis mittlere Bestandsmandate mit etablierten Buchungsroutinen — keine Erstaufträge, keine in laufender Außenprüfung befindlichen Mandate.
Verbinden Sie diese Mandate via DATEVconnect online OAuth mit PrimeBalance. Der Konfigurationsschritt dauert pro Mandant rund 15 Minuten. Im Anschluss synchronisiert PrimeBalance Stammdaten (Mandantenname, Anschrift, Steuernummern, USt-IdNr., Kontenrahmen) und übernimmt die letzten 12 Monate Bewegungsdaten als Referenz für Plausibilitätsprüfungen.
Wichtig: in dieser Phase werden noch keine Buchungen automatisiert. PrimeGuard validiert eingehende Belege, PrimeForge erstellt Buchungsvorschläge — die finale Freigabe und Festschreibung erfolgt manuell durch das Kanzleiteam in DATEV. Das reduziert das Risiko und gibt dem Team Zeit, das Vorschlagsverhalten zu kalibrieren.
Phase 3: Paralleltest und Kalibrierung (Tag 8–21)
Drei Wochen Paralleltest sind der wichtigste Teil der Migration. Hier zeigt sich, ob die Buchungsvorschläge die Mandatsspezifik treffen — Kontenrahmen-Eigenheiten, Sonderfälle, Mandanten-Konventionen.
Der Workflow im Paralleltest: alle eingehenden Belege werden von PrimeGuard validiert. PrimeForge erstellt Buchungsvorschläge im SKR-Format des Mandanten. Statt direkt zu festzuschreiben, werden die Vorschläge in einer Vorschlagsliste gesammelt. Das Kanzleiteam akzeptiert, korrigiert oder verwirft jeden Vorschlag. Akzeptierte Buchungen fließen via DATEVconnect zurück in DATEV — exakt wie eine manuell in DATEV erfasste Buchung.
Kalibrierungsmetrik: ab Woche zwei sollte die Akzeptanzrate über 85 Prozent liegen. Liegt sie darunter, ist meist eine spezifische Konfiguration des Mandanten nicht erfasst — etwa eine Sonderkostenstellen-Logik oder ein eigenes Kontensystem für eine GmbH-Holding-Struktur. PrimeBalance unterstützt mandatsspezifische Buchungsregeln; das Onboarding-Team hilft beim Anlegen.
Phase 4: Cut-over und Skalierung (ab Woche 4)
Nach erfolgreichem Paralleltest pro Mandat wird der Auto-Buchungs-Modus aktiviert. PrimeForge schreibt akzeptierte Buchungen direkt in DATEV; nur risikobehaftete Buchungen (markiert von PrimeWatch) gehen weiterhin durch das Vier-Augen-Prinzip mit manueller Freigabe.
Ab diesem Punkt skalieren Sie die Migration. Faustregel: drei bis fünf Mandate pro Woche pro betreuendem Mitarbeiter. Bei 50 Mandaten ist eine vollständige Migration in zwei bis drei Monaten realistisch — schneller geht, aber dann übersteigt die Onboarding-Last die Kapazität für laufende Arbeit.
SKR03 / SKR04 / SKR49 / IKR — was beim Mapping zu beachten ist
PrimeBalance unterstützt alle gängigen Kontenrahmen nativ. Beim Wechsel zwischen Rahmen (etwa SKR03 → SKR04 nach IFRS-Umstellung) gilt jedoch: das Mapping wird einmal pro Mandant erstellt und bleibt dann konstant. Eine nachträgliche Änderung des Kontenrahmens erfordert eine GoBD-konforme Migrationsbuchung — das ist im Prinzip eine Sonderform des Systemwechsels und gehört in die Verfahrensdokumentation.
Für die häufige Konstellation "Kanzlei nutzt SKR03 für GmbHs und SKR04 für Personengesellschaften" ist nichts zu tun — PrimeBalance liest den verwendeten Rahmen aus den DATEV-Stammdaten und behandelt jedes Mandat entsprechend.
ELSTER-Kontinuität während der Migration
Eine kritische Frage: welches System übermittelt während der Migration ans Finanzamt? Antwort: zunächst weiterhin DATEV. PrimeDispatch (der ELSTER-Agent) wird erst nach abgeschlossenem Paralleltest aktiviert, frühestens für die zweite USt-Voranmeldung nach Migrationsstart.
Der Wechsel ist klar markiert: PrimeBalance erzeugt eine Übermittlungs-Vorschau mit Transferticket-Vergleich, die im Audit-Trail festgehalten wird. Damit lässt sich später eindeutig nachvollziehen, ab welchem Voranmeldungszeitraum welches System übermittelt hat — wichtig für Außenprüfungen.
Unterstützte ELSTER-Übermittlungen: USt-Voranmeldung, Zusammenfassende Meldung (ZM), ESt, KSt, GewSt, Lohnsteuer-Anmeldung. Die Authentifizierung erfolgt mit dem bestehenden Organisations- oder Mitarbeiterzertifikat — kein neues Zertifikat, keine separate Anmeldung beim Bundeszentralamt für Steuern.
Häufige Stolperfallen — und wie Sie sie vermeiden
Aus rund 50 Pilotmigrationen lassen sich diese fünf Punkte zusammenfassen.
- Mandant nicht informiert — Lösung: Standard-Anschreiben an Mandanten beim Migrationsstart, das die zusätzliche Verarbeitungsschicht plus AVV erklärt. Die meisten Mandanten haben keine Einwände, wollen aber informiert sein.
- Sonderkostenstellen nicht erfasst — Lösung: vor Phase 3 ein 30-Minuten-Workshop pro Mandant, in dem das Kanzleiteam die Eigenheiten dokumentiert. Das spart viel Kalibrierungs-Aufwand in der Paralleltestphase.
- Belege ohne saubere PDF-A-Konformität — viele Mandanten schicken JPEGs oder Word-Dokumente. PrimeGuard konvertiert in PDF/A-3, aber die Konvertierung sollte protokolliert werden (Verfahrensdokumentation).
- DATEV-Berechtigung zu eng — Lösung: dedizierter API-Account mit klar definiertem Berechtigungsumfang. Kein "Default Admin"-Zugang, das passt nicht zum Berechtigungskonzept der GoBD.
- Audit-Trail-Vorhaltedauer zu kurz — manche Cloud-Lösungen löschen Logs nach 90 Tagen. PrimeBalance hält den Trail über die volle Aufbewahrungsfrist (10 Jahre) revisionssicher vor; bei anderen Tools muss das vor der Migration verifiziert werden.
Was passiert, wenn Sie zurück wollen?
Die Migration ist nicht einbahnstraße. PrimeBalance exportiert jederzeit den vollständigen Bestand in DATEV-Formaten (KNE, ASCII), CSV und JSON — ohne weitere Gebühren, ohne Sperrfrist. Aufbewahrungspflichtige Daten gemäß § 147 AO können auch nach Vertragsende für die volle Frist im Read-Only-Archiv gehalten werden.
Konkret heißt das: ein Mandat, das während des Paralleltests Probleme zeigt, kann jederzeit zurückgerollt werden. Ein vollständiger Reverse-Migration-Pfad (PrimeBalance → reines DATEV ohne Automatisierungsschicht) braucht weniger als einen Tag pro Mandat. Datenmäßig geht nichts verloren — die Mandantenstämme lagen ohnehin in DATEV.