Nordlet

← Blog

Echtzeit-EU-Umsatzsteuer für Entwickler im tschechischen Markt

Ein fundierter Vergleich von Buchhaltungs- und Steuerplattformen, die tschechische und EU-Umsatzsteuer über APIs, SDKs und Webhooks abwickeln, mit klaren Hinweisen zu ihrem tatsächlichen Funktionsumfang.

Nordlet Team · · 13 Min. Lesezeit

Tschechien verlangt etwas, das die meisten USt-Anbieter nicht bereitstellen: eine Kontrollmeldung (control statement) auf Rechnungsebene, die monatlich neben der regulären Umsatzsteuer-Voranmeldung eingereicht wird. Das kontrolní hlášení ist keine Zusammenfassung – es listet einzelne Belege auf. Eine Plattform, die Ihnen zwar die geschuldete Gesamtumsatzsteuer nennt, aber die zugrunde liegende Belegliste nicht erzeugen kann, hat nur die halbe tschechische Integration gelöst – und zwar die einfachere Hälfte.

Dieser Artikel vergleicht entwicklerorientierte Plattformen, die EU- und tschechische Umsatzsteuer in Echtzeit verarbeiten. Er trennt die Berechnung von der Buchführung sowie dem Meldewesen und zeigt auf, wofür sich die jeweilige Option tatsächlich eignet.

Was ein „Echtzeit-EU-Umsatzsteuer-Management“ umfassen muss

Dieser Begriff wird oft gedehnt und für sehr unterschiedliche Produkte verwendet. Damit er Aussagekraft hat, muss eine Plattform das Meiste des Folgenden leisten, während eine Transaktion, eine Rechnung, ein Settlement oder ein Buchungssatz erstellt wird:

  • Die umsatzsteuerliche Behandlung aus den Transaktionsdaten ermitteln.
  • Die aktuellen Länder- und Produktregeln anwenden.
  • Tschechien und die gesamte EU abdecken, einschließlich B2B-Reverse-Charge-Verfahren und B2C-Bestimmungslandprinzip (destination taxation).
  • All dies über eine API, ein SDK oder einen Webhook bereitstellen.
  • Die Daten für USt, OSS, Betriebsprüfungen (audits) und das Rechnungswesen vorhalten.

Hinter dem Begriff „Echtzeit“ verbergen sich drei verschiedene Funktionen:

  • Echtzeitberechnung (Real-time calculation) – Die USt wird bei der Erstellung der Transaktion oder Rechnung berechnet.
  • Echtzeitbuchführung (Real-time accounting) – Die Transaktion, der Buchungssatz (ledger entry) und die USt-Daten landen sofort im Hauptbuch.
  • Echtzeit-Meldewesen (Real-time reporting) – Die Daten werden kurz nach der Transaktion an eine Finanzbehörde übermittelt.

Die meisten Produkte beherrschen Ersteres. Nur sehr wenige bieten alle drei. Tschechien liegt dazwischen: Es gibt zwar keine Clearance-Plattform (Echtzeit-Freigabesystem), aber durch die monatliche Kontrollmeldung erhält die Finanzverwaltung Details auf Rechnungsebene anstelle von reinen Summen. Ein System, das nur aggregierte Daten speichert, kann dies nicht leisten.

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

Tschechien wendet einen Regelsteuersatz von 21% und einen einzigen ermäßigten Steuersatz von 12% an, der 2024 aus den früheren Sätzen von 15% und 10% zusammengelegt wurde; Bücher sind steuerbefreit (zero-rated), ebenso wie Exporte und innergemeinschaftliche Lieferungen. Die aktuelle Rechtsgrundlage ist das Umsatzsteuergesetz, Gesetz Nr. 235/2004 Sb.. Eine umsatzsteuerliche Registrierung ist bei einem Umsatz von mehr als CZK 2,000,000 in einem Kalenderjahr erforderlich, wobei ein zweiter Schwellenwert von CZK 2,536,500 die Umsatzsteuerpflicht sofort auslöst. Tschechien nutzt die Krone. Eine Plattform, die standardmäßig von Euro-Beträgen ausgeht, benötigt daher Umrechnungs- und Rundungsregeln, die einer Betriebsprüfung standhalten.

Für qualifizierende innergemeinschaftliche B2C-Fernverkäufe und grenzüberschreitende digitale Dienstleistungen gilt ein EU-weiter Schwellenwert von €10,000, der auf dem One Stop Shop-Portal der Europäischen Kommission verankert ist. Wird dieser überschritten, richtet sich die Umsatzsteuer grundsätzlich nach dem Mitgliedstaat des Kunden. Der One Stop Shop ermöglicht es einem Unternehmen, sich in einem einzigen Mitgliedstaat zu registrieren und die grenzüberschreitende B2C-Umsatzsteuer für die gesamte EU anzumelden, macht jedoch die komplexe Steuerlogik auf Transaktionsebene keinesfalls überflüssig.

Darüber hinaus gibt es eine Marktplatz-Regelung, die strenger ist, als die meisten Teams erwarten. Gemäß Artikel 14a wird eine elektronische Schnittstelle (electronic interface) zum fiktiven Lieferer (deemed supplier) für Fernverkäufe von aus dem Drittlandsgebiet eingeführten Gegenständen in Sendungen mit einem Sachwert von höchstens €150, sowie separat für an EU-Kunden gelieferte Gegenstände unabhängig vom Wert, wenn der zugrunde liegende Verkäufer nicht in der EU ansässig ist. Die Erläuterungen der Kommission zu den Mehrwertsteuer-Vorschriften für den elektronischen Geschäftsverkehr definieren beide Teilbereiche präzise. Wenn Sie einen Marktplatz entwickeln, verändert dies die gesamte Architektur, anstatt nur ein neues Feld hinzuzufügen.

Die engere Auswahl auf einen Blick

Plattform Am besten geeignet für Echtzeit-USt-Fähigkeit Umfang für Buchführung, OSS & Meldewesen Größter Vorbehalt
Stripe Tax Produkte und Marktplätze, die bereits Stripe nutzen Berechnet die USt bei Transaktionserstellung, Tschechien inbegriffen EU-Exporte und OSS-Daten; kein tschechisches Hauptbuch und reicht EU-Meldungen nicht selbst ein Lohnt sich nur, wenn Stripe bereits die Zahlungsinfrastruktur ist
Paddle SaaS und herunterladbare digitale Produkte Berechnet die USt im Checkout basierend auf dem Kundenstandort Registriert, meldet und führt als Merchant of Record (MoR) ab Übernimmt die Rolle als rechtlicher Verkäufer (seller of record) und damit auch die Rechnungsstellung
Quaderno Kleinere SaaS- und digitale Handelsunternehmen Berechnet im Checkout, validiert USt-IdNrn. Steuerberichte und -aufzeichnungen; automatische Einreichung ist nicht für jeden Tarif dokumentiert Eine Steuer- und Rechnungsebene, kein Buchhaltungssystem (ledger)
Avalara AvaTax Enterprise-ERPs und Billing-Stacks Echtzeitermittlung mit kontinuierlich gepflegten Steuerinhalten VAT Reporting ist ein separates Produkt in der Returns-Reihe Ausgelegt und bepreist für Enterprise-Rollouts
Fonoa Tax Engine Große Plattformen und Marktplätze Echtzeitermittlung in über 190 Steuerhoheitsgebieten Meldewesen, E-Invoicing und Reporting; Validierung der USt-IdNr. ist ein separates Produkt Keine veröffentlichten Preise
Nordlet Eingebettete Buchhaltung innerhalb von Marktplätzen und Plattformen Ermittelt Schema und Steuersätze pro Transaktion, verbucht zusammen mit dem Journal-Eintrag Unveränderliches System der doppelten Buchführung, Auszahlungen, OSS- und IOSS-Zahlen, exportierbarer Audit-Trail Kein tschechisches Paket für USt-Voranmeldungen oder Kontrollmeldungen; liefert stattdessen die detaillierte Buchhaltung, auf der beide aufbauen

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 am leichtesten zugängliche Echtzeit-Berechnungsebene. Die Dokumentation behandelt die weltweite USt-Berechnung, die Tax API in Verbindung mit PaymentIntents, den Steuereinzug auf Rechnungen und die Nutzung von Tax mit Connect als Plattform oder Marktplatz.

Wo Stripe aufhört, kommuniziert Stripe ganz offen. In der Filing-Dokumentation heißt es: „Sie müssen die von Ihnen eingenommenen Steuern für jeden Standort, an dem Sie registriert sind, anmelden und abführen.“ Ein automatisiertes Meldewesen wird in den USA angeboten; andernorts arbeitet Stripe mit Partnern zusammen, sodass eine EU-Umsatzsteuer-Voranmeldung von Ihnen oder einem Partner eingereicht wird, nicht von Stripe Tax. Es ist eine Berechnungs- und Exportebene, keine echte Buchhaltung.

Für eine tschechische Integration liefert Stripe Tax den Steuersatz, bietet aber keinerlei Unterstützung für die Kontrollmeldung, wo die eigentliche wiederkehrende monatliche Arbeit anfällt.

Paddle: Die komplette Steuerrolle an jemand anderen abgeben

Paddle fällt in eine völlig andere Produktkategorie. Es fungiert als Merchant of Record und übernimmt die rechtliche Verantwortung für das „Berechnen, Melden und Abführen“ von Steuern an den Standorten Ihrer Kunden. Es berechnet also die USt im Checkout, stellt die Rechnung aus und kümmert sich für Sie um die Anmeldung und Abführung. Die Entwicklerdokumentation deckt Paddle.js, die Katalog-APIs, den Checkout und Webhooks ab – wie beispielsweise transaction.completed, der ausgelöst wird, sobald eine Transaktion den Status completed erreicht, und der üblicherweise genutzt wird, um den Zugriff nach der erfolgreichen Zahlung freizugeben.

Der Kompromiss ist eher struktureller als technischer Natur. Paddle wird zum Verkäufer (seller of record), Sie behalten also nicht mehr das Händler-, Rechnungs- und Buchhaltungsmodell in der eigenen Hand, das Sie bei einem eigenen Checkout behalten würden.

Für digitale Produkte, die an tschechische Verbraucher verkauft werden, löst dies das Problem der Steueranmeldung. Ein tschechisches Unternehmen muss jedoch für seine inländischen Aktivitäten weiterhin seine eigene DPH-Erklärung und sein kontrolní hlášení beim Finanzamt einreichen.

Quaderno: Eine Steuerebene für kleinere Digitalunternehmen

Quaderno ist eine der übersichtlicheren „Developer-First“-Optionen für kleinere Digitalunternehmen, die einen von einem bestimmten Zahlungsabwickler unabhängigen Steuer-Service suchen. Die API dokumentiert einen /tax_rates/calculate-Endpunkt, der den geltenden Steuersatz anhand der Kundenadresse und des Transaktionstyps berechnet, einen /tax_ids/validate-Endpunkt, der EU-USt-IdNrn. abdeckt, sowie Endpunkte für Rechnungen, Quittungen und Gutschriften. Ein dokumentierter Connect-Bereich mit Account-Ressourcen bildet die Grundlage, auf der ein Marktplatz aufbauen würde.

Die Grenze liegt hier im Funktionsumfang. Quaderno ist eine Steuer- und Rechnungsebene, kein vollwertiges Buchhaltungssystem mit einem unveränderlichen System der doppelten Buchführung, und die öffentlichen Materialien sichern keine automatische Einreichung von Steuermeldungen in jedem Tarif und jedem Land zu. Betrachten Sie die Verantwortung für das Meldewesen als etwas, das Sie sich schriftlich explizit bestätigen lassen sollten.

Eine durchaus funktionierende Checkout-Ebene für ein kleines tschechisches Digitalunternehmen, aus der jedoch weder die DPH-Umsatzsteuererklärung noch die Kontrollmeldung automatisiert hervorgeht.

Avalara und Fonoa: Die Enterprise Tax Engines

AvaTax von Avalara führt eine Echtzeit-Steuerermittlung 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-USt-Compliance-Workflow besteht also nicht einfach nur aus „AvaTax“ – grenzen Sie die Module vorab ein, die Sie tatsächlich benötigen. Avalara dokumentiert einen Registrierungsprozess mit einer 90-tägigen kostenlosen Testversion, während das kommerzielle Produktionsmodell vollständig auf Enterprise-Kunden zugeschnitten ist.

Die Tax Engine von Fonoa gibt an, dass sie „die korrekte indirekte steuerliche Behandlung für jede Transaktion in Echtzeit berechnet“, und zwar über eine versionierte API für mehr als 190 Steuerhoheitsgebiete. Ein Architektur-Detail ist hier wichtig: Die Validierung von Steuernummern ist ein separates Fonoa-Produkt (Validate) und nicht Teil der Tax Engine. Wenn VIES-Nachweise für Sie relevant sind, müssen Sie dieses Produkt explizit einplanen und sollten nicht davon ausgehen, dass die Engine dies automatisch mit abdeckt.

Beide Lösungen sind für eine große, länderübergreifende Plattform, die zufällig auch Tschechien umfasst, eine plausible Wahl. Für eine rein tschechische Integration sind die Kosten jedoch extrem schwer zu rechtfertigen.

Wo Nordlet ansetzt: USt-Ermittlung und Buchungssatz sind ein und derselbe Datensatz

Nordlet ist eine Buchhaltungs-API für Marktplätze und Plattformen, die Hauptbücher (ledgers), Auszahlungen, EU-Steuern und einen exportierbaren Audit-Trail innerhalb ihres eigenen Produkts benötigen, anstatt einer an einen Checkout angehängten Rechnungs-App.

Der architektonische Unterschied besteht darin, dass die USt-Ermittlung und der Buchungssatz zu einem einzigen, integrierten System gehören. POST /v1/reference/vat/resolve beantwortet die Frage nach der steuerlichen Behandlung rein anhand der Transaktionsfakten:

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

{
  "scheme": "oss_union",
  "vatCountryCode": "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"
}

Ändern Sie den Kunden zu einem Unternehmen mit gültiger tschechischer USt-IdNr., und derselbe Aufruf gibt reverse_charge mit Directive 2006/112/EC art. 44, 196 — VAT due by the customer (reverse charge) zurück. Setzen Sie actingAsMarketplace mit einem außerhalb der EU ansässigen Verkäufer, und es wird deemedSupplier: true gemäß art. 14a(2) zurückgegeben. Die rechtliche Grundlage (legal basis) wird mit der Antwort konsequent mitgeliefert – genau danach wird ein Betriebsprüfer Jahre später fragen.

Neun Schemata sind modelliert: domestic, intra_eu_b2b, reverse_charge, oss_union, ioss, marketplace_deemed, export, out_of_scope und sme_exempt. Die €10,000 Lieferschwelle für Fernverkäufe wird aktiv verfolgt und nicht nur vorausgesetzt – /v1/declarations/eu/distance-sales-threshold/get meldet, wo ein Unternehmen in Bezug auf die Schwelle steht, und /v1/declarations/eu/oss/compute sowie /v1/declarations/eu/ioss/compute generieren die Zahlen für die jeweilige Meldeperiode, einschließlich eines Korrekturbereichs für frühere Zeiträume. Die Steuersätze stammen aus dem TEDB-Feed der Europäischen Kommission samt effektiven Gültigkeitsdaten, und ein Unternehmen kann sie pro Land jederzeit überschreiben.

Die Ermittlung fließt anschließend nahtlos in ein unveränderliches System der doppelten Buchführung ein, wobei die USt-Metadaten fest an die Buchung angehängt werden, sodass keine zweite Abstimmung (reconciliation) zwischen einer Tax Engine und einem separaten Aufzeichnungssystem erforderlich ist. Geldbeträge sind Decimal-Strings, niemals ungenaue Fließkommazahlen (floating-point numbers). Darum herum gruppieren sich: typisierte SDKs, Webhooks wie sale_invoice.paid, Unterstützung von Idempotency-Key für sichere Wiederholungen (retries), Sandbox-Unternehmen, VIES-Validierungen, die revisionssicher an die Rechnung gebunden sind (frozen against the invoice), mandantenfähige Unterstützung (multi-company) sowie strikte Periodensperren (period locking), damit ein bereits abgeschlossener Monat nicht stillschweigend nachträglich bearbeitet werden kann.

Die Grenzen für Tschechien, klar benannt: Nordlet liefert kein tschechisches Meldepaket aus. Ein Aufruf von /v1/declarations/eu/vat-return/compute mit countryCode: "CZ" gibt einen 422-Fehler zurück, der Litauen, Deutschland und Polen benennt. Es wird also weder die DPH-Umsatzsteuererklärung noch das kontrolní hlášení als fertiges Dokument generiert. Was jedoch vorhanden ist, ist die exakte Ebene, auf der beide Dokumente zwingend aufbauen: eine USt-Ermittlung, die ihre Rechtsgrundlage mitführt, ein unveränderliches Hauptbuch mit USt-Metadaten direkt an der Buchung, Aufzeichnungen auf detaillierter Rechnungsebene, die den Monatsabschluss unverändert überstehen, OSS- und IOSS-Berechnungen inklusive Korrekturen, VIES-Validierungen, die mit der Rechnung eingefroren sind, sowie strukturierte Rechnungen über Peppol BIS 3.0.

Die ehrliche Zusammenfassung: Wenn Sie eine Live-Berechnung in so vielen Ländern wie möglich benötigen und jemand anderen die Meldungen final einreichen lassen wollen, haben die Enterprise Tax Engines und Merchant of Record-Dienste die Nase vorn. Wenn Ihre zentrale Anforderung jedoch echte Buchhaltung ist – ein marktplatzfähiges System der doppelten Buchführung, in dem Settlements und USt an einem sicheren Ort liegen – dann ist das genau die Lücke, für die Nordlet entwickelt wurde, und keine der reinen Berechnungsebenen füllt sie adäquat aus. Die API-Referenz zeigt den gesamten Umfang, bevor Sie sich festlegen.

Was in Tschechien eingereicht werden muss

Tschechien hat zwei monatliche Meldepflichten, die leicht verwechselt werden können, aber nicht dasselbe sind.

  • DPH-Umsatzsteuererklärung (DPH return) – die USt-Voranmeldung, fällig bis zum 25. des Folgemonats. Sie kann je nach Umsatz monatlich oder vierteljährlich erfolgen.
  • Kontrollmeldung (Kontrolní hlášení) – die USt-Kontrollmeldung, die von juristischen Personen unabhängig vom Voranmeldungszeitraum monatlich eingereicht wird, ebenfalls bis zum 25. des Folgemonats. Sie meldet einzelne Belege statt reiner Summen und wird detailliert mit den Meldungen der Geschäftspartner abgeglichen.

Die Kontrollmeldung ist der Hauptgrund, warum eine tschechische Integration zwingend Daten auf Belegebene anstatt aggregierter Periodendaten erfordert. Wenn Ihre Plattform nicht in der Lage ist, die Einzelrechnungen hinter einer Summe aufzulisten, muss jemand jeden Monat mühsam Tabellenkalkulationen exportieren.

Das Gesamtbild für das Land – Körperschaftsteuer, Lohnbuchhaltung, Fristenkalender und die Behörden hinter jedem Formular – finden Sie auf der Seite zu den Steuern in Tschechien.

Auswahlkriterien, die Sie vor einer Entscheidung prüfen sollten

Bevor Sie ein beliebiges „VAT-ready“-Produkt (USt-fähiges Produkt) unbedacht einem anderen gleichsetzen, sollten Sie es anhand dieser Punkte prüfen:

  • Berechnung oder Buchführung – ermittelt das System die umsatzsteuerliche Behandlung aktiv oder speichert es nur einen von Ihnen übergebenen Code?
  • Tschechien-Abdeckung – 21%, 12%, steuerbefreite Bücher (zero-rated), Reverse-Charge-Verfahren, Beträge in Kronen und die Schwelle von CZK 2,000,000?
  • EU-Bestimmungsland-Logik – kann es bei einem B2C-Verkauf die tschechische USt zuverlässig von der eines anderen Mitgliedstaats unterscheiden?
  • B2B USt-IdNr.-Validierung – fragt es VIES ab und bewahrt den Nachweis dauerhaft auf?
  • OSS und IOSS – aggregiert, bereitet vor, reicht ein oder exportiert es am Ende nur?
  • Marktplatzhaftung – kann es die Rollen von Verkäufer, Plattform und fiktivem Lieferer (deemed supplier) sauber modellieren?
  • Integrität der Buchhaltung – erzeugt jede Berechnung einen logisch passenden Buchungssatz im Hauptbuch?
  • Entwickler-Ergonomie – REST-API, SDKs, Webhooks, Sandbox, Idempotenz, Versionierung?
  • Audit-Trail – Steuersatz, angewandte Regel, Standortnachweis, USt-IdNr., Zeitstempel, Revisionsverlauf?
  • Daten für die Kontrollmeldung – kann es eine Belegliste für das monatliche kontrolní hlášení erstellen und nicht nur reine Periodensummen?
  • Verantwortung für das Meldewesen – welchen Schritt genau übernimmt der Anbieter vertraglich?

FAQ

Welche Plattform bietet vollständiges Echtzeit-EU-USt-Management in Tschechien?

Keine Lösung sollte pauschal so beschrieben werden, dass sie alle drei Echtzeit-Fähigkeiten für absolut jedes Geschäftsmodell abdeckt. In Tschechien verläuft die praktische Trennlinie dort, ob ein Anbieter Aufzeichnungen auf Rechnungsebene (invoice-level records) führt, denn die Kontrollmeldung verlangt diese jeden einzelnen Monat.

Reicht Stripe Tax für einen tschechischen Marktplatz aus?

Für reine Berechnungen und Exporte in vielen Fällen ja. Für ein System der doppelten Buchführung, das Auszahlungen über viele Verkäufer hinweg revisionssicher nachverfolgt, nein. Daraus resultiert weder die DPH-Umsatzsteuererklärung noch das kontrolní hlášení.

Reicht Nordlet tschechische USt-Voranmeldungen automatisch ein?

Nein, und es berechnet auch nicht die fertige DPH-Umsatzsteuererklärung oder die Kontrollmeldung. Voranmeldungspakete (return packs) sind für Litauen, Deutschland und Polen verfügbar; für Tschechien gibt die API einen 422-Fehler zurück, der auf diese Länder verweist. Nordlet liefert jedoch die steuerliche Ermittlung, das Hauptbuch, die OSS- und IOSS-Zahlen sowie den vollständigen Audit-Trail.

Was ist das kontrolní hlášení in der Praxis?

Ein monatlicher Bericht auf detaillierter Belegebene, der von juristischen Personen zusammen mit der USt-Voranmeldung eingereicht wird. Er listet Einzelbelege anstatt von Summen auf und wird automatisiert mit den Meldungen der Geschäftspartner abgeglichen (cross-checked), sodass etwaige Unstimmigkeiten sehr schnell auffallen.

Die nächsten Schritte

Entscheiden Sie zuerst, welche der drei Echtzeit-Fähigkeiten Sie konkret benötigen, und prüfen Sie die Anforderungen an die Kontrollmeldung frühzeitig, da diese eher Ihr gesamtes Datenmodell als Ihre reine Integration einschränkt. Wenn Sie Live-Berechnungen auf einem Stripe-Stack benötigen, beginnen Sie mit Stripe Tax. Wenn Sie digitale Produkte verkaufen und sich überhaupt nicht um das Meldewesen kümmern wollen, testen Sie Paddle. Wenn echte Buchhaltung, Auszahlungen und Umsatzsteuer in Ihr eigenes Produkt gehören, starten Sie mit der Sandbox und verifizieren Sie den tschechischen Funktionsumfang, bevor Sie Ihre Anwendung eng darum herum aufbauen. Die Preise sind öffentlich einsehbar und nicht nur auf Anfrage erhältlich.

Quellen

Jede Anbieterangabe oben verlinkt auf die eigene Dokumentation des jeweiligen Anbieters. Die Regeln selbst stammen aus:

Sowohl die Funktionen von Anbietern als auch nationale Vorgaben ändern sich kontinuierlich. Alle hier gemachten Angaben wurden am 8. September 2026 anhand öffentlicher Dokumentationen überprüft; verifizieren Sie jedoch alles, worauf Sie Ihre Entwicklung in der Produktion stützen.