Prüfung und Normkonformität (EN 16931)

Eine E-Rechnung zu prüfen heißt festzustellen, ob sie die Regeln ihres Formats erfüllt — bevor der Empfänger sie ablehnt. Der Bericht kennt genau zwei Stufen: Error und Warning. „Konform“ heißt „kein Befund der Stufe Error“. Eine Warnung bleibt im Bericht stehen und sollte gelesen werden, macht die Rechnung aber nicht unwirksam.

Die drei Prüfwege — nicht gleichwertig

Formate	Weg	Angezeigte Prüfstufe
XRechnung, ZUGFeRD/Factur-X, Peppol BIS	nativer EN-16931-Validator: die Schematron-Regeln als C#-Prädikate portiert, mit Regel-IDs und BT-Fundstellen. Bei Peppol entscheidet eine Jurisdiktions-Weiche über die PINT-Regelsätze	„EN 16931 … (nativ)“
FatturaPA, Finvoice, ebInterface, Austrofix, FA_VAT, Facturae	amtliches XSD, Geschäftsregeln und eine rechnerische Gegenrechnung	„Rechnerische Konsistenz + Geschäftsregeln“
ERP-Formate, außereuropäische Formate, ZUGFeRD 1.0	nicht prüfbar — kein EN-16931-Dokument. Die Antwort nennt das Format und verweist aufs Umwandeln	„Format-Erkennung“

Die Prüfstufe gehört in jedes Protokoll

Ein „Konform“ aus der Konsistenzprüfung ist eine andere Zusage als eines aus dem EN-16931-Validator. Wer Prüfergebnisse archiviert oder weitergibt, notiert die Stufe mit — sonst behauptet das Protokoll später mehr, als geprüft wurde.

Was im Bericht steht

Spalte	Inhalt
Regel	die verletzte Regel: BR-… (EN 16931), BR-DE-… (deutsche Ausprägung), PEPPOL-EN16931-…, CONS-… (eigene Konsistenzregeln). Ein — bedeutet Befund ohne Regelbezug
Schwere	Error oder Warning
Meldung	der Text der Prüf-Engine
Ort	die Fundstelle — ein XPath oder ein Geschäftsbegriff wie BT-10

Für die automatische Auswertung ist die Regel-ID maßgeblich, nie der Meldungstext

Die normativen EN-16931-Regeln behalten absichtlich ihren Originalwortlaut. Ein Teil der Meldungen kommt aus der Engine und ist deutsch, auch wenn die Oberfläche auf Englisch steht; diese Stellen sind im Bericht gekennzeichnet. Regel-IDs und BT-Fundstellen sind sprachneutral.

Zwei Regeln, die oft überraschen

Peppol verlangt eine Referenz. PEPPOL-EN16931-R003 fordert entweder eine Käuferreferenz (BT-10) oder eine Bestellreferenz (BT-13) — als Error, nicht als Warnung.

XRechnung ist strenger. BR-DE-15 verlangt BT-10 selbst; eine Bestellreferenz genügt nicht. Bei öffentlichen Auftraggebern ist BT-10 die Leitweg-ID. Hinterlegen Sie sie im Kundenstamm, dann fehlt sie nicht mehr.

Warum ZUGFeRD manchmal abgelehnt wird

Wahrscheinlich ist es ZUGFeRD 1.0. Das Format ist älter als EN 16931 und damit lesbar, aber nicht prüfbar. Wandeln Sie es in eine aktuelle Fassung um und prüfen Sie diese — genau das ist der Migrationsweg für ein Altarchiv.

Reparierte Dokumente

Eng gefasste Defekte werden vor dem Lesen behoben: falsche Kodierungsnamen, ungültige Tag-Namen, nackte &, Steuerzeichen, Müll vor der XML-Deklaration, ein verwaistes End-Tag am Dateiende. Jede Reparatur steht im Bericht; nichts davon geschieht stillschweigend. Eine falsch verschachtelte oder mitten im Element abgebrochene Datei behält ihren Fehler.

Der Warnkasten über dem Bericht sagt auch, was daraus folgt: Die Originaldatei bleibt fehlerhaft und scheitert bei jedem weiteren Empfänger — der Absender sollte seinen Export korrigieren.

Grenzen der Prüfung

• Kein <!DOCTYPE> und kein xsi:schemaLocation. Beides würde das hochgeladene Dokument darüber entscheiden lassen, wogegen geprüft wird. Es gelten ausschließlich die mitgelieferten Schemata.
• Fehlende Codelisten lassen die Prüfung nicht scheitern — sie würde sonst fälschlich ablehnen. Stattdessen werden diese Regeln ausgelassen und der Bericht trägt eine Warnung. So wird eine ungeprüfte Rechnung nie als geprüfte gemeldet.
• Über die API bedeutet 200 nur „geprüft“. Die Aussage steht in isValid und errorCount; ein 400 heißt, dass die Prüfung gar nicht laufen konnte.