Pologne — KSeF et la facture FA(2)

La Pologne a choisi un modèle clearance complet : toute facture B2B passe par le Krajowy System e-Faktur (KSeF) opéré par le ministère des Finances, qui attribue un numéro KSeF (UPO) tenant lieu d'horodatage légal.

Timeline réglementaire

• Ustawa du 9 novembre 2018. Introduit dans la loi TVA la notion de faktura ustrukturyzowana (facture structurée) et amorce les travaux sur KSeF.
• 18 avril 2019. Mise en service de la plateforme PEF pour le B2G en application de la directive UE 2014/55.
• 1^er janvier 2022. Lancement de KSeF en mode volontaire pour le B2B. Schéma initial FA(1).
• Ustawa du 16 juin 2023 (Dz.U. 2023 poz. 1598). Pose l'obligation B2B avec une mise en service initialement prévue au 1^er juillet 2024.
• Communiqué Ministerstwo Finansów du 19 janvier 2024. Report à 2025 puis à 2026 après audit technique du système (incident KSeF stress test de fin 2023).
• Ustawa du 9 maja 2024. Fixe le calendrier définitif : 1^er février 2026 pour les grands contribuables, 1^er avril 2026 pour les autres.
• Rozporządzenie du 29 juin 2023. Publication du schéma FA(2) — variante 2 du formulaire FA, structurée pour KSeF.

Approfondissements — 10 pages dédiées

Dix pages dédiées approfondissent chaque dimension du mandat polonais KSeF — la réforme clearance 2026, les spécifications techniques (API, FA(2), UUID, e-Doręczenia), et l'usage B2B réel qui pré-existe et survivra à la réforme.

Réforme 2026

• KSeF obligatoire 2026 · Krajowy System e-Faktur, clearance pur, obligatoire 1ᵉʳ février 2026 (gros contribuables > 200M PLN), 1ᵉʳ avril 2026 universel. Base légale art. 106nf-106nm.
• FA(2) — e-faktura ustrukturyzowana · Schéma XML officiel polonais, UN/CEFACT CII + EN 16931, extensions sectorielles (mediation, transport, énergie), schémas sur biznes.gov.pl.
• JPK_FA et JPK_VAT — SAF-T polonais · Standard SAF-T polonais depuis 2018, JPK_V7M mensuel obligatoire, JPK_FA en bascule vers KSeF. 7 structures actives (FA, VAT, KR, MAG, WB, EWP, PKPiR).
• Calendrier KSeF 2022-2027 · 1ᵉʳ janv 2022 volontaire, 1ᵉʳ fév 2026 gros contribuables, 1ᵉʳ avr 2026 universel, 1ᵉʳ juil 2026 caisses fiskalne, 2027 évaluation parlementaire.

Specs techniques

• Spécifications API KSeF · REST sur ksef.mf.gov.pl, OAuth 2.0 hiérarchie AuthorizationToken / SessionToken / AccessToken, batch limits 50 fakt/paquet, codes erreur 21xxx.
• Numer KSeF — UUID juridique · Identifiant 36 caractères attribué après visa, remplace juridiquement la séquence émetteur. Format NIP-DATE-UUID-CHK. Propagation comptable.
• e-Doręczenia — courrier recommandé · Plateforme Mc Cyfryzacji / Poczta Polska, e-IDAS QERDS, obligatoire entreprises 1ᵉʳ janv 2025, ADE associé NIP, intégration notifications KSeF.

Usage B2B réel

• EDIFACT retail polonais · Biedronka, Lidl, Kaufland, Auchan, Carrefour, Żabka, Dino — subsets EANCOM 2002 S4/S5, GS1 Polska, ~1,2 milliard messages/an.
• EDIFACT automotive polonais · Volkswagen Poznań, Stellantis Tychy + Gliwice, FCA Bielsko-Biała, MAN Niepołomice, Toyota Wałbrzych — standards VDA + Galia + Odette, OFTP2 sur ENX.
• Régimes TVA polonais · Taux 23/8/5/0/zw/np, ryczałt, zwolnienie podmiotowe (< 200K PLN), reverse charge art. 17, split payment załącznik 15.

Schéma technique

Le format est FA(2), XML polonais propriétaire publié par le ministère des Finances sur le portail crd.gov.pl. Il diffère structurellement de PEPPOL BIS et de FatturaPA — pas d'alignement EN 16931. La racine est tns:Faktura dans le namespace http://crd.gov.pl/wzor/2023/06/29/12648/. Les principales sections : Naglowek (en-tête), Podmiot1 (vendeur), Podmiot2 (acheteur), Podmiot3 (tiers éventuel), et Fa (corps de facture, dates, lignes). Exemple minimal d'une facture FA(2) :

<?xml version="1.0" encoding="UTF-8"?>
<tns:Faktura xmlns:tns="http://crd.gov.pl/wzor/2023/06/29/12648/"
             xmlns:etd="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2022/01/05/eD/DefinicjeTypy/">
  <tns:Naglowek>
    <tns:KodFormularza kodSystemowy="FA (2)" wersjaSchemy="1-0E">FA</tns:KodFormularza>
    <tns:WariantFormularza>2</tns:WariantFormularza>
    <tns:DataWytworzeniaFa>2026-04-01T10:15:00</tns:DataWytworzeniaFa>
    <tns:SystemInfo>ediverse-demo</tns:SystemInfo>
  </tns:Naglowek>
  <tns:Podmiot1>
    <tns:DaneIdentyfikacyjne>
      <etd:NIP>5260250995</etd:NIP>
      <tns:Nazwa>Warsztat Warszawa Sp. z o.o.</tns:Nazwa>
    </tns:DaneIdentyfikacyjne>
    <tns:Adres>
      <etd:KodKraju>PL</etd:KodKraju>
      <etd:AdresL1>ul. Marszalkowska 102</etd:AdresL1>
      <etd:AdresL2>00-026 Warszawa</etd:AdresL2>
    </tns:Adres>
  </tns:Podmiot1>
  <tns:Podmiot2>
    <tns:DaneIdentyfikacyjne>
      <etd:NIP>7011089487</etd:NIP>
      <tns:Nazwa>Spoldzielnia Krakowska</tns:Nazwa>
    </tns:DaneIdentyfikacyjne>
  </tns:Podmiot2>
  <tns:Fa>
    <tns:KodWaluty>PLN</tns:KodWaluty>
    <tns:P_1>2026-04-01</tns:P_1>
    <tns:P_2>FA/04/2026/00187</tns:P_2>
    <tns:RodzajFaktury>VAT</tns:RodzajFaktury>
  </tns:Fa>
</tns:Faktura>

KSeF impose une authentification forte : signature qualifiée polonaise (kwalifikowany podpis elektroniczny), signature avancée ZUS, ePUAP, ou token d'autorisation délivré par KSeF. L'horodatage légal est constitué par le numer KSeF retourné à la suite du dépôt — c'est lui qui fait foi devant l'administration fiscale, pas la date d'émission portée par le vendeur.

Flux de soumission

Le modèle est clearance pur : le vendeur publie la facture sur KSeF (API interactive REST ou batch), KSeF valide la structure et les règles, attribue un numer KSeF avec UPO (Urzędowe Poświadczenie Odbioru), puis la facture devient accessible à l'acheteur dans son espace KSeF.

┌────────────┐    ┌──────────────┐    ┌────────────┐
│ Vendeur PL │───>│    KSeF      │───>│ Acheteur PL│
│ (ERP)      │    │ (Ministerstwo│    │ (ERP)      │
└────────────┘    │  Finansow)   │    └────────────┘
                  └──────┬───────┘
                         │
                         ▼
                ┌─────────────────┐
                │ Numer KSeF       │  ← attribué dans les
                │ (UPO)            │     24h, signature horodatée
                └─────────────────┘

L'acheteur n'est pas notifié activement : il consulte son espace KSeF. Pour les flux cross-border, KSeF n'est pas applicable : les opérations avec un partenaire étranger restent traitées selon la facturation traditionnelle (PDF structuré ou non, EN 16931 par PEPPOL pour l'UE).

Validation

• Environnement KSeF Demo : ksef-demo.mf.gov.pl — sandbox du ministère des Finances pour tester l'API et la signature.
• Documentation KSeF : podatki.gov.pl/ksef — référentiel officiel des schémas FA(2), des règles métier et des codes d'erreur.
• XSD FA(2) téléchargeable depuis crd.gov.pl/wzor/2023/06/29/12648/.
• Validateur PEPPOL : /tools/peppol-validator/ — pour les flux cross-border sortants en parallèle.

Pièges courants

1. Push 24 heures pour le numer KSeF. L'attribution de l'UPO peut prendre jusqu'à 24 heures en cas de file d'attente système. Toute architecture qui présuppose un retour synchrone sous quelques secondes risque de déclencher des doubles soumissions. Le SDK officiel recommande un poll asynchrone avec backoff.
2. Authentification multifacteur stricte. Le token KSeF est lié à un certificat ZUS, à un ePUAP, ou à un certificat qualifié : une rotation du certificat sans réémission du token bloque toute la chaîne. Prévoir un processus de renouvellement automatisé.
3. Aucune interop PEPPOL native. KSeF n'émet ni n'accepte de facture PEPPOL UBL. Pour les flux cross-border vers/depuis la Pologne, il faut maintenir un deuxième canal en parallèle (PEPPOL ou EDI bilatéral). Les passerelles privées qui annoncent une interop sont en réalité des convertisseurs à double saisie.
4. Date d'émission vs date d'attribution KSeF. Le vendeur peut saisir une date d'émission (P_1) antérieure à la date d'envoi à KSeF, mais seule la date de l'UPO est opposable fiscalement. Cette dissociation surprend les équipes habituées à un horodatage de l'ERP seul.
5. Notification passive de l'acheteur. KSeF ne pousse pas la facture vers l'acheteur : c'est lui qui doit interroger son espace KSeF. Les architectures qui n'industrialisent pas la collecte côté acheteur génèrent des retards comptables.

Liens transverses

• PEPPOL — réseau européen, à maintenir en parallèle pour la cross-border.
• Feuille de route e-invoicing Europe 2025-2030.
• Article — Tour d'horizon e-invoicing 2026.
• Sources officielles : podatki.gov.pl/ksef, gov.pl/web/finanse, crd.gov.pl (Centralne Repozytorium Wzorów).