Shopify
WooCommerce
Shopware
JTL-Shop
Magento
PrestaShop
n8n
Zapier
Make
Airtable
HubSpotWarum es drei Stufen sind, nicht eine
„Ist die Rechnung gültig?" ist keine einzelne Frage. Sie zerfällt in drei, die nacheinander beantwortet werden und von denen jede eine andere Fehlerklasse findet. Wer den Unterschied kennt, liest eine Fehlermeldung in Sekunden statt in Stunden.
Stufe 1 — Syntax
Ist das Dokument überhaupt wohlgeformtes XML? Nicht geschlossene Tags, kaputte Zeichenkodierung, ein abgeschnittener Upload. Diese Stufe hat nichts mit Rechnungen zu tun; sie würde jedes XML gleich behandeln.
Fehler hier sind selten und meistens ein Transportproblem, kein Datenproblem.
Stufe 2 — Schema
Entspricht das Dokument seiner XSD? Hat cbc:IssueDate wirklich ein Datum,
steht cac:AccountingSupplierParty an der erlaubten Stelle, ist die
Kardinalität eingehalten? Hier entscheidet sich auch, ob das Dokument in der
richtigen Syntax vorliegt — CII oder UBL sind zwei verschiedene XSDs für
denselben fachlichen Inhalt.
Fehler hier bedeuten fast immer: Der Erzeuger baut ein Feld an der falschen Stelle oder mit dem falschen Typ ein.
Stufe 3 — Geschäftsregeln
Hier scheitern die meisten Dokumente, und hier ist die Fehlermeldung am schwersten zu lesen. Geschäftsregeln sind in Schematron formuliert und prüfen fachliche Aussagen mit XPath-Ausdrücken:
1<assert test="cac:Party/cac:Contact" flag="fatal" id="DE-R-002">2 The group "SELLER CONTACT" (BG-6) shall be provided.Das Dokument ist an dieser Stelle einwandfreies XML und schema-konform. Es fehlt nur eine fachliche Pflichtangabe — und genau deshalb wird es abgelehnt.
Die drei Regelwerke, die gleichzeitig gelten
Eine deutsche B2G-Rechnung wird nicht gegen ein Regelwerk geprüft, sondern gegen mehrere, die aufeinander aufbauen:
| Ebene | Beispiel-Regel | Herkunft |
|---|---|---|
| Europäische Norm | BR-11 — die Käuferanschrift braucht ein Länderkennzeichen | EN 16931 |
| Rechenregeln der Norm | BR-CO-10 — Summe der Positionen = Nettobetrag | EN 16931 |
| Nationale Ausprägung | DE-R-001 — Zahlungsangaben (BG-16) sind Pflicht | XRechnung / CIUS |
Ein Dokument muss alle bestehen. Deshalb genügt es nicht, gegen die europäische Norm zu validieren, wenn das Ziel eine deutsche Behörde ist.
Wie man einen Fehler tatsächlich findet
Eine brauchbare Fehlermeldung nennt drei Dinge: die Regel-ID, das betroffene Feld in BT/BG-Notation und die Schwere. Mit der Regel-ID lässt sich der XPath-Ausdruck nachschlagen, der fehlgeschlagen ist — und der zeigt exakt, an welcher Stelle im Dokument gesucht wurde.
Der häufigste Zeitfresser ist, die BT-Nummer aus der Meldung nicht auf das
eigene Datenmodell abzubilden. BT-10 heißt im Behördenkontext Leitweg-ID; wer
danach in seinem ERP unter „Leitweg" sucht, findet sie, wer unter „BT-10" sucht,
nicht.
Validierung ist keine Einmal-Prüfung
Regelwerke bekommen neue Versionen, und mit ihnen ändern sich Schweregrade. Eine Rechnung, die letztes Jahr mit einer Warnung durchging, kann dieses Jahr an derselben Stelle hart scheitern. Wer E-Rechnungen erzeugt, sollte deshalb gegen die Version validieren, die der Empfänger einsetzt — nicht gegen die, die beim Bau der Schnittstelle aktuell war.