Was ein signierter Bericht belegt

Einen Bericht ohne Konto verifizieren. Die Verifizierung prüft die Signatur des Manifests, alle gebündelten Hashes und einen gegebenenfalls erforderlichen Zeitstempel. PHIVE wird dabei nicht erneut ausgeführt. Ein verifizierter Bericht kann eine ungültige Rechnung dokumentieren.

Um das Paket auf Ihrem Computer zu behalten, laden Sie den Offline-Verifizierer für Linux, macOS oder Windows herunter. Prüfen Sie das Archiv gegen die SHA256SUMS des Releases, und beziehen Sie öffentliche Schlüssel unabhängig davon. Der Verifizierer braucht keinen API-Schlüssel und stellt keine Netzwerkanfragen.

Bericht anfordern

Senden Sie einen POST an /finance/v1/einvoices/reports mit einem Schlüssel mit finance:einvoices:read. Übergeben Sie {"operation_id":"your-operation-uuid"}. Der Vorgang muss zu Ihrer Organisation gehören, und sein gespeichertes Ergebnis muss noch aufbewahrt sein. Das Portal bietet für gespeicherte Ergebnisse ebenfalls den Download eines signierten Berichts an. Die Ausstellung erfordert einen aktivierten Signaturdienst; HTTP 503 report_unavailable bedeutet, dass er nicht verfügbar ist, und lässt das gespeicherte Ergebnis unverändert.

Pakete einer Erzeugung enthalten genau das validierte XML. Fügen Sie "include_pdf": true hinzu, um ein frisch gerendertes lesbares PDF und seine Vorlagenversion einzubinden. Uploads, die nur validiert werden, bewahren das Quell-XML nicht auf, daher enthalten ihre Berichte den Hash der Quelle ohne XML-Datei. Sie können kein lesbares Rechnungs-PDF enthalten.

Die Ausstellung erzeugt keinen neuen Validierungsvorgang und keine Nutzungskosten und speichert keine weitere gehostete Kopie. Wiederholte Downloads können unterschiedliche Ausstellungszeiten, Signaturen, Zeitstempel-Token oder PDF-Bytes haben. Die ursprünglichen Fakten der Validierung bleiben fixiert. Nach dem Löschen oder Ablauf des Ergebnisses wird die Ausstellung abgelehnt. Ein heruntergeladener Bericht lässt sich weiterhin offline prüfen.

Berichte zu Ergebnissen von V2

Ergebnisse über die API V2 (Peppol BIS Billing 3, XRechnung und ZUGFeRD / Factur-X, als XML oder, bei ZUGFeRD / Factur-X, als PDF mit eingebettetem Rechnungs-XML) haben einen eigenen Bericht: Senden Sie {"operation_id":"your-operation-uuid"} per POST an /finance/v2/einvoices/reports mit einem Schlüssel mit finance:einvoices:read. Sein Manifest (ironfang/finance/einvoice/report-manifest/v2) hält die Eingabe per Hash fest und, bei einem PDF, das eingebettete XML per Hash; das Release des Regelwerks mit Familie, Variante, Syntax, Prüfumfang und Prüfsumme des Pipeline-Manifests; bei einem PDF-Release die PDF-Engine, die PDF/A-Profile und die Bindungstabelle, die es fixiert; beide Engines per Image-Digest; jede Prüfgruppe und jeden Prüfschritt; was nicht geprüft wurde; und die Regeldateien des Releases per Hash. Das Paket enthält das Manifest, seine Signatur, das exakte gespeicherte Ergebnis, die vollständigen Befunde und die lesbare Seite. Ein Ergebnis von V2 hat kein lesbares Rechnungs-PDF.

Berichte von V2 werden mit denselben Schlüsseln unter einer eigenen Signaturdomäne signiert, sodass eine Signatur von V1 nie als V2 gelesen werden kann und umgekehrt. Für ein Ergebnis über V1 stellt derselbe Endpunkt genau den Bericht von V1 aus. Verifizieren Sie beide Versionen unter /finance/v2/einvoices/reports/verify, das auch die Verifizierungsseite nutzt; der Verifizierungsendpunkt von V1 liest nur Berichte von V1. Ein Bericht zu einem PDF sagt nicht, ob das sichtbare PDF dieselbe Rechnung zeigt wie sein XML: Das wurde nicht geprüft.

Inhalt des Pakets

• manifest.json: kanonische Fakten von Ironfang Finance, genaues Regelwerk/VES und Engine-Image, Prüfsummen der ausführbaren Artefakte, Ergebnisse der Prüfschritte, vollständige Anzahl der Befunde, Hashes der Quellen, Versionen von Generator und Rendering, soweit zutreffend, Ausstellungszeit, Signaturschlüssel und Grenzen der Aussage.
• signature.json: die Ed25519-Signatur und die Schlüssel-ID, mit einem eigenen Domänentrenner für Ironfang Finance.
• result.json und findings.json: die exakte gespeicherte Antwort und das vollständige Array der Befunde, jeweils per Hash und Bytelänge gebunden.
• report.html: eine maskierte, druckbare Ansicht, die aus dem signierten Manifest abgeleitet ist. Die Verifizierung prüft, dass sie übereinstimmt.
• document.xml und optional readable.pdf: das aufbewahrte erzeugte XML und die angeforderte lesbare Darstellung.
• timestamp.tsq und timestamp.tsr: gemeinsam vorhanden, wenn die signierte Richtlinie einen Zeitstempel nach RFC 3161 verlangt.

Ironfang Finance bewahrt derzeit höchstens 1.000 zurückgegebene Befunde auf. Gibt ein gespeichertes Ergebnis an, dass seine Befunde gekürzt wurden, liefert die Ausstellung eines Berichts 422 report_incomplete. Eine unvollständige Liste wird nie als vollständige signierte Aufzeichnung der Befunde ausgegeben. Bibliotheksversionen, die in der ursprünglichen Beobachtung fehlen, werden nicht aus dem Validator rekonstruiert, der gerade zufällig läuft.

Vertrauen und Zeitstempel

Der Endpunkt für öffentliche Schlüssel enthält vom Betreiber konfigurierte Schlüssel. Beziehen Sie Schlüssel unabhängig vom Bericht selbst. Aktive Schlüssel stellen Berichte aus; ausgemusterte Schlüssel verifizieren frühere Berichte; widerrufene Schlüssel werden abgelehnt. Die Offline-Verifizierung spiegelt die Schlüsselliste wider, die Sie angeben, halten Sie Widerrufe also aktuell. Ein mitgelieferter oder von einem Angreifer bereitgestellter Schlüssel ist kein unabhängiger Vertrauensanker.

Derzeit ist keine Zeitstempelstelle konfiguriert. Die Ausstellungszeit ist eine Angabe des Dienstes Ironfang Finance. Ist die Zeitstempelung konfiguriert, wird nur der Digest des domänengetrennten Manifests an die konfigurierte Zeitstempelstelle gesendet. Die signierte Richtlinie verlangt das zurückgegebene Zeitstempelpaar; wird es entfernt oder scheitert seine unabhängige Prüfung gegen die CA, gilt der Bericht als nicht verifiziert. Der öffentliche Verifizierer stellt keine Netzwerkverbindungen her, auch nicht zu einer Zeitstempelstelle.

Limits und Datenschutz

Komprimierte wie entpackte Pakete sind auf 48 MiB begrenzt, mit Limits für einzelne Einträge und einer exakten Positivliste von bis zu neun Namen. Doppelte, unbekannte oder unsichere ZIP-Einträge werden abgelehnt. Die gehostete Prüfung nimmt nur ZIP-Bytes an, verarbeitet sie flüchtig, ruft keine Dokument-URLs ab und lädt keine Dateien anderswohin hoch. Die Offline-CLI stellt keine Netzwerkverbindungen her.

Eine Signatur versendet keine Rechnungen, registriert keine Peppol-Teilnehmer, macht Ironfang nicht zu einem Access Point, bescheinigt keine rechtliche oder steuerliche Konformität, belegt nicht, dass eine Rechnung angenommen wurde, und ersetzt keine buchhalterische oder normative Prüfung. Im Validierungsleitfaden erfahren Sie, was PHIVE geprüft hat.