Im DACH-Raum gibt es viele Inhalte zur Frage welches ERP. Fast alle stammen von ERP-Anbietern oder von Beratungen, die ERP einführen. Es gibt kaum vendor-neutrale Inhalte zur Frage wann. In der Praxis sehe ich folgendes Muster regelmäßig: Series A, der Beirat sagt "runter von der Cloud-Buchhaltung", jemand empfiehlt ein bekanntes ERP, der Vertrag wird unterschrieben, bevor klar ist, was eine sechs- bis zwölfmonatige Einführung für ein dreiköpfiges Finance-Team bedeutet. Achtzehn Monate und 200.000 EUR später läuft das System in Teilen, und das eigentliche Reporting hat sich nicht verbessert. Dieser Artikel zeigt, welche operativen Trigger ein ERP rechtfertigen, warum Geschäftsmodell wichtiger ist als Headcount und welche Komponenten neben dem ERP oft den größeren Hebel haben.
Warum die meisten Startups ein ERP zu früh einführen
Vier wiederkehrende Auslöser stehen hinter zu frühen ERP-Entscheidungen. Erstens: Ein neuer Investor schreibt im Term Sheet "Implementation of an ERP system within 12 months", und niemand prüft, ob das fachlich begründet ist oder nur ein Standardbaustein. Zweitens: Der erste Vollzeit-CFO kommt aus einem Konzern, ist große ERP-Umgebungen gewohnt und sucht reflexartig nach dem vertrauten Werkzeug. Drittens: Die Buchhaltung läuft in einer Cloud-Lösung, das Reporting in Excel, das Wachstum erzeugt erste Reibungspunkte, und jemand sagt, ein ERP würde "alles zusammenbringen". Viertens: Ein Vertriebsmitarbeiter eines ERP-Anbieters platziert ein zehnseitiges Angebot im Posteingang, und plötzlich gibt es einen konkreten Anlass für eine Entscheidung, die niemand strukturiert vorbereitet hat.
Das Problem dabei ist die Asymmetrie zwischen Aufwand und Reife. Eine ERP-Einführung in einem Startup mit dreißig Mitarbeitenden bindet je nach System fünf- bis sechsstellige Implementierungskosten, sechs bis achtzehn Monate interne Bandbreite und einen mehrjährigen Lizenzvertrag. Wenn das Geschäftsmodell sich danach noch verändert, und das tut es in dieser Phase fast immer, sind diese Investitionen sunk cost mit Lock-in-Effekt. Branchenanalysen zeigen ein konsistentes Bild: rund 60 bis 70 Prozent der ERP-Projekte überschreiten ihr Initialbudget, und etwa die Hälfte erreicht die ursprünglichen Business-Case-Ziele nicht vollständig. Die Hauptursachen liegen weniger im Produkt als in zu früher Auswahl, fehlender Vorbereitung und unklarer Owner-Struktur. Die saubere Reihenfolge ist umgekehrt: Erst Geschäftsmodell stabilisieren, dann Prozesse standardisieren, dann Tooling entscheiden.
Geschäftsmodell statt Headcount: wann ein ERP tatsächlich nötig wird
Die meisten Phasenmodelle für Finance-Tooling nutzen Headcount-Schwellen ("ab 50 Mitarbeitenden", "ab 100 Mitarbeitenden"). Das ist eine Vereinfachung, die in der Praxis nicht funktioniert. Ein 25-Personen-Hardware-Startup mit Lager, Stückliste und Manufacturing hat mehr ERP-Bedarf als ein 80-Personen-SaaS-Unternehmen mit zwei Verträgen pro Monat. Die belastbare Frage ist: Welche Kernprozesse muss das Tooling abbilden?
| Geschäftsmodell | Typischer ERP-Bedarf | Wann am ehesten |
|---|---|---|
| SaaS / Software | Oft minimal, Cloud-Buchhaltung plus BI (Business Intelligence) plus Subscription-Billing (Abonnement-Abrechnung) reicht lange | Series B+ oder gar nicht |
| E-Commerce / D2C (Direct-to-Consumer) | Auftragsabwicklung, Lager, Multi-Channel-Sync | Sobald >2 Lager oder >100 SKUs (Stock Keeping Units) |
| Hardware / Manufacturing | Stücklisten und Produktionsplanung (BOM, Bill of Materials), Beschaffung; oft kombiniert mit PLM/PDM (Product Lifecycle/Data Management) | Fast immer früh, oft schon ab Seed |
| Projektgeschäft (Engineering, Anlagenbau / EPC) | Project-P&L, Backlog, Multi-Project-Allokation | Light-ERP ab Series A, Mid-Market ab ~80 Mitarbeitenden |
| Multi-Entity-Holding | Konsolidierung, Intercompany, Mehrwährung | Ab zweiter Tochtergesellschaft |
| Marketplace / Plattform | Eigene Plattform, ERP nur für FiBu-Backbone (Finanzbuchhaltungs-Kern) | Selten klassisches ERP |
Headcount korreliert mit Komplexität, ist aber kein verlässlicher Trigger. Hardware-Startups brauchen oft schon mit 15 bis 25 Mitarbeitenden ein ERP, weil die Stückliste und die Beschaffungslogik in keiner Cloud-Buchhaltung sauber abgebildet werden können. SaaS-Unternehmen kommen umgekehrt mit 100 Mitarbeitenden noch ohne ERP aus, solange Subscription-Billing, Buchhaltung und BI sauber integriert sind. Die Frage "welcher Stack passt" beginnt mit dem Geschäftsmodell, nicht mit der Mitarbeitendenzahl.
Die operativen Symptome, die einen ERP-Schritt rechtfertigen
Statt Headcount oder Funding-Stage hilft ein Symptom-Check. Wenn drei oder mehr der folgenden Punkte zutreffen, ist die Diskussion über ein integriertes System fachlich begründet:
- Monatsabschluss benötigt regelmäßig mehr als fünfzehn Werktage, ohne dass dies durch Personalwechsel oder Sondereffekte erklärbar ist.
- Konsolidierung mehrerer Entities lebt in einem einzigen Spreadsheet, das nur eine Person versteht und das bei Krankheit oder Kündigung zum Engpass wird.
- Mehrwährungs-Buchhaltung wird manuell gepflegt, mit Wechselkurs-Updates über Copy-Paste und ohne automatische Bewertung am Bilanzstichtag.
- Lagerwirtschaft mit mehr als 100 SKUs oder mehreren Standorten wird über Excel oder eine reine Auftragsabwicklungs-Software geführt, ohne integrierte Bestandsbewertung.
- Stücklisten- oder Produktionsplanung ist relevant, lebt aber außerhalb des Buchhaltungs-Flows, mit manuellem Übertrag in die FiBu.
- Project-P&L für mehr als fünfzehn parallele Projekte wird in Tabellen geführt, mit nachträglicher Allokation von Kosten auf Projekte.
- Audit oder Wirtschaftsprüfung verlangt Kontrollen, die das aktuelle Setup nicht systematisch abbildet (Belegzwang, Mehraugenprinzip, Genehmigungsworkflows).
- Investor-Reporting auf Konzernebene erzeugt jeden Monat manuelle Aggregation, die Stunden statt Minuten kostet.
Wer keines oder nur eins dieser Symptome hat, braucht in der Regel kein ERP. Wer drei oder mehr hat, sollte den Schritt strukturiert vorbereiten. Wer weniger als drei hat, aber bereits unter Vendor-Druck steht, sollte zwölf Monate warten und prüfen, ob die Symptome durch Prozess-Standardisierung oder gezielte Best-of-Breed-Tools gelöst werden können.
Was im Stack neben dem ERP zählt: meist der größere Hebel
Ein ERP ist selten der Engpass im Finance-Tech-Stack. Häufiger sind die folgenden Komponenten ausschlaggebend für die Qualität der Finanzfunktion:
| Komponente | Funktion |
|---|---|
| Buchhaltung / Finanzbuchhaltung (FiBu) | Belegfluss, Buchungen, Steuer-Compliance, DATEV-Schnittstelle |
| Cash-Steuerung / Runway | Liquiditäts-Forecast, Burn-Tracking, einfaches Cash-Reporting |
| BI / Reporting | Datenkonsolidierung, Dashboards, Investor-Reporting |
| FP&A (Financial Planning & Analysis) / Forecasting | Modellbau, Szenarien, rollierender Forecast |
| Spend Management | Karten, Spesen, Genehmigungen, Pflichtfeld Projekt |
| Cap Table / VSOP (Virtuelles Mitarbeiterbeteiligungsprogramm) | Beteiligungen, Mitarbeiter-Programme, Verwässerungs-Modelle |
| Banking-API | Echtzeit-Liquidität, automatisierte Buchungsfreigaben |
| Vertragsmanagement | Strukturierte Vertragsablage, Erinnerungen, automatische Verlängerungen |
In der Frühphase (Pre-Seed bis Series A) ist Cash-Steuerung oft die erste Komponente, die nach der Buchhaltung dazukommt. Wer mit zwölf bis achtzehn Monaten Runway operiert, braucht ein verlässliches Liquiditäts-Modell mit Banksaldo, fixen und variablen Cash-Outs und realistischen Erlös-Annahmen. In den allermeisten Fällen reicht zu Beginn ein gut gepflegtes Spreadsheet, das wöchentlich aktualisiert wird. Mit steigender Komplexität (Mehrkonten-Struktur, Mehrwährung, mehrere Entities) lohnt sich der Schritt zu einem Cash-Forecasting-Tool, das Banking-Daten und Buchhaltungs-Daten automatisch zieht.
Gezielte Investitionen in Cash-Steuerung, BI-Tool, FP&A und Spend-Management bringen in den meisten Series-A- bis Series-B-Phasen mehr operativen Hebel als eine vorgezogene ERP-Einführung. Voraussetzung: Die Buchhaltung ist sauber digitalisiert, die Schnittstellen funktionieren, die Daten sind belastbar. Wer die Reihenfolge umkehrt und zuerst das ERP einführt, baut häufig genau die Strukturen auf, die er eigentlich vermeiden wollte: ein integriertes System ohne integriertes Reporting.
Die DATEV-Frage als DACH-Killer-Kriterium
Im DACH-Markt entscheidet die DATEV-Schnittstellen-Frage darüber, ob ein ERP funktioniert oder nicht. DATEV dominiert den deutschen Steuerberater-Markt. Wer einen Steuerberater hat, hat in der Regel auch DATEV im Datenstrom. Wer ein ERP einführt, muss diese Anbindung mitdenken, sonst entsteht entweder Doppelarbeit oder ein Steuerberater-Wechsel.
Wichtig zur Einordnung: DATEV ist kein ERP, sondern eine dominante Buchhaltungs- und Steuer-Plattform mit ergänzendem Tool-Marktplatz. Klassische ERP-Systeme integrieren Buchhaltung als Teilmodul und ergänzen sie um operative Prozesse wie Beschaffung, Lager, Produktion, Vertrieb. Die richtige Architektur ist Co-Existenz statt Ablösung: Das ERP wird operatives Backbone, DATEV bleibt FiBu-Layer und Schnittstelle zum Steuerberater. Buchungsdaten fließen aus dem ERP nach DATEV, der Steuerberater arbeitet weiter in seiner gewohnten Umgebung.
Konkret heißt das für die ERP-Auswahl: Eine zertifizierte DATEV-Schnittstelle ist Pflichtkriterium, kein Nice-to-have. ERP-Lösungen ohne native Anbindung erzeugen entweder Drittanbieter-Module mit Wartungsaufwand und Sicherheitsrisiken oder einen kompletten Steuerberater-Wechsel. Beides ist teurer als der vermeintliche Mehrpreis eines DATEV-fähigen ERP.
GoBD-Konformität als zweites DACH-Pflichtkriterium
Neben der DATEV-Schnittstelle gibt es eine zweite verbindliche DACH-Anforderung an jedes ERP: GoBD-Konformität. Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff wurden vom BMF zuletzt im Juli 2025 aktualisiert, ausgelöst durch die Pflicht zur elektronischen Rechnung (E-Rechnung) im B2B-Bereich seit Januar 2025. Sie definieren, wie IT-gestützte Buchführung in Deutschland aussehen muss. Anders als die DATEV-Schnittstelle ist GoBD-Konformität nicht verhandelbar: Verstöße können in einer Betriebsprüfung zur Verwerfung der Buchführung oder zu steuerlichen Schätzungen führen.
Sechs Kernanforderungen müssen erfüllt sein: Nachvollziehbarkeit jeder Buchung mit Belegnachweis, Vollständigkeit aller Geschäftsvorfälle, Richtigkeit der Erfassung, Zeitgerechtigkeit der Buchung, Ordnung der Ablage und Unveränderbarkeit einmal gebuchter Sätze. Hinzu kommt die Pflicht zu einer Verfahrensdokumentation, die beschreibt, wie die Buchhaltungs-Prozesse im Unternehmen organisiert sind, sowie zu einem internen Kontrollsystem (IKS), das Fehlbuchungen verhindern und nachweisbar machen soll.
Konsequenz für die ERP-Auswahl: Internationale Systeme ohne explizite GoBD-Konformität sind im DACH-Markt ein Compliance-Risiko, kein Komfort-Defizit. Wer ein nicht-konformes System einführt, übernimmt das Risiko, dass eine Betriebsprüfung Daten oder Strukturen beanstandet. Im Vendor-Gespräch sollte der Nachweis der GoBD-Konformität angefragt und im Vertrag verankert werden, idealerweise inklusive Verpflichtung zur Anpassung an künftige BMF-Aktualisierungen. Auch die Verfahrensdokumentation gehört in das Implementierungs-Projekt, nicht in eine spätere Pflicht-Übung kurz vor der Betriebsprüfung.
Das Phasenmodell als sekundärer Anhalt
Wenn das Geschäftsmodell stimmt und die operativen Symptome zutreffen, hilft das klassische Phasenmodell als Orientierung für die Tooling-Klasse. Headcount-Bandbreiten sind grobe Richtwerte, nicht Schwellen.
Phase 1: Cloud-Buchhaltung (typisch 1 bis 30 Mitarbeitende)
Setup: Cloud-Buchhaltung in Verbindung mit dem Steuerberater. Reporting in Excel oder Google Sheets, ergänzt um ein BI-Tool, sobald Daten aus mehreren Quellen zusammengeführt werden. Banking-Anbindung über die Buchhaltungssoftware oder direkte API-Integration. Diese Phase deckt die Bedürfnisse fast aller DACH-SaaS-Startups bis Series A vollständig ab. Hardware- und projektbasierte Geschäfte verlassen diese Phase oft früher.
Phase 2: Light-ERP (typisch 30 bis 80 Mitarbeitende)
Setup: ein Light-ERP mit Cloud-Architektur und API-First-Logik. Diese Systeme decken Auftragsabwicklung, Lagerverwaltung, einfache Produktion und Schnittstellen zur Buchhaltung ab, ohne die Komplexität klassischer Enterprise-ERPs. Sie eignen sich für E-Commerce, Hardware-Startups, kleinere B2B-Vertriebsorganisationen und projektgetriebene Geschäfte mittlerer Komplexität. Die Buchhaltung läuft weiterhin parallel in DATEV oder einer Cloud-Lösung. Implementierungsdauer typischerweise drei bis sechs Monate, Implementierungskosten 30.000 bis 150.000 EUR.
Phase 3: Mid-Market-ERP (typisch 80 bis 250 Mitarbeitende)
Setup: ein Mid-Market-ERP mit DATEV-Schnittstelle und Anpassungs-Spielraum. Diese Systeme decken Finanzbuchhaltung, Anlagenbuchhaltung, Konsolidierung kleinerer Tochtergesellschaften, Projektabrechnung, fortgeschrittene Lagerwirtschaft und Multi-Currency-Themen ab. Implementierung typischerweise sechs bis zwölf Monate, Kosten 200.000 bis 800.000 EUR plus laufende Lizenzen. Hier lohnt sich erstmals der Sprung weg von Cloud-Buchhaltung in eine integrierte Lösung. Voraussetzung: stabile Prozesse, klare Anforderungen, dedizierte interne Ressourcen für die Implementierung.
Phase 4: Enterprise-ERP (typisch 250+ Mitarbeitende)
Setup: ein Enterprise-ERP der großen Anbieter. Diese Systeme sind für komplexe Konzernstrukturen, internationale Organisationen, mehrere Geschäftsbereiche und regulatorisch anspruchsvolle Branchen gebaut. Implementierungsdauer ein bis drei Jahre, Kosten oft im Millionenbereich. Im Startup-Kontext ist diese Phase fast immer durch eine Übernahme, einen IPO oder einen größeren strategischen Investor getrieben. Wer ohne diese Trigger ein Enterprise-ERP plant, bekommt mit hoher Wahrscheinlichkeit ein Werkzeug, das er nicht braucht.
Was ein ERP tatsächlich kostet: die unterschätzten Posten
Die Lizenzkosten sind im DACH-Markt selten das Hauptproblem. Vier Kostenblöcke werden regelmäßig unterschätzt:
- Implementierung und Discovery: Bei Mid-Market-ERPs typischerweise das Zwei- bis Dreifache der ersten Lizenzgebühren (DACH-Faustregel: 1 EUR Lizenz zu 2,5 EUR Implementierung). Bei umfangreichem Customizing kann das auf das Fünf- bis Zehnfache steigen. Solution Architecture und Discovery-Phase werden in Erst-Angeboten oft unterschlagen, machen aber 20 bis 30 Prozent des Gesamtbudgets aus.
- Interne Bandbreite: Sechs bis achtzehn Monate Vollzeit-Aufwand des Finance-Teams plus Beteiligung von Operations, IT und Geschäftsführung. In dieser Zeit fällt das Finance-Team zu zwanzig bis dreißig Prozent für strategische Arbeit aus. Diese Kosten tauchen in keinem Vendor-Angebot auf.
- Integrations-Tax: Jedes bestehende Tool (Banking, Personalsystem, BI, Spend, Time-Tracking) braucht eine Anbindung. Pro Schnittstelle 5.000 bis 30.000 EUR plus laufende Wartung. Wer fünf bis zehn Tools angebunden hat, summiert hier sechsstellige Beträge.
- Scope Creep: Der häufigste Treiber für Budget- und Timeline-Überschreitungen. "Ein zusätzlicher Report hier, ein zusätzlicher Workflow dort" und das Projekt wächst um dreißig bis fünfzig Prozent gegenüber dem Erstangebot. Branchenstudien identifizieren Scope Creep als Hauptursache, dass etwa zwei Drittel aller ERP-Projekte als problematisch eingestuft werden.
Hinzu kommen Migrationsverluste während der Einführung (Reporting-Qualität sinkt typisch für drei bis sechs Monate) und Lock-in über die Vertragsmindestlaufzeit. Eine zu früh getroffene Entscheidung wirkt fünf bis zehn Jahre, weil Daten, Anpassungen und Schulungen nach dieser Zeit kaum noch rückbaubar sind. Realistisch betrachtet machen Lizenzgebühren über fünf bis sieben Jahre nur etwa 20 bis 35 Prozent des Total Cost of Ownership (TCO) aus. Der Rest entfällt auf Implementierung, interne Aufwände, Schulung, Customizing, Schnittstellen, Hosting und Wartung. In Summe liegt der TCO über sieben Jahre häufig beim Drei- bis Vierfachen des Erst-Angebots.
Lock-in-Mechaniken: was die Stack-Flexibilität langfristig bestimmt
Eine ERP-Entscheidung bindet das Unternehmen typisch fünf bis zehn Jahre. Über diesen Zeitraum entscheiden weniger die im Sales-Pitch betonten Funktionen, sondern strukturelle Eigenschaften der Lösung über Stack-Flexibilität und Total Cost of Ownership. Vier Punkte, die selten in Vendor-Gesprächen explizit werden:
- Pricing nach Umsatz, nicht nach Value: Große ERP-Anbieter modellieren ihre Preise oft nicht nach gelieferten Funktionen, sondern nach erwartetem Umsatz des Kunden, mit der impliziten Annahme, dass eine Branche bei einer bestimmten Größe einen bestimmten Anteil an IT-Budget hat. Verhandlungen sind möglich, gehen aber selten unter den "Marktanteil" des Vendors am Kunden-IT-Budget. Konsequenz für den Stack: Lizenzkosten skalieren mit Umsatz und Headcount, nicht mit Nutzwert.
- API-First als unverzichtbares Kriterium: Ein ERP ohne offene, dokumentierte und stabile API ist heute keine Option mehr. APIs sind die Grundlage für Automatisierung, Integration in den restlichen Stack und KI-gestützte Workflows. Geschlossene Systeme bauen Lock-in auf, der nach drei bis fünf Jahren teurer ist als die ursprüngliche Einführung. Wer hier kompromisst, schließt damit auch die Tür zu zukünftigen Stack-Komponenten, die noch gar nicht existieren.
- Konfiguration vs. Customizing: Was als "Konfiguration" verkauft wird, ist häufig Customizing mit eigenem Wartungs-Risiko. Jede Anpassung am Standard erschwert spätere Updates und Migrationen. Faustregel: Standard nutzen wo möglich, Customizing nur wenn der Wettbewerbsvorteil dokumentiert ist und das Wartungs-Risiko explizit eingepreist wurde. Modifikationen am Kern-Code (statt sauberer API-Erweiterung) sind ein No-Go, weil sie zukünftige Major-Upgrades zu mehrwöchigen Projekten machen.
- Vertragsmindestlaufzeiten und Datenexport: Drei bis fünf Jahre Mindestlaufzeit ist DACH-Standard, automatische Verlängerung um zwölf Monate ebenso. Wer hier nicht aktiv kündigt, sitzt fest. Beim Vertragsabschluss klären, mit welcher Frist gekündigt werden kann und welche Datenexport-Optionen vertraglich zugesichert sind. Datenexport im offenen Format ist nicht Komfort, sondern Voraussetzung für Stack-Flexibilität.
Diese Mechaniken bestimmen, wie offen der Stack in fünf Jahren noch ist. ERP-Entscheidungen werden selten bereut, weil das System nicht funktioniert, sondern weil es zu früh gewählt oder zu stark angepasst wurde.
Decision-Framework: drei Bedingungen für den ERP-Schritt
Ein ERP-Schritt ist gerechtfertigt, wenn drei Bedingungen gleichzeitig erfüllt sind:
- Geschäftsmodell stabilisiert. Die Kernprozesse (Vertriebslogik, Erlösmodell, Lieferketten, Kostenstrukturen) werden in den nächsten zwei Jahren strukturell nicht mehr neu erfunden. Wer noch im Pivot-Modus ist, baut ein ERP für ein Geschäft, das es bald nicht mehr gibt.
- Operative Komplexität rechtfertigt das integrierte System. Mindestens drei der oben genannten Symptome treffen zu (Multi-Entity, Mehrwährung, BOM, Project-P&L, lange Monatsabschlüsse, Audit-Anforderungen, Investor-Reporting-Aufwand). Headcount allein reicht nicht.
- Interner Owner mit Kapazität und fachlicher Tiefe. Eine Person trägt die fachliche Verantwortung, hat dafür Zeit (mindestens 50 Prozent der Arbeitszeit über die Implementierungs-Phase) und versteht sowohl das Geschäft als auch die ERP-Logik. Ohne diesen Owner scheitern ERP-Einführungen fast immer, unabhängig vom Vendor.
Wenn eine dieser Bedingungen fehlt, ist das Startup für ein ERP zu früh dran. Die saubere Reaktion ist nicht, das ERP trotzdem einzuführen, sondern die fehlende Bedingung gezielt aufzubauen: Geschäftsmodell stabilisieren, Symptome dokumentieren, Owner suchen oder einstellen. Das dauert sechs bis achtzehn Monate und zahlt sich als Vorbereitung mehr aus als jede vorgezogene ERP-Einführung.
Fazit
Die wichtigste Entscheidung im Finance-Tech-Stack ist nicht welches ERP, sondern wann überhaupt. Wer in den frühen Phasen mit einer sauberen Cloud-Buchhaltung, einem belastbaren BI-Layer und einem strukturierten Spend-Management arbeitet, hat fast immer mehr operativen Hebel als ein Startup, das gleichzeitig ein ERP einführt. Der Sprung ins ERP rechtfertigt sich, wenn das Geschäftsmodell stabilisiert ist, mindestens drei operative Symptome zutreffen und ein interner Owner mit Kapazität bereitsteht. Bis dahin gilt: Tooling folgt dem Geschäft, nicht umgekehrt. Und in DACH gilt zusätzlich: ERP-Auswahl ohne DATEV-Schnittstellen-Logik ist eine Auswahl ohne den wichtigsten Filter.