Banktransaktionen landen in den Büchern, nicht in einer Datei

Über den Verzug beschwert sich der Endkunde. Eine Bewegung, die am Montag bei der Bank gebucht ist, steht in den Büchern, wenn jemand zum Export kommt, und bis dahin hinkt die Buchhaltung der Bank eine Woche hinterher. Diese Lücke ist keine Eigenschaft der Buchhaltung. Sie ist die Länge der Aufgabenliste von irgendjemandem.

Der teurere Posten ist, dass der Umweg je Kunde anfällt. Ein Anbieter, der Transaktionsdaten bewegt, kann sich nicht aussuchen, in welchem Buchhaltungssystem die Bewegung landen muss: das hat vor Jahren entschieden, wer die Bücher eingerichtet hat, und über einen Kundenbestand hinweg sind das ein Dutzend verschiedene Antworten. Direkt in jedes davon zu bauen heißt eine eigene Integration je System, jede mit ihrer eigenen Vorstellung davon, wie eine Bewegung heißt und welche Felder sie tragen muss, und jede altert nach ihrem eigenen Fahrplan.

Und die zwei Dinge, die die Bewegung bei der Ankunft brauchbar machen würden, fallen als Erstes weg. Die Bank kennt das Valutadatum und den Verwendungszweck; ein Auszugsexport behält beide meist, eine abgetippte Buchung meist nicht. Genau auf diesen zwei Feldern liefe später eine Zuordnung, und deshalb wird so viel Zuordnung am Ende nach Augenmaß gemacht.

Das direkt zu bauen heißt, je System herauszufinden, welche Form es annimmt und worauf diese Form besteht, und dann mitzuhalten, wenn ein Hersteller es sich anders überlegt. Bei den meisten gibt es genau eine richtige Antwort, der Preis des Ratens ist also kein schwächerer Feed, sondern ein abgelehnter Schreibvorgang. Das ist die Arbeit, die diese Anbindung abnimmt: Ihr Produkt sendet eine Bewegung einmal, in einem Vokabular, und welcher Endpunkt daraus wird, entscheidet sich darunter.

Was sich dadurch in der Praxis ändert, ist, wann die Buchung existiert, und nicht, ob sie entstehen kann. Eine Bewegung kann an dem Tag in die Bücher kommen, an dem sie ausgeglichen wird, statt an dem Tag, an dem sich jemand an den Export erinnert, und die Person, die sie zuordnet, arbeitet weiter dort, wo sie das ohnehin tut. Es ändert auch, was Ihre Roadmap tragen muss: eine Anbindung zu pflegen statt einer je Buchhaltungssystem über einen Kundenstamm, den Sie nicht steuern.

Der Abstand zwischen den Schreibzeilen und den Lesezeilen macht daraus eine Einbahnstraße. Das Schreiben ist gut abgedeckt, weil jedes Buchhaltungssystem etwas hereinlassen muss, und jedes von ihnen hat eine Meinung dazu, wie dieses Etwas heißt. Das Lesen ist dünn, weil eine Bankbewegung in diesem Modell überhaupt kein Objekt ist: sie ist eine Buchung, ein Vorschlag oder eine Zahlung, je nachdem, wie sie dorthin kam. Deshalb können sich auch zwei Seiten Endpunkte teilen und trotzdem verschieden zählen: die Zeilen, die sie brauchen, sind nicht dieselben.

Eine Vorsichtsregel zum Wortschatz. Das Objekt, das in der Dokumentation Transaction heißt, ist ein Auffangbecken für Datensätze, die nicht in die anderen Modelle passen, und keine Bankbewegung per Definition. Es ist der richtige Behälter für eine, und das Beispiel der Anfrage ist eine Kartenzahlung, aber der Name ist breiter als der Use Case, und nichts hier ist als Kontoauszugs-Feed zu lesen. Die Systeme, denen ein europäischer Anbieter auf diesen Wegen am häufigsten begegnet, lohnen sich vor dem Zuschnitt einzeln zu prüfen: DATEV Unternehmen Online, Lexware Office, sevdesk und Exact Online. Was die Anbindung behält und wie lange, steht auf der Sicherheitsseite.