Was eine ERP-Schnittstelle leisten muss
Eine ERP-Schnittstelle ist die Verbindung zwischen Ihrem ERP-System und einem zweiten System, das dieselben Daten braucht: Aufträge aus dem Shop, Kontakte aus dem CRM, Rechnungen in die Buchhaltung, Zahlungseingänge von der Bank. Ohne Schnittstelle laufen diese Daten über Exporte, Tabellen und erneute Eingabe. Jede dieser Stationen kostet Zeit und erzeugt Abweichungen, die erst Wochen später auffallen, meist in der Buchhaltung.
Gut gebaut erfüllt eine ERP-Schnittstelle vier Anforderungen:
- Eindeutige Zuordnung: Jedes Feld der einen Seite hat ein klar bestimmtes Gegenstück auf der anderen. Was nicht zugeordnet werden kann, wird gemeldet, nicht geraten.
- Nachvollziehbarkeit: Jede Übertragung wird protokolliert, mit Zeitpunkt, Datensatz und Ergebnis. Sie können im Nachhinein prüfen, wann welcher Beleg übertragen wurde.
- Fehlerbehandlung: Abweichungen und Ablehnungen des Zielsystems werden sichtbar gemacht, zum Beispiel per E-Mail oder in einer Fehlerliste. Eine Schnittstelle, die Fehler still überspringt, ist schlimmer als keine.
- Wiederholbarkeit: Ein abgebrochener Lauf lässt sich erneut starten, ohne dass Datensätze doppelt entstehen.
Die Begriffe Schnittstellenentwicklung, API-Entwicklung und Systemintegration beschreiben dasselbe Vorhaben aus verschiedenen Blickwinkeln: die Programmierschnittstelle (API) ist der technische Zugang, die Schnittstelle das Stück Software, das ihn nutzt, und die Systemintegration das Ergebnis, bei dem zwei Systeme wie eines arbeiten.
REST, GraphQL oder Datei-Export?
Welchen Weg eine ERP-Anbindung nimmt, hängt davon ab, was die beteiligten Systeme anbieten. In der Praxis gibt es drei Varianten:
- Programmierschnittstelle (REST oder GraphQL): Das Zielsystem stellt Funktionen bereit, über die Datensätze gelesen, angelegt und geändert werden. Odoo, sevDesk, Lexware Office, die meisten Shop-Systeme und CRM-Lösungen bieten das. Vorteil: Daten fließen zeitnah und in beide Richtungen, Fehler werden sofort zurückgemeldet. Voraussetzung: Die Schnittstelle des Anbieters deckt die benötigten Felder ab, was Sie vor dem Angebot prüfen sollten.
- Datei-Export und -Import (CSV, XML, DATEV-Format): Das Quellsystem schreibt eine Datei, das Zielsystem liest sie ein. Typisch für die Übergabe an den Steuerberater per DATEV-Export oder für Systeme ohne Programmierschnittstelle. Vorteil: einfach, robust, von jedem System unterstützt. Nachteil: Verzögerung, nur eine Richtung, und Fehler fallen erst beim Import auf.
- Datenbankzugriff: Die Schnittstelle liest direkt aus der Datenbank des Quellsystems. Nur sinnvoll, wenn der Hersteller das ausdrücklich zulässt; sonst gefährden Updates des Systems die Schnittstelle.
Eine Entscheidung für REST oder GraphQL ist selten eine Grundsatzfrage. Sie richtet sich danach, was das Gegensystem versteht. Wichtiger als das Protokoll ist, wie die Schnittstelle mit Grenzfällen umgeht: ein Kunde, der in beiden Systemen leicht unterschiedlich heißt, ein Artikel ohne Steuersatz, eine Rechnung, die im Zielsystem bereits existiert.
Beispiel: Warenwirtschaft an Buchhaltung anbinden
Der häufigste Fall im Mittelstand: Aufträge und Rechnungen entstehen in der Warenwirtschaft oder im Shop, die Buchhaltung läuft in Lexware, sevDesk oder beim Steuerberater über DATEV. Ohne Schnittstelle werden Rechnungen einmal im Monat exportiert, in einer Tabelle bereinigt und importiert. Wer das macht, kennt die typischen Fehler: fehlende Debitorennummern, abweichende Steuersätze, Rechnungen, die doppelt oder gar nicht ankommen.
Eine ERP-Schnittstelle für diesen Fall arbeitet so:
- Jede neue Rechnung in der Warenwirtschaft wird zeitnah an die Buchhaltung übergeben, mit Kunde, Positionen, Steuersatz und Fälligkeit.
- Kunden werden über eine gemeinsame Kennung zugeordnet, etwa die Kundennummer. Fehlt sie, legt die Schnittstelle den Kunden nach festen Regeln an oder meldet den Fall zur Prüfung.
- Jede Übergabe wird protokolliert. Die Buchhaltung sieht, welche Rechnung wann angekommen ist.
- Lehnt die Buchhaltung einen Datensatz ab, etwa wegen eines unbekannten Steuerschlüssels, erscheint der Fall in einer Fehlerliste und wird nach Korrektur erneut übertragen.
Derselbe Aufbau gilt in Gegenrichtung für Zahlungseingänge. Wie eine Schnittstelle zwischen Bankkonto und offenen Rechnungen arbeitet und woran die Zuordnung scheitert, beschreibt der Ratgeber zum automatischen Zahlungsabgleich.
Ablauf eines Schnittstellenprojekts
Schnittstellenentwicklung beginnt nicht mit Programmierung, sondern mit der Frage, welche Daten heute wie von A nach B kommen. Ein Projekt läuft in vier Schritten:
- Aufnahme: Welche Systeme sind beteiligt, welche Daten fließen in welche Richtung, wie oft, und was passiert heute von Hand? Hier zeigt sich auch, ob das Zielsystem überhaupt eine Programmierschnittstelle anbietet und was sie abdeckt.
- Feldzuordnung: Für jedes Feld wird festgelegt, woher es kommt, wohin es geht und wie es umgewandelt wird: Steuersätze, Einheiten, Datumsformate, Kennungen. Diese Tabelle ist das wichtigste Dokument des Projekts und bleibt auch im Betrieb die Referenz.
- Testlauf mit echten Daten: Die Schnittstelle läuft zunächst gegen Testumgebungen oder mit einem abgegrenzten Datenbestand. Jeder Grenzfall aus der Aufnahme wird gezielt durchgespielt, bevor der erste echte Beleg übertragen wird.
- Betrieb und Überwachung: Nach dem Start werden Protokolle und Fehlerliste regelmäßig gesichtet, zu Beginn täglich. Änderungen an einem der Systeme, etwa ein Update der Buchhaltung, werden vorab auf Auswirkungen geprüft.
Welche Technologien RLOX für Schnittstellen einsetzt und wie ein solches Projekt im Angebot abgegrenzt wird, steht auf der Seite zur individuellen Softwareentwicklung.
Was eine ERP-Schnittstelle kostet: die Treiber
Eine belastbare Zahl gibt es erst nach der Aufnahme. Was den Aufwand bestimmt, lässt sich aber vorab benennen:
- Anzahl der Systeme und Richtungen: Eine Übergabe in eine Richtung ist der einfachste Fall. Sobald Daten in beiden Richtungen fließen, muss die Schnittstelle Konflikte auflösen: Wer gewinnt, wenn derselbe Kunde in beiden Systemen geändert wurde?
- Datenqualität: Doppelte Kunden, fehlende Kennungen und uneinheitliche Schreibweisen müssen vor dem Start bereinigt oder von der Schnittstelle behandelt werden. Beides kostet, das Bereinigen ist meist günstiger.
- Qualität der Programmierschnittstelle: Gut dokumentierte, stabile Schnittstellen wie die von Odoo oder sevDesk verkürzen die Entwicklung. Systeme ohne Programmierschnittstelle zwingen zum Datei-Weg mit allen Einschränkungen.
- Anforderungen an Zeitnähe: Ein nächtlicher Lauf ist einfacher als eine Übertragung innerhalb von Sekunden, die auf Ausfälle des Gegensystems reagieren muss.
- Betrieb: Eine Schnittstelle läuft dauerhaft und braucht jemanden, der Fehlerlisten sichtet und bei Updates der angebundenen Systeme prüft, ob noch alles passt. Dieser Posten wird in Angeboten am häufigsten vergessen.
Typische Fehler bei der ERP-Anbindung
- Fehler werden still übersprungen. Die Schnittstelle überträgt, was geht, und verwirft den Rest. Die Abweichung fällt Monate später beim Jahresabschluss auf.
- Kein Protokoll. Niemand kann sagen, ob und wann ein Beleg übertragen wurde. Jede Rückfrage wird zur Suche in zwei Systemen.
- Zuordnung über Namen statt über Kennungen. „Müller GmbH“ und „Mueller GmbH“ werden zu zwei Kunden, oder schlimmer, zu einem falschen.
- Keine Wiederholbarkeit. Ein abgebrochener Lauf erzeugt beim Neustart doppelte Datensätze, weil die Schnittstelle nicht weiß, was schon übertragen wurde.
- Direkter Datenbankzugriff ohne Freigabe des Herstellers. Funktioniert bis zum nächsten Update.
- Betrieb nicht geregelt. Die Schnittstelle läuft, aber niemand liest die Fehlerliste.
Wann eine fertige Integration reicht
Nicht jede ERP-Anbindung braucht eigene Schnittstellenentwicklung. Viele Systeme bringen fertige Integrationen mit: Shop-Systeme an gängige Buchhaltungen, CRM-Lösungen an Newsletter-Werkzeuge, Buchhaltungen an die Bank. Eine fertige Integration ist die richtige Wahl, wenn drei Bedingungen erfüllt sind:
- Sie bildet die Felder ab, die Sie tatsächlich brauchen, einschließlich Ihrer Besonderheiten bei Steuersätzen, Kostenstellen oder Zahlungsbedingungen.
- Sie meldet Fehler sichtbar und nicht nur in einem Protokoll, das niemand öffnet.
- Der Anbieter pflegt sie weiter, wenn sich eines der beiden Systeme ändert.
Eine eigene Schnittstelle lohnt sich, wenn eine dieser Bedingungen nicht gilt, wenn ein beteiligtes System keine fertige Integration hat oder wenn die Daten vor der Übergabe nach Regeln umgewandelt werden müssen, die nur in Ihrem Unternehmen gelten. Häufig ist der Auslöser auch ein zweites Vorhaben: Sobald Kunden Aufträge oder Rechnungen selbst einsehen sollen, wird aus der Schnittstelle der Unterbau für ein Kundenportal.
Ob fertige Integration oder Eigenentwicklung, lässt sich im Erstgespräch meist in einer halben Stunde klären. Entscheidend ist, dass die Antwort vor dem Angebot feststeht, nicht während der Umsetzung.
