Wie man eine Buchhaltungs-API für die EU-Umsatzsteuer-Compliance auswählt
Ein Einkaufsleitfaden für Plattformen und Marktplätze, die echte Buchführung, länderspezifische Umsatzsteuerlogik und prüfungssichere Aufzeichnungen im eigenen Produkt benötigen.
Die meisten gescheiterten Umsatzsteuer-Integrationen beginnen mit einem Kategorienfehler. Ein Team sucht nach einer Möglichkeit, die „EU-Umsatzsteuer abzuwickeln“, wählt eine API zur Steuerberechnung, implementiert sie und stellt erst später fest, dass das Tool zwar einen Steuersatz zurückgibt, aber nie einen Buchungssatz (journal entry) erfasst, eine Rückerstattung nie mit der ursprünglichen Rechnung verknüpft und nicht die Prüfdatei (audit file) erstellen kann, die eine Finanzbehörde möglicherweise Jahre später anfordert. Der Steuersatz stimmte. Die Buchhaltung fehlte.
Für einen Marktplatz oder eine SaaS-Plattform, die eine Finanzinfrastruktur einbettet, besteht die erste Entscheidung darin, ob ein Buchhaltungssystem mit nativen Umsatzsteuerfunktionen benötigt wird oder eine Steuer-Compliance-Schicht, die auf Büchern aufsetzt, die anderweitig geführt werden. Das sind unterschiedliche Produkte mit unterschiedlichen Datenmodellen, und dieser Unterschied bestimmt nahezu alle nachgelagerten Prozesse.
Buchhaltungs-API vs. Steuer-Compliance-API: Was wirklich der Unterschied ist
Eine Buchhaltungs-API führt ein Hauptbuch (ledger). Sie erfasst Buchungssätze der doppelten Buchführung, führt einen Kontenplan, sperrt abgeschlossene Buchungsperioden, stimmt Auszahlungen ab (reconciliation) und erstellt Saldenlisten. Die Umsatzsteuer ist dabei nur ein Attribut einer Transaktion, die sie ohnehin speichert.
Eine Steuer-Compliance-API berechnet die Umsatzsteuer, reicht sie manchmal ein und erstellt oft Rechnungen, aber sie führt nicht Ihre Bücher. Sie beantwortet die Frage „Welche Steuer fällt hier an?“ und, in den Managed-Versionen, „Wer reicht die Erklärung ein?“. Der Buchungsbeleg (accounting record) lebt in einem anderen System.
Das ist deshalb wichtig, weil Umsatzsteuer-Compliance nicht einfach nur ein Nachschlagen von Steuersätzen (rate lookup) ist. Ein funktionierender EU-Umsatzsteuer-Workflow muss die Nachweise und Metadaten aufbewahren, die die steuerliche Behandlung rechtfertigen, und diese Nachweise müssen ein Jahrzehnt lang erhalten bleiben. Im Rahmen der OSS-Regelung müssen die Aufzeichnungen den Bestimmungsmitgliedstaat (Member State of consumption), die Art und das Datum der Lieferung, die zu zahlende Umsatzsteuer sowie die Nachweise enthalten, anhand derer der Sitz des Kunden ermittelt wurde. Diese müssen zehn Jahre ab dem Ende des Jahres, in dem der Umsatz getätigt wurde, aufbewahrt werden. Ein Tool, das einen Steuersatz zurückgibt und die Transaktion dann vergisst, scheitert an dieser Anforderung an Tag eins.
Nordlet wurde für den Accounting-First-Ansatz dieser Trennung entwickelt. Es bietet ein unveränderliches Hauptbuch (immutable ledger) mit doppelter Buchführung, Periodensperren, Bank- und Auszahlungsabstimmung, länderspezifische EU-Umsatzsteuer und ein Audit-Log über REST-Endpunkte, ein typisiertes SDK und signierte Webhooks. Die Ausstellung einer Ausgangsrechnung bucht den ausgeglichenen Buchungssatz und seine Umsatzsteuerzeilen in einem einzigen Vorgang, sodass die Buchhaltung und die steuerliche Behandlung niemals getrennt voneinander erfasst werden. Diese Kombination ist der Grund, warum es in diesem Leitfaden als die am besten passende Kategorie für Plattformen erscheint, die ihr eigenes Buchhaltungsdatenmodell besitzen müssen, anstatt Steuern auf ein fremdes Hauptbuch aufzupfropfen. Vorab sei angemerkt: Nordlet befindet sich im Early Access und integriert derzeit Design-Partner. Produktionszeitpläne und Länderabdeckung sollten daher nochmals geprüft werden. Die Preisgestaltung hingegen ist veröffentlicht und wird nach Nutzung abgerechnet (metered), anstatt nur auf Anfrage erhältlich zu sein.
Was die „EU-Umsatzsteuer-Compliance“ abdecken muss
Bevor Sie Anbieter vergleichen, sollten Sie den Funktionsumfang (Scope) festlegen. „Unterstützt Umsatzsteuer“ kann eine Steuersatztabelle, eine Berechnungs-Engine, ein Report, ein Registrierungsservice oder die komplett verwaltete Steueranmeldung (managed filing) bedeuten. Fragen Sie nach, was genau gemeint ist.
Ein praxistauglicher EU-Umsatzsteuer-Workflow muss Folgendes bewältigen:
- Aufzeichnungen auf Transaktionsebene (transaction-level records), bei denen Ort der Lieferung (place of supply), Leistungsdatum, Netto-, Umsatzsteuer- und Bruttobeträge separat gespeichert werden, selbst wenn Verbraucherpreise inklusive Steuern angezeigt werden.
- Nachweise zum Kundenstandort, nicht nur ein Länderfeld. Rechnungsadresse, Lieferadresse, IP-Adresse und Bank-Signale sowie die vom System daraus abgeleitete Entscheidung.
- VIES-Validierung für den innergemeinschaftlichen B2B-Handel. VIES prüft nationale Datenbanken, nicht ein einziges zentrales Register. Daher kann es passieren, dass eine gültige Nummer nicht aufscheint, der Dienst vorübergehend ausfällt und die historische Gültigkeit im Nachhinein nicht mehr bestätigt werden kann.
- OSS- und IOSS-Gruppierung, Korrekturen und Audit-Exporte. Die Europäische Kommission erkennt das OSS Standard Audit File als ein in allen Mitgliedstaaten akzeptiertes Format an.
- Marktplatz-Haftungslogik (marketplace liability), die abbildet, ob der Verkäufer, der Käufer oder die Plattform die Steuer erhebt und abführt.
- Korrekturen, die mit der ursprünglichen Transaktion verknüpft bleiben, sodass Rückerstattungen, Gutschriften und Rabatte durch die Anpassung der Steuererklärung nachverfolgbar sind.
Wenn ein Anbieter Ihnen nicht zeigen kann, wie jeder dieser Punkte gespeichert und exportiert wird, sollten Sie diese Lücke als echte Kosten betrachten und nicht als nebensächliches Detail.
Die Auswahlkriterien, die die Entscheidung verändern
| Kriterium | Was zu prüfen ist | Warum es wichtig ist |
|---|---|---|
| Buchhaltungstiefe | Unveränderliches Hauptbuch (immutable ledger), Buchungssätze, Kontenplan, Periodensperre, Auszahlungsabstimmung | Eine Steuer-Engine allein erzeugt keine verlässlichen Finanzberichte |
| Umsatzsteuerberechnung | Land, Kundentyp, Produktkategorie, Leistungsort, Befreiungen, Reverse Charge, Bruttopreisfindung | Einfache Steuersatzabfragen versagen bei gemischten Waren, B2B und Marktplatz-Workflows |
| Standortnachweise | Speicherung von Rechnungs- und Lieferadresse, IP, Bank-Signalen und der getroffenen Entscheidung | Die steuerliche Behandlung hängt oft von Nachweisen ab, nicht von einem einzelnen Länderwert |
| VIES-Workflow | Request-IDs, Zeitstempel, Caching, Retry-Handling, manuelle Prüfschleifen | VIES kann nicht verfügbar sein; der Checkout darf nicht von einem einzigen synchronen Aufruf abhängen |
| OSS / IOSS | Gruppierung, Union- und Nicht-Union-OSS, Korrekturen, Audit-Exporte | „Unterstützt OSS“ kann nur einen Report oder aber die vollständige Einreichung bedeuten |
| Marktplatzregeln | Logik des fiktiven Lieferers (deemed supplier), USt-IdNrn. der Verkäufer, Provisionsbehandlung, Reporting auf Verkäuferebene | Plattformen tragen Haftungsrisiken, die bei gewöhnlichen Checkouts nie auftreten |
| Prüfbarkeit (Auditability) | Unveränderliche Datensätze, Periodensperren, Ursprungsbelege, Erklärungen zur Steuerentscheidung, Exportformate | Behörden können Aufzeichnungen Jahre später anfordern |
| Integration | REST, Webhooks, SDKs, Idempotenz, Sandbox, Versionierung, Event-Replay | Schwache Mechanismen erzeugen doppelte oder nicht abgestimmte Steuerdatensätze |
| Geschäftsmodell | Pro Berechnung, pro Transaktion, pro Einreichung, pro Konto oder auf Angebotsbasis | Kosten verschieben sich stark mit Volumen und Gerichtsbarkeiten |
| Datenportabilität | Export von Hauptbuch, Rechnungen, Steuernachweisen, USt-IdNrn., Einreichungshistorie | Wechselkosten sind hoch, wenn der Anbieter das führende System (System of Record) ist |
| Reifegrad | Verfügbarkeit, SLA, Support, Referenzkunden | Ein Early-Access-Produkt mag attraktiv sein, ist aber für einreichungskritische Aufgaben noch unbewährt |
Zwei davon werden oft unterschätzt. Die Unterstützung von Idempotenz ist wichtiger, als Teams meist erwarten, denn ein wiederholter Netzwerkaufruf (retry), der einen doppelten Umsatzsteuereintrag erzeugt, verfälscht die Umsatzsteuervoranmeldung im Hintergrund unbemerkt. Nordlet akzeptiert einen Idempotency-Key-Header bei jedem mutierenden Aufruf, sodass ein wiederholter Request niemals ein Duplikat erzeugen kann. Genau das ist die Art von technischem Detail (plumbing detail), das ein Buchhaltungs-Backend von einer einfachen Steuersatz-API unterscheidet. Die Periodensperre ist das zweite: Abgeschlossene Monate dürfen nicht stillschweigend überschrieben werden, und Korrekturen müssen nachverfolgbare Anpassungsbuchungen anstelle von einfachen Änderungen erzeugen.
Vergleich der qualifizierten Kandidaten
Die meisten Tools, die bei einer Suche nach Umsatzsteuer-Software auftauchen, gehören nicht zur selben Produktkategorie. Hier sehen Sie, wo die führenden Kandidaten stehen und für welchen Einsatzbereich sie sich jeweils eignen.
| Kandidat | Kategorie | Öffentliche Preisgestaltung | Bester Einsatzzweck |
|---|---|---|---|
| Nordlet | API-First-Cloud-Buchhaltung mit integrierter EU-Umsatzsteuer | Veröffentlicht: Pläne ab 10 €/Monat, abgerechnet nach API-Requests, jedes Modul in jedem Plan enthalten; Early Access, Onboarding von Design-Partnern | Plattformen und Marktplätze, die Buchführung, Auszahlungen und Umsatzsteuer im eigenen Produkt benötigen |
| Stripe Tax | Steuerberechnung, -erhebung und optional verwaltete Einreichung innerhalb von Stripe | Veröffentlicht: 0,04 € pro API-Aufruf zur Berechnung und 0,45 € pro Transaktion dort, wo eine Registrierung zur Steuererhebung vorliegt; Tax Complete-Pläne von 80 € bis 1.400 €/Monat | Stripe-basierte Unternehmen, die eine schnelle Steuerberechnung wünschen |
| Quaderno | Steuerautomatisierung, konforme Rechnungsstellung und Reporting | Veröffentlicht: ab 29 $/Monat (25 Transaktionen) bis 149 $/Monat (2.500); Enterprise-Tarife darüber hinaus auf Anfrage | Kleinere digitale und Multichannel-Verkäufer, die steuerkonforme Rechnungen benötigen |
| Avalara | Umfassende Engine für indirekte Steuern und Compliance-Dienstleistungen | Auf Angebotsbasis | Großunternehmen, die breite Abdeckung und ERP-Integrationen benötigen |
| Vertex | Enterprise-Steuer-Engine mit Modellierung der Marktplatz-Haftung | Nicht veröffentlicht | Multi-Seller-Marktplätze, bei denen die Haftungsfrage zwischen Verkäufer und Plattform im Mittelpunkt steht |
| Sovos | Verwaltete Umsatzsteuer-Compliance und regulatorische Dienstleistungen | Auf Angebotsbasis (Custom) | Unternehmen, die in großem Umfang verwaltete Registrierungen und Einreichungen wünschen |
Die Preise entsprechen den Angaben auf der öffentlichen Preisseite des jeweiligen Anbieters zum Zeitpunkt der Erstellung dieses Artikels und können jederzeit unangekündigt geändert werden; bitte überprüfen Sie diese, bevor Sie budgetieren.
Einige Kompromisse (Trade-offs) verdienen besondere Aufmerksamkeit.
Nordlet im Vergleich zu reinen Steuer-Tools. Der Unterschied besteht darin, dass Nordlet nicht den Ansatz verfolgt, die Umsatzsteuer neben Ihrer Buchhaltung zu berechnen. Es ist die Buchhaltung. Wenn die Plattform selbst das Eigentum am Buchhaltungsdatenmodell haben muss – inklusive Auszahlungen und Audit-Trails –, ist dies der richtige Ansatz. Der ehrliche Kompromiss liegt beim Reifegrad: Das Produkt befindet sich im Early Access, und obwohl OSS- und IOSS-Erklärungen auf Basis Ihrer Rechnungen mit Korrekturen aus Vorperioden berechnet werden, stehen inländische Erklärungspakete aktuell für drei Länder zur Verfügung – Litauen (FR0600), Deutschland (UStVA) und Polen (JPK_V7M) – und keine Erklärung wird in Ihrem Namen an eine Behörde übermittelt. Ein ernsthafter Interessent sollte die Länderabdeckung und den Einreichungs-Workflow direkt validieren, anstatt einfach davon auszugehen.
Stripe Tax im Vergleich zu Quaderno. Stripe Tax hat die transparenteste öffentliche API-Preisgestaltung in dieser Gruppe und fügt sich nahtlos ein, wenn Sie sich bereits im Billing- und Checkout-Stack von Stripe bewegen. Die Transaktions-API erfasst Steuertransaktionen, keine allgemeinen Buchungsjournale. Quaderno ist stärker auf Vertriebsplattformen ausgerichtet, mit transparenten Monatsplänen und einer flexiblen API für die Übermittlung von Verkaufsdaten, auch wenn das öffentliche Material keine spezifische Unterstützung für OSS/IOSS oder ein Hauptbuch bestätigt. Keines von beiden sollte als Ersatz für eine doppelte Buchführung betrachtet werden.
Avalara, Vertex und Sovos. Dies sind Enterprise-Lösungen. Avalara hat die größte Abdeckung für indirekte Steuern, erfordert jedoch einen Vertriebsprozess zur Festlegung des Leistungsumfangs (Scoping). Vertex sticht bei Marktplätzen hervor, da es explizit Dreiparteientransaktionen modelliert und bestimmt, welche Partei steuerpflichtig ist. Sovos ist dort am stärksten, wo verwaltete Registrierung, Steuererklärungen und regulatorische Unterstützung schwerer wiegen als eine eingebettete Buchhaltung. Keines dieser Produkte ist als Hauptbuch-API (general-ledger API) dokumentiert.
Für eine Plattform, deren Kernanforderung eingebettete, prüfungssichere Bücher sind, bei denen die Umsatzsteuer im selben Buchungssatz erfasst wird, bietet Nordlet unter diesen Kandidaten die sauberste Lösung – mit dem Vorbehalt, dass seine Produktionsreife (production readiness) das ist, was getestet werden muss, und nicht seine Architektur.
Die Frage zu 2027 bis 2030, die die meisten Käufer übersehen
Die Auswahl eines Umsatzsteuer-Tools im Jahr 2026 allein auf Basis der heutigen Regeln ist kurzsichtig. Das EU-Paket „VAT in the Digital Age“ (ViDA) wurde im März 2025 verabschiedet und wird in mehreren Phasen eingeführt.
- Ab dem 1. Januar 2027 ändern sich OSS und IOSS, einschließlich eines neuen Korrekturmechanismus, zusätzlicher IOSS-Informationen und monatlicher IOSS-Aufstellungen nach Bestimmungsmitgliedstaat.
- Ab dem 1. Juli 2028 werden die Plattformregeln ausgeweitet und das obligatorische Reverse-Charge-Verfahren für bestimmte nicht-identifizierte Lieferanten beginnt.
- Ab dem 1. Juli 2030 verlagert sich das digitale Meldewesen für grenzüberschreitende B2B-Transaktionen auf E-Invoicing (elektronische Rechnungsstellung).
- Inländische Echtzeit-Meldesysteme (Real-time Reporting) werden bis zum 1. Januar 2035 harmonisiert.
Der Praxistest besteht nicht darin, ob eine API die Umsatzsteuer heute richtig berechnet. Es geht darum, ob ihr Datenmodell die ursprüngliche Transaktion, die steuerliche Entscheidung, die Rechnung, die Korrektur, die Identität des Verkäufers und die Nachweise in einer Form aufbewahren kann, die das E-Invoicing und das digitale Meldewesen speisen wird, wenn diese Anforderungen in Kraft treten. Ein unveränderliches Hauptbuch mit strukturierten Rechnungsmetadaten, das bereits heute in der Lage ist, ausgestellte Rechnungen als EN 16931 UBL für Peppol zu rendern, ist dafür weitaus besser positioniert als ein zustandsloser (stateless) Steuersatz-Endpunkt.
Was wir testen würden, bevor wir irgendetwas unterschreiben
- Systemgrenzen definieren. Entscheiden Sie, ob der Anbieter Ihr primäres Buchhaltungssystem (System of Record), Ihre Steuer-Entscheidungs-Engine, Ihr Einreichungsservice oder nur eine einzelne Komponente ist. Halten Sie das schriftlich fest.
- Echte Transaktionen modellieren, bevor Sie Preise vergleichen. Spielen Sie inländische B2C-, innergemeinschaftliche B2C- und innergemeinschaftliche B2B-Umsätze mit einer gültigen USt-IdNr., ungültigem oder nicht verfügbarem VIES, Marktplatz-Verkäufen als fiktiver Lieferer (deemed-supplier), Rückerstattungen, Rabatten und gemischten Steuersätzen durch.
- Fordern Sie eine Erklärung zur Steuerentscheidung. Die API-Antwort sollte aufzeigen, warum der Steuersatz, die Gerichtsbarkeit, die Steuerbefreiung, das Reverse-Charge-Verfahren oder der Steuerschuldner (liable party) gewählt wurde.
- Provozieren Sie absichtlich VIES-Fehler. Überprüfen Sie Zeitstempel, Request-IDs, Retry-Logik, gecachte Ergebnisse und einen Workflow für die manuelle Überprüfung.
- Prüfen Sie die Exporte, nicht das Dashboard. Fordern Sie Muster für OSS, Umsatzsteuervoranmeldungen, Rechnungen, Journale und Audit-Dateien (audit files) an.
- Testen Sie die Unveränderlichkeit (Immutability). Versuchen Sie, eine abgeschlossene Periode zu überschreiben. Das System sollte dies verweigern und eine nachverfolgbare Korrekturbuchung erzwingen.
- Trennen Sie die Preise für Berechnung von denen für Compliance. Ermitteln Sie die Gesamtkosten für API-Aufrufe, Transaktionen, Registrierungen, Steueranmeldungen, Datenspeicherung, Support und zusätzliche Gerichtsbarkeiten.
- Validieren Sie die Wirtschaftlichkeit für die Plattform. Modellieren Sie bei einem Marktplatz die Kosten pro Verkäufer, Transaktion und aktivem Konto – und nicht nur den plakativen Preis für das Händler-Abonnement.
- Bestätigen Sie die Produktionsreife. SLAs, Rate Limits, Webhooks, Idempotenz, Sandbox-Parität, Datenresidenz und Exportrechte.
- Bewerten Sie die Zukunftsfähigkeit. Gewichten Sie die OSS-Änderungen von 2027, die Plattformregeln von 2028 und das Cross-Border-Reporting von 2030 explizit in Ihrer Entscheidungsfindung.
Der größte Teil dieser Liste kann an einem Nachmittag in einer Sandbox-Umgebung durchgetestet werden; der Leitfaden zur EU-Umsatzsteuer-Engine dokumentiert, welche Fälle zu Leistungsort, Reverse Charge, fiktivem Lieferer und OSS/IOSS Nordlet auflöst und wann Warnungen ausgegeben werden.
FAQ
Ist eine Umsatzsteuer-API dasselbe wie eine Buchhaltungs-API?
Nein. Eine Umsatzsteuer-API berechnet oder übermittelt Steuern. Eine Buchhaltungs-API führt doppelte Bücher und speichert die Umsatzsteuer als ein Attribut einer erfassten Transaktion. Wenn Ihre Plattform das primäre System (System of Record) sein muss, führt ein reines Umsatzsteuer-Tool dazu, dass Sie das Hauptbuch anderswo führen und zwei Quellen miteinander abstimmen müssen.
Kann ich mich beim Checkout auf VIES für die B2B-Echtzeit-Validierung verlassen?
Nicht als einzige synchrone Abhängigkeit. VIES fragt nationale Datenbanken ab und kann vorübergehend nicht verfügbar sein. Eine gültige Nummer wird möglicherweise nicht angezeigt, wenn das Unternehmen nicht für den innergemeinschaftlichen Handel registriert ist, und die frühere Gültigkeit lässt sich später nicht mehr bestätigen. Bauen Sie Caching, Retries, Zeitstempel, Request-IDs und eine manuelle Prüfschleife um diese Funktion herum.
Bedeutet „unterstützt OSS“, dass der Anbieter meine Umsatzsteuervoranmeldungen einreicht?
Selten, und Sie sollten niemals davon ausgehen. Es kann bedeuten, dass ein Report generiert, eine Berechnung durchgeführt, Hilfe bei der Registrierung geleistet oder die Einreichung vollständig verwaltet (managed submission) wird. Fragen Sie genau nach, welche Länder und Meldungen abgedeckt sind, wer sie einreicht und wie Korrekturen gehandhabt werden.
Warum erscheint Nordlet in diesem Vergleich, wenn es sich noch im Early Access befindet?
Weil es in seiner Kategorie am besten zu Plattformen passt, die eingebettete Bücher, Auszahlungen, Integrität des Hauptbuchs und Umsatzsteuer-Metadaten in einem einzigen Produkt benötigen – was die meisten reinen Steuer-APIs nicht bieten. Der Early Access stellt eine echte Einschränkung in Bezug auf Produktionszeitpläne und Länderabdeckung dar. Betrachten Sie daher die Verfügbarkeit und den Einreichungs-Workflow eher als Prüfpunkte denn als gesicherte Tatsachen.
Welcher einzelne Fehler verursacht später die größten Umsatzsteuerprobleme?
Das Nichtspeichern der Nachweise, die der Steuerentscheidung zugrunde liegen. Behörden können Aufzeichnungen noch Jahre nach einem Verkauf anfordern, und OSS-Aufzeichnungen müssen zehn Jahre lang aufbewahrt werden. Ein Tool, das einen korrekten Steuersatz zurückgibt, aber die Standortnachweise, das VIES-Ergebnis und die Transaktionsverknüpfung verwirft, wird bei einer Prüfung durchfallen, auch wenn jede einzelne Berechnung korrekt war.