Donnees reglementaires de la facture electronique : le guide technique

A partir de septembre 2026, chaque facture electronique transmise au portail public de facturation (PPF) devra contenir un ensemble precis de donnees reglementaires conformes a la norme europeenne EN 16931. Ce guide detaille les exigences techniques, les formats acceptes, les controles appliques par le PPF et les motifs de rejet possibles.

L'essentiel en 1 minute

  • Les donnees reglementaires sont les informations fiscales et commerciales extraites de chaque facture et transmises a l'administration
  • Elles respectent le format semantique EN 16931, complete par des extensions francaises (EXT-FR-FE)
  • Les formats de transmission acceptes sont UBL 2.1 et CII D22B, dans une archive tar.gz
  • Le PPF applique des controles fonctionnels (semantiques, structure, coherence, unicite) avant acceptation
  • FrenchInvoice genere des factures Factur-X nativement conformes a toutes ces exigences

Qu'est-ce que les donnees reglementaires d'une facture ?

Les donnees reglementairesd'une facture sont l'ensemble des informations fiscales, commerciales et d'identification que chaque facture soumise au champ d'application de la TVA doit contenir. Ces donnees ne se limitent pas au contenu visible du PDF : elles constituent un jeu structure de donnees numeriquesqui sera transmis a l'administration fiscale via le portail public de facturation (PPF).

Concretement, les donnees reglementaires comprennent les informations sur le vendeur(SIREN, adresse, numero de TVA), l'acheteur (identification, adresse), les lignes de facture (designation, quantite, prix unitaire HT, taux de TVA), les totaux (HT, TVA, TTC), ainsi que les conditions de paiement et les references documentaires(numero de facture, date d'emission, date de livraison).

Ces donnees doivent etre transmises dans un format structure normalise, et non sous forme de texte libre. C'est cette structuration qui permet a l'administration de les traiter automatiquement pour le pre-remplissage des declarations de TVA et la detection des fraudes.

Le format semantique EN 16931 et les extensions francaises

Les donnees reglementaires d'une facture respectent le format semantique de la norme europeenne EN 16931. Cette norme definit un modele de donnees universel pour la facturation electronique en Europe, garantissant l'interoperabilite entre les systemes de facturation de tous les Etats membres.

La norme EN 16931 decrit un ensemble de champs semantiques (identifiant vendeur, montant HT, taux de TVA, etc.) avec leurs regles de validation. Chaque champ a un identifiant unique (par exemple BT-1 pour le numero de facture, BT-2pour la date d'emission).

Les extensions francaises (EXT-FR-FE)

Pour couvrir les specificites de la legislation fiscale francaise, la norme EN 16931 est completee par des extensions identifiees sous le prefixe EXT-FR-FE (Extension France - Facturation Electronique). Ces extensions ajoutent des champs et des regles de gestion propres au droit francais, comme :

La mention de franchise de TVA (article 293B du CGI) pour les auto-entrepreneurs non assujettis
Les penalites de retard et l'indemnite forfaitaire de recouvrement de 40 euros, obligatoires sur toute facture B2B
Le numero SIREN/SIRET du vendeur et de l'acheteur, specifique au referentiel francais
Les regles de gestion specifiques a la reforme francaise de facturation electronique (controles supplementaires)

L'ensemble des extensions francaises est decrit dans l'annexe 1 des specifications externes de la DGFIP (version 3.1).

Les donnees exigees des septembre 2026

En raison de la mise en conformite progressive des assujettis a la TVA, un socle initial de donnees reglementaires est exige des le demarrage de la reforme, a compter du 1er septembre 2026. Ce socle sera ensuite complete au moment de la generalisation du dispositif.

L'approche progressive permet aux entreprises et aux plateformes agreees de s'adapter par etapes, tout en garantissant que les donnees essentielles pour l'administration fiscale sont disponibles des le premier jour.

Les donnees du socle initial

Numero de facture (unique, sequentiel)
Date d'emission de la facture
Date de livraison ou d'execution
Identite du vendeur (SIREN, adresse)
Identite de l'acheteur (SIREN, adresse)
Numero de TVA intracommunautaire
Designation des biens ou services
Quantite et prix unitaire HT
Taux de TVA applicable par ligne
Montant total HT par taux de TVA
Montant total de TVA
Montant total TTC
Conditions et delai de paiement
Mention franchise TVA le cas echeant
Penalites de retard
Indemnite forfaitaire de recouvrement

A noter : le socle initial sera enrichi progressivement. Les entreprises doivent anticiper en structurant leurs donnees de facturation des maintenant pour faciliter la montee en charge.

Les formats de transmission acceptes

Les donnees reglementaires doivent etre transmises a l'administration fiscale dans une archive au format tar.gzcontenant un fichier structure dans l'un des deux formats normalises suivants :

UBL 2.1 (Universal Business Language)

Le format UBL supporte par le PPF est conforme a la norme OASIS U.B.L. 2.1. C'est un standard XML largement adopte dans le commerce electronique international. UBL definit un vocabulaire precis pour les documents commerciaux (factures, avoirs, commandes) avec une structure hierarchique rigoureuse.

Norme OASIS Universal Business Language v2.1

CII D22B (Cross-Industry Invoice)

Le format CII supporte par le PPF est conforme a la norme UN/CEFACT CCTS 3.0, dans la version de langage CII D22B. C'est le format utilise par Factur-X pour le XML embarque dans le PDF/A-3. FrenchInvoice utilise nativement ce format pour generer des factures conformes.

Norme UN/CEFACT Cross-Industry Invoice D22B

Chaque fichier est mono-objet: il ne contient qu'une seule facture. L'archive tar.gz peut contenir plusieurs fichiers, mais chacun correspond a une facture distincte.

Les controles fonctionnels du PPF

Lorsque les donnees reglementaires parviennent au portail public de facturation (PPF), celui-ci effectue une serie de controles techniques et applicatifssur le flux recu. Si aucune anomalie technique n'est detectee, le PPF procede alors a des controles fonctionnels sur chaque fichier de donnees reglementaires.

Ces controles sont implementes au travers de schematrons, des regles de validation XML qui verifient la conformite semantique et structurelle de chaque document.

1

Controles semantiques

Verification des regles de gestion de la norme EN 16931 et de celles specifiques a la reforme francaise. Par exemple : presence des champs obligatoires, coherence entre le type de document et les donnees presentes, respect des regles de calcul de TVA.

2

Controles de structure de donnees

Verification des longueurs maximales des champs, des formats de donnees (dates, montants, identifiants) et de la conformite au schema XSD du format choisi (UBL ou CII).

3

Controles de coherence des donnees

Verification de la coherence avec les referentielsde l'administration : validite du SIREN du vendeur, correspondance des codes TVA, coherence des montants (total HT + TVA = TTC).

4

Controles d'unicite

Verification que les donnees reglementaires n'ont pas deja ete transmises et traitees. L'unicite est determinee a partir du numero de facture, de l'identifiant du fournisseur (SIREN)et de l'annee de production de la facture.

Les statuts des donnees reglementaires

Le resultat des controles fonctionnels determine le statut de chaque objet metiertransmis au PPF. Pour les donnees reglementaires, il n'existe que deux statuts possibles, tous deux obligatoires :

250

Deposee

Obligatoire

Les donnees reglementaires sont controlees comme conformeset transmises a l'administration fiscale. Ce statut confirme que la facture a passe avec succes tous les controles fonctionnels du PPF.

251

Rejetee

Obligatoire

Les donnees reglementaires sont controlees comme non conformes. Elles ne sont pas integrees et ne sont pas transmises a l'administration fiscale. Seule l'information du rejet avec le numero de facture, l'annee d'emission et le SIREN du vendeur sont transmises a l'administration.

Important :tout partenaire est informe via le cycle de vie du caractere accepte ou rejete des objets metiers qu'il a transmis. En cas de rejet, l'emetteur doit analyser les motifs et corriger les anomalies avant de retransmettre les donnees.

Les motifs de rejet

Lorsque le PPF rejette des donnees reglementaires, il associe un ou plusieurs motifs de rejetavec l'indication de la source des anomalies, afin de permettre au partenaire de realiser les actions correctives adaptees.

Motifs de rejet des donnees reglementaires

REJ_SEMANControle du format semantique

Le format semantique d'une ou plusieurs donnees n'est pas conforme a la norme EN 16931 ou aux regles de gestion francaises. Exemples : champ obligatoire manquant, format de date invalide, identifiant TVA mal forme.

REJ_UNIControle d'unicite

Les donnees reglementaires ont deja ete transmises et traitees. Le triplet numero de facture + SIREN vendeur + annee de production existe deja dans le systeme du PPF.

REJ_COHControle de coherence des donnees

Une ou plusieurs donnees sont incoherentes avec les referentiels de l'administration. Exemples : SIREN inexistant, code TVA invalide, montant total incoherent avec la somme des lignes.

Motifs de rejet des statuts obligatoires

REJ_RGControle des regles de gestion

Une ou plusieurs regles de gestion ne sont pas respectees dans les statuts transmis.

REJ_INCControle de coherence des statuts

Un ou plusieurs statuts sont incoherents avec l'etat actuel du cycle de vie de la facture.

REJ_INEXControle de conformite des statuts

Un ou plusieurs statuts sont incorrects ou non autorises dans le contexte de la facture.

Que faire en cas de rejet ?

1

Premier cas : le rejet releve d'anomalies lors de la constitution du fichier de donnees reglementaires a partir d'une facture conforme. La plateforme agreee d'emission peut generer a nouveau le fichier corrige (portant le meme numero de facture) pour retransmission au PPF.

2

Deuxieme cas : le rejet releve d'anomalies fonctionnelles au niveau des donnees de la facture elle-meme. L'entreprise doit etre informee du rejet avec les motifs associes et doit corriger les anomalies dans son systeme de facturation.

Comment FrenchInvoice garantit la conformite

FrenchInvoice a ete concu des le depart pour respecter les exigences de la reforme 2026. Voici comment chaque aspect des donnees reglementaires est pris en charge :

1

Format Factur-X EN 16931 natif

Chaque facture generee par FrenchInvoice est au format PDF/A-3 avec XML CII embarque, conforme au profil Comfort de la norme EN 16931. Le fichier XML contient toutes les donnees reglementaires requises.

2

Extensions francaises integrees

Les extensions EXT-FR-FE sont automatiquement incluses : mention franchise TVA, penalites de retard, indemnite forfaitaire, identifiants SIREN/SIRET. Aucune configuration manuelle necessaire.

3

Numerotation sequentielle conforme

La numerotation des factures est sequentielle, sans trou, avec transaction atomique (article L441-9 du Code de commerce). Le controle d'unicite du PPF (REJ_UNI) ne posera jamais de probleme.

4

Calculs automatiques verifies

Les montants HT, TVA et TTC sont calcules automatiquement avec verification de coherence. Les controles de coherence du PPF (REJ_COH) sont anticipes par le logiciel.

5

Compatibilite PDP et PPF

Les factures generees sont compatibles avec toutes les plateformes agreees (PDP) et le portail public de facturation (PPF). Le format CII D22B utilise est celui supporte nativement par l'infrastructure de la reforme.

Des factures conformes des le premier jour

FrenchInvoice genere des donnees reglementaires conformes EN 16931 nativement. Pas de configuration, pas de risque de rejet PPF. Community ou SaaS.