Embedded Accounting: Build vs. Buy für Marktplätze

Eine Scope-Liste, ein Kostenmodell mit klaren Annahmen und die Bedingungen, unter denen jede Entscheidung richtig ist.

Jeder Marktplatz baut früher oder später ein Hauptbuch (Ledger). Die einzige Frage ist, ob dies bewusst und als kontrolliertes System geschieht oder unabsichtlich – als eine balance-Spalte, in die drei verschiedene Services schreiben und der niemand so recht vertraut.

In diesem Artikel geht es darum, diese Entscheidung ganz bewusst zu treffen. Er beleuchtet, was die Arbeit tatsächlich umfasst, wie man die Kosten ohne Selbsttäuschung kalkuliert und unter welchen spezifischen Bedingungen die Eigenentwicklung die richtige Antwort ist – denn manchmal ist sie das tatsächlich.

Was „Embedded Accounting“ hier bedeutet

Embedded Accounting bedeutet, dass die Buchführung direkt in Ihrem Produkt stattfindet und nicht in einer separaten Anwendung, die erst geöffnet werden muss. Ihre Software erfasst die Buchungssätze in dem Moment, in dem die Ereignisse eintreten. Ihre Nutzer sehen genau das, was Ihre Benutzeroberfläche anzeigt, und niemand muss am Monatsende eine Tabelle für den Buchhalter exportieren.

Für einen Marktplatz umfasst dies mindestens: erhaltene Käuferzahlungen, Verbindlichkeiten gegenüber Verkäufern, verdiente Provisionen, Zahlungsabwicklungsgebühren, Umsatzsteuer (VAT) auf Ihre Gebühren und auf die zugrunde liegende Leistung, Rückerstattungen, Rückbelastungen (Chargebacks), Rücklagen (Reserves), Auszahlungen (Payouts) sowie die Abstimmung (Reconciliation) all dieser Posten mit einer Bank oder einem Zahlungsdienstleister.

Was Sie wirklich bauen, wenn Sie sich für eine Eigenentwicklung entscheiden

Das eigentliche Hauptbuch ist nur ein kleiner Teil. Entwicklungsteams schätzen in der Regel nur den ersten Punkt ab und stoßen erst danach auf den Rest.

Komponente	Was sie beinhaltet
Journal und Konten	Saldierte Buchungen, Kontenrahmen, Kontoarten, Eröffnungssalden
Unveränderbarkeit (Immutability)	Append-only-Speicherung, Storno- und Korrektur-Workflows, keine direkten Datenänderungen (In-place Edits)
Periodensteuerung	Abschluss, Sperrung, Abweisung verspäteter Buchungen, kontrollierte Wiedereröffnung mit Audit-Protokoll
Idempotenz	Schlüssel (Keys), Speicherung früherer Antworten, Kollisionserkennung bei geänderten Payloads
Geldverarbeitung	Exakte Dezimal- oder Minor-Unit-Arithmetik, Währungscodes, Wechselkurse und deren Quelle, Rundungskonten
Umsatzsteuer-Engine	Länderspezifische Steuersätze mit Gültigkeitsdaten, Ort der Leistung (Place of Supply), Reverse-Charge-Verfahren, Fiktiver-Lieferer-Regelungen (Deemed Supplier), Steuerbefreiungen
USt-IdNr.-Prüfungen	Validierung gegen das offizielle Register, Caching, Zeitstempel, Request-Identifier, eine Warteschlange zur manuellen Prüfung bei Fehlern
Dokumente	Rechnungen, Gutschriften, lückenlose Nummernkreise pro Serie und Jahr, PDF-Generierung, Zustellung
E-Rechnungen	Strukturierte Formate wie EN 16931 UBL sowie länderspezifische nationale Formate, sofern gesetzlich vorgeschrieben
Bankdaten-Import	Kontoauszugsimport oder PSD2-Bankanbindung, Deduplizierung bereits importierter Transaktionen
Abstimmung (Reconciliation)	Matching-Regeln, Scoring, Teilzuordnungen, Ausnahmefälle zur manuellen Klärung
Auszahlungen	Erstellung von Zahlungsdateien, Bündelung von Auszahlungen (Batching), Zuordnung von Auszahlungen zu den zugrunde liegenden Posten
Reporting	Saldenbilanz, Bilanz, Gewinn- und Verlustrechnung (GuV), Cashflow, Umsatzsteuerzusammenfassungen, Fälligkeitsstruktur von Forderungen (Aged Debt)
Steuerregister und -erklärungen	Alles, was die jeweiligen Länder verlangen, in den von den Behörden akzeptierten Formaten
Audit	Akteur, Aktion, Entität und die Änderung selbst – abfragbar für jede einzelne Mutation
Aufbewahrung und Export	Zehnjährige Aufbewahrungsfrist für OSS-Aufzeichnungen, vollständiger Datenexport, revisionssicheres Archiv

Wenn Teams sagen, „Wir bauen ein Hauptbuch“, denken sie in der Regel an höchstens zwei dieser siebzehn Zeilen.

Die Kosten ehrlich kalkulieren

Jegliche Zahlen hängen hier von Ihrem Team ab. Betrachten Sie das Folgende also eher als Methode und nicht als Kostenvoranschlag. Nehmen Sie die obigen Komponenten, weisen Sie jeder eine Größe in Entwicklerwochen zu (basierend auf der Velocity Ihres Teams) und wenden Sie dann drei Korrekturen an, die bei Schätzungen meist übersehen werden.

Korrektur eins: Die Compliance-Komponenten sind keine einmalige Sache. Steuersätze ändern sich, Schwellenwerte ändern sich, Formate ändern sich, und das EU-Paket „VAT in the Digital Age“ (ViDA) bringt terminierte Verpflichtungen mit sich — OSS- und IOSS-Änderungen ab 1 January 2027, erweiterte Plattformregeln ab 1 July 2028, grenzüberschreitendes digitales Reporting ab 1 July 2030. Eigenentwicklung bedeutet, dass Sie jede dieser Migrationen selbst verantworten müssen.

Korrektur zwei: Die Arbeit an der fachlichen Richtigkeit überdauert die Feature-Entwicklung. Die erste Version deckt den Happy Path ab. Der Long Tail besteht aus Rückerstattungen nach der Auszahlung, Teilrückerstattungen, Wochen später eintreffenden Chargebacks, Währungsrundungen, doppelten Webhooks und Abrechnungsdateien (Settlements), die nicht mit Ihren Aufzeichnungen übereinstimmen. An dieser Stelle gerät jeder Zeitplan aus den Fugen.

Korrektur drei: Der Buchhalter ist ein Stakeholder, kein bloßer Reviewer. Eine Buchführung, die ein Finanzexperte nicht freigibt, ist nicht fertiggestellt – und dieses Feedback kommt bei Eigenentwicklungen oft sehr spät im Prozess.

Ein nützlicher Realitätscheck: Kalkulieren Sie den kleinsten vertretbaren Build – Hauptbuch, Korrekturen, Periodensperrung, Idempotenz, Geldverarbeitung, die Umsatzsteuer eines einzigen Landes, Rechnungen, Bankimport, Matching und ein grundlegendes Reporting-Set – und vergleichen Sie dies mit den Jahreskosten eines nutzungsbasierten Dienstes (Metered Service). Die veröffentlichten Tarife von Nordlet beginnen bei €10 pro Monat mit inkludierten 3,000 Requests und reichen bis zu €300 pro Monat bei 200,000 Requests. Wenn ein Build nur einen Bruchteil eines einzelnen Entwicklerjahres kostet, ist das ein echtes Argument für eine Eigenentwicklung. Kostet es jedoch mehrere Entwicklerjahre plus permanente Wartung, fällt der Vergleich mehr als eindeutig aus – und dieser Abstand vergrößert sich mit jedem Jahr, in dem sich die Vorschriften ändern.

Wann eine Eigenentwicklung tatsächlich richtig ist

Es gibt drei reale Anwendungsfälle.

Ihr Hauptbuch ist Ihr Produkt. Wenn Sie eine Zahlungsplattform, ein Bankprodukt oder ein Wallet entwickeln, bei dem das Saldenverhalten unter Nebenläufigkeit (Concurrency) das Alleinstellungsmerkmal ist, gehört das Hauptbuch zum Kernprodukt und sollte Ihnen gehören. Ziehen Sie in diesem Fall Ledger-Infrastruktur-Produkte einer kompletten Neuentwicklung vor und trennen Sie diese von der handelsrechtlichen Buchführung (Statutory Accounting).

Ihr Geschäftsmodell passt in kein Buchhaltungssystem. Manche Marktplätze haben wirklich ungewöhnliche Abrechnungsstrukturen — Multi-Party-Splits mit bedingten Freigaben, Treuhandkonten (Escrow) mit gestaffelten Meilensteinen, komplexe Rücklagenrichtlinien. Wenn kein Produkt dies abbilden kann und die Workarounds schlimmer sind als die Entwicklung selbst, dann bauen Sie es.

Ihr Volumen macht nutzungsbasierte Preise unwirtschaftlich. Ab extrem hohen Transaktionsraten ist ein Preismodell pro Request (Per-Request Pricing) nicht mehr attraktiv. Modellieren Sie dies jedoch mit echten Zahlen, bevor Sie Vermutungen anstellen, denn „extrem“ bedeutet hier weitaus mehr, als die meisten Plattformen jemals erreichen.

Wann der Kauf die richtige Wahl ist

Ein Kauf ist die bessere Wahl, wenn die Buchhaltung zwar notwendig, aber kein Differenzierungsmerkmal ist – was der Regelfall ist. Niemand entscheidet sich für Ihren Marktplatz, weil Ihre Buchungssätze so elegant sind. Die Nutzer bemerken es erst, wenn die Buchhaltung fehlerhaft ist.

Ein Kauf ist auch dann die richtige Entscheidung, wenn Sie Verpflichtungen in mehreren Ländern haben. Länderspezifische Umsatzsteuerregeln, Nachweispflichten und E-Rechnungs-Mandate erfordern einen permanenten Wartungsaufwand, den ein Anbieter auf alle seine Kunden umlegen kann. Nordlet liefert länderspezifische EU-Umsatzsteuer mit VIES-Validierung, OSS- und IOSS-Meldungsberechnung, i.SAF-Registern und EN 16931 UBL für Peppol als Teil des Produkts aus, anstatt als Projekt, das Sie erst planen müssen.

Ein Mittelweg, den die meisten Teams letztendlich gehen

Die pragmatische Antwort lautet meist nicht „Entweder-oder“. Sie lautet: Kaufen Sie das Hauptbuch, bauen Sie den Workflow.

Das Accounting-Backend übernimmt die Buchungssätze, die steuerliche Behandlung, die Dokumente, den Periodenabschluss und den Audit-Trail. Ihr Produkt steuert alles, was Ihre Nutzer sehen, und jede Geschäftsregel, die spezifisch für Ihren Marktplatz ist — wann Gelder freigegeben werden, wie die Rücklagenrichtlinie aussieht, wie Streitfälle (Disputes) gehandhabt werden und was das Verkäufer-Dashboard anzeigt. Sie rufen die Accounting-API in den Momenten auf, in denen Geldflüsse verbindlich werden, und behalten die Teile unter eigener Kontrolle, die tatsächlich Ihnen gehören.

Diese klare Trennung übersteht auch zukünftige Änderungen besser als die Alternativen. Ein neues Land erfordert lediglich eine neue Konfiguration anstelle eines Projekts. Eine neue Auszahlungsrichtlinie ist Ihr eigener Code, kein Ticket beim Software-Anbieter.

Was Sie entscheiden sollten, bevor Sie sich festlegen

Ist Ihr Hauptbuch ein Alleinstellungsmerkmal oder eine bloße Pflichtaufgabe? Seien Sie ehrlich; meistens ist es eine Pflichtaufgabe.
Wie viele Länder sind involviert und was verlangt jedes einzelne? Nur Steuersätze oder auch Meldungen, Register oder direkte Übermittlungen (Submissions).
Wie sieht Ihre Strategie für Korrekturen aus? Rückerstattungen nach erfolgter Auszahlung und verspätete Chargebacks sind genau die Fälle, die ein schwaches Systemdesign gnadenlos offenlegen.
Wer gibt die Bücher frei? Binden Sie diese Person ein, bevor das Design in Stein gemeißelt ist, nicht erst danach.
Wie sieht der Plan für die zehnjährige Aufbewahrung aus? OSS-Aufzeichnungen müssen ab dem Ende des Jahres der Transaktion zehn Jahre lang aufbewahrt werden, und ein Archiv ist ein vollwertiges System, kein bloßes Backup.
Wie sieht eine Migration in drei Jahren aus? Und zwar in beide Richtungen. Bauen Sie am ersten Tag einen Testexport und stellen Sie sicher, dass er funktionsfähig bleibt.

FAQ

Wie lange dauert es, ein Marktplatz-Hauptbuch zu entwickeln?

Eine erste Version, die saldierte Buchungen verarbeitet, kann in wenigen Wochen laufen. Eine Version, die jedoch Rückerstattungen nach der Auszahlung, verspätete Chargebacks, Mehrwährungsrundungen, doppelte Provider-Webhooks, den Periodenabschluss sowie ein Audit bewältigt, das ein Buchhalter auch akzeptiert, dauert erheblich länger – und die Wartung endet nie. Schätzen Sie den Aufwand für Letzteres ab, denn das ist es, was Produktionsreife wirklich bedeutet.

Können wir mit einer `balance`-Spalte starten und später migrieren?

Das können Sie, und viele tun das auch. Planen Sie aber ein, dass die Migration weitaus schwieriger wird als der ursprüngliche Build. Die Rekonstruktion der Historie aus einem veränderbaren Saldo (Mutable Balance) ist nur möglich, wenn Sie jedes Ereignis aufbewahrt haben, das ihn verändert hat — was wiederum bedeutet, dass Sie eigentlich ohnehin schon ein Hauptbuch brauchten.

Ersetzt eine Embedded Accounting API unser Finanzteam?

Nein. Sie beseitigt lediglich die manuelle Datenerfassung und Abstimmung. Jemand muss weiterhin den Monatsabschluss durchführen, Ausnahmefälle prüfen, Ermessensentscheidungen treffen und Steuererklärungen einreichen.

Was ist mit der DSGVO (GDPR), wenn das Hauptbuch unveränderlich ist?

Speichern Sie finanzielle Fakten und pseudonymisierte Referenzen in den unveränderlichen Datensätzen und lagern Sie personenbezogene Daten in ein separates System mit eigenem Aufbewahrungs- und Löschprozess aus. Die Unveränderbarkeit bezieht sich auf das finanzielle Ereignis, nicht auf jedes daran angehängte Attribut.

Ist Open-Source-Buchhaltungssoftware eine Option für den Mittelweg?

Das ist eine valide Option, allerdings verlagert sie die Kosten lediglich, anstatt sie zu beseitigen: Sie übernehmen das Hosting, die Upgrades, die länderspezifische Lokalisierung und die Compliance-Updates selbst. Kalkulieren Sie diese Kostenpunkte ein, bevor Sie die eingesparten Lizenzkosten als das Gesamtbild betrachten.