Facturation électronique - Plateformes agréées - FAQ Service Déclaration


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

 

Table des matières

 

I. Généralités et périmètre

 

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 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 :

 

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 :

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

 

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.

 

5. Quel fuseau horaire doit être utilisé pour les horodatages dans les flux de cycle de vie (F6) ?

Tous les horodatages générés par le PPF dans les flux de cycle de vie (F6) sont exprimés avec le fuseau horaire de Paris :

A ce stade, le PPF ne réalise pas de contrôle sur le fuseau horaire des horodatages présents dans les F6 reçus ; il vérifie uniquement si le format date / date-heure est respecté.
Toutefois, afin de garantir une cohérence globale des données métier entre les flux F6 reçus et ceux émis par le PPF, il est recommandé aux plateformes agréées d’utiliser également le fuseau horaire de Paris (UTC+1 en hiver / UTC+2 en été) pour l’ensemble des horodatages transmis.

 

6. Est-ce que le raccordement G2B à Chorus Pro est-il obligatoire ?

Les plateformes agréées doivent obligatoirement se raccorder à Chorus Pro pour le circuit G2B, via un raccordement EDI.

En revanche, 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.

 

7. Que dois-je faire si je n'arrive pas à me connecter au raccordement SFTP ?

Si un message d’erreur apparaît lors de la connexion à votre raccordement SFTP, vérifiez que le login de votre certificat est bien votre code application partenaire (AABxxx).

 

8. Une plateforme agréée peut-elle accéder aux données du PPF depuis un pays situé hors de l'Union européenne ?

Il n'est pas possible qu'une société, dont l'activité de « plateforme agréée » se situe en dehors de l'UE, puisse accéder aux données de facturation du PPF.

Pour rappel, une société étrangère (située hors UE) peut avoir une activité de plateforme agréée autorisée uniquement si :

- L'activité de PA (la branche plateforme agréée) se situe en UE, avec du personnel sous contrat de travail européen afin d'éviter les lois extra-territoriales ;

- Les données sont bien hébergées en Union Européenne et respectent les obligations définies (SecNumCloud).

Par ailleurs, les décisions d'adéquation de la Commission Européenne, reconnaissant que le Royaume-Uni dispose du même niveau de protection de données personnelles que l'UE, concernent uniquement les données personnelles et non les données professionnelles. Le transfert de données personnelles au Royaume-Uni est ainsi autorisé, mais pas le transfert de données professionnelles et donc du PPF.

 

II. Les règles de nommage à connaître et le principe d’unicité des flux

 

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 :

 

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.

 

III.  Comprendre l’e-invoicing et le Flux F1 des données réglementaires

 

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 :

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 :

 

3. Quel est le délai d'envoi du flux de données réglementaires de la facture (F1) au PPF ?

Le flux F1 doit être transmis au PPF dans un délai maximum de 24 heures à compter de l’émission du statut de cycle de vie « Déposée » de la facture (statut obligatoire).

 

4. 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.

 

5. 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.

 

6. 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 :

 

7. 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 :

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.

 

8. Le SIREN présent dans l'identifiant d'adressage doit-il correspondre au SIREN de l'acheteur renseigné dans la facture ?

Pour les factures relevant du périmètre de l'e-invoicing (hors autofacturation), l'adresse électronique de l'acheteur (BT-49) doit être renseignée sous la forme SIREN ou SIREN_XXX, avec un schemeID (BT-49-1) égal à 0225. Le SIREN utilisé dans cet identifiant d'adressage doit bien correspondre au SIREN de l'acheteur renseigné en BT-47.

Chorus Pro et le PPF contrôlent la cohérence entre l'identifiant d'adressage de l'acheteur et le SIREN de l'acheteur renseigné dans la facture.

 

9.  Qu’est-ce qu’une facture rectificative ?

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.

 

10. Que dois-je faire si une facture de type F2 ou F3 est acceptée par la plateforme agréée, alors que le F1 est rejeté, refusé ou déclaré irrecevable par le PPF ?

L’acceptation d’une facture F2 ou F3 par la plateforme agréée de réception est indépendante du traitement du F1 par le PPF.  Ainsi, même si la facture est acceptée, un flux F1 rejeté, refusé ou déclaré irrecevable par le PPF doit impérativement être corrigé rapidement puis renvoyé dès que possible.

 

11. Que dois-je faire si mon flux de factures au format Factur-X est déclaré irrecevable par Chorus Pro ?

En cas d'irrecevabilité d'un flux contenant une facture au format Factur-X, il convient de vérifier en priorité que le PDF associé est conforme au format requis par la norme Factur-X. Vous pouvez vérifier la conformité du PDF à l'aide de l'outil de validation suivant : Ave PDF.

 

IV. Comprendre le flux des cycles de vie (F6) et les statuts de facture

 

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 :

 

2. Le statut « Encaissé » est-il définitif ?

Le statut « Encaissé » n'est pas définitif. En effet, une facture déjà payée peut être refusée par le destinataire, notamment en cas d'erreur. Cela implique alors de corriger le cycle de vie si le statut « Encaissé » a déjà été envoyé, en relançant un cycle de vie pour annuler le statut.

 

3. 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 :

 

4. Quelles conventions de nommage doit-on appliquer ?

Cf. la question n°29

 

5. 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é.

 

6. 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é.

 

7. 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.

 

8. 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.

 

9. 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 possibles pour un flux de déclaration des données réglementaires des factures. Ils sont transmis par le FFE0654A :

 

10. Quels sont les motifs de rejet liés à l’adressage pour le statut de facture « Rejetée » (DEST_INC, ADR_ERR, REJ_ADR) ?

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.

 

11. Quelle est la différence entre les motifs « DOUBLON » et « REJ_UNI » ?

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).

 

12. Que dois-je faire pour remettre une facture à l’acheteur lorsque sa ligne d’annuaire est inactive ou ne permet pas son adressage via le PPF ?

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.

 

13. En l’absence d’information sur l’adresse de retour de cycle de vie dans l’annuaire PPF, comment le statut cycle de vie est retourné au vendeur ?

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.

 

14. Que dois-je faire si j’ai appliqué un statut cycle de vie à une mauvaise facture ?

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.

 

15.  À qui revient la responsabilité de générer un cycle de vie « Annulé » à la suite de la réception de la facture rectificative : l’acheteur ou le vendeur ?

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.

 

16. Quelle date doit-être communiquée au PPF pour le cycle de vie « Encaissé » dans le cadre du pré-remplissage de la TVA à l’encaissement ?

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 :

 

V.     Comprendre l’e‑reporting et le flux F10

 

1. Quelle est la règle d’unicité des déclarations d’e-reporting ?

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é.

 

2. 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 :

 

3. 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.

 

4. Faut-il envoyer un seul flux 10 unique ?

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.

 

5. 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.

 

6. 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 :

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 :

 

7. 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 :

 

8. 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  :

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

 

9. Dans le cadre de l’e-reporting, est-il obligatoire de recevoir le détail des lignes de facture afin de recalculer les totaux avant transmission au PPF ?

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.

 

10. Les plateformes agréées doivent-elles gérer les flux B2Bi/Bi2B avec les DROM/COM ?

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 :

 

11. Quelle est ma responsabilité en tant que plateforme agréée lorsqu’un déclarant fait appel à plusieurs plateformes pour transmettre des données pour un même SIREN et une même période ?

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.

 

12. En tant que plateforme agréée, est-ce que je dois agréger les factures reçus de mes clients en régime réel normal mensuel uniquement en fonction de la date de réception, ou dois-je prendre en compte la date de la facture pour déterminer la période de déclaration (1-10, 11-20, 21-31 du mois) ?

Voici les principes à retenir concernant l’agrégation des données d’e-reporting :

 

13. Que dois-je faire si mon fichier e-reporting dépasse la taille maximale d’envoi autorisée ?

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.

 

14. Que se passe-t-il si je dépasse le délai de déclaration e-reporting sur une période ?

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 :

Pour transmettre un flux e-reporting hors délai, il est possible d'ajouter les données dans la transmission pour la période suivante ou de faire une transmission rectificative pour la période concernée, cette dernière option étant à privilégier. Il n'y a pas de délai imposé d'un point de vue technique pour effectuer une transmission rectificative.

En revanche, la transmission hors délai implique l'absence de préremplissage de la déclaration de TVA. Il conviendra de la vérifier et de la compléter le cas échéant.

 

15. Que dois-je faire en cas de rejet (code 301) d’un e-reporting contenant des erreurs, notamment si le délai de transmission est dépassé ?

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.

 

16. Dans le cadre d'un Assujetti Unique (groupe TVA), les données de e-reporting doivent-elles être transmises au niveau de l'Assujetti Unique ou au niveau de chacun de ses membres ?

Pour les opérations de e-reporting relatives aux ventes B2C, aux opérations B2B internationales, aux acquisitions internationales ainsi qu'aux données de paiement associées, il est autorisé de transmettre un flux 10 distinct pour chaque membre de l'Assujetti Unique. Cette règle s'applique également lorsque plusieurs membres de l'Assujetti Unique utilisent la même plateforme agréée. Il n'est donc pas nécessaire de transmettre un unique flux 10 consolidé pour l'ensemble de l'Assujetti Unique.

VI. 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 :

 

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°15).

 

3. Quelles règles d'allotissement les plateformes agréées doivent-elles appliquer aux flux qu'elles transmettent au PPF ?

Afin de préserver les capacités de service du PPF, les plateformes agréées doivent obligatoirement allotir les flux transmis au PPF. Les données doivent ainsi être regroupées par émetteur, dans des flux contenant plusieurs objets métiers, c'est-à-dire qu'un flux peut contenir « n » fichiers, correspondant à « n » flux envoyés par l'émetteur des flux.

Le PPF déclenche l'envoi du flux lorsque l'une des trois conditions suivantes est atteinte :

Par ailleurs, une limite de 1000 flux par heure et par émetteur est actuellement fixée.

 

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 :

 

VII.Pour aller plus loin

 

1. Une plateforme agréée a-t-elle l’obligation de conserver les flux de facturation électronique et quelles preuves doit-elle être en mesure de fournir ?

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.

 

2. Une plateforme agréée a-t-elle l’obligation d'identifier le type de document (facture, avoir, acompte, etc.) et d'établir les liens entre les documents associés (facture d'acompte et factures définitive après acompte, facture initiale et facture rectificative, etc.) ?

Une plateforme agréée a l'obligation d'identifier le type de document. En revanche, elle n'a pas l'obligation d'établir les liens entre les documents associés, puisqu'elle ne reçoit pas forcément tous les documents de l'entité (si celle-ci a plusieurs plateformes agréées de réception par exemple). C'est donc à l'entité elle-même de contrôler la présence d'une facture antérieure en cas d'avoir ou de facture rectificative par exemple, et de traiter ensuite la facture.

 

3. 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 :

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

 

4. 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.

 

5. Une plateforme agréée peut-elle recevoir une facture finale après acompte dont certains acomptes référencés dans ses données structurées ne lui sont pas parvenus ?

Il est en effet possible d’avoir une facture finale après acompte dont des acomptes référencés ne parviendront pas à la plateforme agréée, notamment si un acheteur dispose de plusieurs plateformes agréées. Dans ce cas, la plateforme agréée ne doit pas appliquer de blocage de cette facture ; l’acheteur sera libre d'accepter ou non la facture finale après acompte.

VIII. Nous contacter

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.