Debitorenbuchhaltung beginnt vor der Rechnung

Der erste Schritt ist gar kein Aufruf, er ist ein anderer Use Case. Der Leitfaden beginnt damit, den Kontaktabgleich einzurichten, damit der Kunde in Ihrer Datenbank und der Kunde in der Buchhaltungsplattform Ihres Nutzers nachweislich dieselbe Partei sind. Das ist keine Bürokratie. Eine Forderung, die auf einen fast doppelten Kundendatensatz gebucht wird, ist die Art Fehler, die niemandem auffällt, bis ein Kontoauszug herausgeht, und dann kostet sie jemanden einen Nachmittag. Diese Arbeit hat ihre eigene Seite, die Synchronisation von Kunden- und Lieferantenstammdaten.

Danach kommen die Strukturen: das Sachkonto, auf das die Rechnung bucht, die verwendeten Steuersätze, und die Dimensionen, die ihre Einrichtung erwartet, falls sie welche nutzen. Nichts davon liegt in Ihrem Produkt, alles unterscheidet sich je Kunde, und jede dieser Stellen macht aus einer sonst korrekten Rechnung eine Korrektur. Besonders die Steuersätze sind weniger einheitlich, als sie aussehen, und das ist ein Thema für sich unter Steuerautomatisierung.

Erst dann taucht die Rechnung auf, und an diesem Punkt ist die interessante Frage nicht mehr, wie man sie sendet. Sie lautet, welchen der dokumentierten Wege sie nehmen soll.

Die zwei sitzen an verschiedenen Punkten derselben Linie. Debitorenmanagement ist dieser Use Case unter einem anderen Namen, und Inkasso ist das, was aus dem unbezahlten Rest wird. Beide brauchen dieselben Dinge aus dem Hauptbuch des Gläubigers, und das ist das Argument für eine Anbindung statt einer je Ablauf, und das Inkasso-Ende davon ist unter dem Forderungsmanagement beschrieben.

Alles links ist die Anbindung bei dem, was eine Anbindung tun soll: dieselben Objekte, unter denselben Namen, auf welchem System Ihr Kunde auch läuft, in beide Richtungen. Das ist der Teil, der sonst eine Anbindung je Buchhaltungsplattform wäre, jede mit eigener Authentifizierung, eigenen Feldnamen und einer eigenen Meinung darüber, was ein Kundendatensatz enthält.

Alles rechts ist Ihr Produkt, und der Leitfaden sagt ausdrücklich, dass das Absicht ist. Er gibt Ihnen die Konten, die Sätze und die Dimensionen und sagt dann, die Geschäftslogik werde von Ihrer Anwendung abhängen. Ob eine Forderung auf ein einzelnes Sachkonto oder auf eine bedingte Regel abgebildet wird, ob Ihre Nutzer das im Moment der Übertragung überschreiben können, und wann eine Übertragung überhaupt stattfindet, sind Produktentscheidungen mit den Buchhaltungsgepflogenheiten Ihrer Kunden dahinter. Eine Schicht, die sie für Sie beantwortete, riete an der Absicht eines Buchhalters herum.

Eine Eigenschaft gehört hierher und nicht auf die Sicherheitsseite. Anfragen werden verarbeitet, wie sie eintreffen, und was Maesn behält, ist der Nachweis, dass eine Übertragung stattgefunden hat, und nicht die übertragenen Daten. Für ein Produkt, das Kunden- und Umsatzdaten anderer Firmen verarbeitet, ist weniger davon zu halten leichter zu verteidigen. Der lastModified-Filter auf den Lese-Endpunkten ist das, was Aktualität billig macht, ohne eine Kopie irgendeines Hauptbuchs zu halten.

Wer zuerst bemerkt, dass eine Forderung altert, sind Finanzteams, bevor es irgendwen sonst erreicht.