XRechnung prüfen, bevor der Empfänger sie zurückweist.

Jeder Fund ist mit seiner Erklärung verlinkt. Wer nur eine Regelnummer aus einer Rückweisung hat, schlägt sie direkt im Fehlerkatalog nach — etwa BR-DE-15 (Leitweg-ID fehlt) oder BR-CO-10 (Summe stimmt nicht).

Die PDF genügt

Was seit 2025 im Posteingang landet, ist meist keine XML-Datei, sondern eine PDF: Bei ZUGFeRD und Factur-X steckt die eigentliche Rechnung als Anhang darin — sichtbar ist das Bild, verbindlich sind die Daten. Wer hier eine solche PDF wählt, muss den Anhang nicht selbst heraussuchen; er wird gelesen und geprüft, egal ob die Datei darin factur-x.xml, zugferd-invoice.xml oder xrechnung.xml heißt. Eine eingescannte oder ausgedruckte Rechnung enthält keinen solchen Anhang; dann sagt der Prüfer genau das, statt einen Formatfehler zu melden.

Was hier geprüft wird

Der Prüfer liest UBL (XRechnung) und CII (ZUGFeRD/Factur-X), rechnet alle Summen nach und wendet die Geschäftsregeln an, die in der Praxis am häufigsten zur Zurückweisung führen:

Gegen die offiziellen Testfälle geprüft

Ein Prüfer, der gültige Rechnungen für kaputt erklärt, richtet mehr Schaden an als gar keiner: Er schickt jemanden auf die Suche nach einem Mangel, den es nicht gibt. Deshalb läuft dieser Prüfer bei jeder Änderung über alle 86 Instanzen der offiziellen XRechnung-Testsuite der KoSIT (Fassung 3.0.2, Release 2026-01-31) — Geschäftsfälle im Standard und in der deutschen Erweiterung, in UBL und in CII. Auf keiner einzigen darf er einen Fehler melden. Tut er es doch, gilt die Regel als falsch, nicht die Rechnung.

Dasselbe gilt für das Lesen der PDFs: Geprüft wird gegen echte ZUGFeRD-Dateien aus dem Testmaterial von Mustangproject, erzeugt von vier verschiedenen Programmen und in den PDF-Fassungen 1.4 bis 2.0. An einer dieser Rechnungen — einer in britischen Pfund — fiel auf, dass der Prüfer die Steuersumme gar nicht las, wenn sie doppelt im Dokument steht, einmal je Währung. Er meldete daraufhin einen Summenfehler auf einer Rechnung, die aufgeht. Das ist behoben.

Was hier nicht geprüft wird

Dies ist nicht der KoSIT-Referenzvalidator. Geprüft wird eine handverlesene Teilmenge der Regeln, nicht das vollständige Schematron, und es findet keine XSD-Schemaprüfung statt. Ein grünes Ergebnis heißt: die häufigsten Fehler sind ausgeschlossen — es ist keine Zusicherung der Konformität. Für die verbindliche Prüfung nutzen Sie den KoSIT-Validator.

Rechnungen erzeugen statt XML basteln

Das eigentliche Problem ist nicht das Prüfen, sondern das Erzeugen: UBL validiert gegen ein sequenzbasiertes Schema, in dem die Reihenfolge der Elemente Teil der Korrektheit ist. Die API nimmt flaches JSON und liefert gültiges XRechnung-XML zurück.

curl -X POST https://erechnung.dev/api/v1/create \
  -H "Content-Type: application/json" \
  -d '{
    "invoiceNumber": "RE-2026-0001",
    "issueDate": "2026-08-07",
    "buyerReference": "991-12345-67",
    "seller": { "name": "Muster GmbH", "vatId": "DE123456789",
      "address": { "street": "Werkstr. 5", "city": "Koblenz",
                   "postalZone": "56068", "country": "DE" },
      "contact": { "name": "A. Muster", "phone": "+49 261 123",
                   "email": "re@muster.de" } },
    "buyer": { "name": "Stadt Beispiel",
      "address": { "city": "Beispiel", "postalZone": "12345",
                   "country": "DE" } },
    "paymentMeans": { "iban": "DE49577615910029675300" },
    "lines": [ { "name": "Wartung", "quantity": 3,
                 "netPrice": 89.50, "vatRate": 19 } ]
  }'

Alle Felder sind mit ihrem Business Term (BT/BG) aus der EN 16931 dokumentiert — siehe API-Dokumentation.