Factoring auf der Rechnung, die Ihr Kunde ausgestellt hat

Die ersten drei Schritte sind die, die jeder Finanzierer braucht, und sie gelten über die Systeme hinweg, die überhaupt Rechnungen zurückgeben. Die letzten zwei prüft man besser je Kunde, statt sie anzunehmen, und dafür stehen die Zahlen daneben. Einen Kunden anzubinden ist eine Authentifizierung und kein Integrationsprojekt, und die Objektformen, die zurückkommen, hängen nicht davon ab, welches System er gewählt hat, dafür ist das Common Data Model da. Die Mechanik der Verbindung selbst ist unter Unified Authentication beschrieben.

Wann Sie es erfahren, ist eine andere Frage als was Sie lesen können, und sie entscheidet darüber, ob die Finanzierung am Tag der Ausstellung stattfindet. Wo das System ein Rechnungs-Event auslöst, erfahren Sie vom Datensatz, sobald er auftaucht, und holen genau diesen; die Mechanik und die Unterschiede je System stehen auf der Webhooks-Seite. Wo es das nicht tut, fragen Sie, und ein inkrementeller Lesezugriff gibt zurück, was sich seit dem letzten bewegt hat, statt noch einmal das Hauptbuch.

Die Filter darunter entscheiden, wie viel von dieser Frage nützt. Nur zu lesen, was sich geändert hat, ist am breitesten dokumentiert; nach Rechnungsstatus zu filtern liegt dicht dahinter; nach Fälligkeit zu filtern ist auf einem System dokumentiert. Der Status ist das Feld, auf das man selektiert: er trägt offen, teilweise bezahlt, überfällig, bezahlt oder storniert, und er ist das Feld, das über die Systeme hinweg gefüllt ist. Ein zweites Feld, das nach der Zahlung benannt ist, gibt es auf einer Handvoll und ist auch dort meist leer, es lohnt sich also zu lesen, wo es da ist, und nicht, darauf zu filtern. Die Form, die sich verallgemeinern lässt, ist also, zu holen, was sich geändert hat, und die eigene Auswahl auf das Ergebnis anzuwenden, was zugleich die Antwortgrößen vorhersehbar hält. Paginierte, filterbare Lesezugriffe decken das ab, und wo ein System einen großen Lesezugriff als Hintergrundauftrag beantwortet, kommt er als eine Aufgabe, die Sie abfragen.

Die unteren drei Zeilen lohnt es sich als Warnung zum Wortschatz zu lesen. Offene Posten nennt ein Finanzierer das, was er haben will, und als eigenes Objekt sind sie selten lesbar. Der dokumentierte Weg zu derselben Tatsache ist die Rechnungsliste, gefiltert nach Status und Fälligkeitsdatum, und deshalb trägt die erste Zeile diesen Use Case und die letzte nicht. Zahlungen als eigenes Objekt sind ebenso dünn, und die Ausgleichsinformation, die ein Finanzierer braucht, steht stattdessen auf der Rechnung.

Der Schuldner ist die andere Stelle, an der ein Name und eine Nummer nicht dasselbe sind. Firmenname, Straße, Ort, Postleitzahl und E-Mail kommen von jedem System, das Kunden zurückgibt, und das genügt, um einem Menschen zu zeigen, wer das Geld schuldet. Eine Umsatzsteuer-Identifikationsnummer, auf der eine Prüfung der Gegenpartei läuft, veröffentlichen nur ein paar davon. Kunden zwischen Ihrer Plattform und dem System, aus dem sie kamen, im Gleichstand zu halten, ist die Kunden- und Lieferantenstammdatensynchronisation, und dieselben Datensätze von der Mahnseite aus gesehen sind das Forderungsmanagement.

Die Systeme, denen ein europäischer Factoring-Anbieter hier am häufigsten begegnet, lohnen sich vor dem Zuschnitt zu lesen, denn sie unterscheiden sich auf diesen Endpunkten stärker, als die Summen nahelegen: Xero, Lexware Office, sevdesk, Microsoft Dynamics 365 Business Central und Qonto. Wie die Anbindung unterwegs gehostet und abgesichert ist, steht auf der Sicherheitsseite.