E-Rechnung PoC

v0.0.000

Datei hochladen — als XML oder als PDF mit eingebettetem XML (ZUGFeRD/Factur‑X). Die Prüfung läuft vollständig lokal im Browser, es wird nichts hochgeladen. Geprüft wird ein praxisnaher Ausschnitt der EN‑16931‑ und XRechnung‑Regeln — als Ergänzung, nicht als Ersatz für den offiziellen KoSIT‑Validator.

Rechnung hierher ziehen
oder klicken zum Auswählen — .xml · .pdf
XML
—
—
wird geprüft …
Prüfung nicht möglich
Rechnungsdaten (aus XML rekonstruiert)

—

—

0 bestanden 0 Hinweise 0 Fehler 0 ohne Befund
Vollständige Prüfung — offizieller KoSIT‑Validator
Prüft alle EN‑16931‑/XRechnung‑Geschäftsregeln, Codelisten und XSD‑Schemas vollständig — läuft lokal in diesem Container.

BT‑Felder — Vollständigkeit (Kopf)

Zwei Prüfebenen: Die Prüfungen oben auf dieser Seite laufen sofort und komplett im Browser (ein handverlesenes Set formaler und rechnerischer EN‑16931‑/XRechnung‑Regeln, u. a. BR‑01 ff. und BR‑CO‑10 ff., sowie die IBAN‑Prüfziffer). Der Bereich "Vollständige Prüfung" führt zusätzlich automatisch bei jedem Upload den offiziellen KoSIT‑Validator mit der offiziellen XRechnung‑Konfiguration aus (vollständiges Schematron‑Regelwerk inkl. Codelisten und XSD‑Schemavalidierung) — läuft als eigener Prozess im selben Docker‑Container, ohne Kommunikation nach außen. Dieser Bereich ist nur verfügbar, wenn die Seite über das Backend aus diesem Container aufgerufen wird (nicht als lokal geöffnete Einzeldatei) — dann erscheint dort ein entsprechender Hinweis statt des Ergebnisses.

PDF‑Verarbeitung: eingebettete ZUGFeRD/Factur‑X‑XML‑Anhänge werden clientseitig mit pdf.js extrahiert und als Seitenvorschau dargestellt. Enthält die PDF kein eingebettetes XML, kann keine Prüfung erfolgen.

Die Ansicht "Rechnungsdaten (aus XML rekonstruiert)" zeigt die aus dem XML ausgelesenen Werte in Rechnungsform an — zur besseren Kontrolle, ob z. B. Positionen und Beträge korrekt gelesen werden. Sie ersetzt bei ZUGFeRD nicht das im PDF hinterlegte, für Menschen gestaltete Originallayout.

PDF/A‑3‑Hinweis: ZUGFeRD/Factur‑X sieht als Sichtformat PDF/A‑3 vor. Das Tool prüft dazu sowohl die XMP‑Selbstauskunft (pdfaid:part/conformance) als auch, ob ein für PDF/A erforderliches OutputIntent mit ICC‑Ausgabeprofil vorhanden ist. Weicht beides voneinander ab oder fehlt eines, wird das nur als Hinweis ausgegeben — eine Rechnung wird dadurch nicht als ungültig eingestuft, und dies ersetzt keine vollständige PDF/A‑Validierung (z. B. mit veraPDF).

Die client‑seitigen "Bekannte Grenzen" (Codelisten, USt‑Regelfamilien BR‑S/Z/E/AE/K/G/O/L/M/IG/IP, PEPPOL‑EN16931‑R0xx, Extension XRechnung, Skonto‑Syntax) gelten nur für die schnelle Browser‑Prüfung oben — die "Vollständige Prüfung" über den KoSIT‑Validator deckt diese Fälle ab, sofern das Backend erreichbar ist.

BT‑Felder — Abdeckung: 97 Kopf‑Felder plus 20 Positions‑Felder (BG‑25 ff., aggregiert über alle Positionen: Pflichtfelder müssen in jeder Position stehen, optionale Felder gelten als befüllt, wenn mindestens eine Position sie enthält) — zusammen 117 der insgesamt rund 165 Business Terms aus EN 16931/XRechnung. Bewusst ausgelassen, weil die XML‑Zuordnung zu unsicher oder das Feld zu selten genutzt wäre, um es verlässlich zu prüfen: SEPA‑Lastschrift-Mandat (BG‑19), die volle Postadresse des Steuervertreters (nur Name/USt‑IdNr./Land werden geprüft), seltene Zusatzangaben wie BT‑18 (Objektkennung) und BT‑33 (zusätzliche Rechtsangaben Verkäufer), sowie die Einzelwerte innerhalb wiederkehrender Gruppen (z. B. jeder einzelne Ab‑/Zuschlag statt nur "kommt mindestens einer vor").

Wichtig — Verhältnis zum Gesamtstatus: Bei den Kopf-Feldern ist "Pflicht" nur dann vergeben, wenn es dafür auch tatsächlich eine Regel oben (BR‑01 ff., BR‑DE‑…) gibt, die bei Fehlen auf "Fehlerhaft" setzt — beides ist jetzt bewusst konsistent gehalten. Bei den Positions‑Feldern ist das nicht der Fall: Sie sind rein informativ und fließen nicht in den Gesamtstatus ein, da hier keine Positions-Regelprüfung implementiert ist. Ein rot markiertes Positionsfeld macht die Rechnung also nicht automatisch "fehlerhaft".