FA(3) : le schéma de facture KSeF polonais — structure, champs, changements

FA(3) est la structure logique XML utilisée par toute facture structurée envoyée au KSeF polonais depuis le 1er février 2026, date à laquelle elle a remplacé FA(2). C'est un schéma national publié par le ministère des Finances — pas une syntaxe de EN 16931 — avec huit éléments de premier niveau, dont Naglowek, Podmiot1, Podmiot2 et Fa sont obligatoires. Par rapport à FA(2), il ajoute une structure plus claire des conditions de paiement, un rôle d'employé pour les tiers, des descriptions d'articles plus longues, des marqueurs pour les collectivités territoriales et les groupes TVA, et une pièce jointe XML.

Ce qu'est FA(3) et quand il s'applique

FA(3) est le « wzór faktury ustrukturyzowanej » — le modèle de document électronique — défini par le ministère des Finances et publié dans le référentiel central des modèles de documents à l'adresse crd.gov.pl/wzor/2025/06/25/13775/. Une facture structurée est juridiquement une facture émise via KSeF avec le numéro que le système lui a attribué, et KSeF n'attribue des numéros qu'aux fichiers conformes au modèle en vigueur.

La brochure du ministère est sans ambiguïté : FA(2) s'appliquait du 1er septembre 2023 au 31 janvier 2026 ; FA(3) s'applique à toute facture structurée émise à partir du 1er février 2026, y compris les corrections de factures initialement émises en FA(2) ou FA(1) et les factures de règlement d'anciennes factures d'acompte. L'API reflète cela : la production et la démo n'acceptent que FA(3) (plus les variantes FA_PEF(3) et FA_KOR_PEF(3) pour les factures de marchés publics issues de Peppol), tandis que l'environnement de test accepte encore FA(2). Un client déclare le schéma à l'ouverture d'une session, et KSeF valide chaque fichier de cette session contre ce schéma.

Structure : les huit éléments de premier niveau

L'élément racine Faktura contient l'en-tête, le vendeur, l'acheteur, des tiers facultatifs, une entité habilitée facultative, le corps de la facture, un pied de page facultatif et une pièce jointe facultative.

La brochure distingue les champs obligatoires (toujours remplis, p. ex. le NIP du vendeur), les champs optionnels (remplis chaque fois que la condition légale est remplie, p. ex. P_11A) et les champs facultatifs (à la discrétion du contribuable, p. ex. SystemInfo). Omettre des nœuds facultatifs ne pose pas de problème ; omettre un champ optionnel dont la condition est remplie donne une facture incorrecte même si le XSD passe.

Les champs clés de Fa

L'essentiel de ce qu'un comptable reconnaît comme « la facture » vit dans Fa, avec des noms de champs hérités de la structure déclarative JPK_FA.

KodWaluty

Devise ISO 4217 ; « PLN » pour les factures en monnaie polonaise. Les montants sont exprimés dans la devise de la facture, sauf les montants de taxe convertis selon la loi TVA, qui ont leurs propres champs (P_14_xW) aux côtés de KursWaluty.

P_1, P_1M

Date d'émission (obligatoire) et lieu d'émission (facultatif). Pour une facture en ligne, la date d'émission légale est la date de transmission, à condition que P_1 lui soit égal ; pour les factures offline24, en indisponibilité et en mode d'urgence — et pour les factures en ligne transmises après P_1 — c'est P_1 lui-même qui est la date formelle d'émission.

P_2

Le numéro de facture séquentiel propre au vendeur. Ce n'est pas le numéro KSeF ; les deux ne doivent pas être confondus.

P_6, P_6A, OkresFa

Date de livraison ou de paiement si elle diffère de P_1 — au niveau de la facture lorsqu'elle est commune à toutes les lignes, par ligne dans P_6A sinon, ou sous forme de période (P_6_Od/P_6_Do) pour les services continus.

P_13_x, P_14_x, P_15

Totaux HT et montants de TVA par tranche de taux (normal 23 % ou 22 %, réduit 8 %/7 %, 5 %/4 %, 3 %, taux zéro national, livraison intracommunautaire, exportation, exonéré, autoliquidation, hors champ), et le montant total à payer. Le ministère note que FA(3) ne sépare toujours pas 22 % de 23 % au niveau des totaux — le taux exact se lit dans P_12 sur la ligne.

Adnotacje

Annotations légales sous forme de codes : P_16 comptabilité de caisse, P_17 autofacturation, P_18 autoliquidation, P_18A paiement fractionné (split payment), P_19 base d'exonération, P_22 moyen de transport neuf, P_23 simplification triangulaire, marqueurs du régime de la marge.

RodzajFaktury

Type de facture : VAT (standard), KOR (corrective), ZAL (acompte), ROZ (règlement après acompte), UPR (simplifiée), KOR_ZAL et KOR_ROZ (corrections des deux précédentes). La correction d'une facture simplifiée utilise KOR. Pour les factures correctives, tous les champs montrent l'état après correction, tandis que les champs de base, de taxe et de total portent la différence.

FaWiersz

Lignes : NrWierszaFa (numéro de ligne), UU_ID facultatif (clé unique de ligne facultative de 50 caractères maximum reliant les lignes de correction aux lignes d'origine), P_7 (désignation des biens ou services, désormais jusqu'à 512 caractères), Indeks, GTIN, PKWiU, CN, P_8A (unité), P_8B (quantité), P_9A (prix unitaire HT), P_9B (prix unitaire TTC), P_10 (remises), P_11 (valeur HT de la ligne), P_11A (valeur TTC de la ligne), P_11Vat, et P_12, le code de taux.

Codes de taux P_12

« 23 », « 22 », « 8 », « 7 », « 5 », « 4 », « 3 », « 0 KR » (taux zéro national), « 0 WDT » (livraison intracommunautaire), « 0 EX » (exportation), « zw » (exonéré), « oo » (autoliquidation nationale), « np I » et « np II » (hors champ polonais, le second pour les services de l'art. 100(1)(4)). Les opérations hors de la loi TVA, telles que les bons à usages multiples, ne sont pas des lignes ; elles ne peuvent apparaître que comme information complémentaire dans Rozliczenie.

Platnosc

Statut et date de paiement, TerminPlatnosci sous forme de date (Termin) ou de description structurée (quantité et unité, p. ex. 14 jours), mode de paiement, comptes bancaires et conditions d'escompte.

Zamowienie

Utilisé uniquement pour les factures d'acompte et leurs corrections, où il remplace FaWiersz.

Formats des champs : XML en UTF-8 ; les champs texte sont par défaut de 256 caractères, avec 512 pour les noms, lignes d'adresse, P_7 et le texte de pièce jointe, 50 pour les codes de classification, unités et UU_ID, 32 pour IDNabywcy, 20 pour le GTIN. Les dates sont au format YYYY-MM-DD ; l'horodatage d'en-tête est ISO 8601 en UTC.

Ce qui a changé par rapport à FA(2)

Le ministère énumère les changements qu'il considère comme bénéfiques pour les contribuables ; aucun ne modifie le contenu fiscal d'une facture, mais plusieurs affectent la correspondance des champs.

• Échéance de paiement : TerminPlatnosci peut porter une date ou une description structurée (nombre plus unité) au lieu d'un texte libre, et le champ peut décrire un paiement déjà effectué ou à venir.
• Rôle d'employé : Podmiot3 gagne le rôle 11, « pracownik », de sorte qu'une dépense achetée par un employé au nom de l'entreprise puisse porter l'identité de l'employé pour le traitement des notes de frais.
• Descriptions plus longues : P_7 passe à 512 caractères.
• JST et groupes TVA : de nouveaux marqueurs dans Podmiot2 indiquent à une collectivité territoriale ou à un groupe TVA à quelle unité subordonnée ou à quel membre l'achat se rattache ; lorsqu'ils valent « 1 », Podmiot3 porte le NIP ou l'identifiant interne de cette unité.
• Pièce jointe : le nouvel élément Zalacznik pour les données d'unité et de prix volumineuses, soumis à notification préalable dans e-Urząd Skarbowy (ouvert depuis le 1er janvier 2026).
• Ce qui n'a pas changé : il n'existe toujours pas de champ de remise en pourcentage sur une ligne — une remise est une ligne séparée ou se reflète dans les prix unitaires — et les totaux ne distinguent toujours pas 22 % de 23 %.

Une session ouverte avec le code de formulaire FA(2) ne peut pas porter de fichiers FA(3) et inversement ; le logiciel doit choisir le code de formulaire correspondant au fichier.

Faire correspondre une facture à FA(3)

Une facture détenue dans un modèle EN 16931 se fait correspondre à FA(3) champ par champ, mais pas sans perte dans les deux sens : FA(3) a des champs que EN 16931 n'a pas (marqueurs JST/GV, annotation de paiement fractionné, codes de taux nationaux) et les codes de catégorie TVA de EN 16931 sont remplacés par la liste de taux P_12.

Deux règles de correspondance méritent attention. Une ligne en autoliquidation est codée oo avec l'annotation dans P_18 ; une livraison intracommunautaire est 0 WDT, une exportation 0 EX, un taux zéro national 0 KR — les réduire à « 0 % » fait perdre ce dont le comptable de l'acheteur a besoin. Et une facture corrective porte l'état après correction dans chaque champ mais les différences dans les bases, la taxe et le total, contrairement à la convention d'avoir de EN 16931. Voir formats de facture électronique et EN 16931.

Validation : ce que vérifie le XSD et ce que vérifie KSeF

Passer le XSD est nécessaire mais pas suffisant : KSeF vérifie le modèle et les permissions de l'expéditeur avant d'attribuer un numéro ; l'exactitude fiscale relève de la responsabilité de l'émetteur.

Le XSD impose l'ordre des éléments, la cardinalité, les types de données, les longueurs de champs et les listes de codes fermées. KSeF ajoute la vérification de la version du schéma pour la session et la vérification des permissions. Il ne vérifie pas le statut de l'acheteur dans le registre des assujettis à la TVA, ne rejette pas une facture adressée au mauvais client et ne recalcule pas l'arithmétique — la FAQ du ministère indique qu'un total erroné dans une facture acceptée se corrige par une facture corrective, tandis qu'un fichier rejeté est corrigé et resoumis parce qu'il n'est jamais devenu une facture. La trentaine d'exemples travaillés de la brochure constitue la référence pratique pour les cas limites.

Comment KRONENWERK gère cela

Pris en charge avec des limitations. KRONENWERK génère le XML FA(3) (version 1-0E) pour les factures, avoirs et factures d'acompte à partir des données de facture et du verdict fiscal, valide le fichier contre le XSD du ministère et ses propres contrôles à l'émission, et relit les fichiers FA(3) entrants en factures fournisseurs. Les trois codes de taux zéro, l'autoliquidation et l'exonération sont portés comme catégories distinctes, et les montants des tranches sont calculés à partir des lignes plutôt que saisis. La transmission à KSeF est Pas encore prêt : le module KSeF 2.0 n'a pas été utilisé contre le système de production, et KRONENWERK ne vend pas d'abonnements aux entreprises polonaises tant que ce n'est pas le cas — voir le hub Pologne et KSeF 2.0. L'élément de pièce jointe, les variantes FA_PEF et les marqueurs JST/groupe TVA ne sont pas générés. Les développeurs peuvent comparer la correspondance ci-dessus avec le guide d'intégration KSeF ; le vérificateur de factures électroniques gratuit valide les fichiers selon les règles d'un pays sans les stocker.