Risiken bei der Migration von Buchhaltungssystemen im Griff
Eine Buchhaltungsmigration scheitert selten am eigentlichen Datenimport. Probleme entstehen meist dann, wenn ein Unternehmen feststellt, dass die neuen Salden nicht mit dem bisherigen Hauptbuch übereinstimmen, Rechnungen nicht korrekt miteinander verknüpft sind oder das Buchhaltungsteam wieder auf manuell gepflegte Tabellen zurückgreifen muss. Risiken bei der Migration von Buchhaltungssystemen, in der Projektpraxis häufig als Accounting System Migration Risks bezeichnet, sind daher nicht nur ein IT-Thema. Sie können den Abschluss, den Cashflow, steuerliche Auswertungen, die Bestandsbewertung und auch das Vertrauen der Geschäftsleitung in das Reporting beeinträchtigen.
In einem Produktionsunternehmen kann eine fehlerhaft übertragene Bestandsbewertung die Marge verzerren. Im E-Commerce können nicht verknüpfte Gutschriften und Zahlungen zum Problem werden. In der Logistik erschweren fehlende Verbindungen zwischen Auftrag, Lieferung und Rechnung die Kontrolle der Rentabilität. Eine gut gesteuerte Migration entsteht nicht durch einen schnellen Export und Import. Sie basiert auf klaren Entscheidungen darüber, welche Daten übertragen werden, wie sie geprüft werden und wer die Verantwortung für ihre Richtigkeit übernimmt.
Warum die Risiken bei der Migration von Buchhaltungssystemen so relevant sind
Ein Buchhaltungssystem ist keine isolierte Datenbank. In der Regel empfängt es Daten aus dem CRM, dem Onlineshop, von Banken, aus dem Lager, der Zeiterfassung, der Produktion oder einem Auftragsmanagement-Tool. Gleichzeitig liefert es Informationen für das Reporting, Konsolidierungsübersichten und häufig auch für Systeme zur Steuer- und Lohnabrechnung. Bei einem Systemwechsel werden somit nicht nur Buchungsbelege verschoben. Der Informationsfluss im gesamten Betrieb verändert sich.
Das größte Risiko ist ein falsches Sicherheitsgefühl. Wenn Tausende Kunden, Rechnungen und Hauptbuchpositionen ohne Fehlermeldung importiert werden, kann das Projekt auf den ersten Blick erfolgreich wirken. Das bedeutet jedoch nicht, dass die Daten verwendbar sind. Dubletten, fehlerhafte Zuordnungen analytischer Konten oder verlorene Verknüpfungen zwischen Belegen fallen häufig erst beim Abschluss, bei einer Reklamation oder im Rahmen einer Prüfung auf.
Zudem muss zwischen technischer und operativer Korrektheit unterschieden werden. Technisch kann ein Datensatz das richtige Format haben. Für die Buchhaltung ist er jedoch möglicherweise wertlos, wenn Kostenstelle, Auftrag, Leistungsdatum, Währung oder Zahlungshistorie fehlen. Ein qualitativ hochwertiges Projekt prüft deshalb nicht nur, ob die Daten erfolgreich importiert wurden, sondern auch, ob sie die tatsächlichen Buchhaltungs- und Managementprozesse unterstützen.
Die häufigsten Problemquellen bei einer Migration
Mangelhafte oder uneinheitliche Quelldaten
Ältere Buchhaltungssysteme enthalten häufig historische Daten aus vielen Jahren, die zu unterschiedlichen Zeitpunkten und nach unterschiedlichen Regeln erfasst wurden. Ein Kunde kann mehrfach unter abweichenden Namen angelegt sein. Kostenstellen können inaktiv sein und dennoch auf offenen Belegen erscheinen. Produktstammdaten können ungültige Umsatzsteuersätze oder veraltete Maßeinheiten enthalten.
Alles ungeprüft zu übertragen, ist verlockend, weil es die Vorbereitungsphase verkürzt. Tatsächlich wird damit jedoch auch die operative Altlast übernommen. Das neue System arbeitet dann mit denselben Fehlern weiter – lediglich in einer moderneren Oberfläche. Der richtige Ansatz besteht darin, die Daten zunächst zu analysieren: ihre Vollständigkeit, Dubletten, fehlende Werte, ungültige Verknüpfungen und Abweichungen bei wichtigen Salden. Erst danach lässt sich entscheiden, welche historischen Daten tatsächlich migriert werden und welche lediglich in einem Archiv verfügbar bleiben.
Fehlerhafte Abbildung der Buchungslogik
Die Zuordnung von Daten ist kein mechanisches Übertragen eines Feldes aus dem alten in das neue System. Jedes Buchhaltungssystem verfügt über einen eigenen Kontenplan, analytische Konten, Dimensionen, Buchungsregeln und eine eigene Handhabung der Umsatzsteuer. Das Altsystem konnte beispielsweise Profitcenter in einer Textnotiz unterscheiden, während das neue ERP eine separate Dimension verlangt. Wird dieser Unterschied nicht bereits in der Konzeption berücksichtigt, ist das Reporting nach der Inbetriebnahme nicht vergleichbar.
Besonders kritisch ist die Zuordnung von Hauptbuch, offenen Posten, Steuerschlüsseln, Währungen, Kostenstellen und Aufträgen. Ebenso wichtig sind die Eröffnungssalden und die Verknüpfungen zwischen Forderungen, Verbindlichkeiten, Zahlungen und deren Zuordnung. Das Unternehmen muss im Voraus definieren, was unter einem korrekt übertragenen Datenbestand zu verstehen ist. Es genügt nicht, dass die Summe der Konten übereinstimmt. Es muss klar sein, wie die einzelnen Buchungsbereiche geprüft werden und wer die Ergebnisse freigibt.
Unterbrochene Integrationen und unklare Datenverantwortung
Ein Buchhaltungssystem ist meist stärker von Integrationen abhängig, als zu Beginn eines Projekts angenommen wird. Der Onlineshop legt Bestellungen an, das CRM übermittelt Kundendaten, die Bank stellt Kontoauszüge bereit, das Lager erzeugt Bestandsbewegungen und das Reporting liest Daten für die Geschäftsleitung aus. Werden die Schnittstellen nicht anhand realer Szenarien getestet, kann das Unternehmen nach der Inbetriebnahme feststellen, dass Belege zwar vorhanden sind, aber nicht automatisch erstellt oder auf falsche Konten gebucht werden.
Jeder wesentliche Datenfluss benötigt daher sowohl auf fachlicher als auch auf technischer Seite einen Verantwortlichen. Das IT-Team kann die korrekte Behandlung der Umsatzsteuer nicht allein bestätigen, und die Buchhaltung kann ohne Unterstützung der Entwicklung nicht über das Verhalten einer API entscheiden. Die Zuständigkeiten müssen klar verteilt sein: Wer erstellt die Daten, wer kontrolliert sie, wer bearbeitet Ausnahmen und wer genehmigt Änderungen an den Regeln?
Unzureichende Tests und ein überstürzter Produktivstart
Eine Testmigration ist kein einmaliger Probelauf des Imports. Sie dient dazu, die gesamte Prozesskette zu überprüfen. Das Unternehmen sollte einen Test mit repräsentativen Daten durchführen, die Ergebnisse mit dem Quellsystem vergleichen, Regeln korrigieren und den Test wiederholen. Bei komplexeren Organisationen ist es sinnvoll, Buchhaltung, Lager, Bestellungen, Bankprozesse und Reporting zunächst getrennt zu testen und anschließend vollständige, systemübergreifende Szenarien zu prüfen.
Ein Produktivstart während des Monats- oder Jahresabschlusses, einer Inventur oder einer saisonalen Hochphase erhöht das Risiko – unabhängig von der Qualität des Dienstleisters. Manchmal empfiehlt es sich, das neue System zu Beginn einer Abrechnungsperiode einzuführen. In anderen Fällen ist eine schrittweise Umstellung nach Niederlassungen, Gesellschaften oder Prozessen erforderlich. Die passende Variante hängt vom Transaktionsvolumen, den regulatorischen Pflichten und der Fähigkeit des Teams ab, die Umstellung im laufenden Betrieb zu bewältigen.
So lässt sich das Risiko bereits vor dem ersten Import reduzieren
Erfolgreiche Projekte beginnen mit einem klar definierten Umfang. Das Unternehmen muss entscheiden, ob die vollständige Historie, nur das aktuelle Geschäftsjahr oder lediglich Eröffnungssalden und aktive Belege übertragen werden. Mehr Daten bedeuten eine bessere Verfügbarkeit historischer Informationen im neuen System, aber auch mehr Transformationen, Tests und mögliche Fehler. Für viele mittelständische Unternehmen ist es praktikabler, ältere Perioden in einem gesicherten Archiv zu belassen und nur die Daten in das neue System zu übernehmen, die für die tägliche Arbeit, gesetzliche Pflichten und eine vergleichbare Leistungssteuerung erforderlich sind.
Im nächsten Schritt wird ein Migrationskonzept erstellt, das für jeden Datenbereich die Quelle, die Zielstruktur, die Transformationsregeln, die verantwortliche Person und die Kontrollmethode beschreibt. Dieses Dokument sollte ein Arbeitsinstrument sein und keine formale Projektanlage. Ändert sich während eines Tests eine Regel für Buchungen oder das Anlegen von Kunden, muss diese Änderung nachvollziehbar dokumentiert und genehmigt werden.
Vor dem Produktivstart sollten mindestens die folgenden Kontrollpunkte bestätigt sein:
- Übereinstimmung von Hauptbuch, offenen Posten, Banksalden und offenen Positionen,
- korrekte Zuordnung von Umsatzsteuer, Währungen, Kostenstellen, Aufträgen und Buchungsdimensionen,
- funktionsfähige Integrationen mit kritischen operativen Systemen,
- getestete Ausnahmefälle wie Gutschriften, Stornierungen, Teilzahlungen und Belegkorrekturen,
- vorbereiteter Rückfallplan oder eingeschränkter Betriebsmodus für den Fall eines schwerwiegenden Fehlers.
Die Kontrolle muss auf konkreten Nachweisen basieren und nicht auf dem Eindruck, dass das System korrekt aussieht. Dazu gehören der Vergleich von Prüfsummen und Datensatzanzahlen, die Kontrolle einzelner Belegstichproben sowie die Prüfung von Berichtsergebnissen. Bei wesentlichen Datenbereichen sollten die Ergebnisse durch den fachlich verantwortlichen Finanzbereich und nicht nur durch den Projektmanager freigegeben werden.
Die Rolle der Automatisierung und eines erfahrenen Implementierungspartners
Automatisierung kann den manuellen Aufwand bei der Bereinigung, Transformation und Prüfung von Daten deutlich reduzieren. Sie kann Dubletten erkennen, Pflichtfelder überwachen, Salden zwischen Systemen vergleichen und auf ungewöhnliche Abweichungen hinweisen. Sie ersetzt jedoch keine buchhalterischen Entscheidungen. Das System kann einen problematischen Steuerschlüssel kennzeichnen, doch die Regel für dessen Verwendung muss das Unternehmen gemeinsam mit den Personen festlegen, die seine Buchhaltung und betrieblichen Abläufe verstehen.
Genau hier ist ein Partner gefragt, der sich mit ERP, Integrationen und der Automatisierung von Arbeitsabläufen auskennt. Logyloop betrachtet Migrationen als Bestandteil einer umfassenderen Modernisierung des Betriebs und nicht als isolierte technische Aufgabe. Das Ziel besteht nicht nur darin, die Vergangenheit in ein neues System zu übertragen, sondern künftig eine höhere Datenqualität, zuverlässigere Verknüpfungen und weniger manuelle Arbeit zu erreichen.
Der beste Zeitpunkt zur Risikoreduzierung ist nicht der Tag vor dem Produktivstart. Er liegt in dem Moment, in dem das Unternehmen erstmals entscheidet, wie Belege im neuen System entstehen, wer die Verantwortung für die Daten trägt und anhand welcher Kennzahlen die Leistung gesteuert wird. Die Migration ist dann kein Sprung ins Ungewisse, sondern ein kontrollierter Übergang zu einer Buchhaltung, der die Geschäftsleitung vertrauen kann.
