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

KSeF-Token-zu-Zertifikat-Migration für ERP und API

Stellen Sie ERP- und API-Integrationen vor 2027 von KSeF-Token auf Authentication-Zertifikate um – mit Paralleltests, Rechteprüfung und Rollback.

Kurzfazit:
  • • Stichtag: Der Altzugang gehört spätestens zum Jahreswechsel aus der Betriebsarchitektur.
  • • Umfang: Identität, Kontextrechte und Sitzungslogik sind getrennte Prüfpunkte.
  • • Aktion: Erst belastbare Produktionsbelege rechtfertigen die Stilllegung des bisherigen Secrets.
Polen-Readiness-BerichtOffizielle Quellen
Zuletzt geprüft: 3. August 2026Offizielle QuellenKlare ZusammenfassungPraktische Information, keine Rechtsberatung
Offizielle Quellen priorisiert
Prüfdatum sichtbar
Kostenloser Check ohne Registrierung

Was Sie wissen müssen

Leitfaden

Frist und Architekturwechsel richtig einordnen

Seit dem 1. Februar 2026 können KSeF-Systemtoken und KSeF-Zertifikate für die Authentifizierung verwendet werden; ab dem 1. Januar 2027 bleiben laut polnischem Finanzministerium nur KSeF-Zertifikate. Planen Sie daher keinen Betriebspuffer über diesen Termin hinaus ein. Der Wechsel ist keine automatische Umwandlung eines Tokens. Ein KSeF-Token enthält die bei seiner Erzeugung deklarierten Berechtigungen. Das Zertifikat weist dagegen eine Identität nach; die Rechte werden in KSeF serverseitig verwaltet und bei der Anmeldung geprüft. Auch der technische Pfad ändert sich: Die tokenbasierte Route übermittelt einen verschlüsselten KSeF-Token an POST /auth/ksef-token, während die Zertifikatsroute mit POST /auth/challenge beginnt und einen XAdES-signierten AuthTokenRequest verwendet. Teilen Sie das Vorhaben in vier Phasen: Bestandsaufnahme und Rechte-Baseline, Implementierung samt Nichtproduktionstests, kontrollierter Produktions-Canary und endgültiger Cutover. Das ist eine empfohlene Projektstruktur, keine amtlich vorgeschriebene Übergangsfolge oder Laufzeit. Ziel ist eine nachweisbar funktionsfähige Zertifikatsroute mit klarer Betriebsverantwortung vor Abschaltung des alten Pfads.

Leitfaden

Token-Abhängigkeiten erfassen und Rechte-Baseline sichern

Beginnen Sie nicht beim Zertifikat, sondern bei allen Verbrauchern des bisherigen Secrets. Der Integrationsverantwortliche sollte pro polnischer Gesellschaft dokumentieren, welches ERP, welche Middleware, welcher Batchjob und welcher externe Dienstleister den KSeF-Token liest, aus welchem Secret Store er stammt, in welchem Kontext die Anmeldung erfolgt und welche Aktionen tatsächlich benötigt werden. Beziehen Sie Versand, Abruf, Statusabfragen, Korrekturen, Hintergrundjobs und Notfallwerkzeuge ein. Finance und der KSeF-Berechtigungsadministrator bestätigen anschließend die fachliche Soll-Berechtigung; IT exportiert Konfiguration, Deployment-Version und letzte erfolgreiche Transaktionen als Ausgangsnachweis. Diese Baseline ist wichtig, weil das Zertifikat selbst keine Unternehmens- oder Gesellschaftszuordnung und keine Berechtigungen trägt. Der Authentifizierungsantrag benennt den Kontext, und KSeF prüft dort mindestens eine aktive Berechtigung. Ein realistisches Beispiel: SAP erzeugt Rechnungen für zwei polnische NIP-Kontexte, eine Integrationsplattform sendet sie und ein separater Nachtjob holt Eingangsrechnungen. Drei Aufrufer können denselben Alt-Token nutzen, aber unterschiedliche Rechte und Fehlerbilder haben. Ohne Abhängigkeitskarte würde ein erfolgreicher Sendetest den unbemerkten Ausfall des Abrufjobs nicht zeigen.

Leitfaden

Typ 1 auswählen, registrieren und privaten Schlüssel schützen

Für die ERP- oder API-Anmeldung benötigen Sie ein KSeF-Zertifikat Typ 1 Authentication. Typ 2 Offline wird separat ausgestellt und dient dazu, Ausstelleridentität und Rechnungsintegrität in offline24-, Systemausfall- und Notfallverfahren zu bestätigen; damit lässt sich keine API-Sitzung authentifizieren. Bestimmen Sie einen Zertifikatsinhaber, einen KSeF-Berechtigungsadministrator und einen technischen Custodian für den privaten Schlüssel. Die Registrierungsdaten für ein Zertifikat können erst nach einer XAdES-Authentifizierung abgerufen werden, nicht nach Anmeldung mit einem KSeF-Token; dieser Vorlauf gehört deshalb ausdrücklich in den Plan. Erzeugen und speichern Sie den privaten Schlüssel in der für Ihre Risikoklasse freigegebenen Schlüsselverwaltung, begrenzen Sie Lese- und Signaturzugriffe auf den Integrationsdienst und protokollieren Sie Ausgabe und Nutzung. Legen Sie keine Schlüsseldatei in Quellcode, Container-Image, Ticket oder gemeinsam genutztes Laufwerk. Als Freigabenachweise eignen sich Zertifikatstyp und Kennung, dokumentierter Inhaber, genehmigte Zugriffsgruppe, Wiederherstellungs- beziehungsweise Ersatzverfahren und ein erfolgreicher Signaturtest. Fragen zu Inventar, Ablaufwarnung und späterer Rotation sollten in einem eigenen Betriebsprozess behandelt werden; der aktuelle Cutover darf sich darauf nicht reduzieren.

Leitfaden

XAdES-Anmeldung und Sitzungstoken korrekt implementieren

Die Zielimplementierung fordert zunächst über POST /auth/challenge eine Challenge an, erstellt den AuthTokenRequest mit dem richtigen KSeF-Kontext und signiert ihn mit dem Typ-1-Zertifikat im geforderten XAdES-Verfahren. Die offizielle Übersicht nennt für kommerzielle Software XAdES-BES-Unterstützung. Nach Annahme der Anmeldung erhält der Client temporäre Authentifizierungs-, Zugriffs- und Refresh-Token und verwendet diese gemäß API-Dokumentation für die Sitzung. Das langlebigere KSeF-Zertifikat ersetzt also nicht den JWT-accessToken im laufenden API-Verkehr. Benennen und speichern Sie KSeF-Systemtoken und temporäre JWTs in Code, Logs und Dashboards getrennt, damit Betreiber sie nicht verwechseln. Implementieren Sie Ablaufprüfung, Refresh, sichere Wiederanmeldung, idempotente Wiederholungen und eine Sperre gegen endlose Authentifizierungsschleifen. Im SAP-Beispiel signiert nur der Connector den AuthTokenRequest; Worker erhalten ausschließlich kurzlebige Sitzungstoken und niemals den privaten Schlüssel. Prüfen Sie außerdem, ob verwendete XML- und Signaturbibliotheken Canonicalization, Zeitangaben und Zertifikatskette so erzeugen, wie KSeF sie erwartet. Code-Review, Architekturdiagramm, Bibliotheksversionen, maskierte Request-Traces und Tests für abgelaufene JWTs bilden die technische Evidenz.

Leitfaden

Testmatrix und belastbare Nachweise aufbauen

Die Testleitung erstellt eine Matrix aus Identität, NIP-Kontext, Berechtigung, API-Funktion und Fehlerfall. Positive Tests umfassen Challenge, XAdES-Signatur, Sitzungsaufbau, Rechnungssendung, Statusabfrage, Abruf und Refresh. Negative Tests provozieren einen falschen Kontext, fehlende Berechtigung, manipulierte Signatur, abgelaufenen accessToken, nicht verfügbaren Signaturdienst und Netzwerkunterbrechung. Ergänzen Sie fachliche Fälle wie Standardrechnung, Korrektur, hohes Volumen und erneute Verarbeitung nach Timeout. Jeder Fall braucht erwartetes Ergebnis, tatsächlichen Statuscode, KSeF-Kennung oder Korrelations-ID, Zeitstempel, Systemversion, verantwortliche Person und Link zum maskierten Protokoll. Finance bestätigt, dass erfolgreiche Übertragungen und Abrufe im ERP richtig verbucht beziehungsweise zugeordnet werden; IT bestätigt Authentifizierung und Wiederanlauf. Ein Test gilt nicht als bestanden, wenn lediglich ein HTTP-Erfolg sichtbar ist, aber Statusrücklauf, Dublettenvermeidung oder Buchungszuordnung fehlen. Offene Abweichungen erhalten Risikostufe, Owner und Behebungsdatum.

Leitfaden

Parallelbetrieb, Canary und Monitoring steuern

Implementieren Sie beide Authentifizierungspfade hinter einer konfigurierbaren Auswahl, ohne denselben Beleg doppelt zu senden. Eine sinnvolle Canary-Einheit ist beispielsweise eine Gesellschaft, ein definierter Mandant oder ein kleiner kontrollierter Jobtyp; wählen Sie sie nach Geschäftsauswirkung und Beobachtbarkeit, nicht nach einer vermeintlich amtlichen Mindestdauer. Vergleichen Sie während des Parallelfensters Erfolgsquote und Latenz der Anmeldung, Signaturfehler, Berechtigungsablehnungen, Token-Refresh, Sendestatus, Abrufvollständigkeit und Queue-Alter. Ein Dashboard sollte Zertifikatsroute und Alt-Tokenroute eindeutig kennzeichnen, während Alarmierungen den On-Call-Owner und Finance Operations erreichen. Für das SAP-Szenario kann zunächst der Nachtabruf einer Testgesellschaft über das Zertifikat laufen, danach ein begrenztes Ausgangsrechnungsvolumen; die übrigen Jobs bleiben bis zur Freigabe unverändert. Vermeiden Sie einen ungeplanten Methodenwechsel innerhalb derselben Transaktion. Halten Sie Deployment-ID, Feature-Flag, Canary-Umfang, Kennzahlen vor und nach Umschaltung sowie die tägliche Freigabeentscheidung fest. So entsteht ein prüfbarer Nachweis, dass nicht nur die Anmeldung, sondern der gesamte Rechnungsfluss unter realer Last stabil arbeitet.

Leitfaden

Cutover und Rollback anhand klarer Kriterien entscheiden

Legen Sie vor dem Produktionswechsel ein Go/No-Go-Meeting mit Integration Owner, Finance Process Owner, KSeF-Administrator, Security-Verantwortlichem und Supportleitung fest. Go setzt voraus: alle kritischen Testfälle bestanden, aktive Rechte je Kontext bestätigt, keine ungeklärten Signatur- oder Refresh-Fehler, Canary über das vereinbarte Volumen stabil, Monitoring und Bereitschaft besetzt sowie vollständige Evidenz abgelegt. Frieren Sie während des Cutovers Änderungen an Connector, Berechtigungen und Schlüsselkonfiguration ein. Schalten Sie Jobgruppen in einer festgelegten Reihenfolge um und prüfen Sie nach jedem Schritt Anmeldung, erste Rechnung, Statusrücklauf, Abruf und Queue. Definieren Sie messbare Abbruchkriterien, etwa wiederholte Authentifizierungsfehler, fehlende Eingangsrechnungen oder wachsende unbehandelte Queues. Vor dem 1. Januar 2027 kann die Rückkehr zum KSeF-Systemtoken als zeitlich begrenzter technischer Rollback dienen, sofern der Token noch unterstützt wird und sicher verfügbar ist. Danach darf er nicht als Fallback eingeplant werden. Ein Rollback korrigiert zudem keine falschen serverseitigen Rechte. Protokollieren Sie Entscheidung, Zeitpunkt, Owner, betroffene Transaktionen und Nachtest; planen Sie anschließend einen neuen Cutover statt eines unbefristeten Altbetriebs.

Leitfaden

Alte Token-Secrets stilllegen und typische Fehler vermeiden

Entfernen Sie den bisherigen KSeF-Systemtoken erst, wenn das vereinbarte Beobachtungsfenster abgeschlossen ist, alle produktiven Aufrufer auf der Zertifikatsroute nachgewiesen sind und keine Rollback-Freigabe mehr besteht. Der Service Owner widerruft beziehungsweise entfernt den alten Token nach dem vorgesehenen KSeF- und Secret-Management-Verfahren; Plattformteams löschen Kopien aus Vault, CI/CD-Variablen, lokalen Konfigurationen und Runbooks. Suchen Sie zusätzlich nach historischen Klartextwerten in zulässigen Secret-Scanning-Prozessen und dokumentieren Sie Widerruf, Löschung und Zugriffsprüfung. Häufige Fehler sind die Annahme einer automatischen Token-Konvertierung, die Wahl von Typ 2 für API-Logins, das Einbetten vermeintlicher Rechte ins Zertifikat, das Verwechseln des KSeF-Systemtokens mit accessToken oder refreshToken sowie das Löschen des Alt-Secrets nach nur einem Happy-Path-Test. Ebenso riskant sind unmaskierte JWTs in Logs und ein Rollback ohne Enddatum. Die Stilllegung ist abgeschlossen, wenn Inventar und Deployments keinen Verbraucher mehr zeigen, die alte Anmeldung nicht mehr möglich ist, Alarme sauber bleiben und Finance die Vollständigkeit der Rechnungsflüsse bestätigt. Bewahren Sie nur die erforderlichen Nachweise auf, nicht die geheimen Werte selbst.

Leitfaden

Software auswählen und die nächsten Schritte festlegen

Bewerten Sie Connector, ERP-Upgrade oder Dienstleister anhand einer Live-Demonstration statt einer allgemeinen KSeF-Zusage. Muss-Kriterien sind Typ-1-Zertifikatsauthentifizierung, vollständige XAdES-BES-Verarbeitung, Unterstützung von Challenge und AuthTokenRequest, saubere Verwaltung temporärer accessToken und refreshToken, konfigurierbarer Kontext, Secret- beziehungsweise Key-Management-Anbindung, getrennte Test- und Produktionskonfiguration, Audit-Trail, Monitoring sowie kontrollierter Rollback vor Fristende. Fordern Sie die Vorführung eines abgelaufenen JWT, einer fehlenden Berechtigung und eines Signaturdienst-Ausfalls. Ein Angebot ist No-Go, wenn Typ 2 als API-Zertifikat verkauft wird, Rechte im Zertifikat versprochen werden, der private Schlüssel exportiert oder breit geteilt werden muss oder der Anbieter keine temporären Sitzungstoken erklären kann. Starten Sie anschließend mit einem zweiwöchigen Discovery-Paket: Abhängigkeitskarte, Rechte-Baseline, Zielarchitektur, Testmatrix, RACI, Terminplan und Aufwandsschätzung. Daraus folgt eine belastbare Build-or-Buy- und Cutover-Entscheidung. Diese praktische Orientierung ersetzt keine Rechts-, Steuer- oder individuelle Sicherheitsberatung.

Checkliste

Alle ERP-, Middleware-, Batch- und Dienstleisterzugriffe auf den bisherigen KSeF-Systemtoken mit Owner und NIP-Kontext inventarisieren.

Benötigte KSeF-Berechtigungen je Funktion serverseitig erfassen und von Finance sowie Berechtigungsadministrator freigeben lassen.

Ein KSeF-Zertifikat Typ 1 Authentication registrieren und Zertifikatskennung, Inhaber sowie Ausstellungsnachweis dokumentieren.

Den privaten Schlüssel in die freigegebene Schlüsselverwaltung übernehmen und Signaturzugriffe technisch begrenzen.

Challenge, XAdES-signierten AuthTokenRequest und Verwaltung temporärer Authentifizierungs-, Zugriffs- und Refresh-Token implementieren.

Positive und negative Tests je Kontext durchführen und Statuscodes, Korrelations-IDs, Versionen sowie fachliche Ergebnisse sichern.

Einen abgegrenzten Produktions-Canary ohne doppelte Rechnungsübermittlung starten und die vereinbarten Kennzahlen überwachen.

Go/No-Go-, Abbruch- und zeitlich begrenzte Rollback-Kriterien mit allen operativen Ownern schriftlich freigeben.

Produktive Jobgruppen in festgelegter Reihenfolge umschalten und nach jedem Schritt Sendung, Status, Abruf und Queue prüfen.

Nach erfolgreichem Beobachtungsfenster alte Token-Zugänge widerrufen, Secret-Kopien entfernen und die Stilllegung belegen.

Häufige Fragen

Ab wann funktionieren KSeF-Systemtoken nicht mehr?

Nach Angaben des polnischen Finanzministeriums können Token und Zertifikate seit dem 1. Februar 2026 parallel genutzt werden. Ab dem 1. Januar 2027 bleiben nur KSeF-Zertifikate. Für den Alt-Token sollte deshalb weder eine nachgelagerte Schonfrist noch ein dauerhafter Notfallpfad angenommen werden. Schließen Sie Entwicklung, Produktionstest und Entfernung der Abhängigkeiten mit ausreichend internem Vorlauf ab.

Kann ein bestehender KSeF-Token in ein Zertifikat umgewandelt werden?

Nein, es handelt sich nicht um eine automatische Konvertierung gleichartiger Zugangsdaten. Der Token enthält die bei Erzeugung deklarierten Rechte; ein KSeF-Zertifikat bestätigt eine Identität, während Berechtigungen separat in KSeF verwaltet werden. Sie registrieren das passende Zertifikat, implementieren den Zertifikats-Anmeldepfad und prüfen die aktiven Rechte im gewählten Kontext neu.

Welcher Zertifikatstyp ist für eine ERP- oder API-Integration erforderlich?

Verwenden Sie Typ 1 Authentication für die API-Authentifizierung. Typ 2 Offline wird separat für die Bestätigung von Ausstelleridentität und Rechnungsintegrität in offline24-, Systemunverfügbarkeits- und Notfallmodi ausgegeben. Er kann keine API-Sitzung authentifizieren und ist daher kein Ersatz für Typ 1 im Connector.

Enthält das KSeF-Zertifikat die Rechte unserer Gesellschaft?

Nein. Das Zertifikat enthält keinen Unternehmenskontext und keine eingebetteten KSeF-Berechtigungen. Der Authentifizierungsantrag gibt den Kontext an; KSeF prüft dort die serverseitig aktiven Rechte. Deshalb gehören eine Rechte-Baseline pro NIP-Kontext und Tests für erlaubte wie abgelehnte Funktionen zwingend in die Migration.

Wie läuft die Zertifikatsauthentifizierung technisch ab?

Der Client startet mit POST /auth/challenge und reicht anschließend einen mit dem Typ-1-Zertifikat XAdES-signierten AuthTokenRequest ein. Danach werden temporäre Authentifizierungs-, Zugriffs- und Refresh-Token für die Sitzung ausgegeben. Das Zertifikat dient also dem Identitätsnachweis beim Sitzungsaufbau; der accessToken bleibt das kurzlebige Mittel für nachfolgende API-Aufrufe.

Wie testen wir den Wechsel ohne Rechnungsausfall oder Dubletten?

Bauen Sie beide Anmeldepfade konfigurierbar, wählen Sie aber pro Job oder Transaktion genau einen davon. Testen Sie zunächst in Nichtproduktion und nutzen Sie dann einen kleinen, gut beobachtbaren Produktions-Canary. Kontrollieren Sie neben der Anmeldung auch Übermittlung, Status, Abruf, Wiederanlauf und Dublettenvermeidung. Vorab definierte Abbruchkriterien verhindern, dass ein fehlerhafter Canary unkontrolliert ausgeweitet wird.

Wann darf der alte KSeF-Token gelöscht werden?

Erst wenn jeder inventarisierte Verbraucher nachweislich über das Zertifikat arbeitet, das vereinbarte Beobachtungsfenster ohne kritische Abweichung beendet wurde und Finance die Vollständigkeit bestätigt hat. Danach sollten Tokenzugang und alle Secret-Kopien kontrolliert entfernt werden. Vor dem Supportende kann der Token nur als befristeter Rollback dienen; ab 1. Januar 2027 ist er kein tragfähiger Rückfallpfad.

Welche Nachweise sollten wir für die Cutover-Freigabe sammeln?

Sinnvoll sind die Abhängigkeits- und Rechte-Baseline, Zertifikatstyp und Inhaber, Architektur- und Datenflussdiagramm, freigegebene RACI, positive und negative Testprotokolle, maskierte Traces mit Korrelations-IDs, Canary-Kennzahlen, Go/No-Go-Entscheidung sowie Belege für die spätere Token-Stilllegung. Speichern Sie keine privaten Schlüssel, KSeF-Systemtoken oder unmaskierten JWTs als Evidenz.

Wichtige Regeln, Formate und Begriffe

Europäische KommissionEN 16931Richtlinie 2014/55/EUstrukturierte elektronische RechnungMigration von KSeF-Token zu Zertifikat für ERP- und API-IntegrationenPolen

Weiterlesen

Offizielle Quellen

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