Kurzüberblick
- Export
- PDF, JSON, CSV
- Nachweis
- Hash, Status, Zeitpunkt
- Grenze
- keine Rechts-/Steuerberatung
Felder, Pfade und Bedeutung
| Information | Richtiger Fundort | Nicht verwechseln mit |
|---|---|---|
| Dateiidentität | Dateiname, Dateigröße, Hash, Upload-Zeitpunkt | sichtbarer PDF-Titel oder ursprünglicher E-Mail-Betreff. |
| Rechnungsdaten | aus UBL/CII/Factur-X/EDI-Pfaden | OCR-Text oder technische Kontextfelder. |
| Prüfebene | Basisdaten, Upload-Sicherheit, Malware, externe Normprüfung | ein pauschaler Gesamtstatus ohne Erklärung. |
| Grenzen | klarer Hinweis im Bericht | verstecktes Kleingedrucktes im Footer. |
Typische Fehlerbilder
| Fehlerbild | Wahrscheinliche Ursache | Saubere Reaktion |
|---|---|---|
| Bericht wirkt wie ein Zertifikat | Status und Grenzen sind nicht sauber formuliert. | Technische Prüfung und fachliche Freigabe klar trennen. |
| Originaldatei nicht nachvollziehbar | Hash oder Dateiname fehlen. | Hash und Zeitpunkt in Bericht und Audit-Spur aufnehmen. |
| Warnungen verschwinden im Export | PDF/CSV enthält weniger Hinweise als UI. | UI und Export fachlich konsistent halten. |
Pflichtinformationen für Nachvollziehbarkeit
Dateiname, Dateigröße, Hash, Upload-Zeitpunkt, erkannter Standard, Quelle und Prüfstatus bilden die technische Basis.
Rechnungsdaten im Bericht
Rechnungsnummer, Datum, Lieferant, Empfänger, Betrag und Währung sollten klar sichtbar sein. Sensible Inhalte gehören aber nicht unnötig in technische Logs.
Hinweise und Grenzen
Der Bericht sollte unterscheiden zwischen erkannt, gewarnt, blockiert, nicht geprüft und extern validiert. Außerdem muss klar sein: keine Steuer- oder Rechtsberatung.
Häufige Fragen
Ist ein Prüfbericht ein rechtlicher Nachweis?
Er dokumentiert den technischen Prüfvorgang, ersetzt aber keine rechtliche oder steuerliche Prüfung.
Warum Hash speichern?
Ein Hash hilft, die geprüfte Datei später wiederzuerkennen, ohne den vollständigen Inhalt in Logs zu schreiben.