Polen · implementatietest voor Offline24

KSeF Offline24 QR-codes en ERP-testplan

Test KSeF Offline24 in het ERP: twee QR-codes, type 2-certificaat, factuurhash, wachtrij, termijnen en herstelbewijs.

Praktische samenvatting:
  • Afbakening: ontwerp één gecontroleerd pad voor uitgifte vóór en visualisatie na KSeF-acceptatie.
  • Hoofdrisico: een foutieve byte, contextwaarde of sleutel maakt een ogenschijnlijk correcte scan onbetrouwbaar.
  • Eerste stap: leg per koperscategorie vast wie de afleverroute en vereiste codestatus goedkeurt.
Laatst gecontroleerd: 4 augustus 2026Officiële bronnenDuidelijke samenvattingPraktische informatie, geen juridisch advies
Officiële bronnen eerst
Controledatums zichtbaar
Gratis checker zonder registratie

Wat u moet weten

Gids

1. Bepaal wanneer Offline24 en het tweecodegeval gelden

Officieel mag iedere belastingplichtige Offline24 kiezen, ook bij netwerk- of internetproblemen. Dat verschilt van officieel aangekondigde onbeschikbaarheid, storing/noodsituatie of totale storing van KSeF; houd die toestanden strikt gescheiden. Voor een binnenlandse btw-plichtige koper vindt ontvangst normaal via KSeF plaats. Twee codes zijn dus niet automatisch nodig op elke Offline24-factuur. Het tweecodegeval betreft een offline opgestelde factuur die vóór indiening buiten KSeF beschikbaar wordt gesteld aan een koper uit artikel 106gb, lid 4, bijvoorbeeld een buitenlandse koper, consument of koper zonder NIP. Maak als aanbevolen beheersmaatregel een beslisregel op basis van verkoopentiteit, koperstype, NIP-status, moment van beschikbaarstelling en indieningsstatus. Tax bepaalt de regels, Order-to-Cash beheert kopersdata en IT implementeert de route. Acceptatiecriterium: elk testsaldo levert precies één gedocumenteerde route op—direct via KSeF, Offline24 zonder voorafgaande externe visualisatie, of Offline24 met twee codes. Veelgemaakte fouten zijn twee codes standaard afdrukken, Offline24 als storingsmodus benoemen en een pdf-visualisatie behandelen als de gestructureerde factuur.

Gids

2. Borg FA(3), P_1 en deterministische XML-bytes

De officiële basis is de toepasselijke logische structuur: sinds 1 februari 2026 FA(3). De factuur wordt elektronisch uitgereikt en de uitgiftedatum staat in P_1. Voor Offline24 moet dezelfde factuurinhoud uiteindelijk naar KSeF; de verificatielinks steunen op een Base64URL-gecodeerde SHA-256-hash van het factuurbestand. Daarom moeten de bytes die worden gehasht exact overeenkomen met de bytes die later worden ingediend. Een opnieuw geserialiseerde XML met andere witruimte, tekenencoding, namespacevolgorde of regeleinden kan technisch dezelfde gegevens tonen maar een andere hash opleveren. Aanbevolen voorbereiding: laat de ERP-export één canoniek, onveranderbaar bytebestand produceren en sla daarvan bestandsgrootte, SHA-256, P_1, verkoper-NIP, schema-versie en generatieversie op. Integratie beheert serialisatie, Tax de FA(3)-mapping en QA de gouden testbestanden. Acceptatiecriterium: tien herhalingen met identieke invoer geven bit-voor-bit dezelfde XML en hash, terwijl één gecontroleerde bytewijziging een andere hash geeft. Blokkeer codegeneratie bij ontbrekende P_1, foutieve NIP, schemafout of mutatie na hashing. Deze aanbevolen test voorkomt dat de codes naar een ander bestand verwijzen dan het ingediende origineel.

Gids

3. Implementeer en verifieer KOD I (OFFLINE)

KOD I wordt lokaal opgebouwd uit de verificatiebasis-URL van de juiste omgeving, uitgiftedatum P_1, NIP van de verkoper en de Base64URL-SHA-256-hash van het factuurbestand. De zichtbare code krijgt het label OFFLINE. Deze code biedt toegang tot de factuurgegevens en ondersteunt gegevensverificatie; hij bewijst niet op zichzelf de identiteit van de uitgever. Gebruik exact de officiële parameteropbouw en codering uit de technische documentatie, niet een zelfbedacht URL-formaat. QA scant vanaf papier en scherm, vergelijkt P_1, NIP en hash met het opgeslagen uitgifteobject en controleert dat een veranderde hash niet als dezelfde factuur wordt geaccepteerd. Meetbaar criterium: 100% van minimaal twintig geldige testcodes opent de verwachte verificatiestroom en alle negatieve varianten met verkeerde datum, NIP, hash of host falen herkenbaar. Fouten zijn standaard Base64, een pdf-hash, de verzendtijd als P_1 of een productiehost in testsoftware.

Gids

4. Maak KOD II (CERTYFIKAT) uitsluitend met type 2

KOD II bevat het type en de waarde van de contextidentifier, het NIP van de verkoper, het serienummer van het certificaat, dezelfde factuurhash als KOD I en een cryptografische handtekening. Die handtekening moet worden gemaakt met de privésleutel van een actief KSeF Offline-certificaat type 2. Een type 1-authenticatiecertificaat kan KOD II niet genereren. Het label op de visualisatie is CERTYFIKAT; de code ondersteunt verificatie van uitgeversidentiteit en authenticiteit, naast de afzonderlijke gegevenscontrole via KOD I. Aanbevolen sleutelcontroles zijn opslag in een HSM, sleutelkluis of gelijkwaardig afgeschermd mechanisme, geen export naar werkstations, beperkte service-identiteit, logging van ondertekenacties en een geteste blokkade voor ingetrokken, verlopen of nog niet geldige certificaten. Security is eigenaar van sleutelbewaring; IAM van toegang; ERP-integratie van de payload. Acceptatiecriteria: een geldige ondertekening wordt geverifieerd met het bedoelde serienummer en de juiste context, terwijl een verkeerde sleutel, gewijzigde hash, afwijkend NIP, ander contexttype en type 1-certificaat allemaal hard falen.

Gids

5. Bouw een end-to-end ERP-testmatrix met realistische voorbeelden

Gebruik een scenario zoals verkoper PL1234567890 die op vrijdag 14 augustus een FA(3)-factuur uitgeeft aan een buitenlandse zakelijke koper zonder Pools NIP. Het ERP bevriest de XML, zet P_1 op 2026-08-14, berekent één hash, maakt KOD I en KOD II en levert een visualisatie buiten KSeF. Daarna gaat exact hetzelfde XML-bestand naar de Offline24-wachtrij met offlineMode:true. Controleer apart een binnenlandse btw-plichtige koper die normaal via KSeF ontvangt; daar mag de beslislogica niet zonder reden het tweecodepad kiezen. Test minstens buitenlandse koper, consument, binnenlandse NIP-koper, ontbrekend of verkeerd certificaat, fout P_1, gewijzigde XML, dubbele enqueue, API-fout, afwijzing en acceptatie. Leg per rij invoer, verwachte codes, route, eigenaar, termijn, status en bewijs vast. QA leidt, Tax keurt uitkomsten goed en Operations herstelt. Acceptatiecriterium: alle kritieke paden slagen en alle negatieve paden blokkeren vóór aflevering of escaleren naar een benoemde eigenaar.

Gids

6. Beheers wachtrij, termijn, idempotentie en reconciliatie

Officieel moet een Offline24-factuur zonder uitstel, uiterlijk op de eerstvolgende werkdag na uitgifte, naar KSeF worden gestuurd om een KSeF-nummer te krijgen. Als vóór indiening een officieel aangekondigde KSeF-storing optreedt, verschuift de termijn naar zeven werkdagen na het einde daarvan. Bij een totale storing wordt de factuur niet later alsnog verzonden. Modelleer die juridische toestanden afzonderlijk en laat de kalenderfunctie Poolse werkdagen verwerken; verzin geen uniforme ‘24 uur’-regel. Offline-indiening gebruikt volgens de officiële API-documentatie offlineMode:true. Bewaar in de wachtrij minstens factuur-ID, hash, P_1, termijn, idempotentiesleutel, fout en KSeF-nummer. Operations bezit de wachtrij, Finance de termijnen en integratie veilige retry. Acceptatiecriteria: een herhaalde verzending maakt geen tweede bedrijfsfactuur, elke vervallen of bijna vervallen post alarmeert een eigenaar, en dagelijkse reconciliatie verklaart elke uitgegeven offline factuur als wachtend, geaccepteerd, afgewezen of formeel uitgezonderd. Test ook feestdagen en procesherstart. Veelgemaakte fouten zijn een nieuwe XML genereren bij retry, technische ontvangst als KSeF-acceptatie registreren en de storingsdeadline toepassen zonder officiële aankondiging.

Gids

7. Accepteer scanbaarheid, rendering, omgeving en toegankelijkheid

QR-afbeeldingen volgen ISO/IEC 18004:2024. Test link, grootte, contrast, stille zone en robuustheid op print, scherm en mobiel. Als het gestructureerde afleverformaat geen afbeelding kan dragen, mogen link of afbeelding en label afzonderlijk met de factuur worden verstrekt. Dat maakt de visualisatie nog steeds niet tot het gestructureerde FA(3)-bestand. Houd productie, test en demo strikt gescheiden: productie gebruikt qr.ksef.mf.gov.pl; test en demo hebben eigen hosts. Blokkeer host-kruising met vaste omgevingsconfiguratie en een pipelinecontrole. QA bezit scanacceptatie, Platform de configuratie en UX de labels en links. Criterium: drie camera-apps lezen beide codes vanaf scherm en print; labels blijven bij 200% zoom zichtbaar en waar nodig staat er een klikbare tekstlink. Geen enkele niet-productiebouw mag naar de productiehost verwijzen. Voorkom afgesneden stille zones, verwisselde codes en test-QR’s in productie.

Gids

8. Test afwijzing, technisch herstel en correctievolgorde

Wanneer KSeF een offline factuur wegens een technische validatiefout afwijst, kan het gedocumenteerde mechanisme voor technische correctie een hersteld technisch bestand koppelen aan de hash van het afgewezen origineel. Dit is geen toestemming om bedrijfsinhoud—zoals koper, regels, prijs of btw—stilzwijgend te veranderen. Routeer inhoudelijke verschillen naar Finance/Tax en behandel ze volgens de toepasselijke factuurregels. Een correctiefactuur die betrekking heeft op een Offline24-origineel hoort te wachten totdat dat origineel een KSeF-nummer heeft. Bewaar afwijzingsantwoord, originele XML en hash; laat een bevoegde eigenaar het technische herstel goedkeuren; koppel de nieuwe versie aan de originele hash en dien idempotent opnieuw in. Acceptatiecriteria: zakelijke velden blijven gelijk, elke bytewijziging is verklaard, de audittrail toont goedkeurder en tijdstippen, en een correctiefactuur kan niet vóór het KSeF-nummer van het origineel vertrekken. Na acceptatie gebruikt een latere visualisatie buiten KSeF één KOD I met als label het toegekende KSeF-nummer, niet opnieuw het voorafgaande paar.

Gids

9. Kies leverancier, bewijs werking en plan vervolgstappen

Vraag een leverancier live te demonstreren dat de KSeF ERP-connector deterministische FA(3)-bytes bewaart, KOD I uit de juiste host en velden opbouwt, KOD II uitsluitend met type 2 ondertekent, offlineMode:true verzendt en na acceptatie naar de eencodevisualisatie met KSeF-nummer overschakelt. Beoordeel daarnaast omgevingsisolatie, sleutelbewaring, idempotente retries, Poolse werkdagen, technische-correctielinks, correctieblokkade, exporteerbare audittrail en reconciliatie. Wijs oplossingen af die de pdf hashen, type 1 accepteren of omgevingen niet hard scheiden. Bewaar beslisregels, testmatrix, gouden XML en hash, QR-payloads, scanresultaten, certificaatmetadata, wachtrijlogs, API-responsen, herstelbewijs, KSeF-nummer en reconciliatie. Benoem Tax voor inhoud, Security voor sleutels, IT voor de connector en Operations voor opvolging. Inventariseer nu kopersroutes, bouw een gouden factuur, test negatieve cryptografie en pilot met niet-productiedata. Laat Poolse fiscale of juridische interpretatie beoordelen door een bevoegde adviseur. Deze pagina biedt praktische implementatie-informatie, geen juridisch of fiscaal advies.

Checklist

Classificeer koper, aflevermoment en KSeF-status voordat het ERP één of twee codes kiest.

Bevries FA(3)-XML, P_1, verkoper-NIP en de Base64URL-SHA-256-hash als één uitgifteobject.

Genereer KOD I met de officiële URL-opbouw en het OFFLINE-label.

Onderteken KOD II alleen met een actief type 2 Offline-certificaat en afgeschermde privésleutel.

Blokkeer elke test-, demo- of productiehost die niet bij de actieve omgeving hoort.

Verzend exact dezelfde XML via de wachtrij met offlineMode:true en een idempotentiesleutel.

Bereken en alarmeer de juiste werkdagtermijn zonder gekozen Offline24 en officiële storing te vermengen.

Scan beide codes vanaf scherm en print en vergelijk hun gegevens met het bevroren uitgifteobject.

Bewijs bij technische correctie dat bedrijfsinhoud gelijk blijft en de originele hash gekoppeld is.

Vervang na acceptatie het voorafgaande codepaar door één KOD I met het toegekende KSeF-nummer als label.

Veelgestelde vragen

Wanneer zijn twee QR-codes nodig bij Offline24?

Niet op iedere Offline24-factuur. Het paar KOD I en KOD II is relevant wanneer de offline factuur vóór indiening buiten KSeF beschikbaar wordt gesteld aan een koper die onder artikel 106gb, lid 4, valt, zoals een buitenlandse koper, consument of koper zonder NIP. Een binnenlandse btw-plichtige koper ontvangt normaal via KSeF.

Wat verifiëren KOD I en KOD II afzonderlijk?

KOD I, met label OFFLINE, geeft toegang tot factuurgegevens en ondersteunt gegevensverificatie aan de hand van onder meer P_1, verkoper-NIP en bestandshash. KOD II, met label CERTYFIKAT, gebruikt een cryptografische handtekening om de identiteit en authenticiteit van de uitgever te verifiëren.

Hoe wordt KOD II technisch gemaakt?

De payload bevat het type en de waarde van de contextidentifier, verkoper-NIP, certificaatserienummer en dezelfde factuurhash als KOD I. Die payload wordt ondertekend met de privésleutel van een geldig Offline-certificaat type 2 volgens de officiële technische specificatie. Bewaar de sleutel afgeschermd en test gewijzigde payloads.

Kan een KSeF-certificaat type 1 KOD II ondertekenen?

Nee. Type 1 is bedoeld voor authenticatie en kan KOD II niet genereren. De ERP-flow moet een type 1-certificaat voor deze handeling hard afwijzen en duidelijk melden dat een actief type 2 Offline-certificaat met de bijbehorende privésleutel vereist is.

Welke code staat op een visualisatie nadat KSeF de factuur heeft aanvaard?

Na acceptatie en toekenning van een KSeF-nummer gebruikt een later buiten KSeF gedeelde visualisatie één KOD I, gelabeld met dat KSeF-nummer. Het voorafgaande paar OFFLINE en CERTYFIKAT hoort bij de fase vóór indiening en mag niet klakkeloos worden hergebruikt.

Welke indieningstermijn geldt voor een gekozen Offline24-factuur?

De factuur moet zonder uitstel en uiterlijk op de eerstvolgende werkdag na uitgifte naar KSeF. Begint vóór indiening een officieel aangekondigde storing, dan geldt zeven werkdagen na het einde ervan; bij een totale storing volgt geen latere indiening.

Wat moet een ERP-test voor wachtrij en technische afwijzing bewijzen?

Bewijs dat retries exact dezelfde bevroren XML gebruiken, dubbele verwerking voorkomen, termijnen bewaken en elke status reconciliëren. Technisch herstel moet naar de originele hash verwijzen, alleen het technische gebrek verhelpen en een audittrail behouden.

Mag een correctiefactuur al weg voordat het Offline24-origineel een KSeF-nummer heeft?

Nee, de correctiefactuur voor zo’n origineel hoort te wachten op het KSeF-nummer van de oorspronkelijke factuur. Test daarom een systeemblokkade, een zichtbare eigenaar en automatische vrijgave na reconciliatie, zodat een correctie niet losraakt van de geaccepteerde oorspronkelijke factuur.

Belangrijke regels, formaten en termen

Europese CommissieEN 16931Richtlijn 2014/55/EUgestructureerde elektronische factuurKSeF Offline24 QR-codes en ERP-testplanPolen

Lees verder

Officiële bronnen

We geven voorrang aan officiële overheids- en EU-bronnen waar beschikbaar en tonen controledatums zichtbaar.