Nordlet

← Blog

Echtzeit-EU-Umsatzsteuer für Entwickler mit Fokus auf Ungarn

Ein fundierter Vergleich von Buchhaltungs- und Steuerplattformen, die ungarische und EU-Umsatzsteuer über APIs, SDKs und Webhooks abwickeln, mit klaren Hinweisen darauf, was die einzelnen Anbieter tatsächlich abdecken.

Nordlet Team · · 13 Min. Lesezeit

Ungarn hat die moderne Form des Echtzeit-Rechnungsreportings erfunden, und es ist nach wie vor die strengste Umsetzung innerhalb der EU. Jede von einem umsatzsteuerpflichtigen Steuerzahler ausgestellte Rechnung wird unverzüglich und ohne Betragsgrenze als XML an das NAV gemeldet. Zudem hat Ungarn mit 27% den höchsten Umsatzsteuer-Normalsatz in der Union. Wenn also ein Anbieter behauptet, er unterstütze „ungarische Umsatzsteuer in Echtzeit“, ist die einzig relevante Frage, ob das System an Online Számla angebunden ist.

Dieser Artikel vergleicht entwicklerfreundliche Plattformen, die EU- und ungarische Umsatzsteuer in Echtzeit abwickeln, unterscheidet dabei zwischen Steuerfindung (Calculation), Buchhaltung (Bookkeeping) und Meldewesen (Filing) und zeigt, für welchen Anwendungsfall sich welche Option tatsächlich eignet.

Was „EU-Umsatzsteuermanagement in Echtzeit“ umfassen muss

Dieser Begriff wird oft sehr weit gefasst und für völlig unterschiedliche Produkte verwendet. Damit er einen echten Wert hat, muss eine Plattform während der Erstellung einer Transaktion, Rechnung, Abrechnung oder einer Buchung im Hauptbuch (Ledger) die meisten der folgenden Aufgaben erfüllen:

  • Die umsatzsteuerliche Behandlung anhand der Transaktionsdaten ermitteln.
  • Die aktuellen länderspezifischen und produktbezogenen Regelungen anwenden.
  • Ungarn und die restliche EU abdecken, einschließlich B2B-Reverse-Charge-Verfahren (Steuerschuldnerschaft des Leistungsempfängers) und B2C-Besteuerung nach dem Bestimmungslandprinzip.
  • All diese Funktionen über eine API, ein SDK oder einen Webhook bereitstellen.
  • Die Daten für die Umsatzsteuer, den OSS, für Prüfungszwecke (Audit) und das buchhalterische Meldewesen vorhalten.

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

  • Echtzeit-Berechnung — Die Umsatzsteuer wird genau dann berechnet, wenn die Transaktion oder Rechnung erstellt wird.
  • Echtzeit-Buchhaltung — Transaktion, Buchungssatz und Umsatzsteuerdaten landen sofort in den Büchern.
  • Echtzeit-Meldewesen — Die Daten werden kurz nach der Transaktion an eine Steuerbehörde übermittelt.

Die meisten Produkte beherrschen Ersteres. Nur sehr wenige beherrschen alle drei. Ungarn ist genau das Land, für das dieser Begriff geprägt wurde. Rechnungsdaten gehen sofort an das NAV, und zwar für jede Rechnung und ohne Freigrenze. Die dritte Kompetenz ist hier also nicht optional und kann nicht am Monatsende im Batch-Verfahren gebündelt werden.

Die ungarischen und EU-Regelungen, die den Vergleich prägen

Ungarn wendet einen Normalsatz von 27% an, den höchsten in der EU, sowie ermäßigte Steuersätze von 18% und 5% und 0% für Exporte und innergemeinschaftliche Lieferungen. Der Steuersatz von 18% gilt für bestimmte Milch- und Backwaren sowie einige Veranstaltungen; der Satz von 5% gilt für neuen Wohnraum, Medikamente, Bücher, Fernwärme und einige Lebensmittel. Die gesetzliche Grundlage bildet das Umsatzsteuergesetz, Gesetz CXXVII aus dem Jahr 2007. Die Kleinunternehmergrenze liegt für 2026 bei HUF 20,000,000, angehoben von HUF 18m, und steigt in 2027 auf HUF 22m. Ungarn nutzt den Forint. Eine Plattform, die nur Euro verarbeitet, benötigt daher Umrechnungs- und Rundungsregeln, die in der gemeldeten XML-Datei Bestand haben.

Für qualifizierte innergemeinschaftliche B2C-Fernverkäufe und grenzüberschreitende digitale Dienstleistungen gilt ein EU-weiter Schwellenwert von €10,000, wie im One Stop Shop-Portal der Europäischen Kommission dargelegt. Wird dieser überschritten, richtet sich die Umsatzsteuer in der Regel nach dem Mitgliedstaat des Kunden. Der One Stop Shop (OSS) ermöglicht es Unternehmen, sich in nur einem Mitgliedstaat zu registrieren und die grenzüberschreitende B2C-Umsatzsteuer für die gesamte EU zu erklären, macht aber eine Logik auf Transaktionsebene nicht obsolet.

Es gibt zudem eine Marktplatz-Regelung, die strenger ist, als die meisten Teams erwarten. Gemäß Artikel 14a wird eine elektronische Schnittstelle zum fiktiven Lieferer (Deemed Supplier) bei Fernverkäufen von aus Drittlandsgebieten eingeführten Gegenständen in Sendungen mit einem Sachwert von höchstens €150, sowie gesondert bei Lieferungen an EU-Kunden unabhängig vom Warenwert, sofern der zugrundeliegende Verkäufer nicht in der EU ansässig ist. Die Erläuterungen der Kommission zu den Mehrwertsteuer-E-Commerce-Regelungen legen beide Ausprägungen dar. Wenn Sie einen Marktplatz (Marketplace) aufbauen, verändert dies die gesamte Systemarchitektur und beschränkt sich nicht auf das bloße Hinzufügen eines Datenfeldes.

Die Shortlist auf einen Blick

Plattform Bester Anwendungsfall Echtzeit-USt-Fähigkeit Umfang Buchhaltung, OSS & Meldewesen Größter Vorbehalt
Stripe Tax Produkte und Marktplätze, die bereits Stripe nutzen Berechnet die Umsatzsteuer bei der Erstellung der Transaktion, einschließlich Ungarn EU-Exporte und OSS-Daten; kein ungarisches Hauptbuch, und reicht EU-Meldungen nicht selbst ein Lohnt sich nur, wenn Stripe bereits als Zahlungsinfrastruktur dient
Paddle SaaS und digitale Download-Produkte Berechnet die Umsatzsteuer beim Checkout basierend auf dem Standort des Kunden Registriert, meldet und führt als Merchant of Record ab Übernimmt die Verkäuferrolle (Seller of Record) und damit auch die Rechnung
Quaderno Kleinere SaaS und Digital Commerce Berechnet beim Checkout, validiert USt-IdNrn. Steuerberichte und Aufzeichnungen; die automatische Einreichung ist nicht für jeden Tarif dokumentiert Ein Steuer- und Rechnungs-Layer, kein Hauptbuch
Avalara AvaTax Enterprise ERPs und Billing-Stacks Echtzeit-Steuerfindung mit gepflegten steuerlichen Inhalten VAT Reporting ist ein separates Produkt innerhalb der Returns-Produktreihe Ausgelegt und bepreist für Enterprise-Rollouts
Fonoa Tax Engine Große Plattformen und Marktplätze Echtzeit-Steuerfindung über mehr als 190 Jurisdiktionen hinweg Returns, E-Invoicing und Reporting; die Validierung von USt-IdNrn. ist ein separates Produkt Keine veröffentlichten Preise
Nordlet Eingebettete Buchhaltung (Embedded Accounting) für Marktplätze und Plattformen Löst das Besteuerungsschema und die Steuersätze pro Transaktion auf und verbucht diese zusammen mit dem Eintrag im Hauptbuch Unveränderliches doppeltes Hauptbuch, Payouts, OSS- und IOSS-Zahlen, exportierbarer Audit Trail Keine Online Számla-Integration und kein Paket für die ÁFA-Erklärung; generiert das Hauptbuch und Peppol-Rechnungen

Stripe Tax: Der schnelle Weg, wenn Stripe ohnehin genutzt wird

Für Teams, die bereits mit Stripe Payments, Billing oder Connect arbeiten, ist Stripe Tax die am leichtesten zugängliche Echtzeit-Berechnungsschicht. Die Dokumentation behandelt die weltweite Berechnung von Umsatzsteuer, die Tax API mit PaymentIntents, die Steuererhebung auf Rechnungen sowie die Nutzung von Tax mit Connect als Plattform oder Marktplatz.

Wo Stripe aufhört, wird von Stripe klar benannt. In der Filing-Dokumentation heißt es: „Sie müssen die von Ihnen eingenommenen Steuern für jeden Ort anmelden und abführen, an dem Sie registriert sind.“ Eine automatisierte Einreichung wird in den Vereinigten Staaten angeboten; andernorts arbeitet Stripe mit Partnern für das Meldewesen zusammen. Eine EU-Umsatzsteuererklärung wird also von Ihnen oder einem Partner eingereicht, nicht von Stripe Tax. Es handelt sich um eine Berechnungs- und Exportschicht, nicht um ein Buchhaltungssystem.

Für eine ungarische Implementierung stoppt Stripe Tax genau dort, wo die Verpflichtung beginnt. Das Online Számla-Reporting ist eine separate Integration, und zwar jene mit unmittelbaren Fristen.

Paddle: Die gesamte Steuerrolle an Dritte abgeben

Paddle fällt in eine andere Produktkategorie. Es fungiert als Merchant of Record (MoR) und übernimmt die Verantwortung für das „Berechnen, Einreichen und Abführen“ von Steuern dort, wo sich Ihre Kunden befinden. Es berechnet also die Umsatzsteuer beim Checkout, stellt die Rechnung aus und kümmert sich für Sie um die Anmeldung und Zahlung. Seine Entwicklerdokumentation deckt Paddle.js, die Katalog-APIs, Checkout und Webhooks wie transaction.completed ab. Dieser Webhook wird ausgelöst, sobald eine Transaktion den Status completed erreicht, und ist in der Regel der Einstiegspunkt, um nach erfolgter Zahlung den Zugriff freizuschalten.

Der Kompromiss ist hier eher struktureller als technischer Natur. Paddle wird zum offiziellen Verkäufer (Seller of Record). Sie behalten somit nicht das Händler-, Rechnungs- und Buchhaltungsmodell, das Sie bei einem eigenen Checkout hätten.

Für digitale Produkte, die an ungarische Endverbraucher verkauft werden, ist dies ein sauberer Weg. Es löst jedoch nicht die eigene Online Számla-Verpflichtung eines ungarischen Unternehmens für die von ihm ausgestellten Rechnungen.

Quaderno: Ein Steuer-Layer für kleinere Digitalunternehmen

Quaderno ist eine der übersichtlicheren Developer-First-Optionen für kleinere digitale Unternehmen, die einen Steuerdienst suchen, der unabhängig von einem einzelnen Zahlungsabwickler arbeitet. Die API dokumentiert einen /tax_rates/calculate-Endpunkt, der den anwendbaren Steuersatz anhand der Adresse des Kunden und des Transaktionstyps berechnet, einen /tax_ids/validate-Endpunkt, der EU-USt-IdNrn. abdeckt, sowie Endpunkte für Rechnungen, Belege und Gutschriften. Ein dokumentierter Connect-Bereich mit Account-Ressourcen ist der Teil, auf den ein Marktplatz aufbauen würde.

Die Grenze liegt im Leistungsumfang. Quaderno ist ein Steuer- und Rechnungs-Layer, kein Buchhaltungssystem mit einem unveränderlichen, nach den Prinzipien der doppelten Buchführung geführten Hauptbuch. Zudem geht aus den öffentlich zugänglichen Materialien nicht hervor, dass eine automatische Einreichung bei jedem Tarif in jedem Land abgedeckt ist. Die Verantwortung für das Meldewesen sollten Sie als etwas betrachten, das Sie sich schriftlich bestätigen lassen müssen.

Es deckt die Berechnung im Checkout ab. Weder die ÁFA-Erklärung noch das Online Számla-Reporting gehören jedoch zum Funktionsumfang.

Avalara und Fonoa: Die Enterprise-Steuer-Engines

Avalaras AvaTax führt über REST-APIs und SDKs eine Echtzeit-Steuerfindung während des Checkouts, der Rechnungsstellung oder der Bestellabwicklung durch. Beachten Sie die Produktaufteilung: VAT Reporting fällt als separater Bereich unter Returns. Ein EU-Umsatzsteuer-Compliance-Workflow besteht also nicht einfach nur aus „AvaTax“ – Sie müssen genau die Module eingrenzen, die Sie tatsächlich benötigen. Avalara dokumentiert einen Registrierungsprozess mit einer kostenlosen 90-Tage-Testversion, während das kommerzielle Produktionsmodell stark auf Enterprise-Kunden zugeschnitten ist.

Fonoas Tax Engine gibt an, dass sie über eine versionierte API für mehr als 190 Rechtssysteme „die korrekte Behandlung indirekter Steuern für jede Transaktion in Echtzeit berechnet“. Ein Architektur-Detail ist hier von Bedeutung: Die Validierung von Steuernummern ist bei Fonoa ein separates Produkt (Validate) und nicht Teil der Tax Engine. Wenn VIES-Nachweise für Sie relevant sind, müssen Sie dies ausdrücklich im Anforderungsprofil (Scope) aufnehmen, anstatt davon auszugehen, dass die Engine dies automatisch abdeckt.

Ungarn ist eines der Länder, in denen der Erwerb einer Enterprise-Engine mit dokumentiertem Online Számla-Konnektor eine vertretbare Investition darstellt, da die Meldepflichten streng (unforgiving) und fortlaufend sind.

Wo Nordlet ansetzt: Die USt-Bestimmung und die Hauptbuch-Buchung sind derselbe Datensatz

Nordlet ist eine Accounting API für Marktplätze und Plattformen, die Hauptbücher, Payouts, EU-Steuer und einen exportierbaren Prüfpfad (Audit Trail) innerhalb ihres eigenen Produkts benötigen, anstatt auf eine Invoicing-App angewiesen zu sein, die an einen Checkout angehängt wird.

Der architektonische Unterschied besteht darin, dass die Umsatzsteuerfindung und die Buchung demselben System angehören. POST /v1/reference/vat/resolve beantwortet die Frage nach der steuerlichen Behandlung anhand der Fakten der Transaktion:

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

{
  "scheme": "oss_union",
  "vatCountryCode": "HU",
  "reverseCharge": false,
  "deemedSupplier": false,
  "zeroRated": false,
  "rates": [
    { "category": "standard", "ratePercent": "27.00" },
    { "category": "reduced", "ratePercent": "18.00" },
    { "category": "reduced", "ratePercent": "5.00" }
  ],
  "legalBasis": "Directive 2006/112/EC art. 58 — taxable where the consumer resides; report via the Union OSS"
}

Ändert man den Kunden in ein Unternehmen mit einer gültigen ungarischen USt-IdNr., liefert derselbe Aufruf reverse_charge mit Directive 2006/112/EC art. 44, 196 — VAT due by the customer (reverse charge). Setzt man actingAsMarketplace zusammen mit einem Verkäufer, der außerhalb der EU ansässig ist, wird deemedSupplier: true gemäß art. 14a(2) zurückgegeben. Die rechtliche Grundlage wird direkt mit der Antwort übergeben – genau der Teil, nach dem ein Wirtschaftsprüfer Jahre später fragen wird.

Neun Besteuerungsschemata sind modelliert: domestic, intra_eu_b2b, reverse_charge, oss_union, ioss, marketplace_deemed, export, out_of_scope und sme_exempt. Der Schwellenwert von €10,000 für Fernverkäufe wird getrackt und nicht bloß geschätzt — /v1/declarations/eu/distance-sales-threshold/get gibt den aktuellen Stand des Unternehmens aus, während /v1/declarations/eu/oss/compute und /v1/declarations/eu/ioss/compute die Periodenzahlen erzeugen, einschließlich eines Korrekturbereichs für vorangegangene Zeiträume. Die Steuersätze stammen aus dem TEDB-Feed der Europäischen Kommission, inklusive ihrer Gültigkeitsdaten, und ein Unternehmen kann diese länderspezifisch überschreiben.

Die Steuerfindung fließt anschließend in ein unveränderliches, nach doppelter Buchführung aufgebautes Hauptbuch ein, wobei die USt-Metadaten direkt an die Buchung angehängt werden. Es ist somit keine zweite Abstimmung (Reconciliation) zwischen einer Tax Engine und einem separaten Aufzeichnungssystem (System of Record) nötig. Geldbeträge sind Decimal Strings, niemals Floating-Point-Zahlen (Gleitkommazahlen). Darüber hinaus: typisierte SDKs, Webhooks wie sale_invoice.paid, Idempotency-Key-Unterstützung für sichere Neuversuche (Retries), Sandbox-Mandanten, eine VIES-Validierung, die fix mit der Rechnung verknüpft (eingefroren) wird, Multi-Company-Support sowie Periodenabschlüsse (Period Locking), sodass ein abgeschlossener Monat nicht heimlich nachträglich geändert werden kann.

Die Einschränkungen bezüglich Ungarn sind weitreichend und sollten an oberster Stelle genannt werden. Nordlet verfügt über keine Online Számla-Integration: Rechnungsdaten werden nicht an das NAV übermittelt, und es gibt kein Paket für die ungarische Umsatzsteuererklärung — /v1/declarations/eu/vat-return/compute mit countryCode: "HU" liefert den Fehler 422 und verweist auf Litauen, Deutschland und Polen. Nationale E-Invoicing-Payload-Builder existieren für Italien, Polen und Rumänien, jedoch nicht für Ungarn. Was Nordlet für ein ungarisches Unternehmen abdeckt, ist die buchhalterische Seite: die USt-Findung samt Rechtsgrundlage, ein unveränderliches, doppeltes Hauptbuch mit USt-Metadaten an jeder Buchung, OSS- und IOSS-Berechnungen samt Korrekturen, die festgeschriebene VIES-Validierung auf Rechnungen sowie EN 16931-Rechnungen via Peppol BIS 3.0. Wenn Ihr ungarisches Unternehmen eigene Rechnungen ausstellt, bleibt die Anbindung an Online Számla eine separate Anforderung.

Zusammenfassend lässt sich ehrlich sagen: Wenn Sie eine Live-Berechnung in so vielen Ländern wie möglich benötigen und das Meldewesen an Dritte abgeben wollen, sind Enterprise-Steuer-Engines und Merchant-of-Record-Dienste im Vorteil. Wenn Ihre zentrale Anforderung jedoch in einer echten Buchhaltung besteht – einem marktplatzfähigen, doppelten Hauptbuch, in dem Abrechnungen (Settlements) und Umsatzsteuer an einem Ort vereint sind –, dann ist dies genau die Lücke, für die Nordlet entwickelt wurde, und die keiner der Calculation-Layer ausfüllt. Die API-Referenz zeigt die gesamte Architektur, bevor Sie sich vertraglich binden.

Was Ungarn an Meldungen von Ihnen verlangt

Ungarn meldet kontinuierlich und reicht regelmäßig Berichte ein.

  • Online Számla — Echtzeit-Rechnungsreporting an das NAV. Es ist für alle von umsatzsteuerpflichtigen Steuerzahlern ausgestellten Rechnungen im XML-Format ohne Betragsgrenze verpflichtend. Die Meldung erfolgt bei der Ausstellung der Rechnung, nicht am Ende der Berichtsperiode.
  • ÁFA-Erklärung — die Umsatzsteuer-Voranmeldung bzw. -Erklärung, die monatlich, vierteljährlich oder jährlich bis zum 20. eingereicht wird. Das NAV legt das Intervall fest.
  • eVAT-Entwürfe — das NAV bereitet auf Basis der gemeldeten Daten Erklärungserntwürfe vor. Das funktioniert jedoch nur, wenn die gemeldeten Daten korrekt sind.

Die Abhängigkeitskette ist der entscheidende Punkt beim Systementwurf: Der Rechnungsbericht steht an erster Stelle, und die Steuererklärung folgt daraus. Wenn das Reporting fehlerhaft ist, ist auch die Steuererklärung fehlerhaft.

Das vollständige Bild für das Land — Körperschaftsteuer, Lohn- und Gehaltsabrechnung, Fristenkalender und die jeweiligen Behörden hinter den Formularen — finden Sie auf der Ungarn-Steuerseite.

Auswahlkriterien, die Sie vor einer Entscheidung prüfen sollten

Bevor Sie ein beliebiges „VAT-ready“-Produkt (umsatzsteuerfähiges Produkt) einem anderen gleichstellen, prüfen Sie es anhand dieser Punkte:

  • Berechnung oder Buchhaltung — Ermittelt das System die umsatzsteuerliche Behandlung selbst oder speichert es lediglich einen Code, den Sie übergeben?
  • Ungarn-Abdeckung — 27%, 18%, 5%, 0%, Reverse-Charge, Forint-Beträge und die Kleinunternehmergrenze von HUF 20,000,000?
  • EU-Bestimmungslandlogik — Kann es bei einem B2C-Verkauf die ungarische Umsatzsteuer von der eines anderen Mitgliedstaats unterscheiden?
  • B2B-USt-IdNr.-Validierung — Fragt es das VIES (MIAS) ab und bewahrt den Nachweis auf?
  • OSS und IOSS — Aggregiert, bereitet auf, übermittelt es oder exportiert es nur?
  • Marktplatz-Haftung — Kann es die Rollen von Verkäufer, Plattform und fiktivem Lieferer (Deemed Supplier) abbilden?
  • Integrität der Buchhaltung — Erzeugt jede Berechnung einen passenden Buchungssatz im Hauptbuch?
  • Entwickler-Ergonomie — REST-API, SDKs, Webhooks, Sandbox, Idempotenz, Versionierung?
  • Audit Trail (Prüfpfad) — Steuersatz, Regelwerk, Standortnachweise, USt-IdNr., Zeitstempel, Änderungshistorie?
  • Online Számla — Meldet es die Rechnungsdaten bei Ausstellung der Rechnungen und ohne Betragsgrenze im erforderlichen XML-Format an das NAV?
  • Verantwortung für das Meldewesen — Welchen Schritt genau übernimmt der Anbieter?

FAQ

Welche Plattform bietet ein vollständiges EU-Umsatzsteuermanagement in Echtzeit in Ungarn?

Keine Plattform kann von sich behaupten, alle drei Echtzeit-Kompetenzen für jedes Geschäftsmodell abzudecken. Ungarn macht die dritte Kompetenz zum entscheidenden Faktor: Ein Anbieter ohne Anbindung an Online Számla ist keine vollständige Lösung, unabhängig davon, wie gut seine Steuerfindung ist.

Meldet Stripe Tax an Online Számla?

Nein. Stripe Tax berechnet die Umsatzsteuer und exportiert Daten. Die Übermittlung der Rechnungsdaten an das NAV ist eine separate Integration, die in Ungarn für jede Rechnung verpflichtend ist.

Meldet Nordlet ungarische Rechnungen an das NAV?

Nein. Es gibt keine Online Számla-Integration und kein ungarisches Paket für die Steuererklärung. Nordlet übernimmt die Steuerfindung, das Hauptbuch, die OSS- und IOSS-Zahlen sowie den Prüfpfad (Audit Trail); die Anbindung an das Meldewesen des NAV ist eine davon getrennte Anforderung.

Gibt es eine Betragsgrenze für das ungarische Rechnungsreporting?

Nein. Jede von einem umsatzsteuerpflichtigen Steuerzahler ausgestellte Rechnung wird unabhängig vom Warenwert im XML-Format gemeldet.

Die ersten Schritte

In Ungarn sollten Sie mit Online Számla beginnen und sich von dort zurückarbeiten, denn diese Verpflichtung duldet keinen Aufschub und bietet keinen Ermessensspielraum. Wenn Sie digitale Produkte verkaufen und die gesamte steuerliche Abwicklung auslagern möchten, testen Sie Paddle. Wenn Sie innerhalb Ihres eigenen Produkts eine echte Buchhaltung (Books), Payouts und einen Audit Trail benötigen, parallel zu einer separaten Anbindung an das NAV-Meldewesen, dann nutzen Sie den Einstieg über die Sandbox und vergewissern sich, welche Bereiche abgedeckt sind, bevor Sie darum herum bauen. Die Preise sind öffentlich einsehbar und nicht nur auf Anfrage erhältlich.

Quellen

Jede obige Aussage zu Anbietern ist mit der eigenen Dokumentation des jeweiligen Anbieters verlinkt. Die Regelungen selbst stammen aus:

Sowohl die Funktionen von Anbietern als auch nationale Vorschriften ändern sich. Alle hier genannten Informationen wurden am 8 September 2026 anhand der öffentlich verfügbaren Dokumentationen überprüft; verifizieren Sie jedoch alles, worauf Sie Ihr System aufbauen wollen, nochmals eigenständig.