E-Invoice Finder
Menu
Länder Software Fristen Leitfäden Check Pflicht prüfen
ENFRDEPLNL
Polen · Offline24-Implementierungstest

KSeF Offline24 QR-Codes und ERP-Testplan

Prüfen Sie KSeF Offline24 im ERP: zwei QR-Codes, Typ-2-Zertifikat, Rechnungshash, Warteschlange, Fristen und Wiederanlauf.

Kurzfazit:
  • • Geltungsbereich: Die Empfängerklasse entscheidet über den Vorab-Nachweis.
  • • Hauptrisiko: Schon eine veränderte XML-Bytefolge entwertet die Prüfkette.
  • • Erster Schritt: Frieren Sie einen repräsentativen Beleg als Golden File ein.
Polen-Readiness-BerichtOffizielle Quellen
Zuletzt geprüft: 4. August 2026Offizielle QuellenKlare ZusammenfassungPraktische Information, keine Rechtsberatung
Offizielle Quellen priorisiert
Prüfdatum sichtbar
Kostenloser Check ohne Registrierung

Was Sie wissen müssen

Leitfaden

Anwendungsfall und Zwei-Code-Fall sauber bestimmen

Offiziell darf jeder Steuerpflichtige Offline24 wählen, auch bei Schwierigkeiten mit dem Übertragungsnetz oder Internet. Das ist von einer amtlich bekannt gegebenen KSeF-Nichtverfügbarkeit, einem Ausfall beziehungsweise Notfall und einem Totalausfall zu trennen. Modellieren Sie deshalb im ERP einen eigenen Offline24-Status und lassen Sie den Finance Process Owner den zulässigen Auslöser sowie den Empfängertyp bestätigen. Ein inländischer umsatzsteuerpflichtiger Käufer erhält die Rechnung normalerweise über KSeF. Zwei Codes werden vor der Übermittlung benötigt, wenn eine offline ausgestellte Rechnung außerhalb von KSeF einem Käufer nach Art. 106gb(4) bereitgestellt wird, etwa einem ausländischen Käufer, Verbraucher oder Käufer ohne NIP: KOD I mit der Bezeichnung OFFLINE ermöglicht Zugriff und Datenprüfung, KOD II mit der Bezeichnung CERTYFIKAT bestätigt Ausstelleridentität und Authentizität. Das bedeutet nicht, dass jede Offline24-Rechnung zwei Codes trägt. Akzeptanzkriterium: Für Testfälle mit inländischem VAT-Käufer, Verbraucher und ausländischem Käufer wählt die Regelengine nachweislich den richtigen Bereitstellungsweg und erzeugt weder fehlende noch überflüssige Codes. Hauptrisiko ist eine pauschale Zwei-Code-Logik; Owner sind Finance und Product Owner des Connectors.

Leitfaden

FA(3), P_1 und deterministische XML-Basis vorbereiten

Amtlich erforderlich sind die jeweils geltende logische Struktur – seit 1. Februar 2026 FA(3) –, eine elektronische Ausstellung und die spätere Übermittlung an KSeF. Das Ausstellungsdatum stammt aus P_1. Für eine verlässliche Implementierung sollte das ERP die endgültigen XML-Bytes vor QR-Erzeugung einfrieren: gleiche fachliche Eingabe, Zeichencodierung, Serialisierung und Zeilenenden müssen denselben SHA-256-Hash liefern. Die Visualisierung ist nur eine Darstellung und nicht die strukturierte Rechnung selbst. Erstellen Sie Golden Files für Standardrechnung, Gutschriftkonstellation, Sonderzeichen und große Positionenzahl; speichern Sie XML-Hash, P_1, Verkäufer-NIP, Schema-Version und Build-ID. Ein realistischer Fehler ist, dass das PDF-Modul XML nachträglich neu serialisiert und der Scan deshalb einen anderen Hash referenziert. Empfohlenes Akzeptanzkriterium: Drei unabhängige Läufe auf zwei Worker-Knoten liefern byteidentische XML-Dateien und denselben Base64URL-kodierten SHA-256-Wert; jede fachliche oder technische Byteänderung erzeugt einen neuen Wert. Data Owner verantwortet FA(3) und P_1, der Integration Owner die Bytes. Diese Wiederholbarkeitsprüfungen sind empfohlene Kontrollen, keine zusätzlichen gesetzlichen Formvorschriften.

Leitfaden

KOD I lokal und prüfbar implementieren

KOD I wird lokal aus der Verifikations-Basis-URL der richtigen Umgebung, dem Ausstellungsdatum P_1, der Verkäufer-NIP und dem Base64URL-kodierten SHA-256-Hash der Rechnungsdatei aufgebaut. In Produktion ist qr.ksef.mf.gov.pl zu verwenden; Test und Demo haben getrennte Hosts. Hinterlegen Sie die Basis-URL nicht frei im Rechnungsdatensatz, sondern binden Sie sie an eine unveränderliche Umgebungskennung. Der QR-Generator erzeugt daraus eine Grafik nach ISO/IEC 18004:2024 und versieht sie vor der KSeF-Annahme mit OFFLINE. Prüfen Sie die URL-Komponenten gegen das Golden File, dekodieren Sie den QR-Inhalt im automatisierten Test und vergleichen Sie Datum, NIP und Hash zeichengetreu. Ein Negativtest vertauscht Test- und Produktionskonfiguration und muss den Druck beziehungsweise Versand blockieren. Weitere Risiken sind Standard-Base64 mit Pluszeichen oder Padding, ein lokalisiertes Datumsformat und Hashing des PDFs statt der XML-Datei. Akzeptanzkriterium: 100 Prozent der freigegebenen KOD-I-Testvektoren ergeben den erwarteten Link und werden von mindestens zwei unabhängigen Scannern gelesen. Owner ist das Connector-Team; Security prüft die gesperrte Umgebungskonfiguration.

Leitfaden

KOD II mit Typ 2 und kontrolliertem Schlüssel erzeugen

KOD II enthält Typ und Wert der Kontextkennung, die Verkäufer-NIP, Seriennummer des Zertifikats, denselben Rechnungshash wie KOD I sowie eine kryptografische Signatur mit dem privaten Schlüssel eines aktiven KSeF-Zertifikats Typ 2 Offline. Ein Typ-1-Authentication-Zertifikat kann KOD II nicht erzeugen. Der Signaturdienst sollte den privaten Schlüssel in einer freigegebenen Schlüsselverwaltung halten, Exporte verhindern, Aufrufer auf den Offline-Worker begrenzen und jede Signatur mit Korrelations-ID, Zertifikatsseriennummer und Ergebnis protokollieren – niemals mit privatem Schlüssel. Testen Sie richtige Signatur, falschen Kontext, abgelaufenes oder gesperrtes Zertifikat, manipulierten Hash und nicht erreichbaren Signaturdienst. KOD II muss CERTYFIKAT heißen und dem Empfänger die Prüfung von Identität und Authentizität ermöglichen. Messbare Freigabe: Jeder positive Test wird mit der erwarteten Identität verifiziert; sämtliche manipulierten oder unzulässigen Varianten scheitern, und kein Schlüsselmaterial erscheint in Logs, Artefakten oder Support-Exports. Security ist Key Custodian, Tax Operations verantwortet den korrekten Kontext, Engineering die Signatur-Nutzlast. Schlüsseltrennung, Vier-Augen-Freigabe und Ausfalltests sind empfohlene Sicherheitskontrollen, nicht eigenständige Offline24-Pflichten.

Leitfaden

End-to-End-Matrix mit realistischem Beleg ausführen

Bauen Sie eine Matrix aus Empfängerklasse, Bereitstellung vor oder nach KSeF, Zertifikatszustand, Umgebung, Übermittlungsergebnis und Darstellungsformat. Beispiel: Eine polnische Gesellschaft stellt am Freitag, 14. August, eine FA(3)-Rechnung an einen deutschen Kunden ohne polnische NIP aus, übergibt sie vor Einreichung als PDF und reiht das XML mit offlineMode:true ein. Erwartet werden vorab KOD I OFFLINE und KOD II CERTYFIKAT, beide auf Basis desselben eingefrorenen XML-Hashs. Nach Annahme und Zuteilung einer KSeF-Nummer darf eine spätere externe Visualisierung nur einen KOD I tragen, dessen Bezeichnung diese KSeF-Nummer ist – nicht erneut das Vorab-Paar. Ergänzen Sie Fälle für inländischen VAT-Käufer, Verbraucher, strukturierten Kanal ohne Grafik, Zertifikatsfehler und verspäteten Worker. Wenn ein Format keine Grafik transportieren kann, dürfen Link beziehungsweise Grafik und Beschriftung separat mit der Rechnung geliefert werden. Akzeptanzkriterium: erwartete Codeanzahl, Bezeichnung, Inhalt, Zustandswechsel und Empfängerweg stimmen in jedem Fall; Finance bestätigt die Darstellung, QA den maschinenlesbaren Inhalt. Das Testdesign ist empfohlen, die beschriebenen Codeinhalte und Zustände folgen den offiziellen Vorgaben.

Leitfaden

Warteschlange, Frist, Idempotenz und Abgleich absichern

Eine Offline24-Rechnung ist unverzüglich, spätestens am nächsten Arbeitstag nach Ausstellung, an KSeF zu senden, damit sie eine KSeF-Nummer erhält. Tritt vor der Einreichung ein amtlich bekannt gegebener KSeF-Ausfall ein, verschiebt sich die Frist auf sieben Arbeitstage nach dessen Ende; bei Totalausfall wird die Rechnung nicht nachträglich gesendet. Implementieren Sie einen polnischen Arbeitskalender, speichern Sie P_1, Fristgrund, nächsten Versuch und unveränderlichen Hash und setzen Sie in der API offlineMode:true. Empfohlen sind idempotente Queue-Schlüssel, exponentielle Wiederholungen, Dead-Letter-Überwachung und ein täglicher Abgleich von ERP-ID, Hash, KSeF-Status und zugeteilter Nummer. Testen Sie Freitag, Feiertagsfolge, Mitternacht, Zeitverschiebung, Timeout nach Annahme und doppelte Worker-Zustellung. Akzeptanzkriterium: kein Testbeleg wird doppelt eingereicht, 100 Prozent angenommener Belege werden ihrer KSeF-Nummer zugeordnet, und jeder offene Beleg alarmiert den Operations Owner vor der berechneten Frist. Ein häufiger Fehler ist, Offline24 nachträglich wie eine amtliche Störung umzudeklarieren. Der Queue Owner betreibt Wiederholungen; Finance entscheidet über fachliche Ausnahmen.

Leitfaden

Scan, Darstellung, Umgebung und Zugänglichkeit abnehmen

Prüfen Sie nicht nur die URL im Unit-Test, sondern die tatsächlich ausgelieferte Darstellung. Drucken und scannen Sie KOD I und KOD II auf den vorgesehenen Layouts, in Graustufen, bei niedriger Druckqualität sowie aus einem E-Mail-PDF und einem mobilen Bildschirm. Die Beschriftungen OFFLINE, CERTYFIKAT beziehungsweise nach Annahme die KSeF-Nummer müssen eindeutig dem richtigen Code zugeordnet sein. Messen Sie Mindestgröße, Ruhezone, Kontrast und Lesbarkeit nach Ihrer Rendering-Strecke; die QR-Grafik selbst folgt ISO/IEC 18004:2024. Für barrierearme Nutzung sollte zusätzlich ein anklickbarer beziehungsweise kopierbarer Verifikationslink mit verständlicher Bezeichnung angeboten werden, sofern der Kanal dies unterstützt. Automatisierte Gates müssen jede Kombination von Produktionsdaten mit Test- oder Demo-Host verhindern. Akzeptanzkriterium: mindestens zwei Gerätemodelle und zwei Scanner lesen alle freigegebenen Muster, kein Link wechselt die Umgebung, und ein Nutzer kann die beiden Prüfzwecke ohne interne KSeF-Kenntnis unterscheiden. UX verantwortet Layout und Beschriftung, QA die Scanmatrix, Platform Engineering die Host-Trennung. Gerätematrix und Zugänglichkeitskontrollen sind praktische Qualitätsmaßnahmen.

Leitfaden

Ablehnung, technische Korrektur und Wiederanlauf testen

Wird die Offline-Rechnung wegen eines technischen Validierungsfehlers abgelehnt, kann der dokumentierte Mechanismus der technischen Korrektur eine korrigierte technische Datei mit dem Hash des abgelehnten Originals verknüpfen. Das ist keine Erlaubnis, Geschäftsinhalt zu ändern. Trennen Sie daher Schema- oder Serialisierungsfehler von fachlichen Änderungen; Letztere gehören in den regulären Rechnungsprozess. Eine Korrekturrechnung zu einem Offline24-Original sollte erst erstellt werden, nachdem das Original eine KSeF-Nummer erhalten hat. Simulieren Sie ungültiges FA(3), falsche Signaturnutzlast, Timeout mit unklarem Annahmestatus, echte Ablehnung und Neustart nach Queue-Ausfall. Der Worker muss zuerst den Status klären, bevor er erneut sendet, und Hashbeziehungen revisionsfest protokollieren. Akzeptanzkriterium: technische Korrektur erhält unveränderte fachliche Werte, referenziert den dokumentierten Ursprung korrekt und erzeugt keine Dublette; die Anwendung blockiert fachliche Korrekturen bis zur KSeF-Nummer des Originals. Engineering besitzt die Fehlerklassifizierung, Finance genehmigt jede fachliche Abweichung, Support nutzt ein Runbook. Typische Fehler sind blindes Resenden und Überschreiben des Originalartefakts.

Leitfaden

Anbieter auswählen, Evidenz sichern und nächsten Schritt planen

Verlangen Sie von ERP-Connector- oder Offline24-Anbietern eine Live-Demonstration des vollständigen Zustandswechsels statt einer allgemeinen KSeF-Zusage. Muss-Kriterien sind FA(3), deterministischer XML-Hash, getrennte Umgebungen, korrekte KOD-I- und KOD-II-Nutzlast, Typ-2-Schlüsselintegration, offlineMode:true, idempotente Warteschlange, Fristenkalender, Ablehnungsbehandlung, Abgleich und Darstellung nach KSeF-Annahme. Lassen Sie einen manipulierten Hash, einen falschen Host, einen Signaturausfall und einen Timeout nach Annahme vorführen. No-Go sind Typ 1 für KOD II, exportierbare private Schlüssel, ein PDF-Hash als Rechnungsidentität oder immer zwei QR-Codes. Das Evidenzpaket sollte freigegebene Testmatrix, Golden Files und Hashs, maskierte QR-Inhalte, Scannergebnisse, Host-Konfiguration, Zertifikatsseriennummer, Queue- und Reconciliation-Protokolle, Fristfälle, RACI und offene Risiken enthalten. Als nächster Schritt empfiehlt sich ein begrenzter Pilot mit einer Gesellschaft und drei Empfängerklassen; Go gilt nur bei vollständig bestandenen kritischen Kriterien und benanntem Betriebs-Owner. Diese Auswahl- und Testempfehlungen sind praktische Orientierung und keine Rechts- oder Steuerberatung.

Checkliste

Offline24, amtlich bekannt gegebene Nichtverfügbarkeit, Ausfall und Totalausfall als getrennte ERP-Zustände konfigurieren.

Empfängerregeln für KSeF-Zustellung und den Vorabfall mit zwei QR-Codes durch Finance freigeben lassen.

FA(3)-XML vor der Codeerzeugung einfrieren und P_1, Verkäufer-NIP sowie Base64URL-SHA-256-Hash protokollieren.

KOD I aus der fest gebundenen Umgebungs-URL und den offiziellen Rechnungsparametern erzeugen und dekodieren.

KOD II ausschließlich mit aktivem Typ-2-Offline-Zertifikat signieren und privaten Schlüssel technisch abschirmen.

OFFLINE, CERTYFIKAT und die spätere KSeF-Nummer in allen vorgesehenen Darstellungsformaten korrekt beschriften.

Offline-Übertragungen mit offlineMode:true, Arbeitskalender, Fristwarnung und idempotentem Queue-Schlüssel ausführen.

Timeouts, Dubletten, technische Ablehnung, technische Korrektur und Neustart mit unveränderlichen Artefakten testen.

QR-Codes auf Druck, PDF und Mobilgerät scannen sowie jede Mischung von Test-, Demo- und Produktionshost blockieren.

ERP-, KSeF- und Queue-Status täglich abgleichen und Freigaben, Ergebnisse, Risiken und Owner im Evidenzpaket sichern.

Häufige Fragen

Wann braucht eine Offline24-Rechnung zwei QR-Codes?

Nicht jede Offline24-Rechnung benötigt das Paar. Es betrifft eine vor der KSeF-Einreichung außerhalb von KSeF bereitgestellte Rechnung an einen Käufer nach Art. 106gb(4), zum Beispiel einen ausländischen Käufer, Verbraucher oder Käufer ohne NIP. Ein inländischer umsatzsteuerpflichtiger Käufer empfängt die Rechnung normalerweise über KSeF.

Was prüfen KOD I und KOD II jeweils?

KOD I mit der Bezeichnung OFFLINE eröffnet den Zugang zur Rechnung beziehungsweise ermöglicht die Prüfung ihrer Daten. KOD II mit der Bezeichnung CERTYFIKAT bestätigt Identität des Ausstellers und Authentizität der Rechnung. Beide beziehen sich vor der Einreichung auf denselben Hash der strukturierten Rechnungsdatei.

Wie wird KOD II erzeugt und kann Typ 1 dafür verwendet werden?

KOD II enthält Kontextkennung, Verkäufer-NIP, Zertifikatsseriennummer, Rechnungshash und eine Signatur mit dem privaten Schlüssel eines aktiven Zertifikats Typ 2 Offline. Typ 1 Authentication ist für diesen Zweck ungeeignet und kann KOD II nicht erzeugen. Der Schlüssel sollte in einer kontrollierten Signaturkomponente verbleiben.

Welche Darstellung gilt nach erfolgreicher Übermittlung?

Nach Annahme der Offline-Rechnung und Zuteilung einer KSeF-Nummer trägt eine später außerhalb von KSeF verwendete Visualisierung einen KOD I, der mit dieser KSeF-Nummer bezeichnet ist. Das vorherige Paar aus OFFLINE und CERTYFIKAT wird nicht erneut verwendet. Die Visualisierung bleibt eine Darstellung, nicht die strukturierte FA(3)-Rechnung.

Bis wann muss eine Offline24-Rechnung eingereicht werden?

Sie ist ohne Verzögerung, spätestens am nächsten Arbeitstag nach Ausstellung, einzureichen. Beginnt vor der Einreichung ein amtlich bekannt gegebener KSeF-Ausfall, gilt stattdessen sieben Arbeitstage nach dessen Ende. Bei einem Totalausfall erfolgt keine nachträgliche Sendung; diese Fälle dürfen im ERP nicht mit frei gewähltem Offline24 vermischt werden.

Was sollte ein Queue- und Wiederanlauftest messen?

Messen Sie Queue-Alter, Fristreserve, Versuche, eindeutigen Belegschlüssel, Annahmestatus und Zuordnung der KSeF-Nummer. Ein Timeout nach möglicher Annahme muss zunächst per Statusprüfung geklärt werden, bevor erneut gesendet wird. Bestanden ist der Test erst ohne Dublette und mit vollständigem ERP-KSeF-Abgleich.

Darf eine technisch abgelehnte Datei inhaltlich geändert werden?

Der dokumentierte technische Korrekturmechanismus dient der Behebung technischer Validierungsfehler und kann den Hash des abgelehnten Originals referenzieren. Er erlaubt keine Änderung des Geschäftsinhalts. Solche Änderungen müssen fachlich eingeordnet werden; das abgelehnte Original und seine Hashbeziehung bleiben als Nachweis erhalten.

Wann darf eine Korrekturrechnung zum Offline24-Original entstehen?

Warten Sie, bis das Original von KSeF angenommen wurde und eine KSeF-Nummer besitzt. So kann die Korrektur eindeutig auf den registrierten Ausgangsbeleg Bezug nehmen. Das ERP sollte die Korrekturfunktion bis dahin sperren und statt manueller Umgehungen den offenen Übermittlungsstatus sichtbar machen.

Wichtige Regeln, Formate und Begriffe

Europäische KommissionEN 16931Richtlinie 2014/55/EUstrukturierte elektronische RechnungKSeF Offline24 QR-Codes und ERP-TestplanPolen

Weiterlesen

Offizielle Quellen

Wir priorisieren offizielle Regierungs- und EU-Quellen, soweit verfügbar, und zeigen Prüfdatumsangaben sichtbar an.