Automatisierte länderbezogene MwSt.-Berichterstattung und VIES-Prüfung

Ein Praxisleitfaden für Entwickler zur Einbindung von EU-MwSt.-Compliance in Marktplätze und Plattformen mithilfe einer Cloud-Buchhaltungs-API.

Die Meisten MwSt.-Fehler im Plattformcode lassen sich auf eine einzige Annahme zurückführen: dass ein gültiges VIES-Ergebnis bedeutet, dass der Umsatz mit null Prozent versteuert werden kann. Das stimmt nicht, und wer auf dieser Abkürzung aufbaut, erzeugt Berichte, die so lange in Ordnung wirken, bis ein Prüfer fragt, warum eine innergemeinschaftliche Befreiung ohne Transportbeleg oder einen konsistenten Nachweis des Leistungsorts angewendet wurde. Die Lücke zwischen „Umsatzsteuer-Identifikationsnummer ist in Ordnung“ und „dieser Umsatz wird korrekt behandelt“ ist der Punkt, an dem die Meisten Integrationen unbemerkt fehlschlagen.

Dieser Leitfaden zeigt, wie sich die länderbezogene MwSt.-Berichterstattung und VIES-Prüfung mit einer Cloud-Buchhaltungs-API automatisieren lassen, wobei die Buchhaltungs-API von Nordlet als Implementierungsumgebung dient. Das Ziel ist ein System, das im Moment des Verkaufs die richtigen Nachweise erfasst, unveränderliche Buchungssätze erstellt und auswertungsfertige Daten liefert, die nach Verfahren und Mitgliedstaat gruppiert sind, ohne später Summen in einer Tabellenkalkulation rekonstruieren zu müssen.

Was VIES tatsächlich aussagt und was nicht

VIES ist das Mehrwertsteuer-Informationsaustauschsystem der EU. Wenn Sie einen Ländercode und eine Umsatzsteuer-Identifikationsnummer übermitteln, wird die relevante nationale Datenbank in Echtzeit abgefragt und zurückgegeben, ob diese Umsatzsteuerinformation gültig oder ungültig ist. Das ist der gesamte Funktionsumfang. Es wird bestätigt, dass eine Nummer registriert und, sofern der Mitgliedstaat dies unterstützt, für den innergemeinschaftlichen Handel aktiviert ist.

Es begründet jedoch nicht das Recht, eine innergemeinschaftliche Lieferung von der Steuer zu befreien. Die Europäische Kommission äußert sich hierzu eindeutig. Eine gültige VIES-Antwort ist ein Nachweis unter mehreren. Sie müssen dennoch bestätigen, dass der Kunde der tatsächliche Empfänger ist, dass die Lieferung die Voraussetzungen für eine innergemeinschaftliche Transaktion erfüllt, dass Transport- oder Versendungsnachweise vorliegen und dass die Rechnung den erforderlichen Hinweis auf das Reverse-Charge-Verfahren enthält.

Die erste Designentscheidung ist daher struktureller Natur: Halten Sie den VIES-Status und die steuerliche Behandlung in separaten Feldern. Verknüpfen Sie niemals viesStatus: valid direkt mit zeroRated: true. In dem Moment, in dem Sie diese beiden Konzepte vermischen, verlieren Sie die Fähigkeit, eine steuerliche Behandlung zu verteidigen, wenn die Nachweise infrage gestellt werden.

Voraussetzungen vor dem Schreiben des Integrationscodes

Bevor ein Endpunkt aufgerufen wird, definieren Sie den Umfang dessen, worüber Sie berichten möchten. Dieser Teil ist trocken, und ihn zu überspringen wird teuer.

Die Länder, in denen das Unternehmen niedergelassen ist oder über feste Niederlassungen verfügt
Die Länder, in denen es über MwSt.-Registrierungen verfügt
Ob Waren, Dienstleistungen, digitale Dienstleistungen oder eine Mischung daraus verkauft werden
Ob es sich bei den Transaktionen um B2B, B2C oder beides handelt
Ob nationale Registrierungen, OSS, IOSS, Reverse-Charge oder Marktplatzregeln für den steuerlichen Vertreter (deemed-supplier rules) genutzt werden
Welche Ausgaben die API generieren muss: nationale Steuererklärungsdaten, OSS-/IOSS-Daten, Rechnungsverzeichnisse wie das litauische i.SAF, reine Buchungssätze oder Payloads für einen separaten Steuerberater bzw. Einrichtungsdienstleister

Dies ist wichtig, da das OSS-Verfahren nicht jede Transaktion abdeckt. Dienstleistungen, die in einem Land erbracht werden, in dem das Unternehmen eine Niederlassung hat, gehören im Allgemeinen in die nationale Steuererklärung dieses Landes und nicht in die OSS-Erklärung. Bilden Sie Niederlassungen von Anfang an separat ab, da Sie diese Umsätze sonst zum Zeitpunkt der Aggregation falsch zuordnen.

Hardcodieren Sie auch keinen MwSt.-Satz pro Land. Die EU kennt reguläre, ermäßigte, super-ermäßigte, Park-Sätze, Nullsätze sowie produktspezifische Regelungen, und diese ändern sich. Die verlässliche Quelle für ein bestimmtes Produkt in einem bestimmten Mitgliedstaat ist die Steuerbehörde des jeweiligen Landes, wobei die TEDB der Kommission eine länderübergreifende Übersicht bietet. Dokumentieren Sie die Quelle und Version hinter jeder Steuersatzentscheidung, damit eine spätere Aktualisierung der Steuersatztabelle nicht unbemerkt die Darstellung einer alten Transaktion verändert.

Modellierung der steuerlichen Entscheidung statt nur des Steuersatzes

Der Kern einer robusten Integration ist eine Steurkategorienschicht, die zwischen Produkten und Steuersätzen sitzt. Ordnen Sie Produkte Kategorien zu, Kategorien länderspezifischen Steuercodes und diese wiederum datumsbezogenen Steuersätzen (effective-dated rates):

Produkt/Dienstleistung
    → Steuerkategorie
    → länderspezifischer Steuercode
    → datumsbezogener Steuersatz und steuerliche Behandlung

Die unsichere Variante, die zu Abweichungen bei der Berichterstattung führt, lautet Produkt-SKU → 21% MwSt.. Dasselbe Produkt unterliegt in verschiedenen Ländern unterschiedlichen Steuersätzen, und ein Steuersatz kann sich mitten im Zeitraum ändern. Nordlets eigener Leitfaden zur MwSt.-Compliance empfiehlt genau diese kategoriebasierte Zuordnung anstelle einer direkten Verknüpfung von Produkten mit Prozentsätzen.

Ihre Steuerkategorietaxonomie sollte stabil und intern sein: standardbesteuerte Waren, ermäßigt besteuerte Waren, auf elektronischem Weg erbrachte Dienstleistungen, sonstige Dienstleistungen, steuerfreie Umsätze, steuerfreie Umsätze mit Vorsteuerabzug (Nullsatz), innergemeinschaftliche B2B-Reverse-Charge-Umsätze, innergemeinschaftliche Fernverkäufe, IOSS-Importe, Transaktionen mit fiktiver Lieferung (deemed-supplier transaction). Alles nachgelagerte richtet sich nach dieser Taxonomie.

VIES-Validierung als asynchroner Belegworkflow

Der offizielle VIES-Dienst stellt eine SOAP/WSDL-Schnittstelle bereit, die einen zweistelligen Ländercode und eine Umsatzsteuer-Identifikationsnummer entgegennimmt. Seine dokumentierten Fehler sind für Ihre Fehlerbehandlung von Bedeutung: ungültige Eingaben, globale und auf den Mitgliedstaat bezogene Gleichzeitigkeitslimits (concurrency limits), Dienstausfälle, Nichtverfügbarkeit von Mitgliedstaaten und Zeitüberschreitungen (timeouts). Behandeln Sie diese als unterschiedliche Ergebnisse und nicht als einen einzigen Fehler-Sammeltopf.

Ein Workflow, der unter Last und bei Prüfungen Bestand hat, sieht wie folgt aus:

Normalisieren Sie die USt-IdNr.: Setzen Sie das Präfix in Großbuchstaben, entfernen Sie erlaubte Leerzeichen oder Satzzeichen und bewahren Sie den ursprünglich vom Benutzer eingegebenen Wert separat auf.
Überprüfen Sie den Ländercode und das Format der Nummer lokal, bevor Sie einen Netzwerkaufruf tätigen.
Übermitteln Sie die normalisierte Nummer an VIES.
Speichern Sie die normalisierte ID, Zeitstempel für Anfrage und Antwort, den Status (gültig/ungültig/nicht verarbeitet), die Rohantwort, etwaige Dienstfehler, Kunden- und Rechnungs-IDs sowie die anwendungsseitige Entscheidung.
Cachen Sie erfolgreiche Ergebnisse für einen definierten, dokumentierten Zeitraum.
Wiederholen Sie temporäre technische Fehler mit exponentiellem Backoff.
Leiten Sie nicht aufgelöste oder widersprüchliche Fälle zur manuellen Überprüfung weiter.
Führen Sie eine erneute Validierung durch, wenn ein Cache-Ergebnis veraltet ist oder vor einer Transaktion, bei der der Nachweis wesentlich ist.

Nordlet überprüft eine EU-Umsatzsteuer-Identifikationsnummer beim Anlegen eines Kunden und prüft sie vor der Rechnungsstellung erneut, wenn das vorherige Ergebnis veraltet ist. Dies ist das gewünschte Verhalten, unabhängig davon, ob die Prüfung in der Plattform oder in Ihrem eigenen Code stattfindet.

Die wichtigste Regel: Machen Sie den Bezahlvorgang (Checkout) nicht synchron von VIES abhängig. Ein Dienstausfall ist keine ungültige Nummer. Wenn VIES während eines Verkaufs einen Timeout meldet, halten Sie die Transaktion zur Prüfung zurück oder weisen Sie ihr einen vorläufigen Status zu. Den Bezahlvorgang von der Erreichbarkeit eines Kommissionsdienstes abhängig zu machen, erzeugt Support-Tickets, und einen guten Kunden fälschlicherweise als ungültig einzustufen, ist schlimmer.

Trennung von Validierungsstatus und steuerlicher Behandlung

Sobald Ihnen ein VIES-Ergebnis vorliegt, muss die Entscheidungs-Engine weitere Arbeit leisten. Speichern Sie diese als separate Felder:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

Bevor ein Reverse-Charge-Verfahren oder eine Steuerbefreiung angewendet wird, sollte die Engine prüfen, ob der Kunde tatsächlich der Empfänger ist, ob Kundenland und USt-Präfix übereinstimmen, ob die Lieferung die Voraussetzungen für eine innergemeinschaftliche Transaktion erfüllt, ob spezielle Regeln zum Ort der Lieferung gelten, ob Transportnachweise vorliegen, ob der Verkäufer als fiktiver Lieferant (deemed supplier) auftritt und ob die Rechnung den vorgeschriebenen Wortlaut enthält. Ein gültiger VIES-Status, der keine dieser anderen Prüfungen besteht, ist kein grünes Licht.

Erstellung einer unveränderlichen MwSt.-Entscheidung zum Zeitpunkt der Rechnungsstellung

Wenn die Rechnung erstellt wird, speichern Sie die vollständige Entscheidung dauerhaft zusammen mit der Rechnung, und nicht nur den endgültigen Steuersatz:

Rechnung
  ├─ Positions-Steuerkategorie
  ├─ Ort der Lieferung (place of supply)
  ├─ MwSt.-Verfahren (VAT scheme)
  ├─ länderspezifischer Steuersatz
  ├─ Steuersatztabellen-Version
  ├─ VIES-Nachweisreferenz
  ├─ Standortnachweis-Referenzen
  ├─ Rechtsgrundlagen-Referenz
  └─ Marktplatzrollen-Flags

Die EU-Rechnungsvorschriften erfordern Angaben zu Lieferant und Kunde, Rechnungsnummer, Beschreibung, steuerpflichtigem Betrag, Steuersatz, MwSt.-Betrag sowie alle Hinweise zum Reverse-Charge-Verfahren oder zu Befreiungen. Gutschriften und Berichtigungen erfordern einen eindeutigen Bezug zur Originalrechnung.

Nordlets Hauptbuch ist unveränderlich, weshalb Korrekturen durch neue Einträge wie Gutschriften oder Stornierungssuche vorgenommen werden und nicht durch Änderungen an abgeschlossenen Datensätzen. Richten Sie Ihren Consumer an diesem Modell aus, selbst wenn Ihr Speicher technisch gesehen Überschreibungen zulassen würde. Das Bearbeiten einer geschlossenen Rechnung zerstört die Verbindung zwischen der ursprünglichen Meldung und der Korrektur, und genau das ist die Historie, der ein Prüfer folgt.

Buchung, Webhooks und Idempotenz

Ein Verkauf erzeugt doppelte Buchführungseinträge (double-entry accounting entries), die sowohl die Geschäftstransaktion als auch die nach Land und Verfahren aufgeteilte MwSt.-Schuld bewahren. Ein inländischer Verkauf könnte wie folgt gebucht werden:

Soll Forderungen aus Lieferungen und Leistungen / Zahlungsverrechnung
    Haben Umsatzerlöse
    Haben Umsatzsteuer - DE - Inland

Ein innergemeinschaftlicher B2B-Reverse-Charge-Verkauf bucht Umsatzerlöse ohne Ausgangssteuer und mit einem Verweis auf den Reverse-Charge-Nachweis. Der genaue Kontenrahmen liegt in Ihrem Ermessen; entscheidend ist, dass die Berichterstattungsdimensionen an jedem Buchungssatz hängen bleiben: Mitgliedstaat, Verfahren, Steuerkategorie, Steuersatz, Periode, Ursprungsrechnung und Korrekturhistorie.

Steuern Sie Statusänderungen über Webhooks statt über Polling (Abfragen). Nordlet gibt Ereignisse wie sale_invoice.paid aus, signiert Lieferungen und versucht erneute Zustellungen mit Backoff. Versehen Sie jeden Schreibvorgang mit einem deterministischen Idempotenzschlüssel:

sale:{platform_order_id}:invoice:{invoice_version}

Auch Ihr Consumer muss idempotent sein. Ein Webhook kann doppelt ankommen, verspätet eintreffen oder ausgelöst werden, nachdem die ursprüngliche Anfrage bereits erfolgreich war. Überprüfen Sie Signaturen, protokollieren Sie Ereignis-IDs, stellen Sie fehlerhafte Ereignisse unter Quarantäne, verarbeiten Sie sie über eine langlebige Warteschlange und gleichen Sie den Webhook-Status regelmäßig mit der API ab. Wenn Sie bisher noch nicht mit signierten Webhooks und Idempotenzschlüsseln gearbeitet haben, finden sich hier die unauffälligsten Fehler bei doppelten Buchungen.

Gruppierung für OSS und Erstellung auswertungsfertiger Exporte

Gruppieren Sie die Hauptbuchdaten für qualifizierende OSS-Transaktionen nach Verfahren, Verbrauchsmitgliedstaat, Art der Lieferung, Steuersatzkategorie, Steuersatz, steuerpflichtigem Betrag, MwSt.-Betrag, Versand- oder Niederlassungsmitgliedstaat, Währung und Berichtigungszeitraum.

Die Erklärung für die Unionsregelung unterteilt Lieferungen nach dem Verbrauchsmitgliedstaat und unterscheidet zwischen Dienstleistungen aus dem Mitgliedstaat der Identifizierung, Dienstleistungen aus anderen festen Niederlassungen und Waren, die aus verschiedenen Mitgliedstaaten versandt wurden. Steuerpflichtige Beträge und MwSt.-Beträge werden für Standard- und ermäßigte Steuersätze separat ausgewiesen. Steuerfreie und nullsatzbesteuerte Lieferungen bleiben vollständig aus der OSS-Erklärung heraus.

Ein paar operative Details, über die man stolpern kann:

Die Zeiträume für die Unionsregelung und Nicht-Unionsregelung sind quartalsweise; IOSS ist monatlich. Erklärungen und Zahlungen sind bis zum Ende des Folgemonats fällig.
Für jeden Zeitraum ist eine Nil-Erklärung (Nullmeldung) erforderlich, selbst wenn keine relevanten Umsätze getätigt wurden. Generieren Sie eine Perioden-Checkliste und erstellen Sie automatisch eine Null-Wert-Erklärung.
OSS-Erklärungen werden in Euro erstellt, wobei gegebenenfalls der EZB-Referenzkurs vom letzten Tag des Steuerzeitraums für die Umrechnung verwendet wird. Speichern Sie Quellwährung, Wechselkurs, Kursdatum, umgerechneten Betrag und Methode.

Exporte sollten aus dem gesperrten Hauptbuch stammen, niemals aus einer separaten Tabellenkalkulation. Tabellensummen verlieren Korrekturen, Versandländernachweise, Steuersätze und Belege. Ein Export enthält den Meldezeitraum, das Verfahren, den Verbrauchsmitgliedstaat, das Versandland, die Lieferkategorie, den Steuersatz, steuerpflichtige und MwSt.-Beträge, Währung und angewandten Wechselkurs, Korrekturbeträge für den aktuellen und vorherigen Zeitraum, Ursprungsrechnungs-IDs, Gutschriftreferenzen sowie Abstimmungssummen (reconciliation totals).

Seien Sie präzise bezüglich dessen, was die API hier liefert. Nordlet berechnet OSS- und IOSS-Erklärungen aus Rechnungen und dem Hauptbuch einschließlich Korrekturen für Vorperioden, liefert nationale Erklärungspakete für Litauen (FR0600), Deutschland (UStVA) und Polen (JPK_V7M) und generiert VMI-gerechte i.SAF-Register für Litauen. Das sind auswertungsfertige Daten. Ein einzelner API-Aufruf reicht keine MwSt.-Erklärung für jedes Land über jedes nationale Gateway ein, und es wird keine Erklärung in Ihrem Namen an eine Behörde übermittelt. Halten Sie Buchhaltung, Erklärungsgenerierung, Export, Gateway-Übermittlung und Zahlungsbestätigung als separate Status in Ihrem System. Der Leitfaden zur EU-MwSt.-Engine dokumentiert, welche Fälle die Engine löst und wann ihre Warnungen ausgelöst werden.

Sperrung des Zeitraums

Nach Prüfung und Freigabe gleichen Sie Rechnungen mit Hauptbuchbucheinträgen ab, gleichen die MwSt.-Salden des Hauptbuchs mit dem Erklärungsdatensatz ab, exportieren die Erklärung, erfassen die Melde- und Zahlungsreferenzen und sperren anschließend den Zeitraum. Nordlet blockiert Buchungen für einen gesperrten Monat, auch über die API. Korrekturen nach der Sperrung fließen in einen späteren Zeitraum ein und verweisen explizit auf das Originaldokument und den betroffenen Meldezeitraum.

Häufige Fehlerquellen und wie man sie vermeidet

Fehlerursache	Warum es passiert	Gegenmaßnahme
Ein gültiges VIES-Ergebnis als ausreichend für die Nullbesteuerung ansehen	VIES begründet keine Steuerbefreiungsrechte	Speichern Sie Kunden-, Liefer-, Transport- und Rechnungsnachweise zusammen mit dem Ergebnis
Ein ungültiges Ergebnis als Nachweis für das Fehlen einer Registrierung ansehen	Die Nummer ist möglicherweise nicht für den innergemeinschaftlichen Handel aktiviert oder die Datenbank hinkt hinterher	Unterscheiden Sie zwischen ungültig, nicht verarbeitet und technischem Fehler; leiten Sie Unstimmigkeiten zur Prüfung weiter
Den Bezahlvorgang synchron von VIES abhängig machen	Gleichzeitigkeitsschranken, Timeouts, Ausfälle	Asynchrone Validierung, kurzlebiges Caching, Backoff, vorläufige Status
Ergebnisse für immer cachen	Registrierungs- und Aktivierungsstatus ändern sich	Speichern Sie Zeitstempel und Ablaufzeiten; prüfen Sie vor der Rechnungsstellung bei Veraltung erneut
Produkte direkt auf MwSt.-Prozentsätze abbilden	Steuersätze und Befreiungen hängen von Land und Datum ab	Produkt zu Kategorie zu Ländercode zu datumsbezogenem Steuersatz
OSS aus Tabellenkalkulationen rekonstruieren	Summen lassen Korrekturen, Versandländer und Belege vermissen	Ableitung aus dem unveränderlichen Hauptbuch mit Dimensionen bei jeder Buchung
Dienstleistungen inländischer Niederlassungen in OSS einbeziehen	Bestimmte Dienstleistungen gehören in die nationale Erklärung	Niederlassungen separat abbilden, vor der Aggregation nach Verfahren routen
Weglassen von Nullmeldungen	OSS erfordert für jede Periode eine Erklärung	Erstellen Sie eine Checkliste und generieren Sie automatisch Null-Wert-Erklärungen
Bearbeiten geschlossener Rechnungen zur Korrektur	Zerstört die Verbindung zwischen Meldung und Korrektur	Verwenden Sie Gutschriften und Stornierungsbuchungen in einer späteren Periode

Worauf wir als Erstes setzen würden

Wenn wir morgen mit dieser Integration beginnen würden, würden wir die Steuerkategorien-Schicht und den MwSt.-Entscheidungsdatensatz aufbauen, bevor wir auch nur einen einzigen Berichts-Endpunkt berühren. Sorgen Sie dafür, dass die Taxonomie stabil ist, Produkte den Kategorien zugeordnet sind und der Entscheidungsdatensatz die rohen Ländersignale sowie den Grund für die Wahl des Lieferorts erfasst. Alles andere – VIES, Buchung, OSS-Gruppierung, Export – hängt davon ab, dass dieses Modell korrekt ist.

Danach würden wir VIES als asynchronen Nachweisschritt mit vier getrennten Status anbinden und das Ganze in einer Sandbox-Umgebung mit Testdaten für die schwierigen Fälle (Timeouts, nicht verarbeitete Ergebnisse, nicht übereinstimmende Präfixe) testen, bevor es in die Nähe der Produktion kommt. Die oben genannten Fehlerquellen lassen sich fast vollständig vermeiden, wenn das Datenmodell Belege und Berichtsdimensionen ab der ersten Buchung mitführt.

FAQ

Bedeutet eine gültige VIES-Antwort, dass ich einen innergemeinschaftlichen B2B-Verkauf mit null Prozent versteuern kann?

Nein. VIES bestätigt, dass eine Umsatzsteuer-Identifikationsnummer registriert und, sofern unterstützt, für den innergemeinschaftlichen Handel aktiviert ist. Das Recht zur Steuerbefreiung einer innergemeinschaftlichen Lieferung hängt von zusätzlichen Nachweisen ab: dass der Kunde der tatsächliche Empfänger ist, Transport- oder Versendungsnachweisen, dem korrekten Ort der Lieferung und dem erforderlichen Rechnungswortlaut. Speichern Sie das VIES-Ergebnis als einen Eingangswert, nicht als die finale Entscheidung.

Sollte die VIES-Validierung den Bezahlvorgang blockieren?

Das sollte sie nicht. VIES kann Zeitüberschreitungen aufweisen oder an Grenzen der Gleichzeitigkeit stoßen, und ein Ausfall ist nicht dasselbe wie eine ungültige Nummer. Validieren Sie asynchron, cachen Sie erfolgreiche Ergebnisse für einen dokumentierten Zeitraum, wiederholen Sie temporäre Fehler und halten Sie mehrdeutige Fälle mit einem vorläufigen Status zur Prüfung zurück, anstatt den Verkauf fehlschlagen zu lassen.

Kann eine Cloud-Buchhaltungs-API meine MwSt.-Erklärungen automatisch einreichen?

Sie kann auswertungsfertige Daten generieren, die nach Verfahren und Mitgliedstaat gruppiert und aus dem unveränderlichen Hauptbuch einschließlich berücksichtigter Korrekturen berechnet sind. Ob sie diese auch über jedes nationale Melde-Gateway einreicht, hängt vom Produkt und Land ab. Nordlet berechnet OSS- und IOSS-Erklärungen, liefert nationale Erklärungspakete für Litauen, Deutschland und Polen und generiert VMI-gerechte i.SAF-Register für Litauen, übermittelt jedoch nichts in Ihrem Namen an eine Steuerbehörde. Betrachten Sie Buchhaltung, Erklärungsgenerierung, Export, Gateway-Übermittlung und Zahlung als separate Status, anstatt anzunehmen, dass ein einzelner Aufruf überall alles einreicht.

Wie gehe ich mit Korrekturen nach der Sperrung eines Zeitraums um?

Buchen Sie diese in einer Folgeperiode mit expliziten Verweisen auf das Originaldokument und den betroffenen Meldezeitraum. Nordlet blockiert neue Buchungen für einen gesperrten Monat, auch über die API, sodass Korrekturen über Gutschriften oder Stornierungsbuchungen statt über Bearbeitungen erfolgen. Dies wahrt die Historie zwischen der ursprünglichen Meldung und der Berichtigung.