Die meisten Anbindungen zwischen einem ERP wie SAP und der Buchhaltung in DATEV beginnen harmlos. Jemand braucht die Buchungen des Monats im anderen System, exportiert sie schnell als Datei und lädt sie drüben wieder hoch. Das funktioniert beim ersten Mal, und genau das ist die Falle. Aus dem einmaligen Export wird eine feste Gewohnheit, aus der Gewohnheit ein Skript, und nach einem halben Jahr hängt ein Teil der Finanzabläufe an einer Datei, die eine einzelne Person im Kopf hat.

Eine Insellösung erkennt man nicht am ersten Tag, sondern am ersten Sonderfall. Ein Beleg storniert, ein Konto ändert sich, ein Feld kommt in neuem Format, und plötzlich passt der Export nicht mehr. Weil niemand die Brücke als eigenes System behandelt hat, gibt es keinen Ort, an dem der Fehler auffällt, und keine Regel, was dann passieren soll. Die Daten liegen doppelt vor, in zwei Wahrheiten, und der Monatsabschluss wird zur Suche.

Nicht die beiden Systeme sind das Problem, sondern die Brücke, die niemand als System behandelt.

Der Ausweg ist keine größere Software, sondern eine bewusste Entscheidung: Die Verbindung zwischen SAP und DATEV ist selbst ein Ablauf mit Eingang, Regeln, Ausnahmen und einer Verantwortung. Wer sie so plant, baut keine Insel, sondern eine Straße.

Es gibt im Kern drei Wege, Daten zwischen zwei Kernsystemen zu bewegen, und sie unterscheiden sich stark in ihrer Haltbarkeit. Der erste ist die dokumentierte Schnittstelle: Beide Seiten bieten definierte Wege, Belege und Buchungen strukturiert zu übergeben, und man spricht diese Wege direkt an. Das ist der stabilste Ansatz, weil das Format vereinbart ist und sich nicht ändert, nur weil sich eine Bildschirmmaske ändert.

Der zweite Weg ist der Datei- oder Formataustausch. Das eine System schreibt eine Datei in ein abgestimmtes Format, das andere liest sie ein. Sauber gemacht ist das ein legitimer Weg, gerade wenn eine Seite keine offene Schnittstelle bietet. Riskant wird er erst, wenn das Format selbst gebastelt ist und keiner Vereinbarung folgt, die beide Seiten kennen.

Der dritte Weg ist der Oberflächen-Trick: Ein Roboter klickt sich durch die Maske und tippt Werte ein, als wäre er ein Mensch. Das kann eine Lücke überbrücken, wenn es weder Schnittstelle noch Format gibt, ist aber der zerbrechlichste Weg, weil jede Änderung an der Oberfläche ihn stoppt. Als Dauerlösung für Finanzdaten taugt er selten.

Die Reihenfolge ist auch die Rangfolge. Nimm die Schnittstelle, wenn es sie gibt. Nimm ein vereinbartes Format, wenn nicht. Nimm den Oberflächen-Trick nur, wenn beides fehlt, und dann bewusst als Übergang.

Ob eine Anbindung hält, entscheidet sich weniger am Weg als an einer Handvoll Eigenschaften, die man leicht überspringt, weil sie am ersten Tag unsichtbar sind. Die wichtigste sind saubere Stammdaten. Kontenrahmen, Kostenstellen, Steuerschlüssel und Belegtypen müssen zwischen beiden Systemen eindeutig aufeinander abgebildet sein. Stimmt diese Abbildung nicht, wandern Zahlen an die falsche Stelle, und der Fehler fällt erst im Abschluss auf, wo er teuer ist.

Fast ebenso wichtig ist Idempotenz, ein sperriges Wort für eine einfache Regel: Derselbe Beleg darf nicht zweimal ankommen. Wird ein Export wiederholt, weil ein Lauf abgebrochen ist, muss die Gegenseite erkennen, was sie schon hat. Ohne diese Absicherung entstehen Doppelbuchungen, und die sind in der Buchhaltung die unangenehmste Sorte Fehler.

Dazu kommt der Fehlerpfad. Es wird immer Belege geben, die nicht sauber durchlaufen, weil ein Konto fehlt oder ein Wert unplausibel ist. Eine gute Integration wirft solche Fälle nicht weg und bucht sie auch nicht blind, sondern legt sie sichtbar zur Seite und übergibt sie an einen Menschen. Ein Protokoll, das zeigt, was wann übertragen wurde, macht den Abschluss nachvollziehbar. Und wie bei jedem Ablauf braucht die Anbindung eine Person, die sie verantwortet, wenn sich rechts oder links etwas ändert.

Bevor du SAP und DATEV verbindest, beantworte diese fünf Fragen. Bleibst du bei einer hängen, hast du die künftige Insel gefunden, und zwar bevor sie entsteht.

• Welche Belege und Buchungen sollen in welche Richtung fließen, und wie oft?
• Wie bildest du Stammdaten ab, also Konten, Kostenstellen, Steuerschlüssel und Belegtypen?
• Wie verhinderst du Doppelbuchungen, wenn ein Lauf abbricht und wiederholt wird?
• Was passiert mit einem Beleg, der nicht durchläuft, und wer entscheidet dann?
• Wer verantwortet die Anbindung im Betrieb, wenn sich eine Seite ändert?

Kernsatz: Eine Anbindung ist zu einem kleinen Teil eine Frage des Werkzeugs und zu einem großen Teil eine Frage der Abstimmung. Wer die Abstimmung überspringt, baut eine Insel, die er später teuer trockenlegt.

Ein Export ist schon eine Integration.

Ein einmaliger Export bewegt Daten, aber er hat keine Regeln für Ausnahmen, keinen Schutz gegen Doppelungen und keinen Owner. Genau daran wird er zur Insel.

Die Anbindung ist ein reines IT-Thema.

Die schwierigen Entscheidungen sind fachlich: Welches Konto entspricht welchem, was ist ein tolerierbarer Fehler, wann greift ein Mensch ein. IT baut die Brücke, aber die Buchhaltung bestimmt, wohin sie führt.

API-Integration, Datenqualität, Exception Handling, Datenhoheit.

Muss ich immer die Schnittstelle nehmen, oder reicht ein Datei-Export?

Nimm die dokumentierte Schnittstelle, wenn beide Seiten sie bieten, weil sie am stabilsten ist. Ein vereinbartes, stabiles Format ist ein legitimer zweiter Weg, wenn eine Seite keine offene Schnittstelle hat. Riskant ist nur das selbstgebastelte Format ohne Absprache.

Wie verhindere ich Doppelbuchungen zuverlässig?

Jeder Beleg braucht eine eindeutige Kennung, und die Gegenseite prüft vor der Übernahme, ob sie diese Kennung schon kennt. So kann ein Lauf gefahrlos wiederholt werden, ohne dass etwas zweimal verbucht wird.

Was gehört in den Fehlerpfad?

Fälle, die nicht durchlaufen, landen sichtbar in einer Liste statt im Papierkorb, mit dem Grund, warum sie hängen. Eine benannte Person schaut regelmäßig hinein, korrigiert oder gibt frei. Ohne diesen Pfad sammeln sich stille Fehler bis zum Abschluss.

Es werden keine externen Statistiken oder Kundenergebnisse als belegt behauptet. SAP und DATEV sind hier als Systeme genannt, nicht als Partnerschaften. Konkrete Format- und Schnittstellenfragen werden vor der Umsetzung am realen Stack geprüft.