Wie ERP-Systeme funktionieren: Module, Datenfluss und das Hauptbuch im Hintergrund
Eine Transaktion durchläuft jedes Modul eines ERPs – inklusive der tatsächlichen Buchungssätze und einer Erklärung, warum das Hauptbuch die zentrale Datenquelle darstellt, auf die sich alles stützt.
Ein ERP-System funktioniert, indem es jedes geschäftliche Ereignis einmal in einer einzigen Datenbank speichert und jedes Modul auf diesen gemeinsamen Datensatz zugreifen lässt – sowohl lesend als auch schreibend. Eine versendete Bestellung ist exakt derselbe Datensatz, unabhängig davon, ob das Lager, das Vertriebsteam oder die Buchhaltung darauf zugreift. Das Modul, das die Integrität des gesamten Systems sicherstellt, ist das Hauptbuch (general ledger): Jedes Ereignis mit einem Geldwert mündet dort in einem ausgeglichenen Buchungssatz (journal entry), und sämtliche Berichte werden aus diesen Buchungen abgeleitet.
Dieser Artikel verfolgt einen einzelnen Verkauf durch die verschiedenen Module, zeigt die daraus resultierenden Buchungssätze und erklärt, warum die Integration mit einem ERP auf Ereignissen und dem Hauptbuch basiert – und nicht auf Benutzeroberflächen.
Die gemeinsame Datenbank
Vor der Einführung von ERP-Systemen betrieb jede Abteilung ihre eigene Software. Bestände wurden in Lagersystemen geführt, Rechnungen in Fakturierungsprogrammen erstellt und die Finanzbuchhaltung lief separat. Das Monatsende verbrachten die Teams damit, diese drei Welten abzugleichen. Der Beitrag Was ist ERP-Software? erläutert die Softwarekategorie; der zugrunde liegende Mechanismus, der sie funktionsfähig macht, ist ein einheitliches Datenmodell, bei dem:
- ein Partnerdatensatz (partner) gleichermaßen von Vertrieb, Einkauf und Buchhaltung genutzt wird,
- ein Artikeldatensatz (item) Lagerbestände, FIFO-Bewertungsschichten, Verkaufspreise und Erlöskonten enthält,
- ein Beleg (document – wie Bestellung, Rechnung, Gutschrift, Einkauf oder Fertigungsauftrag) auf Partner und Artikel verweist und exakt einen Satz von Buchungssätzen erzeugt,
- ein Buchungssatz (journal entry) auf den ihn erzeugenden Beleg verweist, sodass jeder Betrag in einem Bericht lückenlos zurückverfolgt werden kann.
Wenn die Datensätze geteilt werden, entfällt jeglicher Abstimmungsaufwand zwischen den Modulen. Was dann noch abzugleichen bleibt, ist die externe Welt: Kontoauszüge und Steuererklärungen.
Die Modulübersicht
| Modul | Schreibt | Liest |
|---|---|---|
| Vertrieb (Sales) | Bestellungen, Rechnungen, Gutschriften | Partner, Artikel, Preise, Umsatzsteuerregeln |
| Einkauf (Purchasing) | Bestellungen, Eingangsrechnungen | Partner, Artikel, Aufwandskonten |
| Lagerwirtschaft (Inventory) | Lagerbewegungen, FIFO-Bewertungsschichten, Inventuren | Artikel, Lagerorte |
| Produktion (Production) | Fertigungsaufträge, Materialentnahmen, Fertigwaren | Stücklisten, Lagerbestände |
| Bank (Bank) | Importierte Transaktionen, Zahlungsabgleiche | Offene Rechnungen, Bankkonten |
| Lohn & Gehalt (Payroll) | Lohnläufe, Sozialabgaben, Meldungen | Mitarbeiter, Verträge, Steuertabellen |
| Anlagevermögen (Assets) | Anlagenspiegel, Abschreibungsläufe | Anlagengruppen, Nutzungsdauern |
| Steuern (Tax) | Umsatzsteuervoranmeldungen, ZM (EU-Meldungen), Intrastat, E-Invoices | Ausgestellte und erfasste Belege |
| Hauptbuch (General ledger) | Buchungssätze, Periodensperren | Alle oben genannten |
| Berichterstattung (Reporting) | Nichts | Das Hauptbuch und die Nebenbücher |
Jede Zeile mit Ausnahme der letzten beiden endet mit einem Schreibvorgang in das Hauptbuch. Das ist die architektonische Regel, die ein ERP von einer Ansammlung verknüpfter Tools unterscheidet.
Ein durchgespielter Datenfluss
Das folgende Beispiel nutzt die Endpunkte von Nordlet sowie die Standardkonten des mitgelieferten litauischen Kontenrahmens. Jedes ERP führt dieselben Schritte aus; lediglich die Kontonummern und Endpunktnamen variieren.
1. Bestellung
Ein Online-Shop gibt über POST /v1/ecommerce/orders/create eine Bestellung auf: ein Partner, Positionen mit Artikeln und Mengen sowie ein Lieferland. Zu diesem Zeitpunkt wird noch nichts im Hauptbuch verbucht. Eine Bestellung ist eine Willenserklärung, keine Transaktion.
2. Bestandsreservierung
orders/reserve reserviert die Bestände, damit eine zweite Bestellung dieselben Einheiten nicht parallel verkaufen kann. Auch hier erfolgt noch kein Buchungssatz, da reservierter Bestand weiterhin dem Unternehmen gehört.
3. Warenausgang (Fulfillment)
orders/fulfill erfasst den Abgang der Waren aus dem Lager. In einer einzigen Datenbanktransaktion geschehen zwei Dinge:
- Der Bestand wird zum FIFO-Verbrauchswert ausgebucht: Die ältesten Anschaffungsschichten für jeden Artikel werden zuerst herangezogen, wie im Glossarbeitrag zur FIFO-Lagerbewertung beschrieben.
- Die Kosten dieser Einheiten werden als Buchungssatz erfasst (Soll: Aufwendungen für Waren, Haben: Bestand).
| Konto | Soll | Haben |
|---|---|---|
| 6000 Materialaufwand (COGS) | 600,00 | |
| 2040 Vorräte / Lagerbestand | 600,00 |
Der Warenausgang erzeugt zudem eine Rechnung im Entwurfsstatus (draft invoice) und ermittelt die steuerliche Behandlung anhand des Lieferlandes über die EU-Umsatzsteuer-Engine (EU VAT engine).
4. Rechnungsstellung
Mit der Rechnungsstellung wird der Umsatz bei einer punktuellen Lieferung realisiert. Der Beleg erhält seine lückenlose Nummer, und ein ausgeglichener Buchungssatz wird erstellt: der Bruttobetrag an die Forderungen, die Umsatzsteuer an das entsprechende Ausgabemotorenkonto und der Nettobetrag an die Erlöse.
Für einen Nettoumsatz von 1.000,00 € bei 21 % litauischer Umsatzsteuer:
| Konto | Soll | Haben |
|---|---|---|
| 2410 Forderungen aus Lieferungen und Leistungen | 1.210,00 | |
| 5000 Umsatzerlöse aus Waren | 1.000,00 | |
| 4492 Umsatzsteuer 21% | 210,00 |
Weist eine Position eine andere Erfassungsmethode als die punktuelle Realisierung auf, fließt der Nettobetrag stattdessen in die passiven Rechnungsabgrenzungsposten (deferred income), und die Umsatzrealisierungs-Engine (revenue recognition engine) bucht ihn fristgerecht frei. Die Verbuchung von Forderungen und Umsatzsteuer bleibt davon unberührt.
Die Rechnung kann nun als PDF, als Peppol BIS 3.0-E-Invoicing-Format oder im jeweiligen nationalen E-Invoicing-Standard des Unternehmenslandes exportiert werden.
5. Bankabgleich
Zwei Wochen später gehen 1.210,00 € ein. Der Zahlungseingang erfolgt über einen PSD2-Bankfeed oder einen camt.053-Kontoauszugsimport. Das Bankmodul bewertet Rechnungskandidaten anhand von Betrag, Verwendungszweck, Name des Zahlungspartners und IBAN; bank/transactions/match bucht den Zahlungsausgleich:
| Konto | Soll | Haben |
|---|---|---|
| 2710 Bank | 1.210,00 | |
| 2410 Forderungen aus Lieferungen und Leistungen | 1.210,00 |
Der Rechnungsstatus wechselt zu „bezahlt“, und ein Webhook vom Typ sale_invoice.paid wird ausgelöst. Der Glossarbeitrag zum Zahlungsabgleich (payment reconciliation) erläutert die Matching-Logik im Detail. Eine Zahlung in einer Fremdwährung verbucht den realisierten Wechselkursunterschied im selben Schritt auf das entsprechende Kursgewinn- oder -verlustkonto.
6. Umsatzsteuervoranmeldung
Zum Monatsende müssen keine Daten manuell übertragen werden. Die Umsatzsteuervoranmeldung wird aus den ausgestellten und erfassten Belegen berechnet: declarations/eu/vat-return/compute für die nationale Anmeldung (FR0600 in Litauen), declarations/eu/oss/compute für grenzüberschreitende B2C-Verkäufe im Rahmen des One-Stop-Shop-Verfahrens (OSS). Der obige Verkauf landet im Standardsteuersatz-Feld der inländischen Erklärung, da sein Steuerskema auf domestic steht.
7. Periodensperre
Sobald die Erklärung eingereicht ist, schließt ledger/periods/lock den Monat. Ab diesem Zeitpunkt wird jede Buchung mit einem Datum in dieser Periode – einschließlich eines nachträglichen Bankabgleichs oder eines wiederholten API-Aufrufs – mit dem HTTP-Statuscode 409 abgelehnt. Das Sperren löst zudem die Erfassung aller noch ausstehenden periodengerechten Abgrenzungen bis zum Monatsende aus, sodass ein Monat nicht mit realisierten Umsätzen auf Passivkonten abgeschlossen werden kann.
Warum das Hauptbuch das führende System ist (System of Record)
Jedes der oben genannten Module führt ein Nebenbuch (subledger): Forderungen nach Kunden, Verbindlichkeiten nach Lieferanten, Bestände nach Artikeln, Anlagen nach Wirtschaftsgütern. Das Hauptbuch (general ledger) enthält die Summen, mit denen diese Nebenbücher übereinstimmen müssen. Der Beitrag Nebenbuch vs. Hauptbuch beleuchtet das Verhältnis näher. Der praktische Aspekt ist, dass ein aus dem Hauptbuch generierter Bericht und ein aus einem Nebenbuch erstellter Bericht exakt dieselbe Zahl ausweisen müssen – und ein ERP garantiert dies, indem es beide aus denselben Buchungssätzen (journal entries) generiert.
Drei Eigenschaften machen das Hauptbuch als Aufzeichnung vertrauenswürdig:
- Erzwungene Bilanzsicherheit (Balance is enforced). In Nordlet verweigert die Datenbank die Annahme eines Buchungssatzes, bei dem Soll und Haben nicht übereinstimmen. Ein Softwarefehler in einem Modul kann somit keine unausgeglichene Buchung erzeugen.
- Die Historie ist nur anfügbar (append-only). Ein bereits gebuchter Beleg wird niemals nachträglich geändert. Ein Fehler wird durch eine Stornierung und einen neuen Buchungssatz korrigiert, die beide miteinander verknüpft sind. Der Glossarbeitrag zum unveränderlichen Hauptbuch (immutable ledger) erklärt, warum Wirtschaftsprüfer hierauf bestehen.
- Perioden werden geschlossen (Periods close). Ein gesperrter Monat lässt sich nicht mehr verändern, sodass die einmal gemeldeten Zahlen dauerhaft im System fixiert bleiben.
Integration: Ereignisse und Idempotenz statt nächtlicher Stapelverarbeitung
Ältere ERP-Integrationen basierten auf nachts ausgetauschten Dateien: Aufträge exportieren, importieren und morgens die Fehlerprotokolle prüfen. Moderne ERPs stellen eine API bereit, wodurch die Integration auf zwei Prinzipien beruht:
Ereignisse nach außen (Events out). Wenn sich etwas ändert, informiert das ERP Sie darüber. Nordlet schreibt jedes Webhook-Ereignis im Rahmen derselben Datenbanktransaktion wie die Änderung in eine Outbox. Ein zurückgerollter Beleg sendet somit niemals ein Ereignis, und es geht kein Event verloren. Auslieferungen werden per HMAC-SHA256 signiert und bei Fehlern mit exponentiellem Backoff erneut versucht. Ihr System reagiert direkt auf sale_invoice.paid, anstatt alle fünf Minuten abzufragen, ob eine Rechnung bezahlt wurde.
Sichere Wiederholungen nach innen (Safe retries in). Netzwerke können ausfallen, und ein wiederholter Request darf keinesfalls eine zweite Rechnung erzeugen. Nordlet akzeptiert bei jedem verändernden Aufruf einen Idempotency-Key-Header: Derselbe Schlüssel mit exakt demselben Payload liefert die gespeicherte Antwort zurück, derselbe Schlüssel mit einem abweichenden Payload wird abgelehnt, und Schlüssel verfallen nach 24 Stunden. Der Glossarbeitrag zur Idempotenz (idempotency) und die API-Konventionen beschreiben das genaue Verhalten.
Da jeder Vorgang ein Aufruf vom Typ POST /v1/{module}/{resource}/{action} ist und die Anwendung dieselben Endpunkte nutzt, kann eine Integration den gesamten obigen Ablauf durchführen, ohne dass jemals eine Benutzeroberfläche geöffnet werden muss. Der Leitfaden So integrieren Sie eine Cloud-Buchhaltungs-API in eine SaaS-Plattform führt durch einen solchen Aufbau.
Worauf Berichte zugreifen
Berichte speichern keine Kennzahlen. Sie sind Abfragen (Queries) über das Hauptbuch und die Nebenbücher zu einem bestimmten Stichtag:
- Summen- und Saldenliste, Bilanz, Gewinn- und Verlustrechnung (GuV) sowie Kapitalflussrechnung werten Buchungssätze nach Konten und Perioden aus.
- Forderungs- und Verbindlichkeitsspiegel (Debt aging) werten offene Posten nach Fälligkeitstagen aus.
- Lagerbestand und -bewegungen lesen das Bestandsnebenbuch samt seiner FIFO-Schichten aus.
- Umsatzsteuerübersichten werten die Umsatzsteuerzeilen ausgestellter und erfasster Belege aus.
- Kostenstellenberichte greifen auf die Kostenstellendimension jeder Buchungszeile zu.
In Nordlet wird ein Bericht im Hintergrund als XLSX, PDF oder JSON generiert, und ein Webhook informiert Sie, sobald die Datei bereitsteht. Konzernzahlen werden über die Konsolidierung (consolidation) ermittelt, welche die Hauptbücher mehrerer Gesellschaften unter Berücksichtigung von Beteiligungsquoten und Währungsumrechnung zusammenführt.
Wo dies in der Praxis scheitert
Die meisten Probleme bei ERP-Projekten sind organisatorische Fehler des Prinzips der gemeinsamen Datenbasis und keine Softwaremängel. Typische Szenarien:
- Eine parallele Tabellenkalkulation für Geschäftsvorgänge, die das ERP angeblich „nicht abbilden kann“, wodurch Abweichungen zur Buchhaltung entstehen.
- Manuelle Buchungssätze zur Korrektur von Modulausgaben anstelle einer Belegkorrektur, wodurch die Rückverfolgbarkeit vom Bericht zum Ursprung zerstört wird.
- Integrationen, die Salden anstelle von Belegen schreiben, sodass das Hauptbuch Summen enthält, die niemand mehr nachvollziehen kann.
- Offene Perioden, die über Monate hinweg ungesperrt bleiben, sodass die Zahlen des letzten Quartals nachträglich drifteffekte aufweisen.
Der Beitrag Warum ERP-Implementierungen scheitern beleuchtet, wie sich diese Verhaltensweisen während der Einführung einschleichen, und Realistische Zeitpläne für ERP-Implementierungen zeigt, in welcher Projektphase sie üblicherweise auftreten.
FAQ
Was ist der Kern eines ERP-Systems?
Das Hauptbuch und das darum herum gruppierte gemeinsame Datenmodell. Jedes Modul schreibt Belege, die ausgeglichene Buchungssätze erzeugen, und jeder Bericht wird aus diesen Buchungen abgeleitet.
Wie fließen Daten durch ein ERP?
Ein Ereignis wird einmalig als Beleg erfasst (Bestellung, Rechnung, Lagerbewegung, Lohnlauf). Der Beleg erzeugt Buchungssätze im Hauptbuch sowie Bestandsveränderungen im entsprechenden Nebenbuch. Berichte und Steuererklärungen werden aus diesen Daten berechnet. Zwischen den Modulen werden keine Daten kopiert.
Was ist der Unterschied zwischen einem Modul und einer Integration?
Ein Modul schreibt in dieselbe Datenbank und dasselbe Hauptbuch wie der Rest des Systems. Eine Integration ist ein externes Programm, das die API des ERPs anspricht. Bei einem API-first ERP ist der Unterschied minimal, da die Integration exakt dieselben Endpunkte verwendet wie die internen Module.
Verbucht ein ERP Buchungssätze automatisch?
Ja. Das Ausstellen einer Rechnung, das Abwickeln einer Bestellung, das Zuordnen einer Zahlung, das Durchführen eines Lohnlaufs oder die Abschreibung eines Wirtschaftsguts erzeugen jeweils eigenständig ihre Buchungssätze, ohne dass ein Anwender Soll und Haben manuell zusammenstellen muss. Die verwendeten Konten stammen aus Buchungsregeln, die pro Mandant angepasst werden können.
Warum sperren ERPs Buchungsperioden?
Damit gemeldete oder eingereichte Zahlen für eine Periode nachträglich nicht mehr verändert werden können. Eine gesperrte Periode weist neue Buchungen zurück, schützt den Prüfpfad (Audit Trail) und erzwingt, dass Korrekturen in der laufenden Periode vorgenommen und dort transparent ausgewiesen werden.