E-Invoice Finder
Menu
Pays Logiciels Échéances Guides Checker Vérifier obligation
ENFRDEPLNL
Pologne · recette de l’implémentation Offline24

Codes QR KSeF Offline24 et plan de test ERP

Testez Offline24 dans l’ERP : deux codes QR, certificat type 2, empreinte de facture, file, délais et preuves de reprise KSeF.

Résumé pratique :
  • Périmètre : valider le parcours allant du fichier figé localement à son rapprochement avec le numéro KSeF.
  • Risque majeur : une représentation scannable mais reliée aux mauvais octets ou au mauvais environnement donne une assurance trompeuse.
  • Premier geste : figer un jeu d’essai de référence et attribuer chaque contrôle à un responsable nommé.
Voir le rapport PologneSources officielles
Dernière vérification : 4 août 2026Sources officiellesRésumé clairInformation pratique, pas un conseil juridique
Sources officielles priorisées
Dates de vérification visibles
Checker gratuit, sans inscription

Ce qu’il faut savoir

Guide

1. Déterminer quand Offline24 et le cas à deux codes s’appliquent

Exigence officielle : tout contribuable peut choisir Offline24, y compris en cas de difficulté liée au réseau de transmission ou à Internet. Ce choix du contribuable ne doit pas être confondu avec une indisponibilité, une panne ou une panne totale officiellement annoncée par KSeF, car les délais et, dans le dernier cas, l’obligation d’envoi ultérieur diffèrent. Pour un acheteur national assujetti à la TVA, la réception intervient normalement dans KSeF. La paire de codes concerne la représentation remise hors KSeF avant l’envoi à un destinataire visé par l’article 106gb(4), par exemple un acheteur étranger, un consommateur ou un acheteur sans NIP. Elle n’est donc pas systématique. Le fiscal décrit les destinataires, le produit traduit la décision en règles et la QA teste chaque branche. Évitez de déclencher deux codes sur le seul mode offline, de confondre panne annoncée et choix Offline24, ou de prendre le PDF pour la facture structurée. Critère recommandé : le tableau couvre 100 % des profils, avec résultat « livraison KSeF », « deux codes préalables » ou « régime à valider », sans ambiguïté.

Guide

2. Stabiliser FA(3), P_1 et les octets XML

Exigence officielle : la facture est émise électroniquement dans la structure logique applicable, FA(3) depuis le 1er février 2026. Sa date d’émission est le champ P_1. Le fichier structuré, et non sa visualisation, sert au calcul de l’empreinte. KOD I et KOD II doivent reprendre la même empreinte SHA-256 du fichier de facture, encodée en Base64URL. Contrôle recommandé : rendre le XML déterministe avant les liens. Validez les données, produisez les octets définitifs, calculez une empreinte, puis fabriquez les codes et archivez l’ensemble. Une régénération — espaces, encodage ou ordre variable — peut rompre la vérification. Le propriétaire ERP garde un cas canonique réaliste, le développeur consigne l’empreinte attendue et la QA compare les octets. Critères recommandés : cent exécutions du même cas donnent exactement le même fichier et la même empreinte ; une modification d’un octet change l’empreinte ; FA(3) est validé avant mise en file ; P_1 reste inchangé lors des reprises.

Guide

3. Implémenter KOD I — OFFLINE

Exigence officielle : KOD I est construit localement avec l’URL de base de vérification propre à l’environnement, la date P_1, le NIP du vendeur et l’empreinte Base64URL SHA-256 du fichier. La représentation porte le libellé « OFFLINE ». Ce code permet l’accès à la facture ou la vérification de ses données ; il ne prouve pas à lui seul l’identité de l’émetteur. L’intégration utilise un constructeur d’URL typé et journalise les éléments non secrets. Le risque est un lien valide associé au mauvais NIP, à une date transformée ou à une empreinte calculée trop tôt. Critères recommandés : les vecteurs d’essai reproduisent exactement l’URL attendue ; un scanner grand public ouvre le lien ; la valeur P_1 n’est jamais remplacée par l’heure de génération ; les caractères Base64URL ne sont ni réencodés ni tronqués. Le propriétaire technique approuve le constructeur, tandis que la QA vérifie séparément le contenu décodé et le rendu. En production, l’hôte est qr.ksef.mf.gov.pl ; aucun hôte de test ou de démonstration ne doit pouvoir s’y substituer.

Guide

4. Implémenter KOD II — CERTYFIKAT et protéger la clé

Exigence officielle : KOD II porte le libellé « CERTYFIKAT » et vérifie l’identité ou l’authenticité de l’émetteur. Sa génération exige un certificat KSeF Offline actif de type 2 et sa clé privée ; un certificat de type 1 destiné à l’authentification ne convient pas. Les données signées comprennent le type et la valeur de l’identifiant de contexte, le NIP vendeur, le numéro de série du certificat, la même empreinte de facture que KOD I, puis une signature cryptographique effectuée avec la clé de type 2. La sécurité définit garde de clé, accès, rotation et arrêt si le certificat est invalide ; la clé ne va jamais dans journaux, tickets ou tests. Contrôles recommandés : signature isolée, vérification locale, refus d’un certificat expiré ou de mauvais type, et traçage du numéro de série. Critères : les essais positifs passent avec un type 2 actif ; les essais avec type 1, clé différente, empreinte altérée et contexte erroné échouent nettement ; chaque utilisation de clé est auditable et attribuable.

Guide

5. Construire une matrice de recette de bout en bout

Exemple réaliste recommandé : une société polonaise au NIP de test vend le 6 août 2026 à 14 h 20 un service à une entreprise française sans NIP polonais. L’ERP produit FA(3), fixe P_1 au 6 août, calcule l’empreinte, crée KOD I et KOD II, remet la représentation avant envoi, place le XML en file avec offlineMode:true, puis obtient un numéro KSeF et rapproche le résultat. La matrice couvre aussi un acheteur national assujetti, week-end, jour férié, certificat expiré, NIP incohérent, clé inaccessible, doublon réseau et rejet technique. Exigence officielle : l’API documente offlineMode:true pour les soumissions offline. Le reste constitue une recette recommandée, non une procédure légale imposée. Propriétaires : produit pour les branches, fiscal pour les hypothèses, intégration pour l’envoi, sécurité pour la signature, QA pour les preuves. Critère : chaque scénario consigne données, attendu, responsable, scan, file et rapprochement ; aucun défaut critique avant production.

Guide

6. Maîtriser file, délai, idempotence et rapprochement

Exigence officielle : en Offline24 choisi par le contribuable, la facture doit être envoyée à KSeF sans délai, au plus tard le jour ouvrable suivant son émission, afin de recevoir un numéro KSeF. Si une panne KSeF officiellement annoncée survient avant la soumission, le délai devient sept jours ouvrables après sa fin ; en cas de panne totale, la facture n’est pas transmise ensuite. Ces régimes doivent rester distincts dans l’état de la file. Contrôles recommandés : enregistrer P_1, empreinte, régime, échéance, tentatives et clé d’idempotence ; reprendre sans recréer le XML ; alerter ; rapprocher réponse, numéro KSeF et empreinte. Le responsable exploitation possède la file, le fiscal maintient le calendrier ouvrable, et la comptabilité traite les écarts. Risques : doublons après délai d’attente réseau, échéance fondée sur un calendrier incorrect, ou nouvel XML créé à chaque reprise. Critères : reprise après coupure sans double comptabilisation ; alerte documentée avant échéance ; 100 % des éléments acceptés associés à un numéro KSeF ; aucun élément bloqué sans propriétaire ; tableau séparant clairement Offline24 volontaire, panne annoncée et panne totale.

Guide

7. Accepter le scan, le rendu, l’environnement et l’accessibilité

Exigence officielle : les graphismes QR suivent ISO/IEC 18004:2024. Si le format de livraison structuré ne peut transporter un graphisme, le lien ou le graphisme et son libellé peuvent être fournis séparément avec la facture. Les hôtes de production, test et démonstration sont distincts : l’application doit empêcher tout mélange, plutôt que compter sur l’attention de l’opérateur. Après acceptation et attribution du numéro KSeF, une représentation ultérieure hors KSeF montre un seul KOD I libellé avec ce numéro, et non la paire préalable. Contrôles recommandés : tester impression, PDF, mobile, redimensionnement, marge calme, contraste, plusieurs scanners et restitution textuelle du lien. Les libellés restent lisibles sans l’image. Le design est propriétaire du rendu, DevOps de la configuration d’environnement et QA du scan. Critères : taux de lecture de 100 % sur le corpus approuvé ; aucun lien de production dans les artefacts test et inversement ; échec fermé si environnement et certificat divergent ; distinction visuelle vérifiée entre représentation préalable et représentation post-acceptation.

Guide

8. Tester rejet, correction technique et reprise

Exigence officielle : si une facture offline est rejetée pour une erreur de validation technique, le mécanisme documenté de correction technique peut relier un fichier technique corrigé à l’empreinte de l’original rejeté. Il ne permet pas de modifier le contenu commercial. Par ailleurs, une facture rectificative portant sur un original Offline24 doit attendre que l’original ait reçu son numéro KSeF. Le workflow doit donc distinguer reprise identique, correction technique et rectification métier. Contrôles recommandés : injecter un XML non conforme, conserver rejet et empreinte, corriger seulement la cause technique, puis démontrer liaison et acceptation. Toute différence commerciale sort de cette voie. Le responsable intégration qualifie l’erreur technique ; le fiscal décide si le changement est métier ; la QA bloque la création prématurée d’une rectificative. Critères : aucun rejet n’est écrasé ; origine, fichiers et réponses sont traçables ; les changements sont comparés champ par champ ; la rectificative reste bloquée tant que le numéro KSeF de l’original manque ; un exercice de reprise produit un dossier probant complet.

Guide

9. Choisir le fournisseur, constituer les preuves et lancer

La conformité des règles relève des exigences officielles décrites plus haut ; les critères de sélection suivants sont des contrôles pratiques. Demandez au fournisseur une démonstration sur votre jeu d’essai : octets déterministes, empreinte exportable, construction séparée des deux codes, signature type 2 sans exposition de clé, verrouillage d’environnement, offlineMode:true, file idempotente, calendrier configurable, gestion des rejets et passage à un seul KOD I après acceptation. Refusez les réponses qui assimilent PDF et facture structurée, promettent KOD II avec un type 1 ou cachent les données encodées. Le dossier de preuve réunit décisions, version FA(3), XML et empreintes, URL décodées, numéros de série, signatures, scans, journaux, réponses KSeF, rapprochements, rejets et validations. Critères : chaque exigence a source et test, chaque risque un propriétaire, les preuves sont reproductibles et fiscal, sécurité, produit et exploitation approuvent la production. Prochaine action : exécuter un atelier de deux heures sur le cas canonique, consigner les écarts puis planifier une répétition complète avant le déploiement. Ces informations sont pratiques et ne constituent pas un conseil juridique ou fiscal.

Checklist

Cartographier les profils d’acheteur et approuver la règle qui déclenche réellement la représentation préalable à deux codes.

Figer un XML FA(3) canonique, sa date P_1, ses octets et son empreinte Base64URL SHA-256 attendue.

Vérifier que KOD I encode l’hôte d’environnement, P_1, le NIP vendeur et l’empreinte exacts.

Démontrer que KOD II utilise un certificat Offline type 2 actif et refuse le type 1.

Tester la garde de la clé privée, les droits minimaux, la traçabilité et l’échec sans fuite de secret.

Soumettre le scénario offline avec offlineMode:true et rapprocher l’empreinte du numéro KSeF reçu.

Simuler week-end, jour férié, panne annoncée et panne totale sans confondre leurs règles de délai.

Mesurer la lecture des codes sur PDF, impression et mobile, avec libellés et liens accessibles.

Forcer rejet, reprise idempotente et correction technique, puis conserver les preuves de chaque transition.

Bloquer la rectificative jusqu’au numéro KSeF de l’original et faire approuver le dossier de recette.

Questions fréquentes

Toute facture Offline24 doit-elle afficher deux codes QR ?

Non. La paire préalable vise notamment l’acheteur étranger, le consommateur ou l’acheteur sans NIP. L’acheteur national assujetti reçoit normalement via KSeF.

Que vérifie KOD I par rapport à KOD II ?

KOD I donne accès aux données vérifiables ; KOD II vérifie par signature l’identité ou l’authenticité de l’émetteur.

Un certificat KSeF de type 1 peut-il générer KOD II ?

Non. Il exige un certificat Offline type 2 actif et sa clé privée ; le composant refuse le type 1 d’authentification.

Quelle donnée doit être hachée pour les codes ?

Calculez SHA-256 sur le fichier structuré final, puis encodez en Base64URL. Un PDF ou un XML régénéré donnerait une autre référence.

Que faut-il montrer après l’attribution du numéro KSeF ?

Elle utilise un seul KOD I libellé avec le numéro KSeF, et non la paire préalable.

Quel est le délai d’envoi d’une facture Offline24 ?

Envoi au plus tard le jour ouvrable suivant. Une panne annoncée ouvre sept jours ouvrables après sa fin ; une panne totale exclut l’envoi ultérieur.

Comment tester la file sans créer de doublons ?

Conservez octets, empreinte et clé d’idempotence, puis simulez une réponse perdue. La reprise rapproche l’existant sans recréer le XML ni doubler l’écriture.

Une correction technique autorise-t-elle à changer le contenu commercial ?

Non. Elle relie la correction à l’empreinte rejetée. Le changement commercial suit un autre traitement ; la rectificative attend le numéro de l’original.

Réglementation, formats et termes clés

Commission européenneEN 16931Directive 2014/55/UEfacture électronique structuréeCodes QR KSeF Offline24 et plan de test ERPPologne

À lire aussi

Sources officielles

Nous privilégions les sources gouvernementales et européennes officielles lorsque disponibles, avec des dates de vérification visibles.