Automatisierung der länderspezifischen USt-Meldungen und VIES-Validierung

Ein praktischer Leitfaden für Entwickler zur Integration von EU-USt-Compliance in Marktplätze und Plattformen mithilfe einer Cloud-Accounting-API.

Die meisten Umsatzsteuer-Fehler in Plattformcode lassen sich auf eine Annahme zurückführen: dass ein gültiges VIES-Ergebnis bedeutet, dass man den Verkauf steuerfrei (zero-rated) behandeln kann. Das ist nicht der Fall. Wer auf dieser Abkürzung aufbaut, erzeugt Umsatzsteuervoranmeldungen, die gut aussehen – bis ein Prüfer fragt, warum eine innergemeinschaftliche Steuerbefreiung ohne Transportnachweis (Gelangensbestätigung) oder einen konsistenten Nachweis des Ortes der Lieferung (place of supply) angewendet wurde. Die Lücke zwischen „USt-IdNr. ist gültig“ und „diese Lieferung wird steuerlich korrekt behandelt“ ist genau der Punkt, an dem die meisten Integrationen unbemerkt scheitern.

Dieser Leitfaden zeigt auf, wie man länderspezifische USt-Meldungen und die VIES-Validierung mit einer Cloud-Accounting-API automatisiert, wobei die Cloud-Accounting-API von Nordlet als Implementierungskontext dient. Das Ziel ist ein System, das zum Zeitpunkt des Verkaufs die richtigen Nachweise erfasst, unveränderliche Buchungssätze im Hauptbuch (ledger) erstellt und meldefertige Daten erzeugt, gruppiert nach Verfahren (scheme) und Mitgliedstaat – ohne die Summen später in einer Tabellenkalkulation rekonstruieren zu müssen.

Was VIES Ihnen wirklich sagt – und was nicht

VIES ist das MwSt-Informationsaustauschsystem der EU. Wenn Sie einen Ländercode und eine USt-IdNr. übermitteln, fragt es die entsprechende nationale Datenbank in Echtzeit ab und meldet zurück, ob diese Umsatzsteuerinformation gültig oder ungültig ist. Das ist der gesamte Umfang. Es bestätigt lediglich, dass eine Nummer registriert und, sofern der Mitgliedstaat dies unterstützt, für den innergemeinschaftlichen Handel aktiviert ist.

Es begründet nicht das Recht, eine innergemeinschaftliche Lieferung von der Steuer zu befreien. Die Europäische Kommission drückt sich hier sehr klar aus. Eine gültige VIES-Antwort ist nur ein Nachweis von mehreren. Sie müssen dennoch bestätigen, dass der Kunde der tatsächliche Empfänger ist, dass die Lieferung als innergemeinschaftlich (intra-EU) qualifiziert ist, dass ein Nachweis über den Transport oder Versand vorliegt und dass die Rechnung den erforderlichen Hinweis auf die Steuerschuldnerschaft des Leistungsempfängers (Reverse-Charge-Verfahren) enthält.

Die erste Designentscheidung ist daher struktureller Natur: Speichern Sie den VIES-Status und die umsatzsteuerliche Behandlung in getrennten Feldern. Verknüpfen Sie viesStatus: valid niemals direkt mit zeroRated: true. In dem Moment, in dem Sie diese beiden Konzepte vermischen, verlieren Sie die Möglichkeit, eine steuerliche Behandlung zu rechtfertigen, falls die Nachweise infrage gestellt werden.

Voraussetzungen vor dem Schreiben von Integrationscode

Bevor ein einziger Endpunkt (Endpoint) aufgerufen wird, müssen Sie den Umfang dessen definieren, was Sie melden. Dieser Teil ist langweilig, aber ihn zu überspringen, wird teuer.

In welchen Ländern das Unternehmen ansässig ist oder feste Niederlassungen (fixed establishments) hat
In welchen Ländern es umsatzsteuerlich registriert ist
Ob es Waren, Dienstleistungen, digitale Dienstleistungen oder eine Mischung daraus verkauft
Ob die Transaktionen B2B, B2C oder beides sind
Ob es lokale Registrierungen, OSS, IOSS, das Reverse-Charge-Verfahren oder Marktplatz-Fiktionen (deemed-supplier rules) anwendet
Welche Outputs die API generieren muss: Daten für lokale USt-Voranmeldungen, OSS/IOSS-Daten, Rechnungsregister wie das litauische i.SAF, reine Hauptbuchbuchungen oder Payloads für einen separaten Meldedienstleister

Das ist wichtig, weil OSS nicht jede Transaktion auffängt. Dienstleistungen, die in einem Land erbracht werden, in dem das Unternehmen eine Niederlassung hat, gehören grundsätzlich in die lokale Umsatzsteuervoranmeldung dieses Landes, nicht in die OSS-Meldung. Modellieren Sie Niederlassungen von Anfang an separat, andernfalls leiten Sie diese Lieferungen bei der Aggregation falsch weiter.

Programmieren Sie auch nicht einfach einen festen Steuersatz pro Land fest ein (hard-coding). In der EU gibt es den Normalsatz, ermäßigte Sätze, stark ermäßigte Sätze, Parksteuersätze, Nullsätze und produktspezifische Behandlungen – und diese ändern sich. Die verlässliche Quelle für ein bestimmtes Produkt in einem bestimmten Mitgliedstaat ist die dortige Steuerbehörde, wobei die TEDB-Datenbank der Kommission einen länderübergreifenden Überblick bietet. Protokollieren Sie die Quelle und die Version hinter jeder Steuersatzentscheidung, damit ein späteres Update der Steuersatztabelle nicht stillschweigend die Darstellung einer alten Transaktion verändert.

Modellierung der Steuerentscheidung, nicht nur des Steuersatzes

Das Herzstück einer robusten Integration ist eine Steuerkategorieschicht (tax-category layer), die zwischen Produkten und Steuersätzen liegt. Ordnen Sie Produkte Kategorien zu, Kategorien länderspezifischen Steuerschlüsseln und diese wiederum zeitlich befristeten Steuersätzen (effective-dated rates):

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

Die unsichere Variante, die zu Abweichungen im Reporting (reporting drift) führt, lautet product SKU → 21% VAT. Dasselbe Produkt hat in verschiedenen Ländern unterschiedliche Steuersätze, und ein Steuersatz kann sich mitten in einem Meldezeitraum ändern. Nordlets eigener Leitfaden zur USt-Compliance empfiehlt genau dieses kategorienbasierte Mapping, anstatt Produkte direkt an Prozentwerte zu binden.

Ihre Taxonomie für Steuerkategorien sollte stabil und intern definiert sein: standardbesteuerte Waren, ermäßigt besteuerte Waren, elektronisch erbrachte Dienstleistungen, sonstige Dienstleistungen, steuerfreie Lieferungen (exempt supply), Nullsatz-Lieferungen (zero-rated supply), innergemeinschaftliches B2B-Reverse-Charge, innergemeinschaftlicher Fernverkauf (intra-EU distance sale), IOSS-Import, Transaktionen mit fiktivem Lieferer (deemed supplier). Alle nachgelagerten Prozesse bauen auf dieser Taxonomie auf.

VIES-Validierung als asynchroner Nachweis-Workflow

Der offizielle VIES-Dienst bietet eine SOAP/WSDL-Schnittstelle, die einen zweistelligen Ländercode und eine USt-IdNr. akzeptiert. Die dokumentierten Fehlertypen sind für Ihr Error-Handling entscheidend: ungültige Eingabe, Überlastung (concurrency limits) auf globaler oder Mitgliedstaatsebene, Nichtverfügbarkeit des Dienstes, Nichtverfügbarkeit des Mitgliedstaates und Timeouts. Behandeln Sie diese als unterschiedliche Ergebnisse und werfen Sie sie nicht alle in denselben „Fehlgeschlagen“-Topf.

Ein Workflow, der unter Last und bei einer Betriebsprüfung standhält, sieht wie folgt aus:

Normalisieren Sie die USt-IdNr.: Präfix in Großbuchstaben umwandeln, zulässige Leerzeichen oder Satzzeichen entfernen und den ursprünglich vom Benutzer eingegebenen Wert separat aufbewahren.
Validieren Sie den Ländercode und das Format der Nummer lokal, bevor Sie einen Netzwerkaufruf starten.
Ü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 (raw response), etwaige Service-Fehler, die Kunden- und Rechnungs-IDs sowie die Anwendungsentscheidung.
Speichern Sie erfolgreiche Ergebnisse für einen definierten, dokumentierten Zeitraum im Cache.
Wiederholen Sie temporäre technische Fehler mittels Backoff-Strategie (Verzögerung).
Leiten Sie ungelöste oder widersprüchliche Fälle zur manuellen Überprüfung weiter.
Validieren Sie erneut, wenn ein zwischengespeichertes Ergebnis veraltet ist oder bevor eine Transaktion stattfindet, bei der der Nachweis wesentlich (material) ist.

Nordlet überprüft eine EU-USt-IdNr., wenn ein Kunde hinzugefügt wird, und prüft sie vor der Rechnungsstellung erneut, falls das frühere Ergebnis veraltet ist. Dies ist genau das Verhalten, das Sie replizieren sollten – unabhängig davon, ob die Prüfung in der Plattform oder in Ihrem eigenen Code stattfindet.

Die wichtigste Regel: Gestalten Sie den Checkout nicht synchron zu VIES. Ein Dienstausfall bedeutet nicht, dass eine Nummer ungültig ist. Wenn VIES während eines Verkaufs einen Timeout meldet, halten Sie die Transaktion zur Überprüfung zurück oder weisen Sie ihr einen vorläufigen Status zu. Den Checkout von der Erreichbarkeit eines Kommissionsdienstes abhängig zu machen, garantiert unzählige Support-Tickets – und einen guten Kunden fälschlicherweise als ungültig einzustufen, ist noch schlimmer.

Trennung von Validierungsstatus und steuerlicher Behandlung

Sobald Ihnen ein VIES-Ergebnis vorliegt, hat die Decision Engine noch mehr zu tun. Speichern Sie diese Parameter als separate Felder:

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

Bevor das Reverse-Charge-Verfahren oder eine Steuerbefreiung angewendet wird, sollte die Engine prüfen, ob der Kunde tatsächlich der Leistungsempfänger ist, ob das Land des Kunden und das Präfix der USt-IdNr. übereinstimmen, ob die Lieferung als innergemeinschaftlich gilt, ob besondere Regeln für den Ort der Lieferung greifen, ob ein Transportnachweis vorliegt, ob der Verkäufer als fiktiver Lieferer (deemed supplier) auftritt und ob die Rechnung den erforderlichen Textzusatz enthält. Ein gültiger VIES-Status, der keinen dieser anderen Tests besteht, ist kein grünes Licht.

Erstellung einer unveränderlichen Umsatzsteuerentscheidung bei Rechnungsstellung

Wenn die Rechnung erstellt wird, speichern (persist) Sie die gesamte Entscheidung zusammen mit der Rechnung, nicht nur den finalen Steuersatz:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

Die EU-Richtlinien zur Rechnungsstellung erfordern Angaben zu Lieferant und Kunde, Rechnungsnummer, Leistungsbeschreibung, Bemessungsgrundlage (taxable amount), Steuersatz, Steuerbetrag sowie Informationen zum Reverse-Charge-Verfahren oder zu Steuerbefreiungen. Gutschriften und Korrekturen benötigen einen unmissverständlichen Bezug zur ursprünglichen Rechnung.

Das Hauptbuch (Ledger) von Nordlet ist unveränderlich (immutable). Korrekturen erfolgen daher durch neue Buchungen wie Gutschriften oder Stornobuchungen, nicht durch das Bearbeiten abgeschlossener Datensätze. Richten Sie Ihren API-Consumer nach diesem Modell aus, auch wenn Ihr Speichersystem technisch in der Lage wäre, Daten zu überschreiben. Die Bearbeitung einer gebuchten Rechnung zerstört die Verknüpfung zwischen der ursprünglichen Meldung und der Korrektur – und genau das ist die Historie (Lineage), der ein Prüfer folgt.

Buchungen, Webhooks und Idempotenz

Ein Verkauf erzeugt Buchungssätze in der doppelten Buchführung (double-entry accounting), die sowohl das Handelsgeschäft als auch die Umsatzsteuerschuld – aufgeteilt nach Land und Verfahren – dokumentieren. Ein Inlandsverkauf könnte wie folgt gebucht werden:

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable — DE — domestic

Ein innergemeinschaftlicher B2B-Verkauf (Reverse Charge) verbucht Umsatzerlöse ohne abzuführende Umsatzsteuer und enthält einen Verweis auf den Reverse-Charge-Nachweis. Der genaue Kontenplan (chart of accounts) bleibt Ihnen überlassen. Wichtig ist nur, dass die Reporting-Dimensionen an jeder Buchung hängen: Mitgliedstaat, Verfahren, Steuerkategorie, Steuersatz, Meldezeitraum, Ursprungsrechnung und Korrekturhistorie.

Steuern Sie Statusänderungen über Webhooks anstatt über Polling. Nordlet sendet Events wie sale_invoice.paid, signiert die Zustellungen (Deliveries) und versucht es bei Fehlern mit einem Backoff erneut. Versehen Sie jeden Schreibvorgang mit einem deterministischen Idempotenzschlüssel (idempotency key):

sale:{platform_order_id}:invoice:{invoice_version}

Ihr Consumer muss ebenfalls idempotent sein. Ein Webhook kann zweimal ankommen, sich verspäten oder erst ausgelöst werden, wenn der ursprüngliche Request bereits erfolgreich war. Verifizieren Sie Signaturen, protokollieren Sie Event-IDs, stellen Sie fehlerhafte Events unter Quarantäne, verarbeiten Sie diese über eine persistente Warteschlange (durable queue) und gleichen Sie den Webhook-Status regelmäßig (Reconciliation) mit der API ab. Wenn Sie bisher noch nicht mit signierten Webhooks und Idempotenzschlüsseln gearbeitet haben: Hier verbergen sich die tückischsten Fehler durch Doppelbuchungen.

Gruppierung für OSS und Erstellung meldefertiger Exporte

Gruppieren Sie Hauptbuchdaten für zulässige OSS-Transaktionen nach Verfahren, Mitgliedstaat des Verbrauchs, Art der Lieferung, Steuersatzkategorie, Steuersatz, Bemessungsgrundlage, Steuerbetrag, Mitgliedstaat des Abgangs oder der Niederlassung, Währung und Korrekturzeitraum.

Die Meldung für die EU-Regelung (Union scheme) trennt die Lieferungen nach dem Mitgliedstaat des Verbrauchs. Sie unterscheidet Dienstleistungen aus dem Mitgliedstaat der Identifizierung, Dienstleistungen aus anderen festen Niederlassungen und Waren, die aus verschiedenen Mitgliedstaaten versandt werden. Die Bemessungsgrundlagen und Umsatzsteuerbeträge werden für Normal- und ermäßigte Steuersätze getrennt ausgewiesen. Steuerfreie oder mit dem Nullsatz besteuerte Lieferungen fließen überhaupt nicht in die OSS-Meldung ein.

Einige betriebliche Details, über die viele stolpern:

Meldezeiträume für die EU- und Nicht-EU-Regelung bei OSS sind quartalsweise; bei IOSS monatlich. Die Meldungen und Zahlungen sind bis zum Ende des Folgemonats fällig.
Für jeden Zeitraum ist eine Nullmeldung (nil return) erforderlich, auch wenn keine relevanten Umsätze erzielt wurden. Generieren Sie eine Checkliste für den Zeitraum und erstellen Sie automatisch eine Nullmeldung.
OSS-Meldungen erfolgen in Euro. Wenn eine Umrechnung erforderlich ist, wird der EZB-Referenzkurs des letzten Tages des Meldezeitraums verwendet. Speichern Sie die Ausgangswährung, den Wechselkurs (FX rate), das Kursdatum, den umgerechneten Betrag und die angewandte Methode.

Exporte sollten immer aus dem geschlossenen Hauptbuch (locked ledger) stammen und niemals aus einer separaten Tabellenkalkulation. In Excel-Summen gehen Korrekturen, Versandländer, Steuersätze und Nachweise verloren. Ein Export enthält den Meldezeitraum, das Verfahren, den Mitgliedstaat des Verbrauchs, das Versandland, die Lieferkategorie, den Steuersatz, Bemessungsgrundlage und Steuerbetrag, die Währung und den angewendeten Wechselkurs, Korrekturbeträge für die laufende und frühere Perioden, Ursprungsrechnungs-IDs, Referenzen auf Gutschriften sowie Abstimmungssummen (Reconciliation Totals).

Seien Sie präzise in Bezug darauf, was die API hier liefert. Nordlet berechnet OSS- und IOSS-Meldungen aus Rechnungen und dem Hauptbuch (inklusive Korrekturen aus Vorperioden), liefert lokale Melde-Pakete für Litauen (FR0600), Deutschland (UStVA) und Polen (JPK_V7M) und generiert VMI-konforme i.SAF-Register für Litauen. Das sind meldefertige Daten. Ein einziger API-Aufruf reicht jedoch nicht aus, um die USt-Voranmeldung jedes Landes über das jeweilige nationale Gateway einzureichen, und es wird auch keine Meldung in Ihrem Namen an eine Behörde übermittelt. Führen Sie Buchhaltung, Melde-Generierung, Export, Gateway-Übermittlung und Zahlungsbestätigung als separate Status in Ihrem System. Der Leitfaden zur EU-USt-Engine dokumentiert, welche Fälle die Engine löst und wann ihre Warnungen ausgelöst werden.

Abschluss des Meldezeitraums (Locking)

Stimmen Sie nach der Überprüfung und Freigabe die Rechnungen mit den Hauptbuchungen ab, vergleichen Sie die USt-Salden des Hauptbuchs mit dem Meldedatensatz, exportieren Sie die Meldung, erfassen Sie die Referenzen für Einreichung und Zahlung und schließen Sie dann den Zeitraum ab (Period Lock). Nordlet blockiert Buchungen in einem abgeschlossenen Monat, auch über die API. Korrekturen nach dem Abschluss fließen in einen späteren Zeitraum – mit expliziten Verweisen auf das Originaldokument und den betroffenen Meldezeitraum.

Häufige Fehlerquellen und wie man sie vermeidet

Fehlerquelle	Ursache	Vermeidung (Mitigation)
Ein gültiges VIES-Ergebnis als ausreichend für eine Steuerbefreiung betrachten	VIES begründet keine Steuerbefreiung	Nachweise zu Kunde, Lieferung, Transport und Rechnung zusammen mit dem Ergebnis speichern
Ein ungültiges Ergebnis als Beweis für fehlende Registrierung betrachten	Die Nummer ist möglicherweise nicht für den EU-Handel aktiviert, oder die Datenbank ist verzögert	Zwischen ungültig, nicht verarbeitet und technischen Fehlern unterscheiden; Unstimmigkeiten zur Überprüfung weiterleiten
Den Checkout synchron zu VIES ausführen	Lastgrenzen (Concurrency limits), Timeouts, Ausfälle	Asynchrone Validierung, kurzzeitiges Caching, Backoff, vorläufige Status
Ergebnisse dauerhaft im Cache speichern	Registrierungs- und Aktivierungsstatus ändern sich	Zeitstempel und Ablaufdatum speichern; vor der Rechnungsstellung neu prüfen, falls veraltet
Produkte direkt auf USt-Prozentsätze mappen	Steuersätze und Befreiungen hängen von Land und Datum ab	Produkt zu Kategorie, zu Ländercode, zu zeitlich befristetem Steuersatz
Rekonstruktion von OSS aus Tabellenkalkulationen	Summen lassen Korrekturen, Versandländer und Nachweise außer Acht	Ableitung aus dem unveränderlichen Hauptbuch mit Reporting-Dimensionen auf jedem Eintrag
Einbezug von Dienstleistungen über Inlandsniederlassungen in OSS	Bestimmte Dienstleistungen gehören in die lokale Meldung	Niederlassungen separat modellieren, vor der Aggregation nach Verfahren routen
Auslassen von Nullmeldungen	OSS verlangt in jeder Periode eine Meldung	Checkliste generieren und automatisch Nullmeldungen erstellen
Bearbeiten abgeschlossener Rechnungen zur Korrektur	Zerstört die Verknüpfung zwischen Meldung und Korrektur	Gutschriften und Stornobuchungen in einem späteren Zeitraum verwenden

Was wir zuerst tun würden

Wenn wir morgen mit dieser Integration beginnen würden, würden wir zunächst die Steuerkategorieschicht (tax-category layer) und den Umsatzsteuer-Entscheidungsdatensatz (VAT decision record) aufbauen, bevor wir auch nur einen einzigen Reporting-Endpunkt anfassen. Stabilisieren Sie die Taxonomie, mappen Sie Produkte auf Kategorien und stellen Sie sicher, dass der Entscheidungsdatensatz die rohen Ländersignale sowie die Begründung für die Wahl des Leistungsorts erfasst. Alles andere – VIES, Buchhaltung, OSS-Gruppierung, Export – hängt davon ab, dass dieses Modell korrekt ist.

Danach würden wir VIES als asynchronen Nachweis-Schritt mit den vier getrennten Status implementieren und es gegen ein Sandbox-Unternehmen testen. Dabei würden wir Fixtures für die hässlichen Fälle (Timeouts, nicht verarbeitete Ergebnisse, nicht übereinstimmende Präfixe) nutzen, bevor wir es in die Nähe der Produktion lassen. Die oben genannten Fehlerquellen sind fast vollständig vermeidbar, wenn das Datenmodell Nachweise und Reporting-Dimensionen ab der ersten Buchung mitschleppt.

FAQ

Bedeutet eine gültige VIES-Antwort, dass ich einen innergemeinschaftlichen B2B-Verkauf steuerfrei behandeln kann?

Nein. VIES bestätigt lediglich, dass eine USt-IdNr. registriert und – sofern unterstützt – für den innergemeinschaftlichen Handel aktiviert ist. Das Recht zur Steuerbefreiung einer innergemeinschaftlichen Lieferung hängt von weiteren Nachweisen ab: dass der Kunde der tatsächliche Empfänger ist, von Transport- oder Versandnachweisen, dem korrekten Ort der Lieferung und dem erforderlichen Rechnungstext. Speichern Sie das VIES-Ergebnis als einen Input-Faktor, nicht als endgültige Entscheidung.

Sollte die VIES-Validierung den Checkout blockieren?

Nein, das sollte sie nicht. Bei VIES kann es zu Timeouts oder Lastengrenzen (concurrency limits) kommen, und ein Ausfall ist nicht gleichbedeutend mit einer ungültigen Nummer. Validieren Sie asynchron, speichern Sie erfolgreiche Ergebnisse für einen dokumentierten Zeitraum im Cache, versuchen Sie es bei temporären Fehlern erneut und halten Sie unklare Fälle mit einem vorläufigen Status zur Überprüfung zurück, anstatt den Verkauf abbrechen zu lassen.

Kann eine Cloud-Accounting-API meine Umsatzsteuervoranmeldungen automatisch einreichen?

Sie kann meldefertige Daten generieren, gruppiert nach Verfahren und Mitgliedstaat, berechnet aus dem unveränderlichen Hauptbuch inklusive Korrekturen. Ob sie diese auch über das jeweilige nationale Einreichungs-Gateway übermittelt, hängt vom Produkt und vom Land ab. Nordlet berechnet OSS- und IOSS-Meldungen, liefert lokale Melde-Pakete für Litauen, Deutschland und Polen und generiert VMI-konforme i.SAF-Register für Litauen, reicht aber keine Daten in Ihrem Namen bei einer Steuerbehörde ein. Behandeln Sie Buchhaltung, Generierung der Meldung, Export, Gateway-Einreichung und Zahlung als separate Status, anstatt davon auszugehen, dass ein einziger API-Call die Meldung überall einreicht.

Wie gehe ich mit Korrekturen um, nachdem ein Meldezeitraum abgeschlossen wurde?

Buchen Sie diese in einem nachfolgenden Zeitraum mit expliziten Verweisen auf das Originaldokument und den betroffenen Meldezeitraum. Nordlet blockiert neue Buchungen für einen abgeschlossenen Monat, auch über die API. Korrekturen fließen daher durch Gutschriften oder Stornobuchungen und nicht durch nachträgliche Bearbeitungen. Dadurch bleibt die Historie (Lineage) zwischen der ursprünglichen Meldung und der Anpassung erhalten.