Cette FAQ est destinée pour le seul usage des plateformes agréées.

 

 

 

1. Les factures doivent-elles transiter par le PPF? Quels flux liés à la facturation électronique sont perçus par le PPF ?

 

Les factures ne passent pas par le Portail Public de Facturation (PPF), elles sont uniquement échangées entre les plateformes agréées (PA). Le PPF prend en charge, quant à lui, trois types de flux liés à la facturation électronique :

• Le flux F1, correspondant au flux des données règlementaires e-invoicing ;
• Le flux F10, correspondant au flux agrégé des données e-reporting ;
• Le flux F6, correspondant au flux cycle de vie.

 

 

2. Pourquoi dois-je interroger l’annuaire avant d’émettre une facture vers une autre plateforme agréée ?

 

La consultation de l’annuaire est indispensable avant l’émission d’une facture vers une autre plateforme agréée. Elle permet de vérifier que le destinataire de la facture est bien assujetti à la TVA et de disposer de ses informations d’adressage à jour. Ces données pouvant évoluer, interroger l’annuaire garantit que la facture sera correctement routée vers la bonne plateforme et évitera tout rejet ou erreur d’acheminement.

 

3. Quelles sont exactement les données que le PPF attend pour répondre aux objectifs de la réforme ?

 

Pour répondre aux objectifs de la réforme, les plateformes agréées d’émission doivent transmettre au PPF des données règlementaires obligatoires pour le e-invoicing et le e-reporting.

Concernant le périmètre du e-invoicing (B2B domestique), les plateformes d’émission doivent transmettre au PPF :

• Les flux de données règlementaires correspondant aux factures transmises aux plateformes de réception (comme le numéro de facture, le SIREN de l’acheteur, le SIREN du vendeur, le montant HT, les éventuelles exonérations, etc.) ;
• Les statuts obligatoires de la facture permettant de suivre le cycle de vie de celle-ci (à savoir « Déposée », « Encaissée », « Rejetée » et « Refusée »).

S’agissant du périmètre du e-reporting (B2B international & B2C), les plateformes déclarantes doivent transmettre au PPF :

• Les données obligatoires d’une facture avec une entreprise étrangère ;
• Les données obligatoires de transactions avec des consommateurs non-assujettis ;
• Les données obligatoires de paiement d’une facture avec une entreprise étrangère ;
• Les données obligatoires de paiement d’une transaction avec un consommateur non-assujetti.

 

4. Quelles normes dois‑je appliquer dans mes échanges vers le PPF et dans quels cas les échanges « non‑normés » sont‑ils admis en dehors du PPF ?

 

Le PPF échange avec les plateformes agréées seulement des flux respectant strictement les normes AFNOR (pour le flux 1) et CDAR (pour le flux 6).

Toutefois, des flux construits dans un autre format, non-normé, peuvent circuler librement entre les plateformes agréées et leurs clients. Ces flux ne sont pas visibles par le PPF et doivent donc être convertis dans les normes AFNOR et CDAR pour atteindre le PPF.

Par ailleurs, concernant l’e-reporting, le flux 10 n’est pas normé, et l’AIFE est propriétaire de son format.

 

 

1. Quelles données minimales un F1 doit‑il contenir (identités, numérotation, montants, TVA, dates, etc.) selon le profil Base vs profil Full ?

 

Un flux F1 doit obligatoirement intégrer l’ensemble des données règlementaires exigées pour une facture par l’administration fiscale. Ces informations permettent d’identifier les parties et de décrire l’opération. Les principales données attendues sont notamment :

• Nom et adresse des parties ;
• Date d’émission de la facture ;
• Date de la vente ou de la prestation de services ;
• Quantité et dénomination précise des produits ou services ;
• Prix unitaire hors taxe et réductions éventuellement consenties ;
• Date d'échéance du règlement et pénalités en cas de retard ;
• Adresse de facturation, si elle est différente de celle du client ;
• Numéro du bon de commande le cas échéant ;
• Numéro d’identification de l’entreprise (SIREN, SIRET) ;
• Numéro individuel d’identification à la TVA (au-delà de 150 euros) ;
• Date d’émission de la facture et son numéro unique ;
• Adresse de livraison des biens si elle est différente de l'adresse du client ;
• Taux et montant de la TVA.

 

Le profil « Base » correspond au socle minimal de données exigées pour le démarrage de la réforme. Tandis que le profil « Full », dont l’entrée en vigueur est prévue le 01/09/2027, correspond aux données cibles plus détaillées et complètes.

Enfin, chaque facture a l’obligation de suivre la règle d’unicité, afin d’être en mesure d’identifier la facture précisément. Ainsi, le triptyque numéro de facture – numéro de SIREN – année d’émission doit être strictement unique.

 

2. Quels formats structurés sont acceptés pour la transmission du F1 au PPF ?

 

Pour la transmission du flux F1, l’administration fiscale impose l’usage exclusif des formats structurés de facture électronique définis dans la norme AFNOR (XP-Z12 012). Les flux 1 doivent donc être produits dans l’un des deux formats suivants :

• UBL 2.1* (Universal Business Language au format xml) avec la Syntaxe Invoice pour les factures et la Syntaxe CreditNote pour les avoirs ;
• CII D22B* (Cross Industry Invoice au format xml).

 

3. Quel est le format d’envoi exact d’un F1 (archive .tar.gz, fichiers XML internes) et quels formats TAR sont acceptés (USTAR/GNU vs PAX rejeté) ?

 

Un F1 doit être envoyé dans une archive .tar.gz sans extension, contenant obligatoirement un ou plusieurs fichiers XML, portant l’extension .xml.  Le nom de ce(s) fichier(s) doit correspondre à <profil>_<nom-de-fichier>.xml, où <profil> désigne « Base » (données de démarrage de la réforme) ou bien « Full » (données cibles de la réforme, incluant les lignes de facture), les majuscules devant être respectées.

Le fichier TAR est impérativement au format USTAR ou GNU. Le format PAX n’est pas accepté par le PPF et entraîne donc un rejet automatique du flux.

Un flux ne doit pas dépasser la taille maximale d’1 Go, et les fichiers qu’il contient ne doivent pas dépasser la taille maximale de 100 Mo.

 

4. Quelle règle d’unicité s’applique à chaque flux ? Que dois‑je modifier précisément lors d’un rejeu (nom du flux, noms de fichiers, contenu) ?

 

Tout flux transmis au PPF est soumis à une règle d’unicité : un même flux ne peut pas être déposé deux fois. Ainsi, chaque envoi fait l’objet d’un contrôle visant à vérifier qu’aucun flux identique (avec le même nom de flux, de fichiers et le même contenu) n’a déjà été traité par le PPF.

Et dans le cas d’un rejeu de flux, les plateformes agréées doivent obligatoirement modifier le nom du flux, le nom du ou des fichiers et le contenu des fichiers, de manière à garantir que le rejeu constitue un flux nouveau, unique et donc passant pour le PPF.

 

5. Quelles erreurs de nommage/structure provoquent le plus souvent un retour de code 501 irrecevable à la réception d’un F1 par le PPF ?

 

Lorsqu’un F1 est envoyé, le PPF peut retourner un code 501 désignant l’irrecevabilité du flux, ce qui signifie que le flux ne respecte pas les règles attendues. Les erreurs de nommage/structure les plus fréquentes sont les suivantes :

• IRR_SYNTAX indiquant que le format syntaxique de l’un ou plusieurs fichiers n’est pas correct ;
• IRR_TAILLE indiquant que le flux dépasse la taille limite autorisée ;
• IRR_UNICITE indiquant que le flux a déjà été envoyé et réceptionné (cf. la question n°8) ;
• IRR_VIDE indiquant que le flux est vide ;
• IRR_NOM indiquant que le ou les noms de fichier/pièce jointe ne respecte pas les règles de nommage (cf. la question n°29) ;
• IRR_EXTRAC indiquant que l’archive du flux déposé n’a pas pu être extraite ;
• IRR_CODE_APP indiquant qu’aucun raccordement n’existe pour le code application du flux.

 

6. Dans le cas d’un avoir, quelles balises doivent être obligatoirement renseignées en profil Full ?

 

Dans le cas d’un avoir avec l’utilisation d’un profil Full, les balises suivantes sont à remplir obligatoirement :

• Au niveau de l’en-tête de facture : BT-25 et BT-26 ;
• Au niveau des lignes de facture : EXT-FR-FE-136 et EXT-FR-FE-138.

Toutefois, à partir de mai 2026, les plateformes agréées pourront compléter la référence et la date de la facture antérieure uniquement en en-têtes ou au niveau des lignes de facture, mais pas aux deux emplacements.

 

 

1. Quels sont les quatre statuts obligatoires à transmettre au PPF (Déposée, Rejetée, Refusée, Encaissée) et qui les émet dans chaque cas ?

 

Parmi les différents statuts de la facture existants, quatre statuts doivent être obligatoirement transmis au PPF :

• Le statut « Déposée » est transmis par la plateforme d’émission au PPF pour lui signaler que la facture correspondante a bien été transmise à la plateforme de réception ;
• Le statut « Rejetée » peut-être émis :
  • Par la plateforme d’émission du vendeur qui rejette une facture transmise par le vendeur pour non-conformité, avant même l’envoi de la facture à l’acheteur ;
  • Par la plateforme de réception de l’acheteur qui rejette une facture transmise par la plateforme d’émission, pour non-conformité.
• Le statut « Refusée » est émis par l’acheteur vers sa plateforme de réception, qui informe la plateforme d’émission et le PPF de ce refus ;
• Le statut « Encaissée » est émis par le vendeur vers sa plateforme d’émission, qui informe la plateforme de réception et le PPF de l’encaissement de la facture.

 

2. Puis‑je transmettre un F6 unitaire (sans extension .xml) ou dois‑je toujours utiliser une archive .tar.gz ?

 

Pour le flux 6, deux modes de transmission sont possibles :

• Le ou les fichiers sont transmis directement, de manière unitaire, sans l’extension .xml ;
• Le ou les fichiers sont transmis au sein d’une archive .tar.gz, auquel cas ils doivent conserver l’extension .xml.

 

3. Quelles conventions de nommage doit-on appliquer ?

 

Voir question VI-1

 

4. Dans quelles conditions reçoit-on un FFE0654A (cycle de vie d’objet) ?

 

Un FFE0654A correspond au code d’interface d’un flux de cycle de vie d’objet métier d’un statut facture. Ce dernier est envoyé seulement lorsque le fichier contenu dans le flux 6 d’origine (FFE0614A) est rejeté.

 

5. Que signifie ne rien recevoir dans l’heure après un CFE0614A recevable ?

 

Si une plateforme agréée a transmis un F6, a reçu en retour un CFE0614A, indiquant que le cycle de vie de flux est recevable, mais ne reçoit aucun FFE0654A dans l’heure, cela signifie que le flux FFE0614A a bien été intégré dans le PPF.

En effet, le flux 6 constitue un cas particulier : après l’émission du CFE0614A, aucun statut « Déposée » n’est envoyé.

 

6. Les champs MDT‑37/MDT‑38 peuvent‑ils contenir mon matricule PA et le schéma 0238 aujourd’hui ? À partir de quand ce sera accepté ?

 

Dans les fichiers F6 de statuts de facture, le matricule PA et l’identifiant de schéma « 0238 » ne sont, actuellement, pas autorisés dans les champs MDT-37 et MDT-38.

Pour rappel, un identifiant de schéma est une étiquette qui indique à quel type de codification appartient une valeur. Ici, l’identifiant 0238 renseigné en MDT-37 permet d’indiquer que la donnée MDT-38 est un matricule de plateforme.

Toutefois, à partir de décembre 2026, les plateformes agréées (et non le vendeur) pourront indiquer le numéro de matricule PA en MDT-37 et un identifiant de schéma correspondant à « 0238 » en MDT-38.

 

7. Pourquoi un statut « Refusée » peut‑il être rejeté ? Quelle liste officielle de MDT‑113 (v3.0 vs v3.1) est actuellement reconnue en production ?

 

À ce jour, seule la liste officielle de code MDT-113 issue de la version 3.0 des spécifications (annexe 7, onglet « Tableau des motifs de rejet ») est reconnue par le PPF, et ce tant qu’aucune date d’évolution n’a été communiquée.

 

8. Quels motifs de rejet CFE0614A / FFE0654A dois‑je surveiller (REJ_INC/INEX/RG/HAB/ENCAISSEMENT) et comment les interpréter ?

 

Il existe cinq motifs de rejet des données réglementaires des factures transmis par le FFE0654A :

• REJ_INC indiquant que l’un ou plusieurs statuts sont incohérents ;
• REJ_INEX indiquant que l’un ou plusieurs statuts sont incorrects ou non autorisés ;
• REJ_RG indiquant que l’une ou plusieurs règles de gestion ne sont pas respectées ;
• REJ_HAB indiquant que l’une des requêtes n’est pas autorisée et/ou requiert une habilitation ;
• REJ_ENCAISSEMENT indiquant que l’un ou plusieurs montants encaissés ne sont pas conformes à la répartition par taux de TVA déclarée.

 

 

 

1. Qui déclare quoi en e‑reporting : vendeur ou acheteur ?

 

Lorsqu’il s’agit de déclarer des données en e-reporting, la charge revient au vendeur ou à l’acheteur selon certaines situations. Voici les principaux cas de figure :

• Pour les livraisons intra-communautaires, c’est au vendeur de déclarer des données ;
• Pour les exportations, c’est au vendeur de déclarer des données ;
• Pour le B2C domestique et l’international, c’est au vendeur de déclarer des données ;
• Pour les acquisitions intracommunautaires, c’est à l’acheteur de déclarer des données ;
• Pour les autoliquidations, c’est à l’acheteur de déclarer des données ;
• Pour les opérations avec Monaco, c’est :
  • Au vendeur de déclarer des données dans le cas où le vendeur est un assujetti français et l’acheteur un client monégasque ;
  • À l’acheteur de déclarer des données dans le cas où le vendeur est un assujetti monégasque et l’acheteur un assujetti français.
• Pour les importations (hors DOM), ni le vendeur ni l’acheteur n’ont besoin de déclarer des données.

 

2. Quel est le délai d’envoi d’une transmission F10 à l’issue de la période ?

 

Afin de faciliter l’intégration des flux de transmission F10 dans le PPF et leur prise en compte par l’administration fiscale, les plateformes agréées doivent les adresser au PPF dans un délai de huit heures à l’issue du dernier jour du délai de dépôt, au titre de la période.

 

3. Comment fonctionne une transmission rectificative (type RE) ? Remplace‑t‑elle toute la période précédente ?

 

Une transmission rectificative (type RE) permet de corriger les transmissions d’e-reporting initiales et rectificatives envoyées au PPF au titre d’une période. Ce flux de transmission rectificatif annule et remplace l’ensemble des données de transaction ou de paiement agrégées et précédemment transmises au titre de cette période.

 

4. Quelle règle de nommage est demandée pour l’identifiant de flux F10 et dans quels cas utiliser fichiers unitaires vs archive .tar.gz ?

 

Le flux 10 obéit à des règles strictes d’envoi et de nommage.

Son identifiant se compose de trois éléments :

• Un code d’application composé de 6 caractères alphanumériques propres à chaque plateforme
  • Sur QUAL : « PPF » + 3 chiffres ;
  • Sur PROD : « PDP » + 3 chiffres.
• Un code interface composé de 4 chiffres ;
• Un identifiant du flux composé de 15 chiffres définis par l’émetteur.

Et deux modes d’envoi des transmissions sont possibles, selon le volume de fichiers à transmettre et la préférence opérationnelle de l’émetteur :

• Le ou les fichiers sont transmis directement, de manière unitaire, sans l’extension .xml ;
• Le ou les fichiers sont transmis au sein d’une archive .tar.gz, auquel cas ils doivent conserver l’extension .xml.

Un flux ne doit pas dépasser la taille maximale d’1 Go, et les fichiers qu’il contient ne doivent pas dépasser la taille maximale de 100 Mo.

 

5. Quels montants dois‑je déclarer HT/TTC/TVA et dans quels sous‑flux ?

 

Lorsqu’une plateforme agréée agrège des données de factures/transactions et des données de paiement, elle doit déclarer divers montants, dont certains sont hors taxes (HT), d’autres toutes taxes comprises (TTC) et d’autres sont des montants de TVA. Voici un récapitulatif du type de montant à déclarer en fonction des sous-flux :

• Dans la constitution des sous-flux 10.1 et 10.3 :
  • Pour la balise TT-51, c’est le montant total HT ;
  • Pour la balise TT-52, c’est le montant total de TVA ;
  • Pour la balise TT-54, c’est le montant total HT par taux ;
  • Pour la balise TT-55, c’est le montant total de TVA par taux ;
  • Pour la balise TT-82, c’est le montant total HT des transactions déclarées ;
  • Pour la balise TT-83, c’est le montant total de TVA sur les transactions déclarées.
• Dans la constitution des sous-flux 10.2 et 10.4 :
  • Pour la balise TT-95, c’est le montant TTC encaissé par taux ;
  • Pour la balise TT-99, c’est le montant TTC encaissé sur l’ensemble des transactions.

 

6. Quelles sont les dates clés à renseigner et les erreurs fréquentes de cohérence période/date ?

 

Dans le cadre du e-reporting, les entreprises déclarantes et leurs plateformes agréées doivent renseigner les dates suivantes :

• TT-3 : date et heure de création de la transmission ;
• TT-17 & TT-18 : date de début et de fin de la période de transmission ;
• TT-20 : date à laquelle la facture a été émise ;
• TT-41 : date à laquelle la livraison est effectuée ;
• TT-42 & TT-43 : date à laquelle commence et se termine la période de facturation ;
• TT-65 & TT-66 : date à laquelle la période de facturation commence et se terminer pour cette ligne de facture ;
• TT-77 : date à laquelle les transactions ont été comptabilisées pour la période de transmission
• TT-89 & TT-90 : date de début et de fin de la période de transmission des paiements ;
• TT-102 : date de la facture, utilisée pour créer l’identifiant de la facture dans le rapport de paiements.

Par ailleurs, la vigilance est de rigueur dans la cohérence des dates. Il faut veiller à respecter les règles suivantes :

• Aucune année ne peut être à l’extérieur de la période [2000 ; 2099] ;
• Aucune date de facture/transaction/paiement ne doit être positionnée dans le futur ;
• La période ne peut pas être dans le futur et doit être cohérente (la date de début de la période doit être positionnée avant la date de fin de la période).
• Dans le flux 10, toutes les dates sont attendues au format AAAAMMJJ, sans tirets

 

V Comprendre les cycles de vie, les contrôles du PPF et les délais de retour

 

1. Quelle est la différence entre cycle de vie de flux et cycle de vie d’objet métier ?

 

La notion de cycle de vie désigne l’ensemble des réponses produites par le PPF et transmises aux plateformes, suite à l’envoi de fichiers. Ces réponses se font en deux temps :

• L’envoi d’un cycle de vie de flux, qui indique la recevabilité technique ou l’irrecevabilité par le PPF de l’enveloppe d’un flux transmis par une plateforme agréée ;
• Et en cas de flux recevable, l’envoi d’un cycle de vie d’objet métier, qui indique à la plateforme agréée si le contenu du flux est considéré comme étant accepté ou rejeté par le PPF.

 

2. Quels sont les délais attendus de retour des CDV pour F1, F6, F10 ?

 

L’ensemble des cycles de vie de flux du PPF, c’est-à-dire F1, F6 et F10, sont envoyés de manière synchrone et ont donc un délai de réponse inférieur à une minute.

En revanche, les délais de réponse ne sont pas identiques pour les trois cycles de vie d’objet métier du PPF. Le CDV du F10 est toujours envoyé de manière synchrone avec un délai de réponse inférieur à une minute. Tandis que ceux du F1 et du F6 sont envoyés de manière asynchrone avec un délai de réponse de maximum une heure.

Il faut également noter que le cycle de vie d’objet métier pour F6 n’est pas systématiquement envoyé (cf. la question n°III-5).

 

3. Quelles sont les trois conditions qui déclenchent l’envoi des CDV d’objet allotis en e‑invoicing et quelle est l’unité d’allotissement?

 

Le e-invoicing suit des règles de lotissement concernant l’envoi asynchrone des flux de cycle de vie d’objet métier pour les F1 et F6. Ces derniers sont allotis par émetteur, c’est-à-dire qu’un flux de cycle de vie d’objet métier de F1/F6 peut contenir « n » fichiers de cycle de vie, correspondant à « n » flux F1/F6 envoyés par l’émetteur des flux.

Le PPF déclenche l’envoi du cycle de vie d’objet métier F1/F6 lorsque l’une des trois conditions suivantes est atteinte :

• Le flux, c’est-à-dire l’archive tar.gz, comprend 1000 fichiers ;
• Le flux a atteint un volume d’un Go ;
• Un délai d’une heure a été atteint depuis l’envoi du premier F1/F6 par une plateforme.

 

4. Quels motifs de rejet sont communiqués par le PPF suite à la réception de flux 10 ?

 

Il existe quatre motifs de rejet des données de transaction et de paiement :

• REJ_SEM indiquant que le format sémantique d’une ou plusieurs données n’est pas conforme ;
• REJ_UNI indiquant que les données ont déjà été transmises et traitées ;
• REJ_COH indiquant que l’une ou plusieurs données sont incohérentes ;
• REJ_PER indiquant que la date de transmission de données n’est pas cohérente avec la période déclarée (cf. la question n°IV-6).

 

 

 

1. Comment construire correctement le nom du flux et l’identifiant (codes application PPF/PDP, code interface, séquence) pour éviter les rejets d’unicité ?

 

Pour éviter tout rejet d’unicité, le nom d’un flux doit être construit comme suit :

•  Un code interface permettant d’identifier la nature du flux et son format ;
• Un code application partenaire de l’émetteur destinataire du flux, composé de 6 caractères alphanumériques propres à plateforme :
  • Sur QUAL : « PPF » + 3 chiffres ;
  • Sur PROD : « PDP » + 3 chiffres.
• Un identifiant de flux composé de 25 caractères et construit à partir du code application de l’émetteur du flux (6 premiers caractères) et d’un numéro de séquence (19 caractères, chiffres ou lettres majuscules).

 

2. Quelles différences de nommage s’appliquent entre F1 (obligatoirement archive.tar.gz avec <Profil>_<Nom>.xml) et F6/F10 (unitaire possible) ?

 

Un F1 doit obligatoirement être envoyé dans une archive .tar.gz sans extension, contenant obligatoirement un ou plusieurs fichiers XML, portant l’extension .xml.  Le nom de ce(s) fichier(s) doit correspondre à <profil>_<nom-de-fichier>.xml, où <profil> désigne « Base » (données de démarrage de la réforme) ou bien « Full » (données cibles de la réforme, incluant les lignes de facture), les majuscules devant être respectées.

Tandis que pour F6 et F10, en plus du mode de transmission via une archive .tar.gz, leurs fichiers peuvent être envoyés directement, de manière unitaire, sans l’extension .xml.

 

 

 

 

1. Quelles annexes des spécifications externes dois‑je consulter en priorité pour connaitre les balises et les règles ?

 

Pour se renseigner sur les balises et les règles associées, il est conseillé de consulter les annexes des spécifications externes suivantes :

• L’annexe 1 spécifie le format sémantique du flux 1 (e-invoicing) 
• L’annexe 2 spécifie le format sémantique du flux 6 (cycle de vie) 
• L’annexe 7 spécifie les règles de gestion.

Les spécifications externes et ses annexes se trouvent sur cette page : spécifications externes B2B.

 

2. Où trouver la définition précise des balises TT‑* du F10 et leurs XPaths ?

 

L’annexe 6 des spécifications externes aborde le flux 10 (e-reporting), et contient donc la définition précise des balises TT-* du F10 et leurs XPaths.

Cette annexe se trouve à la même page que les spécifications externes et les autres annexes : spécifications externes B2B.