Prüfen

Wofür. Feststellen, ob eine E-Rechnung die Regeln ihres Formats erfüllt — bevor der Empfänger sie ablehnt.

Hinein. Eine Datei oder eingefügtes XML. Das Format wird aus dem Dokument selbst erkannt; es gibt keine Auswahl dafür. Eine ZUGFeRD-/Factur-X-Hybrid-PDF ist zulässig: Ihre eingebettete XML wird herausgelöst und geprüft.

Jede Rechnungsart hat zusätzlich eine eigene Unterseite — /de/pruefen/xrechnung, /de/pruefen/zugferd und so fort. Geprüft wird dasselbe; der Unterschied ist erklärender Text.

Die drei Prüfwege

Formate	Weg	Angezeigte Prüfstufe
XRechnung, ZUGFeRD/Factur-X, Peppol BIS	nativer EN-16931-Validator — die Schematron-Regeln als C#-Prädikate, kein Saxon; liefert Regel-IDs und BT-Fundstellen	„EN 16931 + XRechnung-CIUS (nativ)“, „EN 16931 (CII, nativ)”, „EN 16931 + Peppol (nativ)“, „EN 16931 + CIUS-RO (nativ)”
FatturaPA, Finvoice, ebInterface, Austrofix, FA_VAT, Facturae	amtliches XSD + Geschäftsregeln + rechnerische Gegenrechnung (`CONS-*`)	„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“

Der Prüfbericht

Zeile	Inhalt
Status	Konform / Nicht konform / Nicht erkannt, rechts daneben der Name des erkannten Formats
Kennzahlen	`Prüfstufe: … · n Fehler · m Warnungen`
Tabelle	je Befund Regel, Schwere, Meldung, Ort — oder „Keine Beanstandungen.“
Fußnote	„Meldungstexte stammen aus der Prüf-Engine (deutsch); Regel-IDs und Fundstellen (BT-…) sind sprachneutral.“

Ein Fehler ist ein Verstoß gegen eine verbindliche Regel — die Rechnung gilt als nicht konform und wird beim Empfänger durchfallen. Eine Warnung ist ein Hinweis und ändert den Status nicht. Der Status oben ist genau dann „Konform“, wenn kein Befund die Schwere Fehler trägt.

In der Spalte Regel steht die verletzte Regel: BR-… (EN 16931), BR-DE-… (deutsche Ausprägung), PEPPOL-EN16931-…, CONS-… (eigene Konsistenzregeln); ein — bedeutet Befund ohne Regelbezug. Die Spalte Ort nennt die Fundstelle — einen XPath oder einen Geschäftsbegriff wie BT-10.

Reparierte Dokumente

Manche Defekte werden behoben, statt das Dokument abzulehnen: kaputte Zeichensatz-Angaben, unzulässige Zeichen in Element-Namen, nicht maskierte &, Steuerzeichen, Müll vor der XML-Deklaration. Dann steht über dem Bericht ein Warnkasten „Die Datei war fehlerhaft — wir haben sie repariert“ mit der Liste der Eingriffe und diesem Schluss:

Das Ergebnis unten stammt aus der reparierten Fassung. Die Originaldatei bleibt fehlerhaft — bitten Sie den Absender, seinen Export zu korrigieren, sonst scheitert dieselbe Datei bei jedem weiteren Empfänger.

Die Reparatur ist eng gefasst: Eine falsch verschachtelte oder mitten im Element abgebrochene Datei behält ihren Fehler.

Grenzen und Sonderfälle

Keine <!DOCTYPE …> und kein xsi:schemaLocation. Beides würde das hochgeladene Dokument darüber entscheiden lassen, was nachgeladen bzw. 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 —, aber der Bericht trägt dann eine Warnung.
Eine gewöhnliche PDF ergibt keinen Bericht. Die Seite sagt das und bietet „PDF zu E-Rechnung“ an; die Datei wird mitgenommen, ein zweiter Upload ist nicht nötig.

Was die Ergebnisseite sonst anbietet

Element	Wann
„Rechnung korrigieren“	nur bei Fehlern: öffnet das Erstellen-Formular mit allen Angaben, die die Datei schon trägt
„Jetzt konvertieren“	sobald ein Format erkannt wurde
menschenlesbare Ansicht	aufgeklappt unterhalb des Berichts
„Datei geändert? Hier direkt erneut prüfen:“	kleines Upload-Feld am Seitenende
„Im Archiv speichern“	nur mit Konto