Wie ERP-Module wirklich zusammenarbeiten

Hinter dem Wort „integriert“ stecken drei verschiedene Dinge

Fast jeder ERP-Prospekt verwendet das Wort „integriert“. Dahinter verbergen sich mindestens drei Anordnungen, die sich sehr unterschiedlich verhalten, wenn beim Monatsabschluss etwas schiefgeht. Die erste ist der Datei- oder zeitgesteuerte Batch-Transfer: Ein System exportiert, ein anderes importiert, meist über Nacht. Die zweite ist die Synchronisation über API oder Middleware, bei der zwei getrennte Datenbanken durch den Austausch von Nachrichten im Gleichschritt bleiben. Die dritte sind echte gemeinsame Daten: Die Module sind gar keine getrennten Systeme, sondern unterschiedliche Sichten auf einen Satz Tabellen, ein Hauptbuch und einen Satz Stammdaten.

Keine dieser Varianten ist grundsätzlich richtig. Der Batch-Transfer ist günstig, leicht nachzuvollziehen und übersteht einen Ausfall auf einer der beiden Seiten, weil die Datei einfach wartet. Er ist aber konstruktionsbedingt immer veraltet, und ein fehlgeschlagener Lauf kann unbemerkt bleiben, bis jemand einen Bericht hinterfragt. Die API-Synchronisation bietet nahezu Echtzeitverhalten und erlaubt es, Systeme zu behalten, für die es gute Gründe gibt – aber Sie betreiben nun ein verteiltes System: Wiederholungen, Reihenfolgen, Teilausfälle und zwei Kopien der Wahrheit, die voneinander abweichen können. Gemeinsame Daten beseitigen die Klasse von Problemen, bei denen zwei Datenbanken auseinanderlaufen, weil es nur eine gibt; sie bedeuten aber, dass sich die Module auf einen Kontenrahmen, eine Artikeldefinition und einen Release-Rhythmus einigen müssen – das ist eine Einschränkung und kein Gratisvorteil.

Die praktische Frage lautet nicht, welche Stufe die beste ist, sondern welche Stufe jeder einzelne Datenfluss verdient. Die nächtliche Übertragung eines Kontoauszugs ist in Ordnung. Die nächtliche Übertragung von Lagerbeständen hinter einer laufenden Kasse ist es nicht. Skyline Nexus arbeitet für seine eigenen Module auf der dritten Stufe: Buchhaltung, Kasse und Lager, CRM, Instandhaltung, Personal, Fuhrpark und Anlagen schreiben in ein Hauptbuch und einen Satz Stammdaten und binden externe Systeme per API an, wo ein Kunde bereits ein System hat, das sich zu behalten lohnt.

Stammdaten sind der Ort, an dem das Auseinanderlaufen beginnt

Integrationsfehler werden meist den Schnittstellen zugeschrieben, doch der erste Riss ist in der Regel ein Stammdatensatz, der zweimal mit leicht unterschiedlichem Inhalt existiert. Sobald zwei Systeme jeweils eine eigene Kundenliste führen, laufen die Listen binnen Wochen auseinander, und jede nachgelagerte Zahl erbt diese Abweichung.

• Kunde: eine Identität über Verkauf, Rechnungsstellung, Zahlungseingang und Kreditkontrolle hinweg – sonst stimmt die Altersstruktur der Forderungen nicht mit dem Verkaufsbericht überein.
• Lieferant: gemeinsam genutzt von Einkauf, Kreditorenbuchhaltung und Zahlungsverkehr, einschließlich der Bankverbindung, die bei Duplikaten ein Ziel für Betrug ist.
• Artikel: ein Code, eine Mengeneinheit, eine Bewertungsmethode. Zwei Artikelstämme bedeuten zwei Bestandsbewertungen.
• Kontenrahmen: eine einzige Struktur. Führt ein Modul eine eigene Kontenliste und bildet sie auf Ihre ab, ist die Zuordnung ein zweites Element, das gepflegt werden muss und falsch sein kann.
• Steuerschlüssel: eine Definition von Satz, Behandlung und Gültigkeitsdaten, die sowohl der Geschäftsvorfall als auch die Steuererklärung verwenden.
• Filiale und Standort: gemeinsam genutzt, weil sowohl Lager als auch Buchhaltung danach gegliedert sind.
• Mitarbeiter: ein Datensatz hinter Lohnabrechnung, Zeiterfassung, Instandhaltungsaufträgen und Fahrzeugzuordnung.
• Anlage: ein Verzeichnis hinter Abschreibung, Instandhaltungshistorie und Abgang.

Nebenbücher und das Sammelkonto

Ein Hauptbuch führt verdichtete Salden. Die Details stehen in den Nebenbüchern, und jedes Nebenbuch ist mit einem Sammelkonto im Hauptbuch verknüpft. Die Debitorenbuchhaltung führt eine Zeile je Kundenrechnung und Zahlungseingang, deren Summe dem Sammelkonto Forderungen entspricht. Die Kreditorenbuchhaltung tut dasselbe für Lieferantenrechnungen. Lagerbewegungen werden auf ein Bestandssammelkonto gebucht, wobei die Umsatzkosten beim Warenabgang erfasst werden. Die Lohnabrechnung bucht Bruttolöhne, Arbeitgeberanteile, Abzüge und Nettoverbindlichkeiten. Die Anlagenbuchhaltung bucht Zugänge, Abschreibungen und Abgänge gegen Anschaffungskosten und kumulierte Abschreibungen. Die Kasse bucht Umsätze, vereinnahmte Steuer, Zahlungsarten und – bei permanenter Inventur – die Kostenseite jedes Verkaufs.

Die Regel, die das vertrauenswürdig macht, ist einfach: Das Nebenbuch muss immer mit seinem Sammelkonto übereinstimmen, auf die kleinste Währungseinheit genau. Zeigt die Altersstruktur der Forderungen einen Betrag und das Sammelkonto Forderungen einen anderen, ist einer von beiden falsch, und welcher, lässt sich ohne Untersuchung nicht sagen. Deshalb sind direkte Buchungen auf Sammelkonten normalerweise gesperrt. Eine manuelle Buchung auf Forderungen erzeugt einen Saldo, den kein Kunde schuldet, und er erscheint auf keinem Kontoauszug, den Sie versenden.

Die Abstimmung sollte ein Bericht sein, den Sie jederzeit abrufen können, und keine Tabelle, die jemand pflegt. Teilen sich die Module ein Hauptbuch, ist die Abstimmung nahezu eine Selbstverständlichkeit. Tun sie es nicht, ist sie die wichtigste einzelne Prüfung, die Sie automatisieren können.

Buchungsregeln und der Prüfpfad

Jede Hauptbuchzeile sollte auf einen Ursprungsbeleg zurückführbar sein: eine Rechnungsnummer, einen Wareneingang, einen Lohnlauf, einen Abschreibungsplan, einen Kassenvorgang. Gibt es eine Zeile ohne Ursprung, hat jemand den Prozess umgangen. Die Belegkennung sollte mit der Hauptbuchzeile mitwandern und nicht in einer separaten Zuordnungstabelle liegen.

Gebuchte Einträge sollten nicht stillschweigend änderbar sein. Korrekturen gehören in Stornobuchungen oder Gutschriften, die sowohl das Original als auch die Korrektur sichtbar lassen, jeweils mit eigenem Datum und eigenem Benutzer. Der Periodenabschluss sollte die Periode sperren, statt sich darauf zu verlassen, dass niemand rückdatiert. Der Test lautet: Können Sie jeden beliebigen Saldo öffnen und sich bis zu den Belegen durchklicken, die ihn erzeugt haben, ohne das System zu verlassen?

Wo Integrationen tatsächlich brechen

Die Fehlerbilder sind bekannt, und es sind fast immer dieselben.

• Zeitpunkt und Periodenabgrenzung: Ein kurz vor Mitternacht am letzten Tag der Periode gebuchter Verkauf kommt im anderen System erst nach dem Stichtag an, sodass die beiden Perioden nie übereinstimmen.
• Fehlgeschlagene Läufe, die niemand überwacht: Ein geplanter Transfer läuft nicht mehr, und das Fehlen von Daten sieht aus wie eine ruhige Woche.
• Teilweise Schreibvorgänge: Der Rechnungskopf wird angelegt, die Positionen scheitern, und eine Seite hält nun einen Beleg, den die andere nicht kennt.
• Doppelte Schlüssel: Eine wiederholte Nachricht erzeugt eine zweite Kopie derselben Rechnung, oder ein Nummernkreis kollidiert zwischen Filialen.
• Währungs- und Rundungsdrift: Zwei Systeme runden an unterschiedlichen Stellen oder verwenden für denselben Tag unterschiedliche Kurse und erzeugen kleine Differenzen, die sich aufsummieren.
• Doppelt berechnete Steuer: Transaktionssystem und Buchhaltungssystem berechnen die Steuer jeweils selbst, mit leicht unterschiedlichen Regeln für Rabatte, Bruttopreise oder Rundung je Position statt je Beleg. Die Rechnung an den Kunden und der Betrag in der Steuererklärung stimmen dann nicht überein.

Idempotenz und der Nachweis, dass beide Seiten übereinstimmen

Alles, was wiederholt werden kann, wird auch wiederholt; jeder Buchungsvorgang braucht daher einen stabilen, aus dem Ursprungsbeleg abgeleiteten Schlüssel. Wird dieselbe Rechnung zweimal gesendet, muss daraus eine Buchung entstehen, nicht zwei. Die empfangende Seite sollte festhalten, welche Schlüssel sie bereits verarbeitet hat, und das frühere Ergebnis zurückgeben, statt ein neues zu erzeugen. Ohne das wird aus gewöhnlichem Netzwerkverhalten doppelter Umsatz.

Daneben brauchen Sie die Abstimmung als vollwertige Funktion: Anzahl und Summen je Periode und Belegart, auf beiden Seiten verglichen, mit einer Auflistung der Differenzen statt einer Zusammenfassung. Ein grüner Haken, der nur besagt, dass der letzte Lauf erfolgreich war, ist kein Nachweis der Übereinstimmung. Nützlich ist der Bericht, der die sieben Belege benennt, die auf der einen Seite existieren und auf der anderen nicht.

Filialen und Währungen

Betrieb mit mehreren Filialen bedeutet, dass jeder Geschäftsvorfall seinen Standort ab dem Moment seiner Entstehung als Dimension trägt und ihn nicht erst später durch Berichtslogik zugewiesen bekommt. Bestand, Umsatz, Kosten und Personal gehören jeweils zu einer Filiale, und bei Umlagerungen zwischen Filialen müssen beide Seiten gebucht werden, sonst ergeben die Bestände der beiden Filialen zusammen nicht den Bestand des Unternehmens. Belegnummern müssen filialübergreifend eindeutig und innerhalb einer Filiale dennoch aussagekräftig sein.

Mehrwährungsfähigkeit erfordert, dass Transaktionswährung, verwendeter Kurs und Betrag in Hauswährung sämtlich auf der Position gespeichert werden. Wer nur den umgerechneten Wert speichert, verwirft den Nachweis. Die Bewertung offener Salden und realisierte Kursgewinne oder -verluste bei Ausgleich haben dann einen Ort, an dem sie gebucht werden, und die Kursdifferenz ist kein Rundungsrätsel mehr.

Regionaler Hinweis: Clearance verändert den Zeitpunkt

Wo ein E-Rechnungsverfahren gilt, ist der Zeitpunkt der Integration keine Frage der Entwurfsvorliebe mehr. Mehrere Steuerverwaltungen verlangen inzwischen, dass Rechnungen freigegeben oder der Behörde gemeldet werden, bevor oder während sie den Käufer erreichen. Das ZATCA-Verfahren in Saudi-Arabien ist ein aktuelles Beispiel: Rechnungen werden mit festgelegter Struktur, kryptografischen Elementen und Kennungen erzeugt, und die Behörde ist in den Lebenszyklus des Belegs eingebunden, statt im Nachhinein eine Zusammenfassung zu erhalten. Damit wird die Rechnungserstellung zu einer Echtzeit-Integrationsaufgabe. Ein nächtlicher Batch kann keinen Beleg erzeugen, auf den der Kunde an der Theke wartet.

Andernorts sieht es anders aus, und es lohnt sich, genau zu sein. Die Vereinigten Staaten haben keine bundesweite E-Rechnungspflicht, und die Sales Tax wird auf Ebene der Bundesstaaten verwaltet, mit Regeln und Sätzen, die je Bundesstaat und oft je Kommune variieren. Kanada erhebt GST und HST auf Bundesebene mit provinziellen Abweichungen, einschließlich provinzieller Umsatzsteuern in einigen Provinzen. Die weiteren MENA-Märkte befinden sich in unterschiedlichen Stadien. Die Lehre für den Systementwurf: Steuerermittlung und Belegausstellung gehören an einen Ort, damit ein Markt, der von der Meldung zur Freigabe wechselt, eine Konfiguration ändert und nicht die Architektur. Skyline Nexus wickelt die ZATCA-Freigabe aus demselben Geschäftsvorfall ab, der die Hauptbuchbuchung schreibt, sodass die Rechnung, die der Kunde erhält, und der Betrag in der Steuererklärung aus einer einzigen Berechnung stammen.