Was ist eine API für die doppelte Buchführung für Marktplätze?

Eine API für die doppelte Buchführung erfasst Geldbewegungen von Marktplätzen in Form von saldierten, unveränderlichen Buchungssätzen, damit Sie immer wissen, wem was geschuldet wird und warum.

Ein Marktplatz kann in seiner orders-Tabelle gesund aussehen und dennoch falsche Finanzdaten aufweisen. Die Bestellung steht auf „bezahlt“. Das Verkäufer-Dashboard zeigt ein Guthaben. Aber nichts in dieser Tabelle belegt, wie viel Liquidität die Plattform hält, wie viel sie jedem Verkäufer schuldet, wie viel der Zahlung Provisionserlöse sind oder wie viel Umsatzsteuer nun fällig wird. Eine API für die doppelte Buchführung (Double-Entry Ledger API) dient dazu, genau diese finanziellen Konsequenzen korrekt zu erfassen – Buchungssatz für Buchungssatz in stets ausgeglichener Form.

Einfach ausgedrückt: Eine Double-Entry Ledger API ist ein programmierbares Buchhaltungssystem. Ihre Anwendung sendet ihr ein finanzielles Ereignis, wie eine eingezogene Zahlung oder eine freigegebene Auszahlung, und das Hauptbuch (Ledger) verbucht dieses Ereignis als Journalbuchung mit identischen Soll- und Haben-Beträgen auf den entsprechenden Konten. Sie bewegt kein Geld. Sie dokumentiert die Wahrheit über das Geld, das an anderer Stelle bewegt wurde.

Was „doppelte Buchführung“ hier bedeutet

Ein Hauptbuch ist die Aufzeichnung von Kontobewegungen, nicht bloß eine Tabelle, die den aktuellen Saldo speichert. Ein funktionierendes Hauptbuch besteht aus drei zusammenhängenden Konzepten:

Konto (Account): eine benannte finanzielle Position, wie z. B. Forderungen gegenüber dem Zahlungsabwickler, Verbindlichkeiten gegenüber Verkäufern, Provisionserlöse oder Umsatzsteuerverbindlichkeiten.
Transaktion (Journal): ein atomares finanzielles Ereignis, das mehrere saldierte Zeilen umfasst.
Buchung (Posting): eine einzelne Soll- oder Haben-Zeile innerhalb dieser Transaktion.

Die Invariante, die jedes System zusammenhält, ist simpel: Die Summe im Soll entspricht der Summe im Haben – für jede Transaktion und in jeder Währung. Ledger-APIs lehnen eine unausgeglichene Buchung in der Regel ab, bevor sie gespeichert wird. Die Dokumentation von Modern Treasury definiert eine Ledger-Transaktion als Vorgang, der zwei oder mehr Konten mit mindestens einer Soll- und einer Haben-Buchung in identischer Gesamthöhe betrifft, und behandelt eine abgeschlossene Buchung als unveränderlich (immutable).

„Doppelte Buchführung“ bedeutet nicht zwingend genau zwei Zeilen. Ein einzelner Verkauf auf einem Marktplatz erfordert oft eine Soll-Buchung und mehrere Haben-Buchungen. Das ist der Punkt, der am häufigsten falsch verstanden wird.

Warum Marktplätze ein Hauptbuch brauchen und nicht nur eine Zahlungstabelle

Ein Marktplatz unterhält mehrere finanzielle Beziehungen gleichzeitig. Ein Käufer zahlt. Ein Zahlungsabwickler rechnet ab. Die Plattform hat möglicherweise vorübergehend die Kontrolle über die Gelder. Der Verkäufer verdient einen Anteil. Die Plattform behält eine Provision ein. Steuern werden fällig. Möglicherweise wird eine Rücklage (Reserve) einbehalten. Später wird das Geld durch eine Auszahlung transferiert, und Rückerstattungen oder Rückbelastungen (Chargebacks) machen Teile davon wieder rückgängig.

Eine payments-Tabelle kann Ihnen den kaufmännischen Status einer Bestellung verraten. Sie kann Ihnen aber nicht verlässlich sagen:

in welcher Höhe Forderungen gegenüber dem Zahlungsabwickler oder liquide Mittel bestehen
wie viel jedem Verkäufer geschuldet wird
wie viel Umsatz der Plattform gehört
wie viel Umsatzsteuer fällig ist und in welchem Land
was für Rückerstattungen oder Konflikte (Disputes) zurückgestellt ist
ob eine Auszahlung die korrekte Verbindlichkeit gegenüber dem Verkäufer verringert hat
ob die Abrechnungen des Zahlungsabwicklers mit den Erwartungen der Plattform übereinstimmen

Nordlets Leitfaden zu APIs für die doppelte Buchführung für die Marktplatz-Buchhaltung zieht hier eine klare Grenze: Anwendungstabellen beschreiben den Status des Produkts, während das Hauptbuch die finanziellen Konsequenzen dieses Status dokumentiert. Er betont auch einen Punkt, der es wert ist, wiederholt zu werden: Berichte von Zahlungsabwicklern sind Eingangsdaten für die Kontenabstimmung (Reconciliation) und ersetzen nicht die komplette doppelte Buchführung.

Ein durchgerechneter Marktplatz-Verkauf

Angenommen, ein Käufer zahlt 100 €, der Verkäufer hat Anspruch auf 85 € und die Provision der Plattform beträgt 15 €. Um es übersichtlich zu halten, ignorieren wir Umsatzsteuer und Abwicklungsgebühren.

Konto	Soll	Haben	Grund
Forderungen gegenüber Zahlungsabwickler	100 €		Der Zahlungsabwickler schuldet der Plattform die eingezogene Zahlung
Verbindlichkeiten gegenüber Verkäufer		85 €	Plattform schuldet dem Verkäufer Geld
Provisionserlöse		15 €	Plattform hat ihre Provision verdient
Gesamt	100 €	100 €	Ist saldiert

Die wichtigste Klassifizierung hier ist, dass die dem Verkäufer geschuldeten 85 € eine Verbindlichkeit darstellen und keine Plattform-Erlöse. Gemäß dem Rahmenkonzept der IFRS ist eine Verbindlichkeit eine gegenwärtige Verpflichtung zur Übertragung einer wirtschaftlichen Ressource. Ein Marktplatz sollte nicht den gesamten Verkaufserlös des Verkäufers als eigene Erträge ausweisen, nur weil der Käufer über ihn bezahlt hat. Ob Sie als Handelsvertreter (Agent), Prinzipal (Principal) oder fiktiver Lieferant (Deemed Supplier) agieren, ändert zwar die bilanzielle Behandlung, der Mechanismus des Hauptbuchs bleibt jedoch derselbe.

Wenn der Verkäufer Anspruch auf eine Auszahlung hat, wird kein neuer Umsatz erfasst. Sie begleichen lediglich die Verbindlichkeit:

Konto	Soll	Haben
Verbindlichkeiten gegenüber Verkäufer	85 €
Bank oder Auszahlungs-Verrechnungskonto		85 €
Gesamt	85 €	85 €

Zieht der Zahlungsabwickler vor der Auszahlung eine Gebühr von 3 € ab, wird die Geldbewegung zu einem dreizeiligen Buchungssatz: 97 € auf das Bankkonto, 3 € in den Aufwand für Zahlungsabwicklung, 100 € Abgang bei den Forderungen an den Zahlungsabwickler. Jede Veränderung einer Position hat eine Herkunft und ein Ziel.

Wie die API funktioniert, Schritt für Schritt

1. Ihre Anwendung erkennt ein geschäftliches Ereignis. Eine Zahlung wird eingezogen, eine Bestellung wird abgewickelt, eine Auszahlung wird genehmigt, eine Rückerstattung wird veranlasst, ein Chargeback wird eröffnet, eine Abrechnung geht ein. Ihre Datenbank verwaltet weiterhin den operativen Status. Das Hauptbuch erfasst die monetären Auswirkungen.

2. Sie senden einen strukturierten Request. Dieser enthält in der Regel die Art des Ereignisses, Betrag und Währung, Bestell- oder Zahlungs-ID, Käufer- und Verkäufer-Identifikatoren, Provision, Steuerdaten, die beteiligten Konten, das Wirksamkeits- und Buchungsdatum, einen Idempotenz-Schlüssel (Idempotency Key) sowie Metadaten, die auf Abwickler- und Produktdatensätze verweisen. Das öffentliche API-Beispiel von Nordlet zeigt eine konzeptionelle Verkaufsanfrage mit Verkäufer-ID, Verkaufsart, Betrag, Währung sowie dem Land und Satz für die Umsatzsteuer.

3. Die API validiert. Sie prüft, ob sich Soll und Haben ausgleichen, ob die Konten existieren und bebuchbar sind, ob die Währung unterstützt wird, ob der Betrag die exakte Handhabung von Untereinheiten nutzt, ob der Idempotenz-Schlüssel nicht für ein anderes Ergebnis wiederverwendet wird, ob die Periode offen ist und ob erforderliche Metadaten vorhanden sind. Eine fehlgeschlagene Prüfung hinterlässt keine unvollständige Journalbuchung.

4. Sie bucht atomar. Die vollständige Transaktion wird als eine geschlossene Einheit geschrieben. Es sollte niemals möglich sein, die Soll-Buchung zu erfassen, während die zugehörige Haben-Buchung fehlschlägt. Bei einem Marktplatz könnte eine teilweise Aufsplittung zu einem scheinbaren Verkäufer-Guthaben ohne entsprechenden Cash-Bestand führen, oder Provisionserlöse ohne die zugehörige Verkäufer-Verbindlichkeit verbuchen.

5. Salden und Berichte werden aus dem Hauptbuch abgeleitet. Nach der Buchung können Sie Kontensalden, schwebende und verfügbare Verkäufer-Salden, eine Saldenbilanz (Trial Balance), Hauptbuchaktivitäten, Umsatzsteuerzusammenfassungen und die Historie zu einem vergangenen Stichtag abrufen. Der Verkäufer-Saldo sollte jederzeit aus den Buchungen rekonstruierbar sein, anstatt sich auf ein veränderliches Feld zu verlassen.

6. Webhooks benachrichtigen Ihr Produkt. Ereignisse wie sale_invoice.paid, eine erfasste Journalbuchung, eine verfügbare Auszahlung oder eine Ausnahme bei der Kontenabstimmung werden an Sie gepusht. Verarbeiten Sie diese idempotent. Ein Webhook ist eine Benachrichtigung, keine Erlaubnis, das finanzielle Ereignis ein zweites Mal zu verbuchen. Die API-Konventionen behandeln detailliert Scopes, Idempotenz-Schlüssel, Fehlermodelle und Webhook-Signaturen.

Verkäufer-Salden sind nicht nur eine einzelne Zahl

Die meisten Marktplätze geraten in Schwierigkeiten, weil sie den Verkäufer-Saldo als eine einzige Zahl behandeln. Geld sollte sich in verschiedenen Status befinden:

Status	Bedeutung
Ausstehend	Verkäufer hat möglicherweise Anspruch, aber Freigabebedingungen sind noch nicht erfüllt
Verfügbar	Berechtigt zur Auszahlung
Reserviert	Zurückbehalten für Rückerstattungen, Retouren oder Konflikte
Ausgezahlt	Verpflichtung durch Überweisung beglichen
Negativ	Rückerstattungen, Chargebacks oder Gebühren übersteigen die verfügbaren Mittel

Die Modelle der Zahlungsabwickler spiegeln dies wider. Der Flow für separate Belastungen und Überweisungen von Stripe ermöglicht es einer Plattform, ihr eigenes Konto zu belasten und dann Teile an verbundene Konten zu transferieren, wobei Gebühren, Rückerstattungen und Chargebacks auf dem Plattform-Saldo landen. Das Marktplatz-Modell von Adyen unterscheidet zwischen Nutzer-Guthabenkonten, die Gelder bis zur Auszahlung halten, und einem Haftungskonto, das negative Salden aus Rückerstattungen oder Chargebacks auffangen kann. Diese sind nützliche Eingangsdaten für Ihr Hauptbuch. Sie stellen jedoch nicht Ihr vollständiges Buchhaltungsmodell dar.

Auszahlungen und Verkäufer-Einnahmen finden zu unterschiedlichen Zeiten statt

Ein Verkäufer kann am Montag etwas verdienen und am darauffolgenden Montag bezahlt werden. Zwischen diesen beiden Zeitpunkten wird eine Bestellung abgewickelt, eine Rücklage gebildet, ein Auszahlungs-Batch erstellt, ein Abwickler rechnet abzüglich Gebühren ab und ein Bankeingang wird verzeichnet. Ein Hauptbuch muss jede Phase beibehalten, anstatt die Bestellung mit einem endgültigen „bezahlt“ zu überschreiben. Nur so lassen sich die zeitlichen Differenzen zwischen Bestellaktivität, Verkäufer-Anspruch, Abrechnung, Auszahlungsinitiierung und Bankeingang 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 Hauptbuch korrigieren Sie mit einer Stornobuchung, gefolgt von einer korrigierten Buchung, sodass das Original für Audits nachvollziehbar bleibt. Modern Treasury behandelt gebuchte Transaktionen als unveränderlich und unterstützt Idempotenz-Schlüssel, um Duplikate bei einem Neuversuch zu verhindern.

Eine Rückerstattung mindert typischerweise die Kasse oder die Käufer-Forderungen, storniert die Verbindlichkeit gegenüber dem Verkäufer, storniert je nach Richtlinie möglicherweise einen Teil der Provision, passt die Steuern an und kann eine Rückerstattungsrücklage aufbrauchen. Ein Chargeback reduziert die Kasse oder die Forderungen gegenüber dem Abwickler, öffnet möglicherweise wieder einen vom Verkäufer oder der Plattform geschuldeten Betrag, erfasst einen Aufwand für den Konflikt sowie eine Abwicklergebühr und leitet Gelder über ein Rücklagenkonto um.

Kontenabstimmung: Die Verbindung von Hauptbuch und echtem Geld

Ein Hauptbuch kann intern saldiert sein und dennoch ein falsches Bild der Außenwelt abbilden. Bei der Kontenabstimmung (Reconciliation) werden interne Aufzeichnungen mit externen Belegen abgeglichen: Abrechnungsberichte von Abwicklern, Kontoauszügen, Auszahlungsdateien, Rückerstattungs- und Konfliktdokumentationen.

Ein funktionierender Kreislauf sieht folgendermaßen aus:

Importieren Sie den Settlement- oder Bank-Batch.
Ordnen Sie jede Zeile einer Bestellung, Zahlung, Rückerstattung, Gebühr, Auszahlung oder einem Konflikt zu.
Vergleichen Sie erwartetes Brutto, Abzüge, Rücklagen und Netto.
Verbuchen Sie bestätigte Bewegungen im Hauptbuch.
Buchen Sie nicht zugeordnete Posten auf ein dediziertes Verrechnungskonto (Suspense Account).
Untersuchen Sie Unstimmigkeiten.
Schließen Sie die Periode ab.

Nordlets Material zur Kontenabstimmung beschreibt genau diesen Prozess: den Import von Settlement-Batches, das Matching von Belastungs- und Rückerstattungszeilen und die Umleitung nicht zugeordneter Eingänge auf ein Verrechnungskonto, anstatt auf Verdacht eine Rechnung zuzuordnen. Zwei Prüfungen sind wichtig, und keine ersetzt die andere: Die Validierung der doppelten Buchführung fragt, ob jedes Journal ausgeglichen ist, und die Kontenabstimmung fragt, ob es mit dem Zahlungsabwickler, der Bank und dem geschäftlichen Ereignis übereinstimmt.

Design-Details, die entscheiden, ob Sie es richtig machen

Idempotenz. Binden Sie den Schlüssel an ein stabiles Ereignis, wie z. B. payment_captured:pi_123. Ein Neuversuch liefert das ursprüngliche Ergebnis und keine zweite Journalbuchung.

Atomarität. Alle Zeilen eines Ereignisses werden zusammen gebucht oder gar nicht.

Unveränderlichkeit und Stornos. Die gebuchte Historie kann nicht durch gewöhnliche Updates bearbeitet werden. Korrekturen erzeugen verknüpfte Einträge, bei denen ursprünglicher Betrag, Datum, Klassifizierung, Grund und Autor erhalten bleiben.

Präzises Geld. Keine binären Gleitkommazahlen. Verwenden Sie ganzzahlige Untereinheiten oder exakte Dezimalzahlen, explizite Währungen und eine deterministische Rundungsregel für Splittungen. Teilen Sie 100 € auf Verkäufer und Gebühren ohne eine solche Regel auf, und ein verirrter Cent wird Ihre Bilanz aus dem Gleichgewicht bringen.

Wirksamkeits- vs. Buchungsdatum. Wann der Käufer bezahlt hat, wann der Verkäufer den Umsatz erzielt hat, wann die Bank abgerechnet hat und wann der Eintrag verbucht wurde, sind unterschiedliche Daten. Vermischt man sie, werden das Perioden-Reporting und die steuerliche zeitliche Zuordnung unzuverlässig.

Mehrwährungsfähigkeit. Soll und Haben sollten innerhalb einer Währung ausgeglichen sein. Eine Währungsumrechnung erfordert ein explizites Wechselkurs-Ereignis mit Konten für die Gebühr, für Rundungen sowie für Kursgewinne oder -verluste. Ein currency-Feld zu akzeptieren, macht ein Hauptbuch noch nicht zu einer FX-Engine.

Was eine Ledger-API nicht für Sie erledigen wird

Sie wird nicht über Ihren Kontenplan entscheiden. Sie müssen immer noch festlegen, ob Sie als Prinzipal oder Handelsvertreter agieren, wann die Provision verdient ist, welche Partei die Abwicklungsgebühren trägt, wie sich Rückerstattungen auf die Provision auswirken und wie die Umsatzsteuer berechnet und gemeldet wird. Nordlets eigener Leitfaden empfiehlt, zuerst die Zahlungsströme abzubilden, den Kontenplan zu entwerfen, ihn von einem Steuerberater prüfen zu lassen und dann einen vollständigen Ablauf – von der Bestellung über die Auszahlung bis zur Kontenabstimmung – zu implementieren, bevor man skaliert.

Sie wird keine steuerlichen Fragen klären. Die Umsatzsteuer hängt vom Standort des Käufers und Verkäufers, der Produktart, dem Registrierungsstatus und den Deemed-Supplier-Regeln ab; der EU-Umsatzsteuer-Leitfaden legt dar, was die Engine selbstständig ableitet und was sie für eine manuelle Prüfung markiert. Nordlets Umsatzsteuer-Abdeckung konzentriert sich auf die EU und den EWR, erstreckt sich also nicht auf die US Sales Tax oder lateinamerikanisches E-Invoicing. Und sie löst keine operativen Unklarheiten, etwa ob ein Rückgabefenster geschlossen ist, ob eine Auszahlung blockiert werden sollte oder ob eine Zahlung betrügerisch ist. Das sind Ihre Entscheidungen. Das Hauptbuch hält lediglich das finanzielle Ergebnis fest.

Wo Nordlet ins Spiel kommt

Nordlet ist eine Buchhaltungs-API für Plattformen und Marktplätze, ausgestattet mit einem unveränderlichen Hauptbuch für die doppelte Buchführung, Auszahlungen, EU-Umsatzsteuer-Handling, REST-Endpunkten, typisierten SDKs und Webhooks, die alle über eine einzige Schnittstelle erreichbar sind. Der entscheidende Vorteil ist die eingebettete Buchhaltung innerhalb Ihres eigenen Produkts und nicht über den Checkout eines Drittanbieters. Zum Zeitpunkt der Veröffentlichung befindet sich das Produkt im Early Access mit einer Sandbox für Design-Partner. Betrachten Sie es also als ein starkes Beispiel dieser Kategorie und evaluieren Sie die Produktionsreife, Uptime und die rechtliche Abdeckung für Ihren eigenen Anwendungsfall, bevor Sie sich festlegen.

Für Marktplatz- und Plattform-Entwickler ist das nützlichste mentale Modell die Trennung zwischen Geldbewegung und finanzieller Wahrheit. Ihr Zahlungsabwickler bewegt das Geld. Eine API für die doppelte Buchführung hält fest, wem was geschuldet wird, was Sie verdient haben, welche Steuern und Rücklagen Sie führen und ob die Außenwelt mit Ihren Büchern übereinstimmt.

FAQ

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

Nein. Ein Zahlungsabwickler (Processor) autorisiert, zieht ein, rechnet ab und zahlt manchmal Gelder aus. Eine Ledger-API erfasst die buchhalterischen Konsequenzen dieser Ereignisse. Die meisten Marktplätze nutzen beides: einen Abwickler wie Stripe oder Adyen für den Geldfluss und ein Hauptbuch für die Buchführung.

Kann ich nicht einfach das Dashboard meines Zahlungsabwicklers als Hauptbuch verwenden?

Sie können es versuchen, aber spätestens bei einer Betriebsprüfung (Audit) wird das zu Problemen führen. Das Reporting eines Zahlungsabwicklers zeigt Belastungen, Gebühren, Transfers und Abrechnungen, stellt aber in der Regel nicht Ihre vollständigen Verpflichtungen gegenüber Verkäufern, Steuerschulden, nicht vom Abwickler stammende Ausgaben oder buchhalterische Anpassungen dar. Behandeln Sie es als Input für die Kontenabstimmung.

Bedeutet ein saldiertes Hauptbuch, dass meine Bücher korrekt sind?

Es bedeutet lediglich, dass Ihre Buchungen der Soll-Haben-Regel entsprechen. Eine perfekt ausgeglichene Transaktion kann dennoch auf das falsche Konto, auf den falschen Verkäufer oder mit der falschen steuerlichen Behandlung gebucht werden. Ein ausgeglichener Saldo ist notwendig, aber nicht ausreichend. Die Kontenabstimmung ist das, was den Rest aufdeckt.

Wenn das Hauptbuch unveränderlich ist, wie behebe ich dann Fehler?

Sie erfassen eine Stornobuchung und danach die korrekte Buchung. Das Original bleibt sichtbar – genau das ist der Sinn der Sache. Die Unveränderlichkeit schützt den Audit-Trail und ist nicht dazu da, Sie bei Fehlern in die Falle zu locken.

Macht mich eine Buchhaltungs-API automatisch rechtskonform?

Nein. Sie erzwingt eine buchhalterische Struktur und erzeugt brauchbare Datensätze. Die rechtliche Compliance hängt jedoch weiterhin von Ihrer Gerichtsbarkeit, Ihrer vertraglichen Rolle, der steuerlichen Behandlung, Zahlungsverordnungen, KYC- und AML-Prozessen sowie Meldepflichten ab.