Warum ERP-Implementierungen scheitern – und warum eine API die Chancen verbessert

Sieben Fehlerbilder, die sich in ERP-Projekten wiederholen, die jeweilige Gegenmaßnahme und eine sachliche Bestandsaufnahme darüber, welche dieser Hürden ein API-first-Buchhaltungskern direkt abräumt.

ERP-Implementierungen scheitern aus einer überschaubaren Liste von Gründen, die sich von Projekt zu Projekt wiederholen: ein stetig wachsender Projektumfang, Customizing, das den Standardprozess ersetzt, unbereinigte Stammdaten, fehlende Entscheidungskompetenz, ein einzelnes Go-Live-Wochenende ohne Rückfalloption, die Abhängigkeit von der Roadmap eines einzigen Anbieters sowie erst nach dem Go-Live entdeckte Steuer- oder Meldepflichten. Nichts davon ist im engeren Sinne ein technisches Problem. Jedes dieser Probleme ist das Resultat einer Entscheidung, die vor der Konfiguration des ersten Bildschirms getroffen (oder versäumt) wurde.

Dieser Artikel geht diese Ursachen nacheinander durch und zeigt jeweils die richtige Vorgehensweise auf. Anschließend wird ein konkretes, begrenztes Argument vorgebracht: Wenn der Buchhaltungskern des Systems eine API ist, in die Ihre eigene Software integriert wird, entfallen einige dieser Ursachen im Projekt gänzlich, da die damit verbundenen Arbeiten schlicht nicht mehr existieren.

Die wiederkehrenden Ursachen

1. Ein Umfang, der sich erst im Projektverlauf zeigt, statt im Vorfeld festgelegt zu werden

Ein Projekt, das für „Finanzwesen und Bestandsführung“ unterzeichnet wurde, absorbiert plötzlich auch noch Einkaufsfreigaben, Projektkostenrechnung, ein Kundenportal und eine Berichtsschicht, weil jede dieser Komponenten „ja fast dasselbe ist“. Budget und Zeitplan waren jedoch auf den ursprünglichen Umfang ausgelegt.

Stattdessen gilt: Erstellen Sie zu Beginn eine Liste der Abnahmekriterien. Die Liste der Dokumente, Berichte und Meldungen, die das neue System für einen abgeschlossenen Monat fehlerfrei ausgeben muss, definiert den Projektumfang. Alles, was nicht darauf steht, ist ein Folgeprojekt.

2. Customizing, das das alte System detailgetreu nachbaut

Der teuerste Satz in einem ERP-Projekt lautet: „Das neue System muss es genau so machen wie bisher.“ Jedes Customizing muss spezifiziert, entwickelt, getestet, dokumentiert und bei jedem Update erneut geprüft werden. Projekte, die damit beginnen, die alten Bildschirmmasken zu replizieren, schließen diese Replikation meist nie ab.

Stattdessen gilt: Akzeptieren Sie den Standardprozess des Anbieters für jeden Ablauf, in dem sich Ihr Unternehmen nicht fundamental unterscheidet, und führen Sie eine schriftliche Liste der Ausnahmen samt Begründung. Ist diese Liste zu lang, stimmt das Produkt nicht – nicht die Konfiguration.

3. Unbereinigte Stammdaten

Doppelte Debitoren und Kreditoren, Artikel ohne Mengeneinheiten, ein Kontenrahmen mit Hunderten ruhender Konten, offene Rechnungen, die vor Jahren beglichen, aber nie ausgeglichen wurden. Eine Datenmigration kann nicht schneller laufen als die Datenbereinigung – und diese wird von denselben Mitarbeitern durchgeführt, die auch den Monatsabschluss stemmen müssen.

Stattdessen gilt: Bereinigen Sie die Daten, bevor das Projekt beginnt. Entscheiden Sie, ob die vollständige Historie oder ob Eröffnungsbilanzen plus offene Posten migriert werden sollen. Validieren Sie das Migrationspaket so lange, bis es fehlerfrei durchläuft, bevor auch nur eine einzige Zeile in das neue System geschrieben wird.

4. Fehlende Prozessverantwortung

Wenn jede Entscheidung an einen Lenkungsausschuss (Steering Committee) verwiesen wird, dauert es Wochen. Wenn niemand den Order-to-Cash-Prozess von Anfang bis Ende verantwortet, werden das Vertriebs- und das Forderungsmodul von verschiedenen Personen mit unterschiedlichen Annahmen konfiguriert.

Stattdessen gilt: Ein benannter Verantwortlicher pro Prozess mit echter Entscheidungskompetenz sowie ein wöchentliches Entscheidungsprotokoll, nach dem sowohl der Anbieter als auch das Team arbeiten.

5. Big-Bang-Go-Live ohne Rückfalloption

Die Umstellung sämtlicher Entitäten und Module an einem einzigen Wochenende bündelt das gesamte Risiko in einem Moment. Schlägt der erste Monatsabschluss fehl, gibt es weder ein Altsystem zum Ausweichen noch einen phasenweisen Rollout, aus dem man lernen könnte.

Stattdessen gilt: Stellen Sie zum Periodenwechsel mit einer abgestimmten Summen- und Saldenliste um, halten Sie das Altsystem lesend verfügbar und führen Sie das System bei mehreren Betriebsstätten schrittweise ein.

6. Vendor Lock-in, der sich im dritten Jahr rächt

Datenexporte, die einen kostenpflichtigen Professional-Services-Einsatz erfordern, Integrationen, die ausschließlich über die proprietäre Middleware des Anbieters funktionieren, sowie eine nutzerbasierte Preisgestaltung, die eher mit der Personaldecke als mit der tatsächlich erbrachten Arbeitsleistung wächst und eine Roadmap, auf die Sie keinen Einfluss haben. Nichts davon ist bei Vertragsunterzeichnung sichtbar; alles davon zeigt sich bei der Verlängerung.

Stattdessen gilt: Exportieren Sie vor der Vertragsunterzeichnung sämtliche Daten aus einer Testumgebung (Tenant) und prüfen Sie, was tatsächlich herauskommt. Überprüfen Sie, ob die API jeden Vorgang abdeckt, den die Benutzeroberfläche bedienen kann, oder nur eine Teilmenge. Lesen Sie die Preistabelle für die nächste Tarifstufe, nicht nur für die, die Sie aktuell erwerben.

7. Compliance-Anforderungen, die erst nach dem Go-Live auffallen

Eine neue USt-IdNr. in einem anderen EU-Mitgliedstaat, eine E-Invoicing-Pflicht, die im kommenden Januar greift, oder ein vom lokalen Finanzamt geändertes Meldeformat. Bei einem traditionellen Projekt bedeutet dies entweder den teuren Einsatz von Dienstleistern oder Individualentwicklung – und jede Anforderung trifft nach ihrem eigenen Zeitplan ein.

Stattdessen gilt: Listen Sie vor der Softwareauswahl sämtliche Meldepflichten und Umsatzsteuerregime auf, denen das Unternehmen je Land unterliegt, und lassen Sie sich vom Anbieter für jeden Punkt die generierte Beispieldatei in einer Testumgebung vorzeigen. „Unterstützt Land X“ ist eine Marketingbehauptung; eine fehlerfreie steuerliche Auswertung ist der Beleg.

Was eine API verändert

Das hier vertretene Argument ist präzise gefasst. Ein API-first-Buchhaltungskern macht ein ERP-Projekt nicht automatisch erfolgreich. Er entfernt jedoch bestimmte Arbeitspakete aus dem Projekt, und die damit verbundenen Fehlerrisiken entfallen automatisch. Die folgenden Punkte beschreiben die tatsächliche Funktionsweise von Nordlet im aktuellen Produktstatus.

Die Integration wird vor Vertragsabschluss getestet. Eine Sandbox-Unternehmung wird über einen einzigen API-Aufruf erstellt, verhält sich exakt wie ein reales Unternehmen mit denselben Modulen und Endpunkten und wird auf Basis des tatsächlichen Nutzungsvolumens berechnet. Der Pre-Production-Testplan ist ein reproduzierbarer Test und keine Verkaufsdemo. Wenn die Integration in der Sandbox nicht funktioniert, wissen Sie das vor jeder vertraglichen Bindung – genau umgekehrt zu einer klassischen Implementierung, bei der die Integration erst die vorletzte Phase bildet.

Wiederholte Aufrufe (Retries) erzeugen keine Duplikate. Jeder schreibende API-Aufruf erfordert einen Idempotency-Key-Header. Derselbe Schlüssel mit demselben Payload gibt die gespeicherte Antwort zurück; derselbe Schlüssel mit einem abweichenden Payload wird mit dem Fehler idempotency_key_reuse abgelehnt. Eine ganze Klasse von Integrationsfehlern – wie etwa doppelte Rechnungen nach einem Netzwerk-Timeout – kann schlicht nicht auftreten und muss daher auch nicht während der Betreuungsphase (Hypercare) aufgespürt werden. Die Mechanismen dazu werden im Glossareintrag zur Idempotenz erläutert.

Ereignisse ersetzen Batch-Synchronisationen. Webhooks werden in derselben Datenbanktransaktion wie die eigentliche Änderung in eine transaktionale Outbox geschrieben. Ein zurückgerolltes Dokument löst niemals ein Event aus, und kein Event geht verloren. Ihr System reagiert auf sale_invoice.paid, exakt in dem Moment, in dem es passiert; nächtliche Dateisynchronisationen und komplexe Abgleichlogiken entfallen vollständig.

Das Hauptbuch fängt Integrationsfehler für Sie ab. Die Datenbank lehnt einen nicht ausgeglichenen Buchungssatz ab. Eine gebuchte Transaktion wird nicht nachträglich bearbeitet; Korrekturen erfolgen ausschließlich über Stornobuchungen, die mit dem Original verknüpft sind. Buchungen in eine gesperrte Periode werden mit dem Status 409 abgelehnt. Diese Restriktionen machen die Funktionsweise eines unveränderlichen Hauptbuchs (Immutable Ledger) in der Praxis aus. Sie verwandeln unbemerkte Datenfehler in der Entwicklungsphase in eindeutige, sofort sichtbare API-Fehler.

Umsatzsteuerregeln und Meldeformate liegen in der Verantwortung des Anbieters, nicht in Ihrem Customizing. Die EU-Umsatzsteuer-Engine ermittelt den Ort der Lieferung bzw. Leistung, Reverse-Charge, OSS, IOSS sowie die Reihengeschäfts- und Dreiecksreglungen und liefert zu jeder Antwort die entsprechende Rechtsgrundlage mit. Meldeformate für 30 Länder sind direkt im Produkt hinterlegt; die Übersicht zur Unterstützung von Meldungen zeigt für jede Frist an, ob Nordlet die Datei direkt übermittelt, für den Upload aufbereitet oder die Kennzahlen zur manuellen Erfassung bereitstellt. Ändert sich ein Format, wird die Anpassung als Produktupdate für alle Unternehmen ausgespielt. Solche Produktänderungen sind im Changelog dokumentiert. Eine erst nach dem Go-Live entdeckte Compliance-Anforderung (Ursache 7) wird damit zu einer Frage, die Sie bereits vor der Auswahl anhand einer öffentlichen Dokumentation beantworten können.

Die Preisgestaltung ist unabhängig von der Nutzeranzahl. Die Tarife basieren auf einem verbrauchsabhängigen Modell (Metered by Request). Jedes Modul und der vollständige API-Zugriff sind in jedem Tarif enthalten – bei unbegrenzter Anzahl von Nutzern und Unternehmen. Die Kosten steigen mit dem tatsächlichen Arbeitsvolumen des Systems, nicht mit der Zahl der Anwender, und es gibt keine künstlichen Feature-Stufen, in die später migriert werden muss. Dies adressiert einen Aspekt des Vendor Lock-ins (Ursache 6), während die verbleibenden Punkte im nächsten Abschnitt beleuchtet werden.

Daten kommen im selben Format heraus, wie sie hineingegangen sind. Berichte werden als XLSX, PDF oder JSON generiert. Für die jeweiligen Länder stehen Hauptbuchausschnitte in den Formaten DATEV, FEC und SIE zur Verfügung. Die Web-App verwendet keine versteckten privaten Endpunkte – alles, was Sie auf einem Bildschirm sehen, können Sie auch über die API abrufen. Der Exporttest aus Ursache 6 lässt sich somit am ersten Tag in der Sandbox durchführen.

Was eine API nicht verändert

Stammdaten müssen nach wie vor von Ihnen bereinigt werden. Der Migration-Importer validiert und verweigert fehlerhafte Pakete, er korrigiert sie jedoch nicht.
Prozessverantwortung bleibt eine organisatorische Personalentscheidung. Eine API verkleinert die Frage „Wer entscheidet?“, da es weniger zu konfigurieren gibt, aber sie nimmt Ihnen die Entscheidung nicht ab.
Irgendjemand muss Code schreiben. Das Konfigurationsprojekt wird durch ein Integrationsprojekt ersetzt, das von Entwicklern durchgeführt werden muss. Wenn Ihr Team über keine Entwickler verfügt, verschiebt diese Produktform die Arbeit, statt sie wegzulassen.
Projektumfang außerhalb des Rechnungswesens bleibt zusätzlicher Umfang. Lagersteuerung, Produktionsplanung und ein CRM über die Lead-Phase hinaus sind entweder separate Nordlet-Module, die auf dieselbe Weise integriert werden, oder eigenständige Nachbarsysteme – und die Integration zwischen diesen Systemen bleibt Ihr Projekt.
Reifegrad des Anbieters. Nordlet befindet sich 2026 in der Early-Access-Phase und betreut ausgewählte Design-Partner. Ein junger Anbieter stellt einen Risikofaktor dar, den auch ein Sandbox-Test nicht eliminiert; er macht lediglich den aktuellen Stand des Produkts messbar.

Eine kurze Checkliste vor der Vertragsunterzeichnung

Erstellen Sie die Abnahmeliste: Dokumente, Berichte und Meldungen für einen abgeschlossenen Monat.
Bereinigen Sie die Stammdaten und klären Sie die Frage der Historie, bevor das Projekt startet.
Benennen Sie genau einen Verantwortlichen pro Prozess.
Führen Sie die Integration in einer Sandbox aus und bewahren Sie die Testsuite auf.
Exportieren Sie alle Daten aus dem Test-Tenant und prüfen Sie die Dateien.
Lassen Sie sich für jedes Land die generierte Meldung zeigen, nicht nur die Feature-Liste.
Prüfen Sie die Kosten der nächsthöheren Tarifstufe sowie die Kosten für einen potenziellen Ausstieg.

FAQ

Was ist der häufigste Grund für das Scheitern von ERP-Projekten?

Ein Projektumfang, der nach der Fixierung von Budget und Zeitplan wächst – meist durch Customizing-Anforderungen, die das alte System exakt nachbauen sollen. Die Datenqualität belegt direkt den zweiten Platz und ist die häufigste Ursache für verschobene Go-Live-Termine.

Verhindert die Wahl eines Cloud-ERP diese Fehlschläge?

Das Hosting ändert lediglich, wer die Server betreibt. Es ändert nichts an Projektumfang, Customizing, Datenqualität oder Prozessverantwortung. Cloud-Produkte sorgen allerdings dafür, dass Software-Updates in die Verantwortung des Anbieters übergehen, wodurch langfristige Customizing-Folgekosten entfallen.

Wie reduziert ein API-first-System das Implementierungsrisiko?

Es verlagert die Integration an den Anfang des Projekts, wo sie vor jeder Bindung in einer Sandbox getestet werden kann, macht Wiederholungen und Events von Natur aus fehlerfrei und liefert Steuervorschriften sowie Meldeformate als Produktfeatures statt als Projekt-Customizing aus. Es bereinigt jedoch weder Ihre Daten noch legt es Ihre Prozesse fest.

Ist ein API-first-Buchhaltungskern ein ERP?

Er bildet den finanziellen Kern eines ERP-Systems: Hauptbuch, Belege, Bank, Steuer, Meldungen – und im Falle von Nordlet zusätzlich Bestandsführung, Produktion, Gehaltsabrechnung, Anlagevermögen und E-Commerce-Bestellungen. Der Artikel zum Thema SaaS-ERP beleuchtet diese Unterscheidung im Detail.

Was sollten wir in der Sandbox testen?

Erstellen Sie eine Rechnung und lesen Sie den Buchungssatz aus. Senden Sie dieselbe Anfrage zweimal und zählen Sie die resultierenden Rechnungen. Buchen Sie in eine gesperrte Periode und prüfen Sie, ob der Fehlercode 409 zurückgegeben wird. Stellen Sie eine Gutschrift aus und prüfen Sie die Stornierung. Generieren Sie die Umsatzsteuervoranmeldung für das Land der Sandbox-Unternehmung. Exportieren Sie das Hauptbuch. Wenn diese Tests erfolgreich durchlaufen, funktioniert der Buchhaltungskern; das verbleibende Risiko liegt nun ausschließlich in Ihren Daten und den angebundenen Fremdsystemen.