Echtzeit-EU-MwSt. für Entwickler mit Fokus auf Tschechien

Tschechien verlangt etwas, das die meisten Mehrwertsteuer-Anbieter nicht im Repertoire haben: eine Kontrollmeldung auf Belegebene (Kontrolní hlášení), die monatlich parallel zur normalen Steuererklärung eingereicht werden muss. Bei der Kontrolní hlášení handelt es sich um keine Zusammenfassung, sondern um eine detaillierte Liste von Belegen. Eine Plattform, die Ihnen zwar die geschuldete Gesamtwertsteuer nennen kann, aber nicht die zugrundeliegende Belegliste ausgibt, hat nur die Hälfte einer tschechischen Integration gelöst – und zwar die einfachere Hälfte.

Dieser Beitrag vergleicht die entwicklerorientierten Plattformen, die EU- und tschechische MwSt. in Echtzeit abwickeln, trennt die Steuerberechnung von der Buchhaltung sowie der Einreichung und zeigt auf, wozu die jeweilige Option tatsächlich passt.

Was „Echtzeit-EU-MwSt.-Management“ beinhalten muss

Der Begriff wird oft so weit gefasst, dass er völlig unterschiedliche Produkte abdeckt. Damit er eine Bedeutung hat, muss eine Plattform die folgenden Punkte während der Erstellung einer Transaktion, Rechnung, Auszahlung oder Buchung weitgehend erfüllen:

• Ermittlung der steuerlichen Behandlung (VAT Treatment) aus den Transaktionsdaten.
• Anwendung der aktuellen Länder- und Produktregeln.
• Abdeckung Tschechiens und der weiteren EU, einschließlich B2B-Steuerschuldumkehr (Reverse Charge) und B2C-Bestimmungslandbesteuerung.
• Bereitstellung all dessen über eine API, ein SDK oder Webhooks.
• Speicherung der Daten für MwSt., OSS, Prüfung (Audit) und buchhalterische Berichterstattung.

Hinter den Worten „Echtzeit“ (Real-Time) verbergen sich drei verschiedene Funktionen:

• Echtzeit-Berechnung (Real-time calculation) – Die MwSt. wird im Moment der Transaktions- oder Rechnungsgenerierung berechnet.
• Echtzeit-Buchhaltung (Real-time accounting) – Die Transaktion, der Buchungssatz und die MwSt.-Daten landen umgehend in der Buchhaltung.
• Echtzeit-Berichterstattung (Real-time reporting) – Die Daten werden kurz nach der Transaktion an die Steuerbehörde übermittelt.

Die meisten Produkte leisten den ersten Punkt. Die wenigsten alle drei. Tschechien nimmt dabei eine Mittelstellung ein: Es gibt keine Clearance-Plattform, aber die monatliche Kontrollmeldung sorgt dafür, dass die Steuerverwaltung detaillierte Belegdaten statt reiner Summen erhält. Ein System, das nur Aggregatwerte speichert, kann diese Anforderung nicht erfüllen.

Die tschechischen und EU-Regeln, die den Vergleich prägen

Tschechien wendet einen Standardsteuersatz von 21% sowie einen einzigen ermäßigten Steuersatz von 12% an (welcher 2024 aus den früheren Sätzen von 15% und 10% zusammengelegt wurde); Bücher sind steuerfrei (nullprozentig), ebenso Ausfuhren und innergemeinschaftliche Lieferungen. Die aktuelle Rechtsgrundlage bildet das Umsatzsteuergesetz, Gesetz Nr. 235/2004 Sb.. Eine Registrierung ist ab einem Jahresumsatz von 2.000.000 CZK vorgeschrieben, wobei eine zweite Schwelle von 2.536.500 CZK die sofortige MwSt.-Pflicht auslöst. Da Tschechien die Krone (Koruna) verwendet, benötigt eine Plattform, die von Euro-Beträgen ausgeht, Umrechnungs- und Rundungsregeln, die einer Betriebsprüfung standhalten.

Für qualifizierte innergemeinschaftliche B2C-Fernverkäufe und grenzüberschreitende digitale Dienstleistungen gilt die EU-weite Schwelle von 10.000 €, wie im One-Stop-Shop-Portal der Europäischen Kommission dargelegt. Oberhalb dieser Schwelle richtet sich die MwSt. im Allgemeinen nach dem Mitgliedstaat des Kunden. Der One-Stop-Shop ermöglicht es Unternehmen, sich in einem Mitgliedstaat zu registrieren und die grenzüberschreitende B2C-MwSt. für die gesamte EU zu erklären, entbindet jedoch nicht von der Notwendigkeit einer transaktionsbezogenen Logik.

Hinzu kommt eine Marktplatzregelung, die strenger ist als von den meisten Teams erwartet. Nach Artikel 14a wird eine elektronische Schnittstelle zum als Lieferant geltenden Beteiligten (deemed supplier) bei Fernverkäufen eingeführter Waren in Sendungen mit einem Wert von höchstens 150 € sowie separat bei Waren, die an EU-Kunden in beliebiger Höhe geliefert werden, wenn der zugrundeliegende Verkäufer nicht in der EU ansässig ist. Die Erläuterungen der Kommission zu den E-Commerce-MwSt.-Vorschriften decken beide Aspekte ab. Wenn Sie einen Marktplatz aufbauen, ändert dies die Architektur grundlegend, anstatt nur ein Feld hinzuzufügen.

Die engere Auswahl auf einen Blick

Plattform	Best Fit	Echtzeit-MwSt.-Fähigkeit	Buchhaltung, OSS und Einreichungsumfang	Hauptvorbehalt
Stripe Tax	Produkte und Marktplätze, die bereits auf Stripe laufen	Berechnet MwSt. bei Transaktionserstellung, inkl. Tschechien	EU-Exporte und OSS-Daten; kein tschechisches Hauptbuch, reicht EU-Meldungen nicht selbst ein	Lohnt sich nur, wenn Stripe ohnehin als Zahlungsschiene dient
Paddle	SaaS und digitale Download-Produkte	Berechnet MwSt. beim Checkout anhand des Kundenstandorts	Registriert, meldet und führt ab als Merchant of Record	Übernimmt die Rolle des Verkäufers (Seller of Record) und damit auch die Rechnung
Quaderno	Kleinere SaaS- und Digitalkonzepte	Berechnet beim Checkout, validiert MwSt.-Nummern	Steuerberichte und Aufzeichnungen; automatische Einreichung nicht für jeden Tarif dokumentiert	Eine Steuer- und Rechnungsschicht, kein Hauptbuch
Avalara AvaTax	Enterprise-ERP- und Abrechnungs-Stacks	Echtzeit-Steuerermittlung mit gepflegten Steuerinhalten	VAT Reporting ist ein separates Produkt innerhalb der Returns-Produktpalette	Konfiguriert und bepreist für Unternehmenseinführungen
Fonoa Tax Engine	Große Plattformen und Marktplätze	Echtzeit-Bestimmung über mehr als 190 Jurisdiktionen hinweg	Steuererklärungen, E-Invoicing und Berichterstattung; Validierung von Steuernummern ist ein separates Produkt	Keine veröffentlichten Preise
Nordlet	Integrierte Buchhaltung in Marktplätzen und Plattformen	Ermittelt Schema und Steuersätze pro Transaktion, verbucht zusammen mit dem Buchungssatz	Unveränderliches doppeltes Hauptbuch, Auszahlungen, OSS- und IOSS-Werte, exportierbarer Audit-Trail	Kein tschechisches Steuererklärungs- oder Kontrollmeldungs-Paket; liefert die Buchungsdetails, auf denen beide basieren

Stripe Tax: Der schnelle Weg, wenn Stripe bereits im Einsatz ist

Für Teams, die bereits Stripe Payments, Billing oder Connect nutzen, ist Stripe Tax die zugänglichste Echtzeit-Berechnungsschicht. Die Dokumentation deckt die weltweite MwSt.-Berechnung, die Tax API mit PaymentIntents, den Steuereinzug auf Rechnungen sowie die Nutzung von Tax mit Connect als Plattform oder Marktplatz ab.

Wo Stripe an seine Grenzen stößt, benennt das Unternehmen ganz offen. In seiner Dokumentation zur Einreichung heißt es: „Sie müssen die von Ihnen erhobene Steuer für jeden Standort, an dem Sie registriert sind, selbst anmelden und abführen.“ Eine automatisierte Einreichung wird in den USA angeboten; andernfalls arbeitet Stripe mit Einreichungspartnern zusammen, sodass eine EU-MwSt.-Erklärung von Ihnen oder einem Partner eingereicht wird, nicht jedoch von Stripe Tax. Es handelt sich um eine Berechnungs- und Exportschicht, nicht um ein Buchhaltungssystem.

Für eine tschechische Implementierung liefert Ihnen Stripe Tax zwar den Steuersatz, aber keinerlei Unterstützung für die Kontrolní hlášení – und genau dort entsteht der monatliche Routineaufwand.

Paddle: Die gesamte steuerliche Verantwortung auslagern

Paddle ist eine andere Produktkategorie. Es agiert als Merchant of Record und übernimmt die Verantwortung für die „Berechnung, Einreichung und Abführung“ von Steuern in den Ländern Ihrer Kunden. Es berechnet somit die MwSt. beim Checkout, stellt die Rechnung aus und kümmert sich um Einreichung und Abführung. Die Entwicklerdokumentation deckt Paddle.js, die Katalog-APIs, den Checkout sowie Webhooks wie transaction.completed ab. Letzterer wird ausgelöst, sobald eine Transaktion den Status completed erreicht, und dient üblicherweise als Hook zur Freigabe des Zugangs nach der Zahlung.

Der Kompromiss ist eher struktureller als technischer Natur. Paddle wird zum offiziellen Verkäufer (Seller of Record), sodass Sie nicht mehr das Händler-, Rechnungs- und Buchhaltungsmodell behalten, das Sie bei einem eigenen Checkout führen würden.

Für digitale Produkte, die an tschechische Verbraucher verkauft werden, löst dies das Problem der Steuererklärung. Ein tschechisches Unternehmen schuldet jedoch nach wie vor seine eigene DPH-Erklärung und die Kontrolní hlášení für seine inländischen Aktivitäten.

Quaderno: Eine Steuerschicht für kleinere digitale Unternehmen

Quaderno ist eine der übersichtlicheren, entwicklerzentrierten Optionen für kleinere digitale Unternehmen, die einen Steuerdienst unabhängig von einem einzelnen Zahlungsabwickler suchen. Die API dokumentiert einen Endpunkt /tax_rates/calculate, der den geltenden Steuersatz anhand der Kundenadresse und des Transaktionstyps berechnet, einen Endpunkt /tax_ids/validate für EU-MwSt.-Nummern sowie Endpunkte für Rechnungen, Belege und Gutschriften. Ein dokumentierter Connect-Bereich mit Kontoressourcen stellt die Grundlage dar, auf die ein Marktplatz aufbauen würde.

Die Einschränkung liegt im Funktionsumfang. Quaderno ist eine Steuer- und Rechnungsschicht und kein Buchhaltungssystem mit einem unveränderlichen doppelten Hauptbuch. Zudem wird in den öffentlichen Materialien nicht garantiert, dass die automatische Einreichung in jedem Tarif und jedem Land verfügbar ist. Die Verantwortung für die Einreichung sollten Sie sich daher immer schriftlich bestätigen lassen.

Das Tool eignet sich gut als Checkout-Schicht für ein kleines tschechisches Digitalunternehmen, liefert jedoch weder die DPH-Meldung noch die Kontrolní hlášení.

Avalara und Fonoa: Die Steuersysteme für Enterprise-Anforderungen

Avalaras AvaTax führt Echtzeit-Steuerermittlungen während des Checkouts, der Rechnungsstellung oder der Auftragsabwicklung über REST-APIs und SDKs durch. Beachten Sie hierbei die Produktaufteilung: VAT Reporting ist separat unter Returns angesiedelt. Ein EU-MwSt.-Compliance-Workflow ist somit nicht einfach mit „AvaTax“ erledigt – definieren Sie den Umfang der Module, die Sie tatsächlich benötigen. Avalara dokumentiert einen Registrierungspfad mit einer 90-tägigen Testversion, während das kommerzielle Produktionsmodell auf Enterprise-Kunden ausgerichtet ist.

Fonoas Tax Engine gibt an, „die korrekte Behandlung indirekter Steuern für jede Transaktion in Echtzeit“ über eine versionierte API in über 190 Jurisdiktionen zu berechnen. Ein architektonisches Detail ist wichtig: Die Validierung von Steuernummern ist ein separates Fonoa-Produkt (Validate) und kein Bestandteil der Tax Engine. Wenn VIES-Nachweise für Sie entscheidend sind, sollten Sie dies explizit einplanen und nicht davon ausgehen, dass die Engine dies automatisch abdeckt.

Beide Lösungen sind für große, multinationale Plattformen denkbar, die zufällig auch Tschechien bedienen. Für ein rein tschechisches Setup ist der Kostenaufwand schwer zu rechtfertigen.

Wo Nordlet ins Spiel kommt: Die MwSt.-Antwort und der Buchungssatz sind derselbe Datensatz

Nordlet ist eine Buchhaltungs-API für Marktplätze und Plattformen, die Hauptbücher, Auszahlungen, EU-Steuern und einen exportierbaren Audit-Trail direkt in ihrem eigenen Produkt benötigen, anstatt auf eine an den Checkout gekoppelte Rechnungs-App angewiesen zu sein.

Der architektonische Unterschied besteht darin, dass die MwSt.-Bestimmung und die Buchung zu einem einzigen System gehören. POST /v1/reference/vat/resolve beantwortet die steuerliche Behandlungsfrage anhand der Transaktionsfakten:

{
  "customerCountryCode": "CZ",
  "customerIsBusiness": false,
  "supplyType": "digital"
}

{
  "scheme": "oss_union",
  "vatCountryCard": "CZ",
  "reverseCharge": false,
  "deemedSupplier": false,
  "zeroRated": false,
  "rates": [
    { "category": "standard", "ratePercent": "21.00" },
    { "category": "reduced", "ratePercent": "12.00" }
  ],
  "legalBasis": "Directive 2006/112/EC art. 58 - taxable where the consumer resides; report via the Union OSS"
}

Wenn Sie den Kunden in ein Unternehmen mit einer gültigen tschechischen MwSt.-Nummer ändern, liefert derselbe Aufruf reverse_charge mit dem Vermerk Directive 2006/112/EC art. 44, 196 - VAT due by the customer (reverse charge). Setzen Sie actingAsMarketplace mit einem außerhalb der EU ansässigen Verkäufer, wird deemedSupplier: true gemäß art. 14a(2) zurückgegeben. Die Rechtsgrundlage wandert direkt mit dem Ergebnis mit – genau der Punkt, nach dem Prüfer Jahre später fragen.

Es werden neun Schemata modelliert: domestic, intra_eu_b2b, reverse_charge, oss_union, ioss, marketplace_deemed, export, out_of_scope und sme_exempt. Die Fernverkaufsschwelle von 10.000 € wird aktiv verfolgt – /v1/declarations/eu/distance-sales-threshold/get gibt Auskunft über die Position des Unternehmens dazu, und /v1/declarations/eu/oss/compute sowie /v1/declarations/eu/ioss/compute generieren die Periodenwerte einschließlich eines Korrekturbereichs für zurückliegende Zeiträume. Die Steuersätze stammen aus dem TEDB-Feed der Europäischen Kommission mit entsprechenden Gültigkeitsdaten, wobei Unternehmen diese pro Land überschreiben können.

Die Ermittlung fließt direkt in ein unveränderliches doppeltes Hauptbuch ein, wobei die MwSt.-Metadaten an den Buchungssatz angehängt werden. Es ist somit keine zweite Abstimmung zwischen einer Steuer-Engine und einem separaten Aufzeichnungssystem erforderlich. Geldwerte werden als Dezimalstrings und niemals als Gleitkommazahlen dargestellt. Hinzu kommen typisierte SDKs, Webhooks wie sale_invoice.paid, Unterstützung für Idempotency-Key für sichere Wiederholungen, Sandbox-Unternehmen, gegen die Rechnung eingefrorene VIES-Validierungen, Unterstützung für mehrere Unternehmen sowie Periodensperren, damit ein abgeschlossener Monat nicht nachträglich bearbeitet werden kann.

Die tschechische Grenze, offen ausgesprochen: Nordlet liefert kein tschechisches Paket. Ein Aufruf von /v1/declarations/eu/vat-return/compute mit countryCode: "CZ" gibt den Fehlercode 422 zurück und verweist stattdessen auf Litauen, Deutschland und Polen; weder die DPH-Meldung noch die Kontrolní hlášení werden generiert. Vorhanden ist jedoch die Schicht, auf der beide aufbauen – eine Steuerermittlung inklusive Rechtsgrundlage, ein unveränderliches doppeltes Hauptbuch mit MwSt.-Metadaten am Buchungssatz, rechnungsbezogene Datensätze, die einen Periodenabschluss überdauern, OSS- und IOSS-Berechnungen mit Korrekturen, gegen die Rechnung eingefrorene VIES-Validierungen sowie strukturierte Rechnungen über Peppol BIS 3.0.

Das ehrliche Fazit: Wenn Sie eine Live-Berechnung in möglichst vielen Ländern benötigen und die Einreichung von Dritten erledigt werden soll, haben die Enterprise-Steuer-Engines und Merchant-of-Record-Dienste die Nase vorn. Wenn Ihre Hauptanforderung jedoch echte Buchhaltung ist – ein marktplatzfähiges, doppeltes Hauptbuch, in dem Auszahlungen und MwSt. an einem Ort zusammenlaufen –, genau diese Lücke schließt Nordlet, und keine der reinen Berechnungsschichten füllt sie aus. Die API-Referenz zeigt den vollen Funktionsumfang, bevor Sie sich festlegen.

Was Tschechien von Ihnen verlangt

In Tschechien müssen monatlich zwei Verpflichtungen erfüllt werden, die leicht verwechselt werden und keineswegs dasselbe sind:

• DPH-Erklärung (DPH return) – Die MwSt.-Erklärung, fällig bis zum 25. des Folgemonats. Sie kann je nach Umsatz monatlich oder vierteljährlich abgegeben werden.
• Kontrolní hlášení – Die MwSt.-Kontrollmeldung, die von juristischen Personen unabhängig vom Meldezeitraum ebenfalls monatlich bis zum 25. eingereicht wird. Sie listet einzelne Belege statt Summen auf und wird mit den Erklärungen der Handelspartner abgeglichen.

Die Kontrollmeldung ist der Grund, warum eine tschechische Integration Daten auf Belegebene und keine reinen Periodenaggregate benötigt. Wenn Ihre Plattform nicht in der Lage ist, die Rechnungen hinter einem Betrag aufzulisten, wird jemand jeden Monat mühsam Tabellen exportieren müssen.

Das Gesamtbild für das Land – Unternehmenssteuern, Lohn- und Gehaltsabrechnung, Meldekalender und die jeweiligen Behörden hinter den Formularen – finden Sie auf der Seite zu Steuern in Tschechien.

Auswahlkriterien, die Sie vor einer Entscheidung prüfen sollten

Bevor Sie ein „MwSt.-fähiges“ Produkt als gleichwertig mit einem anderen betrachten, sollten Sie es anhand dieser Kriterien überprüfen:

• Berechnung oder Buchhaltung – Bestimmt das System die steuerliche Behandlung oder speichert es nur einen übergebenen Code?
• Tschechische Abdeckung – 21 %, 12 %, steuerfreie Bücher, Reverse-Charge, Kronenbeträge und die Schwelle von 2.000.000 CZK?
• EU-Bestimmungslandlogik – Kann es bei einem B2C-Verkauf die tschechische MwSt. von der eines anderen Mitgliedstaats unterscheiden?
• B2B-MwSt.-Nummern-Validierung – Prüft das System VIES und speichert den Nachweis?
• OSS und IOSS – Aggregiert, vorbereitet, übermittelt oder exportiert das System lediglich?
• Marktplatzhaftung – Können die Rollen von Verkäufer, Plattform und Steuerschuldnerschaft (deemed supplier) abgebildet werden?
• Buchhalterische Integrität – Erzeugt jede Berechnung einen passenden Buchungssatz?
• Entwickler-Ergonomie – REST-API, SDKs, Webhooks, Sandbox, Idempotenz, Versionierung?
• Audit-Trail – Steuersatz, Regel, Standortnachweis, MwSt.-Nummer, Zeitstempel, Revisionshistorie?
• Kontrollmeldungsdaten – Kann eine belegbasierte Liste für die monatliche Kontrolní hlášení statt reiner Periodensummen ausgegeben werden?
• Verantwortung für die Einreichung – Welchen Schritt übernimmt der Anbieter exakt?

FAQ

Welche Plattform bietet ein vollständiges Echtzeit-EU-MwSt.-Management in Tschechien?

Keine der Plattformen deckt alle drei Echtzeit-Funktionen für jedes Geschäftsmodell gleichermaßen ab. In Tschechien liegt die praktische Trennlinie darin, ob ein Anbieter belegbezogene Datensätze speichert, da die Kontrollmeldung diese jeden Monat erfordert.

Ist Stripe Tax für einen tschechischen Marktplatz ausreichend?

Für Berechnungen und Exporte meist ja. Für ein doppeltes Hauptbuch, das Auszahlungen über viele Verkäufer hinweg verfolgt, nein. Weder die DPH-Erklärung noch die Kontrolní hlášení werden ausgegeben.

Reicht Nordlet tschechische MwSt.-Erklärungen automatisch ein?

Nein, und es berechnet auch weder die DPH-Meldung noch die Kontrolní hlášení. Erklärungspakete sind für Litauen, Deutschland und Polen verfügbar; für Tschechien gibt die API den Fehlercode 422 zurück. Das System liefert jedoch die Steuerermittlung, das Hauptbuch, die OSS- und IOSS-Werte sowie den Audit-Trail.

Was ist die Kontrolní hlášení in der Praxis?

Ein monatlicher Bericht auf Belegebene, der von juristischen Personen parallel zur MwSt.-Erklärung eingereicht wird. Er listet Belege anstelle von Summen auf und wird mit den Meldungen der Handelspartner abgeglichen, sodass Diskrepanzen schnell zutage treten.

Was als Nächstes zu tun ist

Entscheiden Sie, welche der drei Echtzeit-Fähigkeiten Sie benötigen, und klären Sie die Anforderung bezüglich der Kontrolní hlášení frühzeitig, da sie eher Ihr Datenmodell als Ihre Integration einschränkt. Wenn Sie eine Live-Berechnung auf einem Stripe-Stack benötigen, beginnen Sie mit Stripe Tax. Wenn Sie digitale Produkte verkaufen und die Einreichung auslagern möchten, testen Sie Paddle. Wenn die Buchhaltung, die Auszahlungen und die MwSt. in Ihr eigenes Produkt gehören, legen Sie los mit der Sandbox und prüfen Sie den tschechischen Leistungsumfang vor der Implementierung. Die Preise sind öffentlich einsehbar und basieren nicht auf individuellen Angeboten.

Quellen

Alle oben genannten Aussagen der Anbieter verlinken auf deren eigene Dokumentation. Die Regeln selbst stammen aus folgenden Quellen:

• Finanční správa: MwSt. und Kontrollmeldung – zur DPH-Erklärung und Kontrolní hlášení
• Umsatzsteuergesetz (Gesetz Nr. 235/2004 Sb.) – zu den Steuersätzen von 21% und 12% sowie den Registrierungsschwellen
• Europäische Kommission: MwSt.-One-Stop-Shop – zur Fernverkaufsschwelle von 10.000 €

Anbieterfunktionen und nationale Vorgaben unterliegen Änderungen. Alle Angaben wurden am 8. September 2026 anhand der öffentlichen Dokumentation überprüft; verifizieren Sie Details vor einer Implementierung.