E-Invoice Finder
Menu
Landen Software Deadlines Gidsen Checker Verplichting checken
ENFRDEPLNL
Polen · omschakeling KSeF-authenticatie

KSeF-token-naar-certificaatmigratie voor ERP en API

Migreer ERP- en API-integraties vóór 2027 van KSeF-tokens naar Authentication-certificaten met paralleltests, rechtencontrole en terugval.

Praktische samenvatting:
  • Deadline: accepteer geen productieplan dat na 31 december 2026 nog op een KSeF-token steunt.
  • Reikwijdte: migreer elke machinekoppeling afzonderlijk; portaaltoegang bewijst geen ERP-gereedheid.
  • Actie: maak de go/no-go afhankelijk van een ondertekend bewijsdossier en een geoefende noodprocedure.
Bekijk Polen-readinessrapportOfficiële bronnen
Laatst gecontroleerd: 3 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. Deadline en architectuurwijziging: twee routes, één eindpunt

Sinds 1 februari 2026 kunnen zowel KSeF-tokens als KSeF-certificaten worden gebruikt. Vanaf 1 januari 2027 blijven volgens het Poolse Ministerie van Financiën alleen KSeF-certificaten over. Er is geen officiële extra respijtperiode en bestaande tokens worden niet automatisch omgezet. Behandel dit daarom als een wijziging van authenticatiearchitectuur, niet als het vervangen van één geheim door een ander. Een KSeF-token bevat de rechten die bij het genereren zijn opgegeven. Een certificaat bewijst daarentegen identiteit; rechten worden in KSeF beheerd en tijdens de login server-side gecontroleerd. Het certificaat bevat geen bedrijfscontext. De authenticatieaanvraag noemt de context, waarna KSeF ten minste één actieve bevoegdheid verifieert. Maak een planning met vier fasen: inventarisatie en ontwerp, bouw en niet-productietests, gecontroleerde productierun en definitieve omschakeling. Deze fasering is een aanbevolen werkwijze, geen officieel voorgeschreven migratieprocedure.

Gids

2. Breng tokenafhankelijkheden en bestaande rechten in kaart

Inventariseer per Poolse entiteit elke ERP-instance, middleware, maatwerkservice, batchtaak, mobiele toepassing en externe leverancier die een KSeF-systeemtoken gebruikt. Zoek niet alleen in configuratiebeheer, maar ook in secret stores, CI/CD-variabelen, scripts, supportdocumentatie en noodprocedures. Noteer eigenaar, omgeving, context, endpoint, factuurstroom, volume, gebruiksvenster en gevolgen van uitval. Laat finance of de KSeF-rechtenbeheerder daarnaast een nulmeting maken van de actieve bevoegdheden die de technische identiteit werkelijk nodig heeft. Een certificaat neemt de in het oude token vastgelegde rechten niet over; KSeF moet passende actieve rechten vinden binnen de gekozen context. Koppel daarom elk proces aan minimale handelingen, zoals verzenden, status ophalen of inkoopfacturen lezen. Het bewijsdossier bevat een afhankelijkhedenregister, rechtenexport of schermbewijs, proceseigenaar en goedkeuring. Onbekende tokengebruikers en onverklaarde brede rechten zijn blokkerende risico’s voor de bouwfase.

Gids

3. Kies Type 1, schrijf het certificaat in en beveilig de privésleutel

Voor ERP- en API-authenticatie hebt u een Type 1 Authentication-certificaat nodig. Een Type 2 Offline-certificaat wordt afzonderlijk uitgegeven voor bevestiging van de identiteit van de uitgever en de integriteit van facturen in offline24-, systeemuitval- en noodmodi; het kan geen API-sessie authenticeren. Leg deze keuze expliciet vast in het technisch ontwerp en in de leveranciersopdracht. Houd er ook rekening mee dat gegevens voor certificaatinschrijving pas kunnen worden verkregen na XAdES-authenticatie, niet na authenticatie met een KSeF-token. Plan dus vooraf wie de bevoegde inschrijving uitvoert. Laat security of PKI-beheer het sleutelpaar genereren en de privésleutel bewaren in een passende secret store, HSM of beheerde sleutelvoorziening; plaats die nooit in broncode, tickets of gewone configuratiebestanden. Documenteer toegangscontrole, back-up, inzetomgevingen en incidentintrekking. Certificaatgeldigheid en rotatie verdienen een apart beheerproces, maar het directe migratiedoel is eerst één veilig uitgegeven Type 1-identiteit werkend krijgen.

Gids

4. Bouw XAdES-authenticatie én correct sessietokenbeheer

Beide API-routes beginnen met POST /auth/challenge. Bij certificaatauthenticatie maakt de connector vervolgens een AuthTokenRequest voor de juiste bedrijfscontext, ondertekent die met het Type 1-certificaat en dient de XAdES-handtekening in. De officiële toelichting vermeldt dat commerciële software XAdES-BES moet ondersteunen. Na succesvolle verificatie ontvangt de integratie tijdelijke authenticatie-, access- en refresh-tokens voor de sessie. Het langlevende certificaat vervangt die JWT’s dus niet: de applicatie moet uitgifte, verversing, verval en veilige opslag correct afhandelen. De oude tokenroute versleutelt juist het KSeF-systeemtoken en stuurt dit naar POST /auth/ksef-token. Houd deze twee implementaties en hun geheimtypen in code, logging en documentatie scherp gescheiden. Een realistisch voorbeeld: een ERP verzendt verkoopfacturen via middleware; de middleware haalt een challenge op, ondertekent het contextverzoek met de afgeschermde privésleutel, vernieuwt access-tokens zonder factuurbatchverlies en schrijft alleen correlatie-ID’s, nooit sleutel- of tokenwaarden, naar de logs.

Gids

5. Testmatrix, acceptatiecriteria en aantoonbaar bewijs

Test eerst buiten productie met dezelfde componentversies, rollen en netwerkroutes als voor livegang. De matrix omvat minimaal: geldige authenticatie, verkeerde context, ontbrekende of ingetrokken bevoegdheid, ongeldig of ingetrokken certificaat, onjuiste XAdES-handtekening, verlopen access-token, refresh-tokenvernieuwing, challenge-hergebruik, time-out, KSeF-fout en hervatting zonder dubbele factuur. Voeg functionele scenario’s toe voor verzenden, status ophalen, officieel KSeF-nummer terugschrijven en ontvangen wanneer dat binnen de koppeling valt. Laat finance aantallen en statussen aansluiten, IT de sessielogica beoordelen, security sleutelgebruik controleren en de integratieleverancier foutcodes verklaren. Bewaar per test datum, versie, context, invoer, verwacht resultaat, werkelijk resultaat, logreferentie en ondertekenaar. Go/no-go vereist nul kritieke defecten, geen onverklaarde rechtenfouten, geslaagde tokenverversing en aantoonbare idempotentie. Een succesvolle login alleen is onvoldoende bewijs dat de factuurketen bestand is tegen storingen.

Gids

6. Parallelle route, productiecanary en gerichte monitoring

Implementeer tijdelijk beide authenticatiepaden achter een beheerde feature flag, zonder dezelfde factuur gelijktijdig via twee sessies te versturen. Laat eerst alleen synthetische controles of veilige leeshandelingen over de certificaatroute lopen. Start daarna een productiecanary met één Poolse entiteit, één connectorinstance of een klein, herkenbaar factuursegment. Een groothandel kan bijvoorbeeld 5% van de verkoopbatches via het certificaat authenticeren, terwijl de resterende batches nog vóór de einddatum via het bestaande KSeF-token lopen. Vergelijk authenticatiesucces, autorisatiefouten, challenge- en XAdES-fouten, refresh-resultaten, verwerkingstijd, wachtrijlengte, dubbele-detectie en aansluiting van KSeF-nummers. Stel waarschuwingen en dagelijkse reconciliatie in en wijs IT Operations als uitvoerder, finance als procescontroleur, security als sleuteltoezichthouder en de product owner als beslisser aan. De duur van parallel draaien volgt uit volume en risicobewijs; KSeF schrijft geen vaste parallelperiode voor.

Gids

7. Cutover en terugval: beslis op meetbare signalen

Plan een change freeze rond de omschakeling en leg het exacte beslismoment, de aanwezige eigenaren en de communicatiekanalen vast. Ga alleen door wanneer de canary representatief was, authenticatie en refresh stabiel zijn, rechten per context kloppen, facturen en KSeF-nummers aansluiten, monitoring actief is en de noodprocedure is geoefend. Schakel vervolgens gefaseerd meer verkeer om en verifieer na elke stap de wachtrij, foutpercentages en boekhoudkundige totalen. Een terugval naar het oude KSeF-token is uitsluitend een tijdelijke herstelmaatregel vóór 1 januari 2027 en alleen als dat token nog geldig, veilig en operationeel ondersteund is. Definieer vooraf drempels, bijvoorbeeld herhaalde authenticatiefouten, oplopende onverwerkte batches of ontbrekende terugschrijvingen. Pauzeer bij twijfel liever de verwerking dan dubbel te verzenden. Na 31 december 2026 is de tokenroute geen geloofwaardige rollback; ontwerp dan herstel binnen de certificaatroute, inclusief sleutelfailover, rechtenherstel en wachtrijhervatting.

Gids

8. Verwijder oude tokengeheimen en vermijd bekende fouten

Trek het KSeF-systeemtoken pas in nadat de volledige productiestroom gedurende de afgesproken observatieperiode aantoonbaar op het certificaat werkt en de product owner, finance, IT en security hebben afgetekend. Verwijder daarna het token uit KSeF, secret stores, omgevingsvariabelen, deploymenttemplates, scripts, lokale bestanden, back-ups volgens beleid en leverancierskluizen. Zoek aanvullend op token-ID’s of herkenbare variabelen en bewaar bewijs van intrekking en opschoning. Veelgemaakte fouten zijn Type 2 Offline gebruiken voor API-login, aannemen dat het certificaat rechten bevat, een certificaat als permanent access-token behandelen, KSeF-systeemtokens verwarren met tijdelijke JWT access- of refresh-tokens en bedrijfscontext hard coderen. Ook riskant zijn privésleutels in applicatielogs, alleen het ideale pad testen en oude secrets onbeperkt laten staan ‘voor het geval dat’. Geef geen automatische retry op elke fout: onderscheid verversbare sessiefouten, rechtenproblemen en mogelijk dubbele verzending.

Gids

9. Softwarekeuze, readinessaudit en concrete vervolgstappen

Vraag een KSeF ERP-connector of API-upgrade niet alleen of deze ‘certificaten ondersteunt’. Eis een demo van Type 1-authenticatie vanaf /auth/challenge, een geldige XAdES-BES AuthTokenRequest, contextselectie, tijdelijke access- en refresh-tokens, rechtenfouten, veilige sleutelopslag, idempotente hervatting en bruikbare monitoring. Beoordeel ook releaseplanning, ondersteunde KSeF-API-versie, incident-SLA, auditlogs, exporteerbaarheid en verantwoordelijkheid bij een certificaat- of rechtenincident. Laat de leverancier de testresultaten koppelen aan uw exacte versie en architectuur. De eerstvolgende actie is een korte readinessaudit: rond in week één inventaris en rechtenbaseline af, in week twee ontwerp en sleutelbeheer, daarna bouw plus niet-productietests, gevolgd door canary, go/no-go en gecontroleerde opschoning. Versnel of verleng op basis van bewijs, niet op basis van een verzonnen officiële doorlooptijd. Deze pagina biedt praktische informatie en is geen juridisch, fiscaal of beveiligingsadvies; laat specialistische keuzes passend bij uw organisatie beoordelen.

Checklist

Registreer per entiteit, omgeving en connector waar een KSeF-systeemtoken wordt gebruikt en wie eigenaar is.

Leg de minimaal benodigde KSeF-rechten per proces vast en laat finance de actuele baseline goedkeuren.

Selecteer uitsluitend een Type 1 Authentication-certificaat voor ERP- en API-sessies.

Wijs een bevoegde inschrijver aan en regel XAdES-authenticatie voor het ophalen van enrollmentgegevens.

Genereer en bewaar de privésleutel in een gecontroleerde sleutel- of secretvoorziening met beperkte toegang.

Implementeer /auth/challenge, de XAdES-BES AuthTokenRequest en correct access- en refresh-tokenbeheer.

Voer de fout-, rechten-, verversings-, hervattings- en duplicaattests uit en archiveer ondertekend bewijs.

Draai een beperkte productiecanary met waarschuwingen, reconciliatie en vooraf bepaalde stopcriteria.

Laat product owner, finance, IT en security gezamenlijk de cutover of tijdelijke terugval besluiten.

Trek het oude token na bewezen omschakeling in en verwijder alle kopieën uit configuraties en leverancierskluizen.

Veelgestelde vragen

Wanneer stopt KSeF met systeemtokens?

KSeF ondersteunt tokens en certificaten sinds 1 februari 2026 naast elkaar. Volgens het Poolse Ministerie van Financiën kunnen vanaf 1 januari 2027 alleen KSeF-certificaten worden gebruikt. Plan de technische omschakeling en bewijsperiode ruim vóór die datum; er is geen officiële migratiereserve na de jaarwisseling waarop een productieplan veilig kan steunen.

Kan ik een bestaand KSeF-token automatisch omzetten in een certificaat?

Nee. Een token en certificaat hebben een andere functie en authenticatiestroom. Het token bevat bij generatie opgegeven bevoegdheden, terwijl het certificaat identiteit bevestigt en KSeF bevoegdheden server-side controleert. Schrijf een certificaat in, bouw de certificaatroute, controleer de rechten binnen de gekozen context en test die end-to-end.

Welk KSeF-certificaattype heeft een ERP-connector nodig?

Gebruik Type 1 Authentication voor ERP- of API-authenticatie. Type 2 Offline dient afzonderlijk voor de identiteit van de uitgever en factuurintegriteit in offline24-, systeemuitval- en noodmodi. Een Type 2-certificaat kan geen API-sessie starten en is daarom geen alternatief voor Type 1 in uw connector.

Bevat een KSeF-certificaat de rechten van ons oude token?

Nee. Een KSeF-certificaat bevat geen bedrijfscontext of ingebouwde set KSeF-rechten. De login identificeert de context en KSeF controleert of ten minste één passende actieve bevoegdheid bestaat. Maak vóór testen een rechtenbaseline en behandel onvoldoende of te ruime bevoegdheden als een afzonderlijk beheerpunt.

Vervangt het certificaat de access- en refresh-tokens van de API-sessie?

Nee. Het Type 1-certificaat ondertekent de AuthTokenRequest waarmee de identiteit wordt geverifieerd. Daarna werkt de sessie met tijdelijke authenticatie-, access- en refresh-tokens. Uw software moet die tijdelijke JWT’s veilig bewaren, tijdig vernieuwen en correct laten vervallen; noem ze niet simpelweg KSeF-tokens, want dat veroorzaakt gevaarlijke verwarring.

Hoe testen we zonder factuuruitval of dubbele verzending?

Scheid authenticatie van factuurroutering met een feature flag en begin buiten productie. Gebruik daarna één beperkte canary en stuur iedere factuur via precies één pad. Test idempotentie, time-outs, tokenverversing en wachtrijhervatting, en reconcilieer bronfacturen, statussen en KSeF-nummers voordat u het verkeerspercentage verhoogt.

Wanneer mogen we het oude KSeF-token verwijderen?

Pas nadat alle relevante productiestromen via Type 1 werken, de observatiecriteria zijn gehaald, reconciliatie sluit en de verantwoordelijke teams hebben afgetekend. Trek het token vervolgens in KSeF in en verwijder kopieën uit alle secret stores, scripts en leveranciersomgevingen. Bewaar controleerbaar bewijs van deze opschoning.

Waarop selecteren we een KSeF ERP-connector of API-upgrade?

Laat de leverancier voor uw exacte versie XAdES-BES, Type 1, contextselectie, rechtenfouten, access- en refresh-tokenbeheer, sleutelbescherming, retries zonder duplicaten en monitoring demonstreren. Vraag daarnaast naar API-versieonderhoud, incident-SLA, logs en testbewijs. Een algemene certificaatclaim of alleen een geslaagde login is onvoldoende voor een koopbesluit.

Belangrijke regels, formaten en termen

Europese CommissieEN 16931Richtlijn 2014/55/EUgestructureerde elektronische factuurMigratie van KSeF-token naar certificaat voor ERP- en API-integratiesPolen

Lees verder

Officiële bronnen

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