Wie lange dauert die ERP-Einführung? Realistische Zeitpläne

Eine phasenbasierte Antwort darauf, wie lange ein ERP-Projekt dauert, welche Faktoren es verlängern und ein kontrastierender Zeitplan für einen Buchhaltungskern, den Sie über eine API anbinden.

Ein kleines Unternehmen, das zu einem Cloud-ERP mit Standardmodulen wechselt, benötigt in der Regel drei bis sechs Monate von der Vertragsunterzeichnung bis zum Go-Live. Ein mittelständisches Unternehmen mit mehreren rechtlichen Einheiten (Entities), benutzerdefinierten Workflows und Integrationen plant üblicherweise sechs bis zwölf Monate ein. Die Einführung in einem großen multinationalen Konzern nimmt ein bis drei Jahre in Anspruch, oft in Wellen nach Region oder Geschäftsbereich aufgeteilt. Diese Zeitspannen decken sich mit den Erfahrungswerten von Implementierungspartnern und Finanzteams; sie basieren jedoch nicht auf einer Umfrage, und ein konkretes Projekt kann in beide Richtung davon abweichen.

Die eine, universelle Zahl, nach der alle fragen, existiert schlicht nicht. Denn eine „Implementierung“ besteht aus neun separaten Arbeitssträngen, deren Dauer jeweils von Entscheidungen abhängt, die der Käufer vor Projektbeginn trifft. Dieser Artikel gliedert den Zeitplan in diese einzelnen Bestandteile, zeigt auf, was sie in die Länge zieht, und stellt ihnen einen alternativen Zeitplan gegenüber: denjenigen, den Sie erhalten, wenn der Buchhaltungskern eine API ist, mit der Ihre eigene Software kommuniziert, anstatt eines Systems, das Sie erst konfigurieren müssen.

Die neun Phasen und ihre zeitlichen Treiber

Phase	Typische Dauer	Haupttreiber für die Dauer
Auswahl (Selection)	1–3 Monate	Anzahl der engeren Auswahl (Shortlist), Demorunden, Referenzgespräche, Beschaffungsrichtlinien
Design	2–8 Wochen	Anzahl der abzubildenden Prozesse, Grad des Einvernehmens im Team, Akzeptanz des Standard-Workflows des Anbieters
Datenmigration	4–16 Wochen	Qualität der Stammdaten, Anzahl der zu migrierenden Historienjahre, Anzahl der Quellsysteme
Konfiguration	4–12 Wochen	Anzahl der rechtlichen Einheiten, Kontenrahmen, Länder, Steuersysteme, Freigabeprozesse
Integration	4–20 Wochen	Anzahl anzubindender Systeme (Bank, Lohn- und Gehaltsabrechnung, E-Commerce, CRM, Lager), API-Qualität der jeweiligen Seite
Tests	3–8 Wochen	Anzahl der End-to-End-Szenarien, Realismus der Testdaten, Anzahl der im ersten Durchlauf gefundenen Fehler (Defects)
Schulung (Training)	2–6 Wochen	Mitarbeiterzahl, Rollenvielfalt, Grad der Abweichung des neuen Prozesses vom alten
Go-Live	1–2 Wochen	Art der Systemumstellung (Big-Bang oder schrittweise), zeitliche Abstimmung auf den Periodenabschluss
Hypercare	4–12 Wochen	Anzahl offener Fehler beim Go-Live, erster Monatsabschluss, erste Umsatzsteuervoranmeldung aus dem neuen System

In der Praxis überlappen sich diese Phasen. Die Integration beginnt oft schon, während die Konfiguration noch läuft; Schulungen überschneiden sich häufig mit der Testphase. Ein realistischer Plan ergibt sich daher nicht aus der einfachen Addition der Tabellenspalten. Der kritische Pfad verläuft jedoch meist über die Datenmigration und die Integration – und genau hier treten auch die meisten Verzögerungen auf.

Was ein Projekt in die Länge zieht

Anpassungen (Customisation). Jede Änderung am Standardverhalten des Anbieters muss spezifiziert, entwickelt, getestet, dokumentiert und bei jedem zukünftigen Upgrade erneut getestet werden. Projekte, die für 90 % der Abläufe den Standardprozess akzeptieren und den Rest anpassen, werden in der Regel erfolgreich abgeschlossen; Projekte, die damit beginnen, die Bildschirmmasken des Altsystems 1:1 nachzubauen, scheitern oft.

Mangelhafte Stammdaten. Doppelte Kunden, Lieferanten mit drei unterschiedlichen Schreibweisen, Artikel ohne Maßeinheit oder ein Kontenrahmen, der über ein Jahrzehnt hinweg unkoordiniert gewachsen ist. Eine Migration kann niemals schneller ablaufen als die Datenbereinigung – und diese Bereinigung erfolgt meist durch Personen, die gleichzeitig ihr Tagesgeschäft bewältigen müssen. Dies ist die häufigste Ursache für verschobene Go-Live-Termine und gleichzeitig die im ursprünglichen Plan am schlechtesten sichtbare.

Mehrere rechtliche Einheiten (Multi-Entity). Jede juristische Person benötigt einen eigenen Kontenrahmen, eine eigene Nummernverkreisung, Umsatzsteueridentifikation, Bankverbindungen und einen eigenen Periodenabschluss. Die konzerninternen Verflechtungen (Intercompany-Abläufe) erfordern ein eigenes Design. Multiplizieren Sie die Konfigurationsphase mit der Anzahl der Gesellschaften und addieren Sie das Design für die Konsolidierung hinzu.

Länderübergreifende Steuern. Ein Unternehmen, das in mehrere EU-Mitgliedstaaten verkauft, muss im neuen System vor der ersten Fälligkeit die Lieferortregeln, das Reverse-Charge-Verfahren, die OSS-Meldung sowie die lokalen Meldeformate fehlerfrei eingerichtet haben. Wenn die Lokalisierung eines Anbieters für ein bestimmtes Land von Partnern statt nativ erstellt wurde, wird die Verfügbarkeit dieses Partners zu einem Teil des kritischen Pfads.

Integrationen mit schwachen APIs. Ein ERP-System, das lediglich dateibasierte Importe unterstützt, zwingt jedes angebundene System in ein Stapelverarbeitungsverfahren (Batch-Pattern). Jedes Batch-Pattern erfordert wiederum eine Abstimmungslogik (Reconciliation), die von jemandem geschrieben und getestet werden muss.

Ein vorab fixierter Go-Live-Termin. Wird ein Termin aus rein politischen Gründen festgelegt und der tatsächliche Projektumfang (Scope) erst später erkannt, führt dies unweigerlich entweder zu Abstrichen bei den Tests oder zu einer Terminverschiebung. Beides ist kostspielig.

Was ein Projekt beschleunigt

Die Übernahme der Standardprozesse des Anbieters in Bereichen, in denen sich das Unternehmen nicht von Mitbewerbern unterscheidet.
Die Bereinigung der Stammdaten vor Projektbeginn statt währenddessen.
Die Beschränkung der Migration auf Eröffnungsbilanzen und offene Posten statt der vollständigen Historie, während das Altsystem für Nachschlagezwecke lesbar bleibt.
Die Wahl eines Umstiegsdatums (Cutover) auf eine Periodengrenze mit einer festgeschriebenen, abgestimmten Summen- und Saldenliste (Trial Balance).
Die Benennung genau eines Prozessverantwortlichen pro Modul mit entsprechender Entscheidungskompetenz.
Das Testen mit echten Belegen aus den letzten zwölf Monaten statt mit künstlich generierten Testdaten.
Die Wahl eines Systems, dessen API es ermöglicht, Integrationen parallel zur Konfiguration statt im Anschluss daran zu entwickeln und zu testen.

Ein anderer Zeitplan: Der API-first-Buchhaltungskern

Die oben beschriebenen Zeitpläne gelten für ein System, das Menschen über Bildschirmmasken konfigurieren und anschließend auch über diese bedienen. Es gibt jedoch eine andere Projektarchitektur mit einem gänzlich anderen Zeittakt. Wenn der Buchhaltungskern eine Buchhaltungs-API ist, verlagert sich die Integrationsarbeit an den Anfang. Der Großteil der Konfigurationsphase entfällt, da es schlicht weniger einzurichten gibt: Der Kontenrahmen, die Steuerregeln und die Meldeformate sind bereits im Produkt enthalten.

Am Beispiel von Nordlet zeigt sich dies wie folgt (gemessen an den tatsächlichen Funktionen des Produkts zum heutigen Tag und nicht an bloßen Versprechungen):

Tag eins: Eine Sandbox-Unternehmung. Eine Sandbox-Umgebung wird direkt aus der App oder über einen einzigen API-Aufruf erstellt. Sie verhält sich exakt wie ein echtes Unternehmen mit denselben Modulen und Endpunkten; es können beliebig viele Instanzen erstellt werden. Der Leitfaden für den Einstieg führt durch die ersten Aufrufe.

Tag eins bis fünf: Der erste funktionierende Ablauf. Einen Geschäftspartner anlegen, eine Rechnung erstellen, diese ausstellen, einen Zahlungseingang verbuchen und den daraus resultierenden Buchungssatz (Journal Entry) auslesen. Jede Operation erfolgt über einen POST /v1/{module}/{resource}/{action}-Aufruf mit einem JSON-Body. Da für neun Programmiersprachen typisierte SDKs bereitstehen, umfasst der erste funktionierende Ablauf nur wenige Dutzend Zeilen Code. Wiederholte Aufrufe (Retries) sind sicher, da ein Idempotency-Key-Header die gespeicherte Antwort zurückgibt, anstatt versehentlich eine zweite Rechnung zu erzeugen.

Woche zwei: Die Historie. Der Migrationsimporter übernimmt den Kontenrahmen, Geschäftspartner, Artikel, Eröffnungsbilanzen oder die vollständige Buchungshistorie, offene Kunden- und Lieferantenrechnungen, Anlagevermögen inklusive bisheriger Abschreibungen sowie den aktuellen Lagerbestand und schreibt diese in einer einzigen Datenbanktransaktion. Der reine Prüfendpunkt (migration/books/validate) führt sämtliche Validierungen durch, ohne Daten zu speichern. So lässt sich das Datenpaket iterativ anpassen, bis keine Fehler mehr gemeldet werden. Erst danach wird migration/books/import genau einmal ausgeführt. Schlägt auch nur eine einzige Zeile fehl, wird gar nichts gespeichert.

Woche zwei bis vier: Die restliche Integration. Bank-Feeds über PSD2-Schnittstellen, camt.053-Kontoauszugsimport, Stripe-Exporte sowie Webhooks wie sale_invoice.paid, damit Ihr System auf Ereignisse reagiert anstatt permanent abzufragen (Polling). Jeder Baustein stellt einen separaten Endpunkt dar und kann von einem eigenen Entwickler parallel umgesetzt werden.

Compliance: Bereits integriert. Die umsatzsteuerliche Behandlung von grenzüberschreitenden Verkäufen wird durch die EU-VAT-Engine abgedeckt, und der Steuerkalender für das jeweilige Land wird automatisch aus den integrierten Regeln befüllt. Die Übersicht zur Meldungsunterstützung zeigt für alle 30 Länder, welche Fristen Nordlet selbst einreicht, für welche Länder es eine Datei generiert und welche manuell eingegeben werden müssen. Nichts davon erfordert projektspezifischen Entwicklungsaufwand.

Der Periodenabschluss als Lackmustest. Der erste Monatsabschluss ist der moment der Wahrheit, in dem ein ERP-Projekt zeigt, ob es funktioniert. Dank eines unveränderlichen Hauptbuchs (Immutable Ledger) und der Periodensperre wird eine Buchung mit Datum in einem gesperrten Monat mit dem Status 409 abgewiesen. Der Abschluss wird somit vom System erzwungen und nicht durch organisatorische Disziplin. Integrationsfehler, die sonst erst in der Hypercare-Phase aufgefallen wären, zeigen sich stattdessen direkt in der Sandbox.

Ehrliche Grenzen dieses Zeitplans: Er deckt den Kern für Buchhaltung, Steuern und Meldewesen ab. Sollte Ihr Projekt zusätzlich eine Lagerverwaltung, Fertigungssteuerung (Manufacturing Scheduling) oder ein CRM erfordern, handelt es sich dabei entweder um Nordlet-Module, die auf dieselbe Weise integriert werden (Bestand, Produktion, E-Commerce-Bestellungen, Leads), oder um eigenständige Nebensysteme, für die der Integrationsaufwand weiterhin bei Ihnen liegt. Zudem ist Nordlet ein junges Produkt, das sich 2026 in der Early-Access-Phase befindet und Design-Partner onboardet – ein Faktor, der bei jeder Anbieterentscheidung berücksichtigt werden sollte.

So schätzen Sie Ihr eigenes Projekt realistisch ein

Zählen Sie die rechtlichen Einheiten, Länder und Umsatzsteuerregistrierungen. Jedes einzelne Element bedeutet Konfigurationsaufwand in einem traditionellen ERP und lediglich einen Stammdatensatz in einem API-first-System.
Zählen Sie die Integrationen und prüfen Sie die API jedes angebundenen Systems vor der Vertragsunterzeichnung. Eine reine Dateischnittstelle verdoppelt den Integrationsaufwand in etwa.
Legen Sie fest, wie viel Historie migriert werden soll. Eröffnungsbilanzen plus offene Posten dauern wenige Wochen; eine vollständige mehrjährige Historie nimmt Monate in Anspruch.
Bestimmen Sie das Umstiegsdatum (Cutover) anhand des Periodenkalenders und nicht umgekehrt. Eine Jahres- oder Quartalsgrenze mit einer abgestimmten Schlussbilanz ist der kosteneffizienteste Umstieg, den es gibt.
Kalkulieren Sie für den ersten Monatsabschluss doppelt so viel Zeit wie gewöhnlich ein und planen Sie Hypercare-Ressourcen für die erste Umsatzsteuervoranmeldung sowie den ersten Lohnlauf aus dem neuen System ein.
Formulieren Sie die Abnahmetests vor Projektbeginn: die Liste aller Belege, Berichte und Meldungen, die das neue System für den ersten geschlossenen Monat korrekt ausgeben muss. Der Vorlauten-Testplan dient hierbei als nackte Vorlage für den Buchhaltungsteil.

FAQ

Kann eine ERP-Implementierung weniger als drei Monate dauern?

Ja, bei einem Unternehmen mit nur einer rechtlichen Einheit, das Standardprozesse akzeptiert, ausschließlich Eröffnungsbilanzen migriert und über ein bis zwei Integrationen verfügt. Bei einem API-first-Buchhaltungskern lässt sich der erste funktionierende Ablauf in Tagen messen; der zeitlich längste Posten ist dann meist nur noch das Datenmigrationspaket.

Welche Phase verzögert sich am häufigsten?

Die Datenmigration, gefolgt von der Integration. Beide hängen vom Zustand von Systemen ab, die außerhalb der Kontrolle des Anbieters liegen: der Qualität Ihrer Altdaten und den APIs der anzuschließenden Fremdsysteme.

Sollten wir die vollständige Historie migrieren oder nur Eröffnungsbilanzen?

Eröffnungsbilanzen und offene Posten reichen völlig aus, damit das neue System ab dem Umstiegsdatum voll funktionsfähig ist – und sie benötigen nur einen Bruchteil der Zeit. Eine vollständige Historie lohnt sich nur dann, wenn Sie im neuen System zwingend Vorjahresvergleiche benötigen oder das Altsystem vollständig abgeschaltet wird. Der Importer von Nordlet unterstützt beide Varianten.

Ist eine schrittweise Einführung (Phased Rollout) schneller als ein Big-Bang-Umstieg?

Schrittweise Einführungen dauern insgesamt länger, bergen jedoch pro Schritt ein geringeres Risiko und ermöglichen es dem Team, aus den Erfahrungen der ersten rechtlichen Einheit für die folgenden zu lernen. Ein Big-Bang-Umstieg ist dann schneller, wenn die Organisation klein genug ist, dass ein einziges Umzugs-Wochenende ausreicht.

Worin unterscheidet sich die „Implementierung“ bei einem API-first-Produkt?

Es gibt kein bildschirmbasiertes Konfigurationsprojekt. Die Arbeit besteht aus Integration und Migration, die von Entwicklern gegen eine Sandbox durchgeführt werden, während die Compliance-Ebene (Steuerregeln, Meldeformate, Kalender) direkt im Produkt enthalten ist. Der Kompromiss besteht darin, dass auf Ihrer Seite Entwicklungsarbeit geleistet werden muss.