Nordlet

← Blog

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

Eine Aufwandsliste, ein Kostenmodell mit expliziten Annahmen und die Bedingungen, unter denen die jeweilige Antwort korrekt ist.

Nordlet Team · · 8 Min. Lesezeit

Früher oder später entwickelt jeder Marktplatz ein eigenes Hauptbuch (Ledger). Die einzige Frage ist, ob es bewusst als System mit Kontrollen entsteht oder versehentlich als eine balance-Spalte, in die drei Dienste schreiben und der niemand so recht vertraut.

In diesem Artikel geht es darum, diese Entscheidung bewusst zu treffen. Er beleuchtet, was die Arbeit tatsächlich beinhaltet, wie man sie ohne Selbsttäuschung kalkuliert und unter welchen konkreten Bedingungen ein Eigenbau die richtige Antwort ist - denn manchmal ist er das tatsächlich.

Was „Embedded Accounting“ in diesem Zusammenhang bedeutet

Embedded Accounting bedeutet, dass die Finanzdaten direkt in Ihr Produkt eingebettet sind und nicht in einer separaten Anwendung liegen, die von jemandem extra geöffnet werden muss. Ihre Software erfasst die Buchungssätze beim Eintreten der Ereignisse, Ihre Nutzer sehen genau das, was Ihre Benutzeroberfläche ihnen anzeigt, und niemand exportiert zum Monatsende eine Tabelle für den Buchhalter.

Für einen Marktplatz umfasst dies mindestens: eingegangene Zahlungen von Käufern, ausstehende Beträge an Verkäufer, verdiente Provisionen, Zahlungsabwicklungsgebühren, Umsatzsteuer auf Ihre Gebühren sowie auf die zugrundeliegende Lieferung, Rückerstattungen, Chargebacks, Rückstellungen (Reserves), Auszahlungen und die Abstimmung all dieser Posten mit einer Bank oder einem Zahlungsdienstleister.

Was Sie beim Eigenbau tatsächlich entwickeln

Das Ledger selbst macht nur einen kleinen Teil aus. Teams unterschätzen diesen Aufwand regelmäßig und entdecken den Rest erst im Nachhinein.

Komponente Was sie beinhaltet
Journal und Konten Ausgeglichene Buchungen, Kontenrahmen (Chart of Accounts), Kontenarten, Eröffnungsbilanzen
Unveränderlichkeit (Immutability) Nur-Lösch-geschützte Speicherung (Append-only), Storno- und Korrektur-Workflow, keine direkten Änderungen an bestehenden Datensätzen
Periodensteuerung Jahres- und Monatsabschluss, Sperrung, Ablehnung verspäteter Buchungen, kontrollierte Wiederöffnung mit Audit-Protokoll
Idempotenz Schlüssel, Speicherung vorheriger Antworten, Kollisionserkennung bei veränderten Payloads
Geld- und Währungsverarbeitung Exakte Dezimal- oder Minor-Unit-Arithmetik, Währungscodes, Wechselkurse und deren Quelle, Rundungskonten
Umsatzsteuer-Engine Länderbezogene Steuersätze mit Gültigkeitsdaten, Ort der Lieferung, Reverse-Charge-Verfahren, Regeln für den steuerlich als Lieferer geltenden Marktplatz (Deemed Supplier), Befreiungen
USt-IdNr.-Prüfungen Validierung gegen das offizielle Register, Caching, Zeitstempel, Anfragekennungen, manuelle Prüfschleife bei Fehlern
Dokumente Rechnungen, Gutschriften, lückenlose Nummerierung nach Serie und Jahr, PDF-Rendering, Bereitstellung
E-Invoicing Strukturierte Formate wie EN 16931 UBL sowie länderspezifische nationale Formate, sofern vorgeschrieben
Bankdaten-Import Kontoauszugsimport oder eine per Einwilligung angebundene Bankverbindung (Consent), Duplikaterkennung bereits importierter Transaktionen
Abstimmung (Reconciliation) Abgleichregeln, Scoring, Teilabgleiche, Ausnahmen, die von Menschen gelöst werden können
Auszahlungen Generierung von Zahlungsdateien, Auszahlungs-Batching, Zuordnung von Auszahlungen zu den zugrundeliegenden Positionen
Berichterstattung Summen- und Saldenliste (Trial Balance), Bilanz, Gewinn- und Verlustrechnung (P&L), Cashflow, Umsatzsteuer-Zusammenfassungen, offene Posten nach Alter
Steuerregister und -meldungen Alles, was Ihre jeweiligen Länder verlangen, in dem Format, das die Behörde akzeptiert
Audit Akteur, Aktion, Entität und die Änderung selbst – für jede Mutation abfragbar
Aufbewahrung und Export Zehnjährige Aufbewahrungspflicht für OSS-Daten, vollständiger Datenexport, revisionssicheres Archiv

Grob gesagt sind etwa zwei dieser siebzehn Zeilen genau der Teil, den sich die meisten Teams vorstellen, wenn sie sagen: „Wir bauen ein Ledger.“

Die Kosten realistisch kalkulieren

Jede Zahl hängt stark von Ihrem Team ab. Betrachten Sie die folgenden Ausführungen daher eher als Methode denn als Festpreis. Nehmen Sie die oben genannten Komponenten, schätzen Sie den Aufwand für jede Einzelne in Entwicklerwochen basierend auf der Geschwindigkeit Ihres eigenen Teams ein und wenden Sie dann drei Korrekturen an, die in Schätzungen oft ü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 zur Mehrwertsteuer im digitalen Zeitalter (ViDA) bringt datierte Verpflichtungen mit sich – Änderungen bei OSS und IOSS ab dem 1. Januar 2027, erweiterte Plattformregeln ab dem 1. Juli 2028 und grenzüberschreitende digitale Meldepflichten ab dem 1. Juli 2030. Wer selbst baut, übernimmt die Verantwortung für jede dieser Migrationen.

Korrektur zwei: Korrekturen dauern länger als neue Funktionen. Die erste Version deckt den Regelfall ab (Happy Path). Der Langzeitaufwand besteht aus Rückerstattungen nach Auszahlungen, Teilrückerstattungen, Chargebacks, die Wochen später eintreffen, Währungsrundungen, doppelten Webhooks und Abrechnungsdateien, die nicht mit Ihren Datensätzen übereinstimmen. Genau hier gerät der Zeitplan aus den Fugen.

Korrektur drei: Der Steuerberater oder Wirtschaftsprüfer ist ein Stakeholder, kein bloßer Prüfer. Bücher, die ein Finanzprofi nicht abzeichnet, sind nicht fertig, und dieses Feedback erreicht das Team bei einem Eigenbau meist viel zu spät.

Ein nützlicher Plausibilitätstest: Kalkulieren Sie den Preis für den kleinsten glaubwürdigen Eigenbau – Ledger, Korrekturen, Periodensperre, Idempotenz, Geldverarbeitung, Umsatzsteuer für ein Land, Rechnungen, Bankimport, Abgleich und einen grundlegenden Berichtssatz – und vergleichen Sie diesen mit den Jahreskosten eines verbrauchsabhängigen Dienstes. Die veröffentlichten Tarife von Nordlet beginnen bei 10 € pro Monat (inklusive 3.000 Abfragen) und reichen bis zu 300 € pro Monat für 200.000 Abfragen. Wenn ein Eigenbau nur einen Bruchteil eines Ingenieur-Jahres kostet, ist das ein echtes Argument für die Eigenentwicklung. Wenn er mehrere Ingenieur-Jahre plus dauerhafte Wartung verschlingt, hinkt der Vergleich – und dieser Abstand wächst mit jeder Regeländerung von Jahr zu Jahr.

Wann ein Eigenbau tatsächlich die richtige Entscheidung ist

Drei Fälle, die allesamt der Realität entsprechen.

Ihr Ledger ist Ihr Produkt. Wenn Sie eine Zahlungsplattform, ein Bankprodukt oder ein Wallet entwickeln, bei dem das Kontostandverhalten unter Gleichzeitigkeitsbedingungen (Concurrency) das entscheidende Differenzierungsmerkmal ist, dann ist das Ledger ein Kernbestandteil und sollte Ihnen gehören. Ziehen Sie dabei Infrastrukturprodukte für Ledger in Betracht, statt komplett bei Null zu beginnen, und halten Sie die gesetzliche Buchhaltung davon getrennt.

Ihr Geschäftsmodell passt in kein Buchhaltungssystem. Einige Marktplätze weisen tatsächlich ungewöhnliche Abrechnungsstrukturen auf – Multiparty-Splits mit bedingten Freigaben, Treuhandkonten mit gestaffelten Meilensteinen oder komplexe Rückstellungsrichtlinien. Wenn kein Produkt dies abbildet und die Workarounds schlimmer sind als der Eigenbau, dann bauen Sie selbst.

Ihr Transaktionsvolumen macht verbrauchsabhängige Preise unwirtschaftlich. Bei extrem hohen Transaktionsraten verliert eine Abrechnung pro Anfrage an Attraktivität. Modellieren Sie dies mit realen Zahlen, bevor Sie voreilig davon ausgehen, denn „extrem“ liegt hier deutlich höher, als die meisten Plattformen jemals erreichen.

Wann der Zukauf die richtige Wahl ist

Zukaufen lohnt sich immer dann, wenn Buchhaltung zwar notwendig, aber nicht differenzierend ist – was dem Regelfall entspricht. Niemand entscheidet sich für Ihren Marktplatz, weil Ihre Buchungssätze besonders elegant sind. Man bemerkt sie erst dann, wenn die Bücher fehlerhaft sind.

Der Kauf ist ebenfalls die richtige Wahl, wenn Sie Verpflichtungen in mehreren Ländern haben. Länderspezifische Umsatzsteuervorschriften, Aufbewahrungspflichten und E-Invoicing-Mandate bedeuten einen permanenten Wartungsaufwand, während ein Anbieter diesen Aufwand auf alle seine Kunden umlegt. Nordlet liefert länderbezogene EU-Umsatzsteuer mit VIES-Validierung, Berechnung von OSS- und IOSS-Meldungen, i.SAF-Registern und EN 16931 UBL für Peppol direkt als Produktbaustein aus, statt als ein Projekt, das Sie erst mühsam einplanen müssen.

Der Mittelweg, bei dem die meisten Teams landen

Die pragmatische Antwort lautet in der Praxis meist weder das eine noch das andere. Sie lautet vielmehr: Kaufen Sie das Ledger, bauen Sie den Workflow.

Das Buchhaltungs-Backend verwaltet die Buchungen, die steuerliche Behandlung, die Dokumente, den Periodenabschluss und den Audit-Trail. Ihr Produkt steuert alles, was Ihre Nutzer sehen, sowie alle marktplatzspezifischen Geschäftsregeln – wann Gelder freigegeben werden, wie eine Rückstellungsrichtlinie aussieht, wie Streitbeilegung gehandhabt wird und was das Verkäufer-Dashboard anzeigt. Sie rufen die Buchhaltungs-API immer dann auf, wenn Geldströme fixiert werden, und behalten die Komponenten, die tatsächlich zu Ihrem Alleinstellungsmerkmal gehören.

Diese Aufgabentrennung hält auch Veränderungen besser stand als Alternativen. Ein neues Land erfordert eine Konfiguration statt eines kompletten Projekts. Eine neue Auszahlungsrichtlinie wird in Ihrem eigenen Code abgebildet, statt eine Anfrage an einen Drittanbieter zu erfordern.

Worüber Sie vor Ihrer Entscheidung im Klaren sein sollten

  1. Ist Ihr Ledger ein Differenzierungsmerkmal oder eine Pflichtübung? Seien Sie ehrlich – die meisten sind reine Pflichten.
  2. In wie vielen Ländern sind Sie aktiv, und was verlangt jedes einzelne davon? Nur Steuersätze, oder auch Steuererklärungen, Register oder Einreichungen?
  3. Wie sehen Ihre Korrekturprozesse aus? Rückerstattungen nach Auszahlungen und verspätete Chargebacks sind die Szenarien, die ein schwaches Design gnadenlos aufdecken.
  4. Wer unterzeichnet die Bilanzen? Beziehen Sie diese Person in den Prozess ein, bevor das Design feststeht, und nicht erst danach.
  5. Wie sieht der zehnjährige Aufbewahrungsplan aus? OSS-Aufzeichnungen müssen zehn Jahre ab dem Ende des Transaktionsjahres aufbewahrt werden, und ein Archiv ist ein eigenständiges System, kein simples Backup.
  6. Wie sieht eine Migration in drei Jahren aus? Und zwar in beide Richtungen. Erstellen Sie am ersten Tag einen Testexport und stellen Sie sicher, dass dieser dauerhaft funktioniert.

FAQ

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

Eine erste Version, die ausgeglichene Buchungen erfasst, kann innerhalb weniger Wochen lauffähig sein. Eine Version, die jedoch Rückerstattungen nach Auszahlungen, verspätete Chargebacks, Multi-Währungs-Rundungen, doppelte Webhooks von Zahlungsdienstleistern, Periodenabschlüsse und von Wirtschaftsprüfern akzeptierte Audits beherrscht, dauert wesentlich länger – und die Wartungsarbeit hört niemals auf. Kalkulieren Sie direkt die zweite Variante ein, denn nur das bedeutet echter Produktivbetrieb.

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

Das können Sie, und viele tun genau das. Planen Sie jedoch ein, dass die Migration schwieriger wird als der ursprüngliche Eigenbau. Die Rekonstruktion der Historie auf Basis eines veränderbaren Kontostands ist nur dann möglich, wenn Sie jedes einzelne ereignisbasierte Update gespeichert haben – was im Grunde bedeutet, dass Sie ohnehin bereits ein Ledger besessen haben.

Ersetzt eine Embedded-Accounting-API unser Finanzteam?

Nein. Sie nimmt Ihnen die manuelle Erfassung und den Abgleich ab. Es ist nach wie vor jemand erforderlich, der den Monat abschließt, Ausnahmefälle prüft, Ermessensentscheidungen trifft und Steuererklärungen einreicht.

Wie verhält es sich mit der DSGVO, wenn das Ledger unveränderlich ist?

Bewahren Sie finanzielle Fakten und pseudonymisierte Referenzen in den unveränderlichen Aufzeichnungen auf und personenbezogene Daten in einem separaten System mit eigenen Aufbewahrungs- und Löschprozessen. Die Unveränderlichkeit gilt für das finanzielle Ereignis, nicht für jedes damit verknüpfte Attribut.

Ist Open-Source-Buchhaltungssoftware eine gute Mittellösung?

Das ist eine durchaus reale Option, die jedoch die Kosten verlagert, statt sie abzuschaffen: Sie übernehmen Hosting, Upgrades, länderspezifische Lokalisierungen und Compliance-Updates komplett in Eigenregie. Kalkulieren Sie diese Faktoren durch, bevor Sie die Einsparung bei den Lizenzkosten als Gesamtrechnung betrachten.

Weiterführende Lektüre