Was ist eine Accounting-API? Ein verständlicher Leitfaden für Plattform-Entwickler

Eine verständliche Definition der Accounting-API, was sie von einer Steuer- oder Zahlungs-API unterscheidet und worauf Sie vor der Integration achten sollten.

Eine Accounting-API ist eine Schnittstelle, die es einem Programm ermöglicht, die Buchhaltung für ein anderes Programm zu führen. Ihre Software sendet ein finanzielles Ereignis über HTTP. Die API wandelt dieses Ereignis in ausgeglichene Buchungssätze der doppelten Buchführung basierend auf einem Kontenplan (Chart of Accounts) um, speichert diese revisionssicher ab, wendet die korrekte steuerliche Behandlung an und liefert Ihnen über dieselbe Schnittstelle Auswertungen, Belege und Exporte zurück.

Diese Definition deckt bereits das Wichtigste ab. Alles Weitere in diesem Artikel leitet sich direkt daraus ab.

Die Zusammenfassung in einem Satz

Eine Accounting-API nimmt finanzielle Ereignisse aus Ihrer Anwendung entgegen, wandelt jedes davon in einen ausgeglichenen Buchungssatz um, speichert diesen unveränderlich mitsamt seiner steuerlichen Behandlung sowie den entsprechenden Nachweisen ab und stellt das daraus resultierende Hauptbuch (Ledger), die Belege und Auswertungen über programmierbare Endpunkte zur Verfügung.

Wenn ein Produkt sich als Accounting-API bezeichnet, aber keine Buchungssätze erzeugt, handelt es sich um etwas anderes mit einem wohlklingenden Namen. Das ist nicht zwingend schlecht. Es bedeutet schlichtweg, dass es nicht die Aufgabe erfüllen wird, die Sie ihm gerade übertragen möchten.

Was eine Accounting-API nicht ist

Vier angrenzende Produktkategorien werden häufig mit Accounting-APIs verwechselt – meistens erst in einer späten Projektphase.

Kategorie	Funktion	Was sie nicht leistet
Steuerberechnungs-API (Tax API)	Liefert den korrekten Steuersatz oder Steuerbetrag für eine Transaktion zurück	Ihre Buchhaltung führen oder die der Entscheidung zugrunde liegenden Nachweise über die gesetzliche Aufbewahrungsfrist hinweg speichern
Zahlungs-API (Payments API)	Bewegt Gelder zwischen Parteien und erstellt Berichte über diese Zahlungsströme	Verdiente Provisionen, geschuldete Umsatzsteuer oder die Verbindlichkeit gegenüber einem Verkäufer zwischen Zahlungseingang und Auszahlung erfassen
Unified- oder Aggregator-API	Liest und schreibt Daten in der bestehenden Buchhaltungssoftware Ihres Kunden	Als führendes System (System of Record) agieren; die Buchhaltung verbleibt in dem Tool, das der jeweilige Kunde bereits nutzt
Reporting- oder BI-API	Liest Kennzahlen aus einem bestehenden Hauptbuch aus und visualisiert sie	Die eigentlichen Buchungssätze erstellen, aus denen sich die Zahlen ableiten

Jede dieser Kategorien hat ihren berechtigten Einsatzzweck. Eine Plattform, die als buchhalterisches System of Record fungieren muss, benötigt die Accounting-API jedoch als zugrunde liegende Basis – nicht als deren Ersatz.

Die fünf Kernaufgaben einer Accounting-API

1. Ausgeglichene Buchungssätze erfassen. Jedes Ereignis wird in Soll und Haben mit derselben Summe gebucht. Wenn ein Käufer auf einem Marktplatz, der 15 € Provision einbehält, 100 € zahlt, wird ein Verrechnungskonto (Clearing Account) im Soll mit 100 € belastet. Im Haben werden eine Verbindlichkeit gegenüber dem Verkäufer (Seller Payable) in Höhe von 85 € sowie Provisionserlöse (Commission Revenue) in Höhe von 15 € gebucht. Das ist kein rein buchhalterischer Formalismus. Es handelt sich um eine strukturelle Kontrolle, die ganze Klassen von Integrationsfehlern abfängt, bevor sie in eine Auswertung einfließen.

2. Eine lückenlose Historie führen. Ein einmal festgeschriebener Buchungssatz wird nicht mehr geändert. Ein Fehler wird durch eine Stornobuchung (Reversal) und eine anschließende Korrekturbuchung behoben, die beide mit der Ursprungsbuchung verknüpft sind. Abgeschlossene Monate (Closed Periods) werden gesperrt, sodass keine neuen Buchungen rückwirkend in diese Periode fallen können.

3. Die steuerliche Behandlung abbilden. Für den Handel innerhalb der EU umfasst dies den Ort der Leistung (Place of Supply), das Reverse-Charge-Verfahren, den Abgleich von USt-IdNr. mit dem offiziellen Register sowie die Dokumentation der Nachweise, die diese Entscheidung rechtfertigen. All das wird direkt an der Transaktion gespeichert und nicht nach der bloßen Berechnung verworfen.

4. Mit externen Zahlungsströmen abstimmen. Eine Buchhaltung, die niemals mit einem Kontoauszug abgeglichen wird, gleicht einem Ratespiel. Die API muss Kontoauszüge oder Abrechnungen von Zahlungsdienstleistern (Provider Settlements) einlesen und mit den erfassten Buchungen abstimmen können (Reconciliation).

5. Exporte bereitstellen. Auswertungen, Belege und Prüfdateien (Audit Files) in Formaten, die von Buchhaltern und Finanzämtern akzeptiert werden.

Ein Produkt, das nur die ersten drei, nicht aber die letzten beiden Punkte erfüllt, führt unweigerlich dazu, dass jeden Monat jemand Daten manuell in Tabellenkalkulationen hin- und herschieben muss.

Wie ein API-Aufruf in der Praxis aussieht

Die technische Funktionsweise ist einfacher als die dahinterliegende Buchhaltung. In der API von Nordlet ist jede Operation ein POST-Request im RPC-Stil mit einer vorhersehbaren Struktur:

POST /v1/{module}/{resource}/{action}
Authorization: Bearer <api key>
Idempotency-Key: <your event id>

Sie erstellen eine Ausgangsrechnung und stellen diese dann aus (issue). Das Ausstellen ist der Moment, in dem die eigentliche Buchhaltung stattfindet: Der Beleg erhält seine lückenlose Rechnungsnummer, der ausgeglichene Buchungssatz wird festgeschrieben und die entsprechenden Umsatzsteuerzeilen werden mit erfasst. Ihre Plattform muss niemals Soll und Haben manuell zusammenbauen.

Drei Details in diesem Code-Snippet sind entscheidender als der Name des Endpunkts:

Der Scope des API-Keys. Ein Schlüssel verfügt über spezifische Berechtigungen wie sales:write, sodass eine Integration exakt nur den Zugriff erhält, den sie auch benötigt.
Der Idempotency-Key. Wenn Sie denselben Request mit exakt demselben Payload erneut senden, erhalten Sie die bereits gespeicherte Antwort zurück, anstatt versehentlich eine zweite Rechnung zu generieren. Senden Sie denselben Schlüssel mit einem abweichenden Payload, wird der Request mit idempotency_key_reuse abgelehnt, anstatt klammheimlich akzeptiert zu werden.
Geldwerte als Strings. Beträge werden als dezimale Zeichenketten (Strings) übergeben und nicht als Gleitkommazahlen (Floats), da Floats Rundungsfehler bei Cent-Beträgen verursachen, die unweigerlich beim Jahresabschluss zutage treten.

Einordnung in Ihre Systemarchitektur

Ihre Anwendung bleibt das Frontend und die Quelle der geschäftlichen Ereignisse. Die Accounting-API fungiert im Hintergrund als buchhalterisches System of Record. Der Ablauf sieht üblicherweise wie folgt aus:

In Ihrem Produkt findet ein Ereignis statt: eine Bestellung, eine Rückerstattung, eine Auszahlung oder die Verlängerung eines Abonnements.
Ihr Backend ruft die Accounting-API mit dem Ereignis und einem Idempotency-Key auf.
Die API verbucht den Journal-Eintrag, wendet die korrekte Umsatzsteuer an und liefert Identifier zurück, die Sie als Referenz in Ihren eigenen Datensätzen speichern.
Ein Webhook wie sale_invoice.paid informiert Ihr System über Statusänderungen, sodass Sie auf Ereignisse proaktiv reagieren können, anstatt sie durch ständiges Polling abzufragen.
Banktransaktionen fließen über eine Bankschnittstelle (Bank Feed) oder einen Kontoauszugs-Import ein und werden mit den erfassten Belegen abgestimmt.
Am Periodenende werden Auswertungen und steuerliche Meldungen aus exakt diesem Datenbestand generiert und der abgeschlossene Monat wird revisionssicher gesperrt.

Keiner dieser Schritte erfordert, dass ein Mensch eine Buchhaltungssoftware manuell öffnen muss. Genau das ist der Kernzweck dieser Produktkategorie.

Wie sie sich von Alternativen unterscheidet

Ansatz	Initialer Aufwand	Revisionssicherheit (Audit)	Skaliert mit Transaktionsvolumen
Tabellenkalkulationen und manuelle Erfassung	Sehr gering	Schwach; Historie ist veränderbar	Nein
Buchhaltungssoftware plus CSV-Exporte	Gering	Hängt vollständig von der Disziplin ab	Schlecht; Dateien müssen manuell importiert werden
Aggregator-API in die jeweilige Buchhaltung des Kunden	Mittel	Erbt die Eigenschaften des vom Kunden genutzten Tools	Ja, aber Sie besitzen nie die Datenhoheit
Eingebettete Accounting-API (Embedded Accounting)	Mittel	Stark, sofern das Hauptbuch unveränderlich ist und Perioden gesperrt werden	Ja
Eigenes Hauptbuch (Ledger) entwickeln	Sehr hoch	Nur stark, wenn Sie auch die Kontrollmechanismen mitbauen	Ja, und Sie müssen es dauerhaft warten

Die Eigenentwicklung ist für einige Teams eine durchaus legitime Entscheidung. Detailliertere Informationen dazu finden Sie in unserem Build-versus-Buy-Leitfaden für Marktplätze.

Worauf Sie vor der Integration achten sollten

Wird der Saldo berechnet oder gespeichert? Fragen Sie nach, ob das Guthaben eines Verkäufers durch eine Abfrage über alle Buchungszeilen ermittelt oder lediglich in einer Datenbankspalte überschrieben wird. Nur Ersteres hält einer Wirtschaftsprüfung stand.
Was passiert bei einem Retry? Senden Sie denselben API-Request zweimal und zählen Sie die erstellten Buchungen.
Können Sie eine festgeschriebene Buchung nachträglich ändern? Die Antwort sollte „Nein“ lauten – stattdessen muss es einen dokumentierten Weg für Korrekturbuchungen geben.
Weist eine gesperrte Periode eine Buchung tatsächlich ab? Probieren Sie es in einer Sandbox aus. Nordlet gibt beispielsweise den HTTP-Status 409 zurück, wenn eine Buchung mit einem Datum innerhalb eines bereits abgeschlossenen Zeitraums erfasst werden soll.
Wie werden Geldwerte abgebildet? Als dezimale Strings oder ganzzahlige kleinste Währungseinheiten (Minor Units). Niemals als Floats.
Was steht im Audit-Protokoll? Akteur, Aktion, Entität und die eigentliche Änderung – und zwar so, dass diese Daten gezielt abgefragt werden können und nicht in unübersichtlichen Log-Dateien vergraben sind.
Wie lauten die Rate Limits? Nordlet erlaubt 300 Requests pro Minute und API-Key und übermittelt das verbleibende Budget in den Response-Headern. Wie auch immer die Limits aussehen – Sie sollten sie kennen, bevor Sie Ihre Datensynchronisierung konzipieren.
Wie exportieren Sie Ihre Daten? Auswertungen, Belege und Journale müssen in Formaten vorliegen, die Sie direkt an einen Steuerberater oder Buchhalter übergeben können.

All diese Aspekte lassen sich an einem Nachmittag anhand eines Sandbox-Unternehmens testen. Die Feature-Listen von Anbietern sind kein verlässlicher Beweis; ein reproduzierbarer Test hingegen schon.

FAQ

Ist eine Accounting-API dasselbe wie eine Buchhaltungssoftware?

Es ist Buchhaltungssoftware, deren Nutzeroberfläche lediglich verschoben wurde. Herkömmliche Buchhaltungssoftware setzt einen Menschen vor das Hauptbuch; eine Accounting-API setzt Ihren Code an diese Stelle. Die zugrunde liegenden gesetzlichen Verpflichtungen, die Systematik der doppelten Buchführung und die Auswertungen bleiben exakt gleich.

Brauche ich trotzdem noch einen Steuerberater oder Buchhalter, wenn ich eine nutze?

Ja. Eine API automatisiert zwar die Erfassung, Berechnung und Berichterstellung, trifft jedoch keine Ermessensentscheidungen darüber, wie Sachverhalte klassifiziert werden, ob Rückstellungen (Provisions) gebildet werden müssen oder wie ein spezifischer Vertrag steuerlich zu bewerten ist. Zudem unterschreibt und übermittelt sie in den meisten Ländern auch nicht Ihren Jahresabschluss (Statutory Accounts).

Kann ich eine Accounting-API nutzen, ohne die doppelte Buchführung zu verstehen?

Bedingt. Eine gute API generiert die Buchungssätze für Sie automatisch anhand eines Geschäftsbelegs, wie beispielsweise einer Rechnung. Sie müssen jedoch weiterhin verstehen, was die einzelnen Konten bedeuten, wenn Sie eine Auswertung lesen oder einem Wirtschaftsprüfer einen bestimmten Saldo erklären müssen.

Was ist der Unterschied zwischen einer Accounting-API und einer Ledger-API?

Eine Ledger-API protokolliert ausgeglichene Geldbewegungen zwischen Konten. Eine Accounting-API tut dies ebenfalls, ergänzt aber die gesetzlich vorgeschriebene Ebene: Belege mit fortlaufender rechtssicherer Nummerierung, Umsatzsteuerbehandlung, Steuerjournale, Anlagenbuchhaltung (Fixed Assets), Periodenabschlüsse und genau die Auswertungen, die der jeweilige Gesetzgeber erwartet. Jede Accounting-API beinhaltet einen Ledger; aber nicht jeder Ledger ist automatisch ein vollständiges Buchhaltungssystem.

Wie lange dauert die Integration?

Für einen ersten funktionierenden Workflow – einen Kunden anlegen, eine Rechnung ausstellen, eine Zahlung empfangen und den generierten Buchungssatz einsehen – sollten Sie bei Nutzung eines typisierten SDKs und einer Sandbox eher in Tagen als in Wochen rechnen. Eine vollumfängliche Produktiv-Integration, die auch Rückerstattungen, Korrekturen, Fremdwährungen, Kontenabstimmung und den Monatsabschluss abdeckt, ist deutlich aufwendiger. Eine realistische Zeitschätzung hängt maßgeblich davon ab, wie viele dieser Anwendungsfälle Ihr Produkt in der Praxis tatsächlich erzeugt.