What Is a Double-Entry Ledger API for Marketplaces?

A double-entry ledger API records marketplace money movement as balanced, immutable journal entries so you always know who is owed what and why.

Ein Marktplatz kann in seiner orders-Tabelle völlig gesund aussehen und trotzdem falsche Finanzdaten ausweisen. Die Bestellung zeigt den Status „bezahlt“. Das Verkäufer-Dashboard weist einen Saldo aus. Doch nichts in dieser Tabelle beweist, wie viel Geld sich tatsächlich im Besitz der Plattform befindet, wie viel sie jedem einzelnen Verkäufer schuldet, welcher Teil der Zahlung auf Provisionen entfällt oder wie viel Mehrwertsteuer nun abzuführen ist. Eine API für doppelte Buchführung (double-entry ledger API) dient dazu, diese finanziellen Konsequenzen korrekt aufzuzeichnen – und zwar transaktionsbasiert mit jeweils ausgeglichenen Werten.

Klar ausgedrückt: Eine Ledger-API ist ein programmierbares Buchhaltungssystem. Ihre Anwendung übermittelt ein finanzwirksames Ereignis – wie etwa eine eingezogene Zahlung oder eine freigegebene Auszahlung –, und das Ledger verbucht dieses Ereignis als Buchungssatz (Journal) mit gleichen Soll- und Haben-Beträgen auf Konten mit entsprechenden Bezeichnungen. Dabei wird kein Geld bewegt. Es wird lediglich die Wahrheit über Geldflüsse abgebildet, die an anderer Stelle stattgefunden haben.

Was „doppelte Buchführung“ in diesem Zusammenhang bedeutet

Ein Ledger ist die Aufzeichnung von Änderungen auf Konten und keine Tabelle, die einfach nur den aktuellen Kontostand anzeigt. Ein funktionierendes Ledger basiert auf drei miteinander verknüpften Konzepten:

Konto (Account): eine benannte finanzielle Position, wie beispielsweise Forderungen aus Zahlungsdienstleistern, Verbindlichkeiten gegenüber Verkäufern, Provisionserlöse oder Umsatzsteuerverbindlichkeiten.
Transaktion (Journal): ein atomares finanzielles Ereignis, das mehrere ausgeglichene Buchungszeilen enthält.
Buchungseintrag (Posting): eine einzelne Soll- oder Haben-Zeile innerhalb dieser Transaktion.

Die grundlegende Invariante, die jeden Entwurf zusammenhält, ist simpel: Die Summe der Soll-Beträge entspricht stets der Summe der Haben-Beträge – und das für jede Transaktion und in jeder Währung. Ledger-APIs lehnen unausgeglichene Schreibvorgänge in der Regel ab, bevor diese überhaupt gespeichert werden. In der Dokumentation von Modern Treasury wird eine Ledger-Transaktion so definiert, dass sie zwei oder mehr Konten mit mindestens einer Soll- und einer Haben-Buchung gleicher Gesamtsumme umfasst, wobei eine festgeschriebene Transaktion als unveränderlich (immutable) gilt.

Doppelte Buchführung bedeutet dabei nicht zwingend genau zwei Zeilen. Ein einzelner Marktplatzverkauf erfordert oft eine Soll-Buchung und mehrere Haben-Buchungen. Genau das ist der Punkt, der am häufigsten missverstanden wird.

Warum Marktplätze ein Ledger statt nur einer Zahlungstabelle brauchen

Ein Marktplatz unterhält gleichzeitig mehrere finanzielle Beziehungen. Ein Käufer bezahlt. Ein Zahlungsdienstleister beglichen die Forderung. Die Plattform verwaltet die Gelder möglicherweise vorübergehend. Der Verkäufer erwirtschaftet einen Anteil. Die Plattform behält eine Provision ein. Steuern werden fällig. Eventuell wird eine Sicherheitseinbehaltung (Reserve) einbehalten. Später fließen die Gelder durch eine Auszahlung ab, während Rückerstattungen oder Chargebacks Teile davon rückgängig machen.

Eine payments-Tabelle kann Ihnen zwar den kommerziellen Status einer Bestellung nennen. Sie kann Ihnen jedoch nicht verlässlich Auskunft darüber geben, über:

wie hoch die Forderungen an den Zahlungsdienstleister oder der Kassenbestand sind
wie viel Geld den einzelnen Verkäufern geschuldet wird
wie hoch die Erlöse der Plattform sind
wie viel Mehrwertsteuer geschuldet wird und in welchem Land
welche Beträge als Rückstellungen für Rückerstattungen oder Streitfälle einbehalten wurden
ob eine Auszahlung die korrekte Verkäuferverbindlichkeit gemindert hat
ob die Abrechnungen des Zahlungsdienstleisters den Erwartungen der Plattform entsprechen

Der Leitfaden von Nordlet zu Ledger-APIs für die Marktplatzbuchhaltung zieht hier eine klare Trennlinie: Anwendungstabellen beschreiben den Produktstatus, während das Ledger die finanziellen Konsequenzen dieses Status aufzeichnet. Zudem wird ein Punkt hervorgehoben, den man gar nicht oft genug wiederholen kann: Berichte von Zahlungsdienstleistern sind Eingangswerte für den Abgleich, jedoch keine vollständigen Bücher der doppten Buchführung.

Ein durchgerechneter Marktplatzverkauf

Nehmen wir an, ein Käufer zahlt 100 €, der Verkäufer hat Anspruch auf 85 € und die Plattformprovision beträgt 15 €. Aus Gründen der Übersichtlichkeit ignorieren wir Mehrwertsteuer und Zahlungsgebühren.

Konto	Soll (Debit)	Haben (Credit)	Grund
Forderungen aus Zahlungsdienstleistern	100 €		Der Dienstleister schuldet der Plattform die eingezogene Zahlung
Verbindlichkeiten gegenüber Verkäufern		85 €	Die Plattform schuldet dem Verkäufer Geld
Provisionserlöse		15 €	Die Plattform hat ihre Provision verdient
Summe	100 €	100 €	Ausgeglichen

Die wichtige Einordnung hierbei lautet, dass die dem Verkäufer geschuldeten 85 € eine Verbindlichkeit darstellen und kein Plattformumsatz sind. Nach dem IFRS-Rahmenkonzept ist eine Verbindlichkeit eine gegenwärtige Verpflichtung zur Übertragung einer wirtschaftlichen Ressource. Ein Marktplatz sollte nicht die gesamten Verkaufserlöse des Verkäufers als eigene Einnahmen ausweisen, bloß weil der Käufer über ihn bezahlt hat. Ob Sie als Kommissionär (Agent), Prinzipal oder fiktiver Lieferant (deemed supplier) agieren, ändert zwar die steuerliche Behandlung, aber der Buchungsmechanismus im Ledger bleibt derselbe.

Wenn der Verkäufer die Voraussetzungen für eine Auszahlung erfüllt, wird dadurch kein neuer Umsatz realisiert. Sie gleichen lediglich die Verbindlichkeit aus:

Konto	Soll (Debit)	Haben (Credit)
Verbindlichkeiten gegenüber Verkäufern	85 €
Bank oder Auszahlungsverrechnung		85 €
Summe	85 €	85 €

Wenn der Zahlungsdienstleister vor der Auszahlung eine Gebühr von 3 € einbehält, wird die Geldbewegung zu einem Buchungssatz mit drei Zeilen: 97 € an Bankguthaben, 3 € als Bearbeitungsaufwand, 100 € Abgang aus Forderungen gegen den Zahlungsdienstleister. Jede Positionsänderung hat eine Quelle und ein Ziel.

Funktionsweise der API Schritt für Schritt

1. Ihre Anwendung erkennt ein geschäftliches Ereignis. Eine Zahlung wird eingezogen, eine Bestellung erfüllt, eine Auszahlung genehmigt, eine Rückerstattung veranlasst, ein Chargeback eingereicht oder eine Abrechnung geht ein. Ihre Datenbank verwaltet weiterhin den operativen Status. Das Ledger zeichnet die monetären Auswirkungen auf.

2. Sie senden eine strukturierte Anfrage. Diese enthält in der Regel den Ereignistyp, Betrag und Währung, Bestell- oder Zahlungs-ID, Käufer- und Verkäuferkennungen, Provision, Steuerdaten, die betroffenen Konten, Wertstellungs- und Buchungsdatum, einen Idempotenz-Schlüssel sowie Metadaten, die auf die Datensätze des Zahlungsdienstleisters und des Produkts verweisen. Das Beispiel der öffentlichen API von Nordlet zeigt eine konzeptionelle Verkaufsanfrage mit Verkäufer-ID, Verkaufstyp, Betrag, Währung sowie Mehrwertsteuerland und -satz.

3. Die API führt Validierungen durch. Sie prüft, ob Soll und Haben ausgeglichen sind, ob die Konten existieren und bebuchbar sind, ob die Währung unterstützt wird, ob der Betrag eine präzise Verarbeitung auf Untereinheitsebene (minor units) verwendet, ob der Idempotenz-Schlüssel nicht für ein anderes Ergebnis wiederverwendet wurde, ob die Abrechnungsperiode offen ist und ob die erforderlichen Metadaten vorhanden sind. Eine fehlgeschlagene Prüfung hinterlässt kein unvollständiges Journal im System.

4. Die Buchung erfolgt atomar. Die gesamte Transaktion wird als eine Einheit geschrieben. Es darf niemals vorkommen, dass eine Soll-Buchung aufgezeichnet wird, während die dazugehörige Haben-Buchung fehlschlägt. Für einen Marktplatz könnte eine unvollständige Aufteilung dazu führen, dass ein scheinbarer Verkäufersaldo ohne entsprechende Liquidität entsteht oder Provisionen verbucht werden, ohne dass die Verkäuferverpflichtung erfasst wird.

5. Salden und Berichte werden aus dem Ledger abgeleitet. Nach der Buchung können Sie Kontostände, ausstehende und verfügbare Verkäufersalden, eine Summen- und Saldenliste (trial balance), Hauptbuchaktivitäten, Mehrwertsteuerübersichten und historische Stichtagssalden abrufen. Der Verkäufersaldo sollte sich aus den Buchungssätzen rekonstruieren lassen und nicht blind aus einem veränderlichen Feld übernommen werden.

6. Webhooks benachrichtigen Ihr Produkt. Ereignisse wie sale_invoice.paid, ein verbuchtes Journal, eine verfügbare Auszahlung oder eine Unstimmigkeit beim Abgleich werden an Sie übermittelt. Verarbeiten Sie diese idempotent. Ein Webhook ist eine Benachrichtigung und keine Erlaubnis, dasselbe finanzielle Ereignis ein zweites Mal anzuwenden. Die API-Konventionen behandeln Bereiche, Idempotenz-Schlüssel, Fehlerstrukturen und die Webhook-Signierung im Detail.

Verkäufersalden sind keine einfache Gesamtzahl

Die meisten Marktplätze geraten in Schwierigkeiten, wenn sie einen Verkäufersaldo als einen einzigen Wert behandeln. Gelder sollten in verschiedenen Zuständen gehalten werden:

Status	Bedeutung
Ausstehend (Pending)	Der Verkäufer hat möglicherweise Anspruch darauf, aber die Auszahlungsbedingungen sind noch nicht erfüllt
Verfügbar (Available)	Bereit für die Auszahlung
Zurückgehalten (Reserved)	Einbehalten als Sicherheit für Rückerstattungen, Retouren oder Streitfälle
Ausgezahlt (Paid out)	Verbindlichkeit durch Überweisung beglichen
Negativ (Negative)	Rückerstattungen, Chargebacks oder Gebühren übersteigen das verfügbare Guthaben

Die Modelle von Zahlungsdienstleistern spiegeln dies wider. Die getrennten Zahlungs- und Transferströme von Stripe ermöglichen es einer Plattform, das eigene Konto zu belasten und dann Teilbeträge auf verknüpfte Konten zu übertragen, wobei Gebühren, Rückerstattungen und Chargebacks den Saldo der Plattform belasten. Das Marktplatzmodell von Adyen unterscheidet zwischen Guthabenkonten für Benutzer (user balance accounts), die Gelder bis zur Auszahlung halten, und einem Haftungskonto (liable balance account), das negative Salden aus Rückerstattungen oder Chargebacks auffangen kann. Diese sind nützliche Eingangswerte für Ihr Ledger, bilden jedoch nicht Ihr vollständiges Buchhaltungsmodell ab.

Auszahlungen und Verkäufererlöse erfolgen zu unterschiedlichen Zeitpunkten

Ein Verkäufer kann am Montag Umsätze erzielen und am folgenden Montag ausgezahlt werden. Zwischen diesen Zeitpunkten wird eine Bestellung abgewickelt, eine Sicherheitseinbehaltung gebildet, ein Auszahlungsstapel erstellt, eine Abrechnung des Zahlungsdienstleisters abzüglich Gebühren erstellt und eine Bankgutschrift gutgeschrieben. Ein Ledger muss jede dieser Phasen abbilden, anstatt die Bestellung einfach mit einem finalen „bezahlt“ zu überschreiben. Genau das versetzt Sie in die Lage, Zeitdifferenzen zwischen Bestellaktivität, Verkäuferanspruch, Abrechnung, Auszahlungsanweisung und Zahlungseingang auf der Bank zu erklären.

Rückerstattungen und Chargebacks: Stornieren, nicht überschreiben

Rückerstattungen und Chargebacks sind neue Ereignisse, die mit der ursprünglichen Zahlung verknüpft sind. In einem unveränderlichen Ledger korrigieren Sie Fehler durch eine Gegenbuchung (Stornierung) gefolgt von einer korrigierten Buchung, sodass das Original für die Prüfung (Audit) sichtbar bleibt. Modern Treasury betrachtet festgeschriebene Transaktionen als unveränderlich und unterstützt Idempotenz-Schlüssel, um doppelte Objekte bei Wiederholungsversuchen zu verhindern.

Eine Rückerstattung mindert typischerweise den Kassenbestand oder die Käuferforderung, storniert die Verkäuferverbindlichkeit, kann je nach Richtlinie einen Teil der Provision rückgängig machen, passt die Steuer an und kann eine Rückerstattungsreserve beanspruchen. Ein Chargeback mindert den Kassenbestand oder die Forderung gegen den Zahlungsdienstleister, kann einen vom Verkäufer oder der Plattform geschuldeten Betrag erneut öffnen, verbucht Streitkosten sowie Dienstleistergebühren und leitet Gelder über ein Reservekonto um.

Abgleich (Reconciliation): Das Ledger mit echtem Geld verknüpfen

Ein Ledger kann intern ausgeglichen sein und dennoch bezüglich der Aussenwelt falsch liegen. Beim Abgleich werden interne Aufzeichnungen mit externen Nachweisen verglichen: Abrechnungsberichten von Zahlungsdienstleistern, Kontoauszügen, Auszahlungsdateien sowie Berichten zu Rückerstattungen und Streitfällen.

Ein funktionierender Ablauf sieht wie folgt aus:

Importieren Sie den Abrechnungs- oder Bankstapel.
Ordnen Sie jede Zeile einer Bestellung, Zahlung, Rückerstattung, Gebühr, Auszahlung oder einem Streitfall zu.
Vergleichen Sie erwartete Bruttobeträge, Abzüge, Rückstellungen und Nettobeträge.
Verbuchen Sie bestätigte Bewegungen im Ledger.
Leiten Sie nicht zuordenbare Positionen auf ein benanntes Notkonto (suspense account) um.
Untersuchen Sie Unstimmigkeiten.
Sperren Sie die Abrechnungsperiode.

Das Material von Nordlet zum Abgleich beschreibt genau diesen Prozess: den Import von Abrechnungsstapeln, das Abgleichen von Belastungs- und Rückerstattungszeilen sowie die Weiterleitung nicht zuordenbarer Einnahmen auf ein Notkonto, anstatt bei einer Rechnung zu raten. Zwei Prüfungen sind wichtig, wobei keine die andere ersetzt: Die doppelte Buchführung prüft, ob jedes Journal ausgeglichen ist, während der Abgleich prüft, ob die Daten mit dem Zahlungsdienstleister, der Bank und dem geschäftlichen Ereignis übereinstimmen.

Design-Details, die über den Erfolg entscheiden

Idempotenz. Verknüpfen Sie den Schlüssel mit einem stabilen Ereignis, wie etwa payment_captured:pi_123. Ein neuerlicher Versuch liefert das ursprüngliche Ergebnis zurück und erzeugt kein zweites Journal.

Atomarität. Alle Zeilen eines Ereignisses werden zusammen verbucht oder keine davon.

Unveränderlichkeit (Immutability) und Stornierungen. Die gebuchte Historie ist nicht über gewöhnliche Aktualisierungen editierbar. Korrekturen erzeugen verknüpfte Einträge, die den ursprünglichen Betrag, das Datum, die Klassifizierung, den Grund und den Bearbeiter bewahren.

Präzise Geldbeträge. Keine Gleitkommazahlen (binary floating point). Verwenden Sie ganzzahlige Untereinheiten (minor units) oder exakte Dezimalzahlen, eine explizite Währung und eine deterministische Rundungsregel für Aufteilungen. Wenn Sie 100 € ohne eine solche Regel auf Verkäufer und Gebühren aufteilen, bricht ein einzelner verloren gegangener Cent Ihre Bilanz.

Wertstellungs- und Buchungsdatum. Der Zeitpunkt, zu dem der Käufer bezahlt hat, der Verkäufer das Geld verdient hat, die Bank abgerechnet hat und die Buchung erfolgt ist, sind unterschiedliche Daten. Wenn man diese vermischt, werden Berichte über Geschäftsperioden und das steuerliche Timing unzuverlässig.

Multi-Währungs-Fähigkeit. Soll und Haben sollten innerhalb einer Währung ausgeglichen sein. Die Konversion erfordert ein explizites Kursereignis mit Konten für Gebühren, Rundungen und etwaige Kursgewinne oder -verluste. Die Akzeptanz eines currency-Feldes macht ein Ledger noch lange nicht zu einer Devisen-Engine.

Was eine Ledger-API für Sie nicht leisten kann

Sie bestimmt nicht Ihren Kontenplan. Sie müssen nach wie vor festlegen, ob Sie als Prinzipal oder Kommissionär (Agent) agieren, wann Provisionen verdient sind, welche Partei die Zahlungsdienstleistergebühren trägt, wie sich Rückerstattungen auf Provisionen auswirken und wie die Mehrwertsteuer berechnet und gemeldet wird. Der Leitfaden von Nordlet empfiehlt, zuerst die Geldflüsse abzubilden, den Kontenplan zu entwerfen, diesen von einem Steuerberater prüfen zu lassen und dann einen vollständigen Durchlauf von der Bestellung über die Auszahlung bis zum Abgleich zu implementieren, bevor skaliert wird.

Steuerfragen werden damit ebenfalls nicht automatisch gelöst. Die Mehrwertsteuer hängt vom Standort des Käufers und Verkäufers, dem Produkttyp, dem Registrierungsstatus und den Vorschriften für fiktive Lieferanten (deemed-supplier rules) ab; der EU-Mehrwertsteuer-Leitfaden legt dar, was die Engine ableitet und was sie für eine manuelle Prüfung markiert. Die Abdeckung der Mehrwertsteuer durch Nordlet konzentriert sich auf die EU und den EWR und erstreckt sich somit nicht auf die US-amerikanische Umsatzsteuer (sales tax) oder die lateinamerikanische E-Invoicing-Rechtsordnung. Auch operative Unklarheiten werden nicht gelöst – etwa ob ein Rückgabefenster abgelaufen ist, ob eine Auszahlung blockiert werden sollte oder ob eine Zahlung betrügerisch ist. Das sind Ihre unternehmerischen Entscheidungen. Das Ledger zeichnet lediglich deren finanzielles Ergebnis auf.

Wo sich Nordlet einfügt

Nordlet ist eine Buchhaltungs-API für Plattformen und Marktplätze mit einem unveränderlichen Hauptbuch der doppten Buchführung, Auszahlungsfunktionen, EU-Mehrwertsteuerabwicklung, REST-Endpunkten, typisierten SDKs und Webhooks, die über eine einzige Schnittstelle erreichbar sind. Das herausstellende Merkmal ist die integrierte Buchhaltung direkt in Ihrem eigenen Produkt anstelle einer Kassenlösung eines Drittanbieters. Zum Zeitpunkt dieses Schreibens befindet sich das Produkt im Early Access mit einer Sandbox für Design-Partner, weshalb Sie es als starkes Beispiel für diese Kategorie betrachten und Produktionsreife, Betriebszeit sowie die rechtliche Abdeckung für Ihren konkreten Anwendungsfall vor einer verbindlichen Entscheidung prüfen sollten.

Für Entwickler von Marktplätzen und Plattformen ist das nützliche mentale Modell die Trennung zwischen Zahlungsströmen und finanzieller Wahrheit. Ihr Zahlungsdienstleister bewegt das Geld. Eine API für doppelte Buchführung zeichnet auf, wer wem was schuldet, was Sie verdient haben, welche Steuern und Rückstellungen Sie vorhalten und ob die Aussenwelt mit Ihren Büchern übereinstimmt.

FAQ

Ist eine API für doppelte Buchführung dasselbe wie ein Zahlungsdienstleister?

Nein. Ein Zahlungsdienstleister autorisiert, zieht ein, rechnet ab und zahlt Gelder bisweilen aus. Eine Ledger-API zeichnet die buchhalterischen Konsequenzen dieser Ereignisse auf. Die meisten Marktplätze nutzen beides: einen Dienstleister wie Stripe oder Adyen für den Geldfluss und ein Ledger für die Bücher.

Kann ich einfach das Dashboard meines Zahlungsdienstleisters als Hauptbuch nutzen?

Sie können es versuchen, aber früher oder später wird dies bei einer Prüfung (Audit) scheitern. Berichte von Zahlungsdienstleistern zeigen zwar Belastungen, Gebühren, Transfers und Abrechnungen, bilden jedoch in der Regel weder Ihre vollständigen Verkäuferverpflichtungen, Steuerverbindlichkeiten und Aufwendungen außerhalb des Dienstleisters noch buchhalterische Anpassungen ab. Betrachten Sie diese Daten als Eingangsquelle für den Abgleich.

Bedeutet ein ausgeglichenes Ledger, dass meine Bücher fehlerfrei sind?

Das bedeutet lediglich, dass Ihre Buchungen die Soll-Haben-Regel erfüllen. Eine perfekt ausgeglichene Transaktion kann trotzdem auf dem falschen Konto, beim falschen Verkäufer oder mit der falschen steuerlichen Behandlung verbucht worden sein. Die Bilanzsumme ist eine notwendige, aber keine hinreichende Bedingung. Der Abgleich fängt den Rest auf.

Wie behebe ich Fehler, wenn das Ledger unveränderlich ist?

Sie verbuchen eine Gegenbuchung (Stornierung) und danach eine korrigierte Buchung. Das Original bleibt sichtbar, was genau der Sinn der Sache ist. Die Unveränderlichkeit schützt den Prüfpfad (audit trail), sie versperrt Ihnen jedoch nicht den Weg zur Fehlerkorrektur.

Macht mich eine Buchhaltungs-API automatisch compliance-konform?

Nein. Sie erzwingt eine buchhalterische Struktur und erstellt verwendbare Aufzeichnungen. Die rechtliche Compliance hängt weiterhin von Ihrer Jurisdiktion, Ihrer vertraglichen Rolle, der steuerlichen Behandlung, den Zahlungsverkehrsvorschriften, den KYC- und AML-Prozessen sowie Ihren Meldepflichten ab.