Kurzüberblick
- Ziel
- E-Rechnung lesbar und nachvollziehbar machen
- Formate
- XRechnung, ZUGFeRD/Factur-X, XML, PDF, ZIP, EDIFACT
- Ergebnis
- Prüfansicht, Hinweise, Export
Ablauf in der Praxis
Dateiendung, Größe und plausibler Inhalt werden geprüft, bevor die Rechnung verarbeitet wird.
Die Anwendung trennt UBL, CII, Factur-X/ZUGFeRD, PDF, ZIP und EDIFACT, damit jedes Format nach seinen eigenen Regeln gelesen wird.
Rechnungsnummer, Datum, Lieferant, Empfänger, Währung und Betrag werden aus den passenden Dokumentpfaden gelesen.
Im Ergebnis steht nicht nur ein grüner oder roter Status, sondern welche Ebene geprüft wurde: Basisdaten, Format, Malware, ZIP oder externe Validierung.
Typische Fehlerbilder
| Fehlerbild | Wahrscheinliche Ursache | Saubere Reaktion |
|---|---|---|
| Rechnungsnummer wirkt wie eine lange URN | Der Parser hat eine ProfileID oder BusinessProcess-ID statt BT-1 gelesen. | Dokumentpfad korrigieren und technische Kontext-IDs nie als Rechnungsnummer speichern. |
| PDF sieht korrekt aus, aber Upload bleibt gelb | Die PDF enthält keine oder keine lesbare eingebettete XML-Rechnung. | Als normales PDF kennzeichnen oder ZUGFeRD-/Factur-X-XML prüfen lassen. |
| Betrag fehlt trotz sichtbarer Summe | Der Betrag steht nur im PDF-Text oder an einem nicht unterstützten XML-Pfad. | Datei als unvollständig markieren und keinen Betrag erraten. |
Was bedeutet E-Rechnung prüfen?
Eine E-Rechnungsprüfung bedeutet nicht nur, eine Datei zu öffnen. Zuerst wird geklärt, ob eine Datei strukturiert lesbare Rechnungsdaten enthält. Danach werden technische Basisdaten, erkannter Standard, Betrag, Beteiligte, Datumsangaben, Hinweise und Exportmöglichkeiten getrennt dargestellt.
1. Format erkennen
Die Prüfung beginnt mit der Frage, welches Format vorliegt. Typische Eingänge sind UBL-XRechnung, CII-XRechnung, ZUGFeRD/Factur-X als PDF mit eingebetteter XML, reine XML-Dateien, ZIP-Sammlungen oder EDIFACT-INVOIC.
- XML-Dateien müssen sicher geparst werden.
- PDF-Dateien können nur dann strukturiert geprüft werden, wenn eine eingebettete Rechnungs-XML vorhanden ist.
- ZIP-Dateien müssen vor dem Entpacken begrenzt und geprüft werden.
- EDIFACT ist ein Legacy-Format und wird getrennt von EN-16931-XML bewertet.
2. Basisdaten auslesen
Für die erste Einordnung sind Rechnungsnummer, Rechnungsdatum, Lieferant, Empfänger, Währung und Gesamtbetrag entscheidend. Diese Daten müssen pfadbasiert ausgelesen werden, damit technische IDs nicht fälschlich als Rechnungsnummer erscheinen.
3. Validierung trennen
Basisdaten-Erkennung und vollständige EN-16931-/Schematron-Validierung sind unterschiedliche Prüfschritte. Eine Seite sollte klar sagen, ob nur Basisdaten extrahiert wurden oder ob zusätzlich eine formale Normvalidierung ausgeführt wurde.
4. Prüfbericht exportieren
Ein Prüfbericht hilft intern, den Stand weiterzugeben. Er sollte Dateiname, Hash, Format, erkannte Daten, Hinweise, Zeitpunkt und Grenzen der Prüfung enthalten.
Häufige Fragen
Ist eine ausgelesene XML automatisch gültig?
Nein. Lesbarkeit und vollständige EN-16931-/Schematron-Validierung sind unterschiedliche Schritte.
Warum wird eine technische URN nicht als Rechnungsnummer verwendet?
Weil Prozess- oder Profilkennungen nicht BT-1/Rechnungsnummer sind. Die Rechnungsnummer muss aus dem richtigen Dokumentpfad gelesen werden.
Kann Rechnungsnotarzt Steuerberatung ersetzen?
Nein. Die Prüfung unterstützt technische Nachvollziehbarkeit, ersetzt aber keine rechtliche oder steuerliche Bewertung.