Cette FAQ est destinée pour le seul usage des plateformes agréées.
Les factures ne s’échangent 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 :
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.
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 :
S’agissant du périmètre du e-reporting (B2B international & B2C), les plateformes déclarantes doivent transmettre au 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.
La France n’impose pas l’usage de PEPPOL comme canal obligatoire de transmission de factures. Un raccordement à Chorus Pro via PEPPOL n’est pas prévu à ce stade.
Pour éviter tout rejet d’unicité, le nom d’un flux doit être construit comme suit :
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.
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 :
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.
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 :
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.
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.
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 :
Dans le cas d’un avoir avec l’utilisation d’un profil Full, les balises suivantes sont à remplir obligatoirement :
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.
Une facture rectificative permet de corriger une facture d’origine en l’annulant et en la remplaçant. Elle est le seul moyen de modification d’une facture émise et doit obligatoirement faire référence à la facture initiale (notamment via son numéro).
Une facture d’origine ne peut faire l’objet que d’une seule facture rectificative directe : elle ne peut pas être corrigée simultanément par plusieurs factures rectificatives distinctes. En revanche, une facture rectificative peut elle-même être corrigée par une nouvelle facture rectificative. Il est ainsi possible d’avoir une chaîne de factures rectificatives : par exemple, une facture initiale F1 corrigée par une facture F2, elle-même corrigée par une facture F3, et ainsi de suite.
Parmi les différents statuts de la facture existants, quatre statuts doivent être obligatoirement transmis au PPF :
Pour le flux 6, deux modes de transmission sont possibles :
Cf. la question n°29
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é.
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é.
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.
À 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.
Il existe cinq motifs de rejet possibles pour un flux de déclaration des données réglementaires des factures. Ils sont transmis par le FFE0654A :
Pour le statut de facture « Rejetée », trois codes motifs sont utilisés lorsqu’un problème d’adressage empêche l’acheminement ou la prise en compte :
1) DEST_INC : Destinataire inconnu
Ce motif est utilisé lorsque le SIREN de l’acheteur n’est pas trouvé dans l’annuaire du PPF. La description associée est la suivante : « À l’émission, le destinataire est inconnu. Il n’existe pas dans l’annuaire. »
2) ADR_ERR : Adresse de facturation électronique erronée
Ce motif est utilisé lorsque l’adresse de facturation électronique du destinataire est absente ou erronée :
3) REJ_ADR : Contrôle d’adressage
Ce motif est utilisé lorsque l’adresse est bien présente dans l’annuaire, mais n’est pas encore active.
Ce cas couvre notamment une adresse assignée à une plateforme, avec une date de début d’effet dans le futur (ex. StatutPlateforme = PA_ATTENTE) : le rejet rentre alors dans le cadre de REJ_ADR.
DOUBLON : motif utilisé lorsqu’une facture est détectée comme doublon (même numéro, même vendeur/fournisseur et même année de date de facture).
REJ_UNI : ce code « Contrôle d’unicité » ne concerne pas les factures ; il peut s’appliquer à d’autres objets/traitements (par exemple : demande de création d’une ligne d’annuaire, dépôt d’un e‑reporting initial, ou un statut déjà transmis).
Dans le cas d’une ligne de facturation non-active de l'acheteur dans l'annuaire central du PPF, la norme impose que la facture ne soit pas rejetée mais qu’un message de cycle de vie (Flux 6 / CDAR) soit émis par la plateforme agréée d'émission (du vendeur) vers le PPF avec le statut Déposée / NON_TRANSMISE.
Une fois ce Flux 6 transmis et accepté par le PPF, aucun autre statut réglementaire n’est attendu du côté de la plateforme agréée d'émission.
Concernant la transmission de la facture à l'acheteur, la plateforme d'émission doit prévenir l'acheteur de la non-distribution de sa facture. Et dans ce cas, il est à la charge du vendeur de transmettre la facture par un autre moyen (email, dépôt SFTP, courrier, etc.). Il revient ensuite à l'acheteur d'indiquer qu'il a traité la facture.
L’annuaire du PPF ne référence effectivement que les adresses électroniques de réception des assujettis à la TVA en France. Les adresses du vendeur, notamment celles renseignées en BT‑34, ne sont pas tenues d’être présentes dans l’annuaire (norme AFNOR XP Z12-012 et son Annexe B V1.3).
La transmission de la mise à jour des statuts s'opère via l’interopérabilité PA <-> PA. Cette interopérabilité peut reposer sur :
In fine, l’émetteur de la facture (le vendeur) obtiendra bien le retour du statut CDV de l’acheteur, via sa plateforme agréée.
Pour rectifier l’envoi d’un mauvais statut de cycle de vie, il est possible de renvoyer le statut correspond à l'état de la facture précédent cette erreur, dans son cycle de vie. Les statuts étant une liste d'étapes du traitement de la facture, c'est l'horodatage du statut qui permet au destinataire de déterminer l'état en cours de la facture.
Dans le cas où le statut « Paiement transmis » a été appliqué par erreur sur une facture, il est tout à fait possible de transmettre un nouveau statut « Paiement transmis » avec un montant négatif pour indiquer l'annulation du paiement.
L’« annulation » d'un statut n'est pas prévue aujourd'hui au niveau de la norme. Néanmoins, il sera inscrit à l'ordre du jour des groupes de travail AFNOR.
Le statut « Annulé » n’est pas obligatoire et peut être généré par l’acheteur ou le vendeur selon le bon vouloir de chaque acteur. De manière générale, la facture (F1) est « Annulée » lorsque la facture (F2) qui vient la remplacer ou la corriger est prise en compte par son destinataire. Le statut sur F1 peut être donc être générée par le vendeur lorsqu'il reçoit le statut « Approuvée » de F2 ou par l'acheteur lorsqu'il génère ce statut sur F2.
Au démarrage de la réforme (septembre 2026), c'est la date de création du cycle de vie « Encaissée » (renseignée en MDT-8) qui sera prise en compte pour le pré-remplissage de la TVA.
À partir de 2027, une évolution est prévue pour intégrer une « date d'encaissement » distincte (renseignée en MDT-219, conformément à la version 1.3 de la norme Z12-012). Cette date correspondra :
La transmission de données de-reporting doit respecter une règle d'unicité : une seule déclaration d'e-reporting peut être effectuée par période, par plateforme agrée et par déclarant. Cela veut dire qu'une entité peut effectuer autant de déclarations qu'elle dispose de plateformes agréées.
Dans le cas particulier où le fichier à envoyer serait trop volumineux, un découpage pourra être réalisé.
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 :
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.
Les flux 10.1, 10.2, 10.3 et 10.4 ne doivent pas être envoyés en un seul flux F10 unique. Il est possible d'émettre
Les transactions sont effectivement à reporter dans une période différente de celle des paiements.
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.
Le flux 10 obéit à des règles strictes d’envoi et de nommage.
Son identifiant se compose de trois éléments :
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 :
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 le cadre du e-reporting, les entreprises déclarantes et leurs plateformes agréées doivent renseigner les dates suivantes :
Par ailleurs, la vigilance est de rigueur dans la cohérence des dates. Il faut veiller à respecter les règles suivantes :
Pour les acquisitions, l'e-reporting n'a pas l'obligation de contenir les lignes de détail, les totaux en pied suffisent. En revanche, il est recommandé pour les ventes de détailler les lignes de facture ; et à partir de septembre 2027, cela deviendra obligatoire.
Le traitement des opérations DROM / COM repose sur une distinction fiscale définie dans la norme AFNOR XP Z12-014 (cas d’usage n°44), qui distingue deux groupes :
La nature du flux à produire dépend donc de la combinaison des territoires impliqués dans la transaction :
Un déclarant peut faire appel à plusieurs plateformes agréées pour transmettre ses données F10 agrégées. Dans ce cas, les plateformes agréées ne sont responsables que du contrôle et la transmission des données F10 agrégées qui leur sont confiées par le déclarant. L’administration fiscale cumulera les données en cas de transmission via plusieurs plateformes.
Voici les principes à retenir concernant l’agrégation des données d’e-reporting :
Si votre fichier e-reporting dépasse la taille d'envoi maximale (100 Mo), vous pouvez créer plusieurs transmissions initiales pour une même déclaration. Cela signifie que vous devez scinder votre fichier en plusieurs parties, chacune respectant la limite de taille, et les envoyer séparément comme des transmissions initiales distinctes pour la même période déclarative.
Le PPF ne contrôle pas la date de réception du flux e-reporting, donc il ne peut pas refuser un flux d'e-reporting transmis en retard. Il le traite et le transmet à l’administration fiscale, qui reste seul décisionnaire de l’acceptation ou du refus de la déclaration.
Le PPF contrôle uniquement :
En cas de rejet d'un e-reporting, une nouvelle transmission initiale doit être réalisée avec les données corrigées. Cette retransmission est acceptée même si le délai de transmission est dépassé (sous réserve de précisions ultérieures concernant la prise en compte de ces données pour le préremplissage).
Si le délai n’est pas dépassé, la correction peut être effectuée et renvoyée dans la période en cours via une transmission rectificative.
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’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°15).
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 :
Il existe quatre motifs de rejet des données de transaction et de paiement :
La plateforme agréée n'a aucune obligation de conservation des flux du moment qu'elle s'est assurée de leur correcte transmission. Tant que le flux n'est pas validé par les différentes parties, il est essentiel de le conserver pour y apporter les correctifs éventuels.
Cependant, la plateforme agréée a l'obligation de conserver les preuves démontrant la traçabilité et l'existence des contrôles concernant les accès, l'utilisation de l'annuaire, les processus de traitements des factures et des données de facturation, de transaction et de paiement. Elle doit pouvoir démontrer qu'elle assure l'authenticité et l'intégrité des données. Les délais de conservation de cette traçabilité sont actuellement de 6 ans et bientôt 10 ans avec la loi anti-fraude.
Pour se renseigner sur les balises et les règles associées, il est conseillé de consulter les annexes des spécifications externes suivantes :
Les spécifications externes et ses annexes se trouvent sur cette page : spécifications externes B2B.
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.
En cas de difficulté, vous pouvez joindre notre support en émettant un ticket.
Chaque environnement (qualification et production) dispose d’un portail de support propre pour émettre des tickets.
Privilégiez le dépôt de ticket en étant connecté à votre compte.
Retrouvez au lien suivant le mode opératoire pour émettre un ticket au support.