3 Présentation du portail public de facturation (PPF)

3 Présentation du portail public de facturation (PPF)

Coller ici le texte original de la section 3 Présentation du portail public de facturation (PPF).

3.1 Les principes directeurs du portail public de facturation (PPF)

Le portail public de facturation (PPF) est l’opérateur public qui : • administre l’annuaire central29 ; • concentre les données de facturation, de transaction et de paiement ainsi que des informations relatives aux statuts de traitement des factures (cycle de vie)30 et transmet ces données à l’administration fiscale.

3.2 La cartographie des flux échangés

Il existe quatre types de flux échangés entre les acteurs de l’écosystème : • les flux e-invoicing ; • les flux de cycle de vie ; • es flux e-reporting ; • les flux annuaire. Figure 4 - Cartographie des flux échangés entre les acteurs de l'écosystème N° de flux Acteurs Description PAE PPF Administration fiscale F1 : Flux de données réglementaires de facture31, au format syntaxique UBL ou CII. Toute plateforme d’émission (PA ou Chorus Pro) a l’obligation d’assurer l’extraction de ces données réglementaires à partir des flux de factures (F2 et/ou F3, cf. infra) qu’elle émet pour le compte de ses clients, et de transmettre le flux correspondant au portail public de facturation (PPF). Le PPF contrôle puis transmet ce flux à l’administration fiscale. Fournisseur PAE PAR Acheteur F2 : Flux de factures électroniques relevant des transactions domestiques entre entreprises ou avec la sphère publique (B2B ou B2G ou G2B), dans l’un des 3 formats syntaxiques du socle (UBL, CII, Factur-X), en fonction de l’offre de services des plateformes (PAE, PAR ou Chorus Pro). Ces factures doivent contenir a minima l’ensemble des données réglementaires car elles sont exploitées par la PAE pour générer le flux de données réglementaires (F1) avant sa transmission au PPF. Ce flux de factures (F2) n’est pas transmis au PPF. Le flux de factures (F2) est transmis par le fournisseur à la PAE. Sur la base des informations d’adressage et de routage contenues dans l’annuaire, la PAE transmet la facture à la PAR de l’acheteur. Selon les souhaits de l’acheteur, la PAR peut convertir la facture au format syntaxique UBL, CII, Factur-X ou autre format (F3, cf. infra) en fonction de son offre de services, avant de lui mettre à disposition. Fournisseur PAE PAR Acheteur F3 : Flux de factures électroniques relevant des transactions domestiques entre entreprises ou avec la sphère publique (B2B ou B2G ou G2B), dans un format syntaxique autre que l’un des 3 formats du socle (UBL, CII, Factur-X), en fonction de l’offre de services des plateformes (PAE, PAR ou Chorus Pro). Ces factures doivent contenir a minima l’ensemble des données réglementaires pour permettre leur exploitation par la PAE pour générer le flux de données réglementaires (F1) avant sa transmission au PPF. Ce flux de factures (F3) n’est pas transmis au PPF. Le flux de factures est transmis par le fournisseur à la PAE. Sur la base des informations d’adressage et de routage contenues dans l’annuaire, la PAE transmet la facture à la PAR de l’acheteur, si cette dernière est en mesure de l’accepter. Selon les souhaits de l’acheteur, la PAR peut convertir la facture au format syntaxique UBL, CII, Factur-X ou autre format (F3) en fonction de son offre de services, avant de lui mettre à disposition. 31 Les mentions obligatoires d’une facture sont définies à l’article 242 nonies A de l’annexe II au CGI, et les données réglementaires sont définies à l’article 41 septies D de l’annexe IV au CGI. Fournisseur PAE PAR Acheteur PPF Administration fiscale F6 : Flux de cycle de vie, au format syntaxique CDAR32. Le cycle de vie véhicule les statuts des objets métiers, nécessaires à tous les acteurs de la chaîne de facturation pour connaître l’évolution des traitements. En fonction des cas, ce flux peut être : – - transmis par le fournisseur à la PAE ; – - transmis par l’acheteur à la PAR ; – - généré par les plateformes (PAE ou PAR). Toute plateforme (PAE ou PAR) a l’obligation de transmettre au PPF les statuts obligatoires véhiculés par ce flux de cycle de vie. Le PPF contrôle puis transmet ce flux à l’administration fiscale. Le PPF émet également des cycles de vie pour tous les objets métiers qu’il reçoit des plateformes : flux, données réglementaires de factures (F1), données de cycle de vie (F6) et/ou annuaire (F13). Fournisseur PAE PAR Acheteur F7 : Flux de cycle de vie, dans un autre format syntaxique que le CDAR, en fonction de l’offre de services des plateformes (PAE et PAR). Le cycle de vie véhicule les statuts des objets métiers, nécessaires à tous les acteurs de la chaîne de facturation pour connaître l’évolution des traitements. Ces flux de cycles de vie doivent véhiculer a minima l’ensemble des données relatives aux statuts obligatoires de factures pour permettre leur exploitation par les plateformes (PAE et PAR) pour générer le flux de cycle de vie (F6) avant sa transmission au PPF. Ce flux de cycle de vie (F7) n’est pas transmis au PPF. En fonction des cas, ce flux peut être : – - transmis par le fournisseur à la PAE ; – - transmis par l’acheteur à la PAR ; – - généré par les plateformes (PAE ou PAR). Fournisseur PAE PAR Acheteur F8 : Flux de factures électroniques relevant des opérations interentreprises internationales (B2Bi, Bi2B et Bi2Bi), au format syntaxique UBL, CII, Factur-X ou autre format en fonction de l’offre de services de la PAE du fournisseur et/ou de la PAR de l’acheteur. En fonction de leur offre de services, les PAE et PAR peuvent accepter et s’échanger ce type de facture, et les traiter de manière analogue (réception, contrôle, traitement, transmission) aux factures électroniques des opérations 32 Le format CDAR supporté par le portail public de facturation (PPF) est UN/CEFACT SCRDM CI Cross Domain Application Response message. interentreprises domestiques (B2B)33 selon les règles posées par la norme AFNOR pour ces factures. Ce flux est transmis par le fournisseur à sa PAE, ou par l’acheteur à sa PAR, qui le convertit en flux de données de transmission (flux 10), pour traitement des données et transmission au PPF34. Fournisseur PAE F9 : Flux de factures électroniques relevant des opérations auprès de non-assujettis (B2C), au format syntaxique UBL, CII, Factur-X ou autre format en fonction de l’offre de services de la PAE du fournisseur. En fonction de leur offre de services, les PAE peuvent accepter ce type de facture, et les traiter de manière analogue (réception, contrôle, traitement, transmission) aux factures électroniques des opérations interentreprises domestiques (B2B)35 selon les règles posées par la norme AFNOR pour ces factures. Il est transmis par le fournisseur à sa PAE, qui le convertit en flux de données de transmission (flux 10), pour traitements des données et transmission au PPF36. Fournisseur PAE PAR Acheteur F10 : Flux de transmission de données de transaction et de paiement relevant d’opérations interentreprises internationales (B2Bi, Bi2B, Bi2G et Bi2Bi) ou auprès de non-assujettis (B2C, G2C). En fonction des cas, ce flux peut être : – - transmis par le déclarant assujetti (le fournisseur ou l’acheteur en fonction des cas) à sa plateforme de déclaration ; – - généré par la plateforme du déclarant assujetti à partir de flux de factures électroniques (flux 8 et 9). A l’issue de la période de déclaration (définie par le régime fiscal du déclarant assujetti), la plateforme de déclaration agrège l’ensemble des flux 10, transmis ou générés au titre de la période. Le flux de transmission de données de transaction et de paiement doit être transmis par la plateforme (PAE et PAR) de manière agrégée au PPF. Le PPF contrôle puis transmet ce flux à l’administration fiscale. 33 Ces factures ne doivent pas faire l’objet de production d’un flux 1 ni de transmission des cycles de vie (flux 6) au PPF. 34 Modalités de traitement et de transmission des données de transaction et de paiement décrits dans les articles 41 septies L à P de l’annexe IV au CGI. 35 Ces factures ne doivent pas faire l’objet de production d’un flux 1 ni de transmission des cycles de vie (flux 6) au PPF. 36 Modalités de traitement et de transmission des données de transaction et de paiement décrits dans les articles 41 septies L à P de l’annexe IV au CGI. Fournisseur PAE PAR Acheteur F11 : Flux de consultation de l’annuaire transmis, en fonction de son offre de services, par une plateforme (PAE ou PAR) à ses utilisateurs (fournisseur ou acheteur). En fonction des cas, ce flux permet à : • un fournisseur d’obtenir les informations d’adressage nécessaires à l’émission d’une facture vers un acheteur ; • un acheteur de vérifier que ses informations d’adressage sont correctes et à jour. Acheteur PAR F12 : Flux d’actualisation de l’annuaire transmis par un acheteur vers sa PAR, en fonction de son offre de services. Ce flux permet à un acheteur de corriger ou mettre à jour ses informations d’adressage de factures. PAR PPF F13 : Flux d’actualisation de l’annuaire transmis par une PAR au PPF. Ce flux permet à une plateforme de corriger ou mettre à jour, pour le compte de ses utilisateurs, leurs informations d’adressage de factures. PAE PAR PPF F14 : Flux de consultation de l’annuaire transmis par le PPF aux plateformes (PAE ou PAR). En fonction des abonnements choisis par les plateformes, elles peuvent recevoir à une fréquence régulière, un export complet de l’annuaire (flux « full ») ou seulement les mises à jour de l’annuaire réalisées au cours d’une période définie (flux « différentiel »). Les flux échangés directement avec le portail public de facturation (PPF), et les données qu’ils contiennent, sont décrits dans les annexes 1 à 6 de ce présent document.

3.3 Le raccordement au portail public de facturation (PPF)

Coller ici le texte original de la section 3.3 Le raccordement au portail public de facturation (PPF).

3.3.1 Les principes directeurs

Un raccordement matérialise l’interconnexion entre un partenaire37 et le portail public de facturation (PPF) pour les échanges depuis l’une de ses applications : 37 On désigne « partenaire » tout système d’information (SI) raccordé au PPF. 38 PISTE : plateforme d’intermédiation des services pour la transformation de l’Etat. 39 Les partenaires habilités ont un compte sur le portail de service (en qualification et en production), sont rattachés à une structure de type « PA » et ont le profil dédié « Raccordements modification ». • un raccordement EDI est associé aux éléments suivants : le code application du partenaire, le protocole technique d’échange, le certificat du partenaire, ses abonnements ; • un raccordement API est associé aux éléments suivants : une application déclarée dans le compte du partenaire ouvert dans l’application PISTE38, un code application du partenaire et un compte technique. Le portail public de facturation (PPF) assure la gestion des raccordements en EDI et en API des partenaires : • la création des raccordements, la mise à jour et la désactivation des raccordements ; • la consultation des informations relatives à un raccordement. Ces fonctionnalités seront accessibles aux partenaires habilités39 depuis le portail de services Chorus Pro.

3.3.2 Le raccordement en EDI

Les raccordements EDI avec le portail public de facturation (PPF) ont vocation à permettre l’échange de flux volumineux afin d’en assurer un traitement en masse. Le portail public de facturation met à disposition des partenaires raccordés en EDI, les protocoles d’échanges SFTP, AS/2 et AS/4 (cf. infra). Un partenaire40 ne peut utiliser qu’un seul de ces protocoles par raccordement. 40 On désigne « partenaire » tout SI raccordé au PPF. 41 Bi-clé RSA. 42 Le certificat SFTP de la norme X509v3 du partenaire contenant la clé RSA publique et d’autres informations comme l’identité du partenaire, l’autorité de certification (AC) qui a émis le certificat, ainsi que la période de validité du certificat. 43 Via des URL, sur les principes d’échanges TLS. 44 AES128_CBC et AES256_CBC. 45 Le délai de retrait des fichiers est fixé à une durée d’une semaine (7 jours). Passé ce délai, les fichiers sont automatiquement purgés et ne sont par conséquent plus disponibles.

3.3.3 Le raccordement en API

Les raccordements API avec le portail public de facturation (PPF) ont vocation à permettre l’échange de données avec un partenaire. L’un des avantages du mode API est de capitaliser sur les outils informatiques déjà déployés au sein de la structure du partenaire, en y intégrant des données additionnelles et/ou complémentaires. Les services API du portail public de facturation (PPF) sont exposés via la plateforme d’intermédiation des services pour la transformation de l’Etat61 (PISTE). Les services API proposés par le portail public de facturation (PPF) sont caractérisés par : • un mode d’authentification OAuth2 ; • des principes architecturaux de type REST ; • l’envoi de requête de données réalisé via le protocole HTTP; • des messages au format JSON ou XML ou un code retour HTTP ; • des appels synchrones (i.e. la connexion est maintenue après chaque appel jusqu’à obtention de la réponse) ; • l’utilisation des verbes GET, POST, PUT et DELETE ; • l’utilisation d’URL pour le versionnage des API62 ; • une gestion multi-langue63. 63 Un paramètre d’entrée de langue sera positionné au niveau des paramètres d’appel API de façon à recevoir les messages de retour API (techniques ou fonctionnels) en français (FR). Le choix de la langue anglaise (EN) sera proposé ultérieurement. 64 Ces API sont décrites dans la documentation technique relative à l’annuaire (swagger publié sur PISTE). 65 Cf. chapitre dédié 3.5.L’annuaire 66 Cf. Chapitre 7 – Documentation applicable : Spécifications externes initiales B2G/G2G de Chorus Pro – Annexe EDI. 67 La plateforme de qualification est accessible depuis le 03/02/2025. À la suite de l’appel d’une API par un partenaire, le serveur retourne des données (JSON ou XML) ou un code retour HTTP. Dans le cas d’un code retour de type erreur, ce retour détaille l’erreur rencontrée dans le corps du message. Les erreurs techniques peuvent être de 2 types : • une erreur client est associée au code d’erreur 40x ; • une erreur serveur est associée au code d’erreur 50x. Les principaux codes retours HTTP sont : Code retour Libellé 200 Ok 201 Ok, une nouvelle ressource a été créée 204 Ok, la ressource a été supprimée 206 La requête est traitée sans erreur, mais le volume d’information renvoyée a été réduit 400 La requête est invalide ou ne peut pas aboutir 401 La requête n’est pas autorisée et nécessite l’authentification de l’utilisateur 403 La requête est refusée ou l’accès n’est pas autorisé 404 Il n’y a pas de ressource correspondante à l’URL donnée 408 Le délai maximal de la requête est atteint 422 Erreur de validation des données 429 Le nombre maximal d’appels dans un délai donné est atteint 500 Une erreur interne au serveur est survenue 501 La ressource n’est pas implémentée 503 Le service est actuellement indisponible Tableau 1 - Liste des codes retours HTTPS Les principaux services API64 proposés par le portail public de facturation (PPF) relèvent du périmètre de l’annuaire PPF65.

3.3.4 La création d’un raccordement

Chaque plateforme agréée (PA) devra mettre en place a minima un raccordement EDI, en suivant la procédure dédiée66 et dans le respect des exigences de sécurité définies par l’AIFE. Elle pourra choisir, via un système d’abonnement, les flux (interfaces) qu’elle souhaite transmettre et recevoir. Ces raccordements devront être testés depuis la plateforme de qualification67 prévue à cet effet. Pour créer un raccordement EDI, le partenaire doit : • choisir le protocole d’échange ; • fournir un certificat RGS 1* (minimum) qui doit être unique et valide ; • choisir ses abonnements aux interfaces (émission et/ou réception) ; • fournir les caractéristiques techniques (information réseaux) ; • fournir un contact facilitant les échanges. Pour créer un raccordement API, le partenaire doit : • déclarer le nom de l’application PISTE qui doit être unique ; • fournir un contact facilitant les échanges. Figure 2 - La mise en place d’un raccordement au portail public de facturation (PPF)

3.3.5 La modification d’un raccordement

Un partenaire peut modifier son raccordement EDI pour : • mettre à jour son certificat ; • mettre à jour ses abonnements aux interfaces (ajout, suppression) ; • mettre à jour la date de fin de son raccordement qui permet de désactiver le raccordement à une date fixée par le partenaire ; • modifier le contact technique. Un partenaire peut modifier un raccordement API pour : • mettre à jour le nom de l’application PISTE ; • désactiver le raccordement API ; • modifier le contact technique.

3.3.6 La consultation d’un raccordement

Un partenaire peut consulter tous les raccordements API et EDI liés à ses structures, via une IHM dédiée. Toutes les informations du raccordement sont restituées, ainsi que le statut courant du raccordement et la date d’expiration du certificat pour un raccordement EDI.

3.4 Le système d’échanges

Coller ici le texte original de la section 3.4 Le système d’échanges.

3.4.1 Les principes directeurs

Le système d’échanges (SE) assure la gestion des transferts entre les systèmes d’informations (SI) partenaires et le SI du portail public de facturation (PPF). L’authentification du partenaire est réalisée via son code application, défini lors de la création de son raccordement. A partir du code application, le système d’échanges contrôle les informations suivantes : • l’existence et la validité, d’un raccordement pour ce code application partenaire ; • la typologie de flux associée à l’abonnement de ce raccordement ; • le protocole technique d’échange à utiliser. Seuls les partenaires raccordés sont autorisés à transmettre des flux au système d’échange, en fonction de la typologie de flux à laquelle ils sont abonnés en émission et/ou en réception, ainsi que le protocole d’échange qu’ils ont choisi à cet effet.

3.4.2 Les contrôles techniques

Tout flux entrant, émis par un partenaire raccordé et habilité, est contrôlé. Les contrôles techniques suivants sont réalisés sur le flux et les fichiers qu’il contient68 : 68 L’ensemble des fichiers contenus dans un flux sont de même nature et de même format. 69 Les extensions autorisées sont tar.gz et xml. 70 La taille maximale autorisée pour un flux est de 1Go, et chaque fichier contenu dans le flux ne doit pas dépasser une taille maximale de 120 Mo. 71 Ces contrôles sont décrits au travers de XSD. 72 Tous les fichiers générés par le PPF sont encodés en UTF-8 et tous les fichiers xml reçus doivent être encodés en UTF-8. • contrôle antivirus ; • contrôle du contenu (non vide) ; • contrôle d’extension69 ; • contrôle de taille du flux et du nombre de fichiers contenus dans le flux 70 ; • contrôle d’enveloppe et d’unicité.

3.4.3 Les contrôles applicatifs

Si les contrôles techniques ne retournent aucune anomalie sur le flux, alors des contrôles applicatifs sont réalisés sur chaque fichier pour s’assurer que : • chaque fichier est exploitable ; • chaque fichier est conforme aux dispositions réglementaires et/ou syntaxiques71.

3.4.4 Le cycle de vie d’un flux

Tout flux reçu par le portail public de facturation (PPF) - hors cycle de vie de flux - fera l’objet d’un cycle de vie72 transmis au partenaire émetteur, afin d’informer ce dernier de l’état de traitement de ce flux par le PPF. Objet Code Libellé Caractère Définition Flux 500 Recevable Obligatoire Le flux est contrôlé et conforme. Flux 501 Irrecevable Obligatoire Le flux est contrôlé mais non conforme. Tableau 2 - Les statuts possibles d'un flux Un flux est irrecevable si : • le résultat d’un ou plusieurs contrôles techniques est en échec ; • le résultat d’un ou plusieurs contrôles applicatifs est en échec. Figure 12 - L'irrecevabilité d'un flux en cas d'échec aux contrôles applicatifs

3.4.5 Les motifs d’irrecevabilité d’un flux

L’irrecevabilité d’un flux est associée à un ou plusieurs motifs, et la source des anomalies73 est indiquée, afin de permettre au partenaire de réaliser les actions correctives adaptées. 73 L’identifiant du flux et/ou des fichiers contrôlés comme non conformes. Les motifs d’irrecevabilité d’un flux sont : Code Libellé Description IRR_TAILLE Contrôle de taille du Le flux dépasse la taille limite autorisée. IRR_TAILLE_F Contrôle de taille des L’un ou plusieurs fichiers contenus dans le flux IRR_TAILLE_PJ Contrôle de taille des L’une ou plusieurs pièces jointes dépassent la taille IRR_UNCITE Contrôle d’unicité Le flux a déjà été envoyé et réceptionné. IRR_VIDE Contrôle de flux non Le flux est vide. IRR_VIDE_F Contrôle des fichiers L’un ou plusieurs fichiers contenus dans le flux sont IRR_VID_PJ Contrôle des pièces L’une ou plusieurs pièces jointes sont vides. IRR_FORM Contrôle du nom de Le nom du flux ne respecte pas les règles de IRR_NOM_F Contrôle du nom des Le nom d’un ou plusieurs fichiers ne respecte pas les IRR_NOM_PJ Contrôle du nom des Le nom d’une ou plusieurs pièces jointes ne respecte IRR_TYPE Contrôle de type et Le type et/ou l’extension du flux ne sont pas IRR_TYPE_F Contrôle de type et Le type et/ou l’extension des fichiers contenus dans le IRR_EXT_DOC Contrôle de type et Le type et/ou l’extension des pièces jointes dans le flux IRR_ANTIVIRUS Contrôle anti Le flux ne respecte pas les conditions de sécurité. IRR_CODE_INTER Code interface Le code interface du flux n’est pas connu du système. IRR_EXTRAC Extraction de l’archive L'archive du flux IRR_CODE_APP Contrôle du code Aucun raccordement n'existe pour le code application IRR_SYNTAX Contrôle syntaxique Le format syntaxique de l’un ou plusieurs fichiers n’est 74 Une règle de nommage pour les fichiers F1 impose le format suivant : <profil>_<nom_de_fichier>.xml. Le <profil> permet de traiter efficacement ces flux en fonction de la trajectoire des données réglementaires (cf. chapitre dédié 3.6.3Les données réglementaires d’une facture), et peut prendre les deux valeurs « Base » et « Full ». Des fichiers de profils différents peuvent être présents au sein d’un même flux. Tableau 3 - Liste des motifs d'irrecevabilité Si les contrôles techniques et applicatifs ne retournent aucune anomalie alors le flux (ainsi que chaque fichier qu’il contient) est recevable. Figure 13 - La recevabilité d'un flux en cas de succès des contrôles techniques et applicatifs Dans un cas de recevabilité comme d’irrecevabilité, le système d’échanges va allotir les objets cycles de vie nécessaires75 à la constitution d’un flux76. Une fois constitué, le système d’échanges adresse le flux au partenaire, via le protocole technique d’échange que ce dernier a choisi lors de la création de son raccordement. 75 Les critères d’allotissement sont : le code application partenaire, la nature du flux, le format du flux, la taille maximale d’un flux, le nombre maximal de fichiers contenus dans un flux et le délai maximal de mise à disposition des informations. 76 De type archive « tar.gz ». 77 Lorsque le flux est émis par un partenaire au PPF (flux entrant) alors le code application du partenaire émetteur du flux est à renseigner. Lorsque le flux est émis par le PPF (flux sortant) à un partenaire alors le code application du partenaire destinataire du flux est renseigné.

3.4.6 Le nommage des flux

L’enveloppe d’un flux est composée de : • un code interface qui permet d’identifier la nature du flux et son format ; • un code application partenaire de l’émetteur destinataire du flux77 ; • un identifiant de flux (25 caractères) 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). Figure 14 - La composition de l'enveloppe d'un flux Recommandation AIFE : Il est recommandé de construire l’identifiant du flux comme suit : - code application (CCCCCC) : 6 caractères alphanumériques - code interface (IIII) : 4 chiffres - identifiant du flux (XXXXXXXXXXXXXXX) : 15 chiffres définis par l’émetteur. Figure 15 – Recommandation de composition de l'identifiant d'un flux Exemple : Dépôt d’un flux de données réglementaires (F1) au format UBL avec le code interface FFE0111A et le code application partenaire AAA123 : FFE0111A_AAA123_AAA1230111000000000000001. Les codes interfaces attendus pour chaque type de flux sont : N° de flux Description Format (syntaxe) Code interface F6 Cycle de vie de flux CDAR CFE + IIIIV (issus du code Cycle de vie de factures CDAR FFE0614A Cycle de vie de données CDAR FFE0604A Cycle de vie de statuts obligatoires CDAR FFE0654A Cycle de vie de données de CDAR FFE0624A Cycle de vie d’actualisation de CDAR FFE0634A F1 Données réglementaires UBL FFE0111A CII FFE0112A F10 Données de transaction et de Format FFE1025A F13 Actualisation de l’annuaire Format spécifique FFE1235A F14 Export de l’annuaire Format spécifique FFE1435A 78 Le code interface d’un flux cycle de vie se rapportant à un objet de type flux est constitué à partir de l’enveloppe de ce flux d’origine, en changement uniquement la première lettre F par C. 79 Ce cycle de vie sera transmis exclusivement par le portail public de facturation (PPF). Tableau 4 - Liste des codes interfaces par type de flux Exemples : • Une plateforme agréée d’émission (code application : AAA123) transmet un flux de données obligatoire - F1 au format UBL (numéro de séquence : 0111000000123456789) au portail public de facturation (code application : PPF001) : Une image contenant texte, capture d’écran, ligne, Police Le contenu généré par l’IA peut être incorrect. Figure 16 - Cinématique des flux F1 • Une plateforme agréée d’émission (code application : AAA123) transmet un flux de statuts réglementaires - F6 (numéro de séquence : 0614000000123456789) au portail public de facturation (code application : PPF001) : Une image contenant texte, capture d’écran, ligne, Police Le contenu généré par l’IA peut être incorrect. Figure 17 - Cinématique des flux F6 A noter : le PPF n’émet de cycle de vie (statuts réglementaires) – F6 que dans le cas où les statuts réglementaires transmis par la plateforme sont rejetés (i.e. : une anomalie a été détectée à l’issue des contrôles fonctionnels). • Une plateforme agréée d’émission (code application : AAA123) transmet un flux de transmission - F10 (numéro de séquence : 1025000000123456789) au portail public de facturation (code application : PPF001) : Une image contenant texte, capture d’écran, ligne, Police Le contenu généré par l’IA peut être incorrect. Figure 18 - Cinématique des flux F10 • Une plateforme agréée de réception (code application : BBB123) transmet un flux d’actualisation de l’annuaire - F13 (numéro de séquence : 1235000000123456789) au portail public de facturation (code application : PPF001) : Une image contenant texte, capture d’écran, ligne, Police Le contenu généré par l’IA peut être incorrect. Figure 3 - Cinématique des flux F13 • Le portail public de facturation émet un flux de consultation - F14 (numéro de séquence : 1435000000123456789) à une plateforme agréée (code application : AAA123) : Figure 4 - Cinématique des flux F14 A noter : la plateforme agréée n’émet pas de cycle de vie (ligne d’annuaire) – F6 au portail public de facturation.

3.5 L’annuaire

Coller ici le texte original de la section 3.5 L’annuaire.

3.5.1 Les principes directeurs

Le dispositif de facturation en Y choisi dans le cadre de la réforme nécessite la mise en place d’un annuaire permettant aux différentes plateformes agréées immatriculées d’échanger des factures électroniques pour le compte d’entreprises assujetties. Le portail public de facturation (PPF) assure l’administration centralisée de cet annuaire et sa mise à disposition aux plateformes et aux entreprises. L’annuaire référence toutes les structures possédant un SIREN, qui sont identifiées comme assujetties à la TVA par l’administration fiscale, ainsi que l’ensemble des entités publiques assujetties ou non. Il contient les informations d’identification de ces structures et de leurs plateformes de réception. Ainsi, l’annuaire est : • une ressource clef du portail public de facturation mise à disposition des entreprises pour adresser les factures et leurs statuts au bon destinataire ; • un service proposé par le portail public de facturation (PPF) aux plateformes agréées pour assurer le routage des factures. L’annuaire centralisé s’appuie sur plusieurs principes directeurs permettant de fiabiliser les échanges dématérialisés prévus dans le cadre de l’obligation de la facturation électronique : • la centralisation : l’annuaire rassemble l’ensemble des acteurs concernés par la réforme (assujettis et acheteurs publics) dans un référentiel unique ; • l’interopérabilité : l’annuaire est accessible à tout utilisateur habilité ; • la précision : l’annuaire garantit un niveau d’information exhaustif et actualisé permettant le bon adressage des factures et de leurs statuts, ainsi que leur routage ; • la sécurité : l’annuaire garantit la sécurité et la traçabilité des mises à jour des données.

3.5.2 La cartographie des flux

Plusieurs types de flux sont impliqués dans les interactions avec l’annuaire : • les flux d’actualisation et de consultation de l’annuaire ; • les flux de cycle de vie (flux80 et annuaire81) ; 80 Cf. le chapitre dédié 3.4.4.Le cycle de vie d’un flux 81 Cf. le chapitre dédié 3.5.7.Le cycle de vie des objets métiers du type ligne d’annuaire Figure 5 - La cartographie des flux Annuaire échangés

3.5.3 L’initialisation de l’annuaire

L’annuaire est alimenté par des informations issues du registre des structures privées, des structures publiques, des assujettis à la TVA et des plateformes immatriculées : • le registre des entreprises privées, extrait du répertoire des entreprises de l’INSEE, contenant les SIREN (unités légales) et SIRET (établissements) des entreprises privées établies en France et actives ; • le registre des structures publiques, issu du portail de services Chorus Pro, contenant les SIRET (établissements) et les services (code routage) des structures publiques destinataires de factures B2G/G2G ; • le registre des assujettis à la TVA française, issu des référentiels de l’administration fiscale ; • le registre des plateformes agréées immatriculées par le service dédié de l’administration. Figure 6 - Les sources d'initialisation de l'annuaire A partir de ces informations, le portail public de facturation (PPF) constitue des lignes d’annuaire à la maille SIREN. Une ligne d’annuaire est unique et contient toutes les informations nécessaires à l’adressage et au routage d’une facture : • les informations d’identification de l’entreprise destinataire de la facture ; • les informations d’identification de la plateforme de réception à qui transmettre la facture ; • la période durant laquelle ces informations sont en vigueur. Une image contenant texte, capture d’écran, ligne, Police Le contenu généré par l’IA peut être incorrect. Figure 23 - La structure d'une ligne d'annuaire La nature d’une ligne d’annuaire permet : • dans le cas d’une ligne de « définition », de constituer une ligne d’annuaire qui porte l’ensemble des informations nécessaire à l’adressage et au routage de factures ; • dans le cas d’une ligne de « masquage », d’annuler la prise d’effet d’une ligne d’annuaire, telle qu’elle a été définie au préalable. La période de validité d’une ligne d’annuaire est composée : • d’une date de début d’effet, soit la date à laquelle la ligne entre en vigueur ; • d’une date de fin d’effet, soit la date à laquelle la ligne ne devrait plus être en vigueur ; • d’une date de fin effective, soit la date à laquelle la ligne n’est plus en vigueur. Dans le cas nominal, la date de fin effective d’une ligne d’annuaire est égale à sa date de fin d’effet. Néanmoins certains évènements exogènes82 ont pour conséquence de raccourcir la période durant laquelle une ligne d’annuaire est en vigueur. Dans ce cas, la date de fin effective correspond à la date d’occurrence de cet évènement, et est antérieure à la date de fin d’effet initialement prévue. Toute ligne d’annuaire dont la date de fin d’effet est échue n’est plus adressable ni consultable. 82 Par exemple, la perte du caractère assujetti d’une entreprise, la perte d’immatriculation d’une PA. Les informations d’identification de l’entreprise peuvent être organisées en différentes mailles d’adressage : • La maille d’une unité légale (SIREN) • La maille d’un établissement (SIRET) • La maille d’un code routage • La maille d’un suffixe Ces mailles d’adressage offrent la possibilité aux entreprises d’adapter les modalités de réception de leurs factures à leur fonctionnement de gestion administrative et comptable interne. En effet, une entreprise peut souhaiter recevoir et traiter ses factures de manière centralisée (exemple : à son siège social), ou de manière décentralisée (exemple : au sein de ses différents points de vente, ou de ses services de comptabilité et de gestion de paie, etc.). Lors de l’initialisation de l’annuaire, des lignes d’annuaire par défaut sont créées par le portail public de facturation (PPF) : • pour les entreprises privées, à la maille de l’unité légale (SIREN). Une plateforme « fictive » est attribuée par défaut à ces lignes d’annuaire ; • pour les structures publiques83,à la maille de l’établissement (SIRET) et à la maille code routage. Chorus Pro est attribuée par défaut comme plateforme de réception à ces lignes d’annuaire. 83 Une ligne d’annuaire à la maille code routage peut également être créée, si l’organisation de la structure publique est renseignée comme telle dans le portail de services Chorus Pro. Les plateformes agréées de réception (PAR) auront la possibilité d’actualiser les lignes d’annuaire des entreprises privées créées lors de l’initialisation, et d’en ajouter d’autres de manière à paramétrer la maille de réception de factures des entreprises pour le compte desquelles elles agissent.

3.5.4 La consultation de l’annuaire

La création de la facture par un fournisseur - depuis son système d’information, via une solution compatible (SC) ou sa plateforme agréée d’émission (PAE) - nécessite la consultation de l’annuaire pour confirmer les informations d’adressage de l’acheteur à indiquer dans la facture. Afin de transmettre la facture à son destinataire (acheteur), la consultation de l’annuaire par la plateforme d’émission du fournisseur est nécessaire pour obtenir les informations de routage de la plateforme de réception choisie et associée aux données d’adressages référencées dans la facture. Figure 7 - La consultation de l'annuaire pour l'adressage et le routage de facture L’annuaire est consultable via : • Le canal EDI par les partenaires habilités, raccordés et abonnés : o un flux différentiel est émis par le portail public de facturation (PPF) toutes les 24h, et contient une extraction de l’annuaire (fichier au format spécifique XML) retraçant l’ensemble des modifications réalisées sur cette durée ; o un flux complet est émis par le portail public de facturation (PPF) à une fréquence hebdomadaire, et le flux complet est produit dans la nuit du dimanche au lundi, sur la base des données présentes dans l’annuaire le dimanche. Lors de la mise en place de l’abonnement à ce type de flux, une extraction de l’annuaire (fichier au format spécifique XML défini dans l’annexe 3 des spécifications externes) référençant l’ensemble des informations en vigueur à la date de constitution du flux est mis à disposition du partenaire raccordé. Ces flux84 s’adressent en particulier aux partenaires qui souhaitent importer les données de l’annuaire dans leurs systèmes d’informations et/ou les intégrer dans leurs outils de gestion. 84 La structure de ces flux d’actualisation (F14), et les données qu’ils contiennent, sont décrites dans l’annexe 3 des spécifications externes. • Le canal API par les partenaires habilités et raccordés. Les ressources Unité légale (SIREN), Établissement (SIRET), Code routage, Plateforme et Ligne d’annuaire, ainsi que les informations qu’elles contiennent, sont : o disponibles en service de recherche (méthode POST). Les résultats de la recherche répondant à des critères, sont paginés et retournés au format souhaité (champs, tri) ; o disponibles en service de consultation (méthode GET). L’ensemble des attributs de la ressource sont restitués. • Le canal Portail pour tout autre utilisateur, sans nécessité d’authentification et habilitation. Une IHM expose une vision consolidée des informations d’adressage, en cours de vigueur à la date de la consultation, et des informations d’adressage futures, relatives aux entreprises destinataires de factures, qu’elles soient privées ou publiques. Les informations de routage relatives aux plateformes de réception (matricules) ne sont pas exposées. Une image contenant texte, capture d’écran, logiciel, Page web Le contenu généré par l’IA peut être incorrect. Figure 8 - Page d'accueil du Portail Annuaire ( https://facturation.chorus-pro.gouv.fr/annuaire/#/ ) Consultation de page Figure 9 - Exemple d'écran de consultation du Portail Annuaire

3.5.5 L’actualisation de l’annuaire

L‘annuaire est actualisé avec : • des informations issues du répertoire des entreprises de l’INSEE ; • des informations issues du registre des assujettis à la TVA française de l’administration fiscale ; • des informations issues du service dédié à l’immatriculation des plateformes agrées (PA) ; • des informations issues du portail de services Chorus Pro ; • des informations actualisées par les plateformes agréées immatriculées. 3.5.5.1. L’actualisation de l’annuaire depuis le répertoire des entreprises 3.5.5.2. L’actualisation de l’annuaire par le registre des assujettis à la TVA française de l’administration fiscale L’annuaire est actualisé quotidiennement par interrogation du répertoire des entreprises de l’INSEE, afin d’obtenir tous les changements apportés aux entreprises présentes dans l’annuaire. Cette actualisation quotidienne permet ainsi de maintenir à jour les informations d’identification des entreprises (raison sociale, adresse postale, état administratif, statut de diffusion) et de leurs établissements (dénomination, adresse postale, état administratif, statut de diffusion). Les établissements secondaires créés seront également ajoutés à l’annuaire lors de cette actualisation pour permettre aux plateformes agréées de créer des lignes d’annuaire correspondantes. Un flux quotidien provenant du registre des assujettis à la TVA française de l’administration fiscale à destination du portail public de facturation (PPF) est prévu de manière à transmettre toutes les mises à jour de ce registre et actualiser les informations de l’annuaire en conséquence lorsque : • une entreprise est nouvellement assujettie à la TVA française ; • une entreprise n’a plus le caractère d’assujetti. Figure 10 - L'actualisation de l'annuaire par le référentiel des occurrences fiscales Dans le cas d’une entreprise nouvellement assujettie : • les données de l‘entreprise85, obtenues auprès du répertoire des entreprise de l’INSEE, sont ajoutées à l’annuaire ; • les données des établissements de cette entreprise en activité au moment de son insertion dans l’annuaire (obtenues auprès de l’INSEE) sont ajoutées à l’annuaire ; • une ligne d’annuaire à la maille de l’entité légale (SIREN) est créée par défaut, et une plateforme « fictive » de matricule 9998 est attribuée à cette ligne. 85 Si l’entreprise est déjà connue de l’annuaire (assujettissement faisant suite à une perte d’assujettissement précédente), les données sont actualisées. Figure 11 - La création d’une ligne d'annuaire pour une entreprise nouvellement assujettie Dans le cas d’une entreprise n’ayant plus le caractère d‘assujetti, les lignes d’annuaire existantes pour cette entreprise sont actualisées : • une date de fin effective est attribuée automatiquement à chaque ligne d’annuaire en cours de vigueur ; • une ligne d’annuaire de type « masquage » est générée automatiquement pour chaque ligne d’annuaire dont la date de début d’effet est postérieure au retrait du caractère assujetti. Une image contenant texte, Police, nombre, ligne Le contenu généré par l’IA peut être incorrect.

3.5.6 Les contrôles fonctionnels des objets métiers du type ligne d’annuaire

Si les contrôles techniques et applicatifs ne retournent aucune anomalie sur le flux (et les fichiers qu’il contient), alors la bulle métier annuaire réalise des contrôles fonctionnels90 sur chaque fichier : 90 Ces contrôles sont décrits au travers de schematrons. 91 En l’occurrence, pour chaque actualisation de ligne d’annuaire. • des contrôles sémantiques ; • des contrôles de structure de données ; • des contrôles de cohérence de données ; • des contrôles d’unicité.

3.5.7 Le cycle de vie des objets métiers du type ligne d’annuaire

Le résultat des contrôles fonctionnels détermine le statut de chaque objet métier91 : • dès lors que le résultat des contrôles fonctionnels est en échec, alors l’objet métier est rejeté et ne sera pas intégré ; • si les contrôles fonctionnels ne relèvent aucune anomalie, l’objet métier est accepté et intégré. Figure 27 - L'actualisation des lignes à la suite de la mise en place d'une nouvelle maille d'adressage Tout partenaire, raccordé en EDI, est informé via un cycle de vie du caractère accepté ou rejeté des objets métiers qu’il a transmis. Objet Code Libellé Cara Définition Ligne d’annuaire 400 Acceptée Obligatoire La ligne d’annuaire est contrôlée comme conforme et intégrée. Ligne d’annuaire 401 Rejetée Obligatoire La ligne d’annuaire est contrôlée comme non conforme et n’est pas intégrée. Tableau 5 - Liste des statuts d'une ligne d’annuaire

3.5.8 Les motifs de rejet des objets métiers du type ligne d’annuaire

Le rejet d’un objet métier est associé à un ou plusieurs motifs, et la source des anomalies est indiquée, afin de permettre au partenaire de réaliser les actions correctives adaptées. Les motifs de rejet d’un objet métier de type ligne d’annuaire sont : Code Libellé Description REJ_RG Contrôle des règles de gestion L’une ou plusieurs règles de gestion ne sont pas respectées. REJ_HAB Contrôle des droits et habilitations L’une des requêtes n’est pas autorisée et/ou requiert une habilitation. REJ_COH Contrôle de cohérence des données L’une ou plusieurs données sont incohérentes. REJ_VAL_INC Contrôle des valeurs autorisées L’une ou plusieurs valeurs sont incorrectes ou non autorisées. Tableau 6 – Liste des motifs de rejet d'une ligne d'annuaire

3.6 La bulle e-invoicing

Coller ici le texte original de la section 3.6 La bulle e-invoicing.

3.6.1 Les principes directeurs

Le dispositif de facturation en Y choisi dans le cadre de la réforme permet aux plateformes de transmettre à l’administration fiscale, par l’intermédiaire du portail public de facturation, les données réglementaires92 et les statuts obligatoires93 de factures électroniques pour les transactions domestiques entre assujettis à la TVA établis, domiciliés ou ayant leur résidence habituelle en France. 92 Les mentions obligatoires d’une facture sont définies à l’article 242 nonies A de l’annexe II au CGI, et les données de facture à transmettre à l’administration sont énumérées à l’article 41 septies D de l’annexe IV au CGI. 93 Le format sémantique du cycle de vie est décrit dans l’annexe 2. Le portail public de facturation assure le contrôle de ces données réglementaires et les statuts obligatoires associés, puis les transmet à l’administration fiscale.

3.6.2 La cartographie des flux

Il existe différents types de flux qui interviennent lors de la transmission des données réglementaires et des statuts obligatoires de facture à l’administration fiscale : • les flux e-invoicing (facture94, données réglementaires95) ; • les flux de cycle de vie (flux96, données réglementaires et statuts obligatoires97). 94 Le flux de factures électroniques (F2, F3) n’est pas transmis au PPF. 95 Les formats sémantiques des données obligatoires sont décrits dans l’annexe 1 des spécifications externes. 96 Cf. chapitre dédié 3.4.4.Le cycle de vie d’un flux 97 Cf. chapitre dédié 3.6.7.Le cycle de vie des objets métiers du type données réglementaires et statuts obligatoires Figure 28 - La cartographie des flux e-invoicing et Cycle de vie échangés en B2B Une image contenant texte, capture d’écran, diagramme, Police Le contenu généré par l’IA peut être incorrect. Figure 29 - La cartographie des flux e-invoicing et Cycle de vie échangés en B2G, si Chorus Pro est la plateforme de réception Une image contenant texte, capture d’écran, diagramme, ligne Le contenu généré par l’IA peut être incorrect. Figure 30 - La cartographie des flux e-invoicing et Cycle de vie échangés en B2G, si Chorus Pro est la plateforme d'émission et réception

3.6.3 Les données réglementaires d’une facture

Les données réglementaires d’une facture soumise au champ d’application de la TVA respectent le format sémantique de la norme EN16931, complété par des règles de gestion spécifiques à la législation française98. De plus, pour couvrir l’ensemble des cas de gestion, des extensions à la norme EN16931 sont prévues99. 98 Le format sémantique des données réglementaires est décrit dans l’annexe 1. 99 Les extensions à la norme EN16931 sont identifiées dans l’annexe 1 par un libellé EXT-FR-FE-XXX. 100 Cf. le chapitre dédié 2.3.5.La mise en conformité progressive des assujettis à la TVA 101 A compter du 1er septembre 2026. 102 Le format UBL supporté par le portail public de facturation (PPF) est conforme à la norme OASIS U.B.L. 2.1. 103 Le format CII supporté par le portail public de facturation (PPF) est conforme à la norme UN/CEFACT CCTS 3.0. La version de langage retenue dans le cadre de la réforme est le CII D22B. En raison de la mise en conformité progressive100 avec la réforme de facturation électronique, un socle de données réglementaires de facture est exigé dès le démarrage101, et sera complété au moment de la généralisation du dispositif. Ces données doivent être transmises à l’administration fiscale dans une archive tar.gz dans l’un des formats structurés suivants : • UBL102 ; • CII103.

3.6.4 Les statuts obligatoires d’une facture

La transmission et la mise à jour du statut des factures tout au long de son cycle de vie sont essentielles pour répondre aux enjeux et atteindre les objectifs fixés par la réforme. Le cycle de vie104 d’une facture permet à chacun des acteurs impliqués (fournisseurs, acheteurs, plateformes agréées, portail public de facturation et administration fiscale) de suivre l’avancement du traitement des factures dans le circuit de facturation, du dépôt de la facture jusqu’à son encaissement. Ces données sont transmises à l’administration fiscale dans le format structuré CDAR105. 104 Le format sémantique du cycle de vie est décrit dans l’annexe 2 des spécifications externes. 105 Le format CDAR supporté par le portail public de facturation (PPF) est UN/CEFACT SCRDM CI Cross Domain Application Response message. 106 Lorsqu’ils sont apposés par l’un des acteurs du circuit de facturation. Le cycle de vie répond aux principes fondateurs suivants : • offrir une vision partagée du traitement de la facture pour l’ensemble des acteurs intéressés (émetteur, récepteur, administration et tous les tiers référencés dans la facture) ; • déterminer une liste et un format d’échange des statuts permettant d’assurer l’interopérabilité entre les acteurs (entreprises, plateformes agréées, portail public de facturation) ; • favoriser une qualité de service pour assurer le respect de la chronologie du traitement d’une facture ; • définir des règles strictes et faciliter le pré-remplissage de la déclaration de la TVA. Le cycle de vie repose sur deux périmètres imbriqués : • un socle de statuts obligatoires106 nécessaires à l’administration et à tous les acteurs de la chaîne de facturation ; • un socle de statuts facultatifs qui ne doivent pas être transmis à l’administration fiscale, mais qui sont recommandés pour assurer le bon déroulé des échanges acteurs de la chaîne de facturation. Une image contenant texte, logiciel, diagramme, Icône d’ordinateur Le contenu généré par l’IA peut être incorrect. Figure 31 - Le cycle de vie nominal d'une facture Les statuts possibles d’un cycle de vie sont : Objet Code Libellé Caractère Définition Facture 200 Déposée Obligatoire La facture du fournisseur est transmise à sa plateforme agréée d’émission (PAE), qui atteste que la facture est contrôlée et conforme. Facture 201 Emise par la plateforme Facultatif La plateforme agréée d’émission (PAE) informe avoir transmis la facture à la plateforme agréée de réception (PAR) du destinataire. Facture 202 Reçue par la plateforme Facultatif La plateforme agréée de réception (PAR) informe avoir reçu la facture de la part de la plateforme agréée d’émission (PAE). Facture 203 Mise à disposition Facultatif La plateforme agréée de réception (PAR) informe avoir mis à disposition la facture à son destinataire. Facture 204 Prise en charge Facultatif Le destinataire accuse réception de la facture. Facture 205 Approuvée Facultatif Le destinataire accepte la facture dans son intégralité. Facture 206 Approuvée partiellement Facultatif Le destinataire n’accepte que partiellement la facture. Facture 207 En litige Facultatif Le destinataire est en désaccord avec tout ou partie de la facture. Facture 208 Suspendue Facultatif Le destinataire souhaite obtenir des pièces justificatives complémentaires et suspend le traitement de la facture jusqu’à leur réception. Facture 209 Complétée Facultatif Le fournisseur fournit des pièces justificatives complémentaires attendues par le destinataire de la facture. Facture 210 Refusée Obligatoire Le destinataire refuse la facture dans son intégralité. Facture 211 Paiement transmis Facultatif Le destinataire informe avoir réalisé le paiement de la facture, ou le fournisseur informe avoir réalisé le remboursement de la facture. Facture 212 Encaissée Obligatoire Selon les conditions définies par l’article 290 A du CGI, le fournisseur informe avoir perçu un paiement partiel ou total de la facture. Facture 213 Rejetée Obligatoire L’un des contrôles fonctionnels réalisés par la plateforme agréée d’émission (PAE) ou de réception (PAR) a détecté une anomalie sur la facture. Tableau 7 - Les statuts d'une facture Dans les cas des statuts « Refusée » ou « Rejetée », le fournisseur doit procéder à une annulation comptable (avoir interne). Cette opération ne doit pas générer de flux de données réglementaires (F1) au PPF.

3.6.5 Délai de transmission des flux de cycle de vie de statuts obligatoires

Afin de faciliter l’intégration des flux de cycle de vie (statuts obligatoires) dans le portail public de facturation (PPF) et leur prise en compte par l’administration fiscale, les plateformes agréées (PAE ou PAR) les adressent au portail public de facturation (PPF) dans un délai de 24h à compter de l’horodatage du statut.

3.6.6 Les contrôles fonctionnels des données réglementaires et des statuts obligatoires

Si les contrôles techniques et applicatifs ne retournent aucune anomalie sur le flux (et les fichiers qu’il contient), alors la bulle métier e-invoicing va réaliser des contrôles fonctionnels107 sur chaque fichier108 : 107 Ces contrôles sont décrits au travers de schematrons. 108 Chaque fichier est « mono-objet », c’est à dire qu’il ne contient qu’un objet métier. 109 Contrôles des règles de gestion de la norme européenne (EN16931) et celles spécifiques à la réforme française de facturation électronique. 110 Contrôles des longueurs maximales. 111 Contrôles de cohérences avec les valeurs des référentiels mentionnées dans l’annexe 7 des spécifications externes. 112 Le contrôle de l’unicité est réalisé uniquement sur les données réglementaires de facture. L’unicité est déterminée à partir du numéro de facture, de l’identifiant du fournisseur (SIREN) et de l’année de production de la facture. 113 En l’occurrence, pour chaque donnée réglementaire et chaque donnée de cycle de vie. • des contrôles sémantiques109 ; • des contrôles de structure de données 110 ; • des contrôles de cohérence de données 111 ; • des contrôles d’unicité112.

3.6.7 Le cycle de vie des objets métiers du type données réglementaires et statuts obligatoires

Le résultat des contrôles fonctionnels détermine le statut de chaque objet métier113 : • dès lors que le résultat des contrôles fonctionnels est en échec, alors l’objet métier est rejeté et ne sera pas intégré ; • si les contrôles fonctionnels ne relèvent aucune anomalie, l’objet métier est accepté et intégré. Figure 32- Le cycle de vie d’un objet métier Tout partenaire est informé via un cycle de vie, du caractère accepté ou rejeté des objets métiers qu’il a transmis. Objet Code Libellé Caractère Définition Données réglementaires 250 Déposée Obligatoire Les données réglementaires sont contrôlées comme conformes et transmises à l’administration fiscale. Données réglementaires 251 Rejetée Obligatoire Les données réglementaires sont contrôlées comme non conformes, elles ne sont pas intégrées et ne sont pas transmises à l’administration fiscale114. 114 Seule l’information du rejet avec le numéro de facture, l’année d’émission de la facture et le SIREN du vendeur sont transmises à l’administration fiscale. Tableau 8 - Liste des statuts de données réglementaires Objet Code Libellé Caractère Définition Statuts obligatoires 601 Rejeté Obligatoire Les statuts obligatoires sont contrôlés comme non conformes et ne sont pas intégrés. Tableau 9 - Liste des statuts des données de cycle de vie d'une facture

3.6.8 Les motifs de rejet des objets métiers du type données réglementaires

À la suite de la transmission de données réglementaires d’une plateforme au PPF, celui-ci peut les rejeter en définissant un ou plusieurs motifs. La source des anomalies est indiquée, afin de permettre au partenaire de réaliser les actions correctives adaptées. Les motifs de rejet des données réglementaires sont : Code Libellé Description REJ_SEMAN Contrôle du format sémantique Le format sémantique d’une ou plusieurs données n’est pas conforme. REJ_UNI Contrôle d’unicité Les données réglementaires ont déjà été transmises et traitées. REJ_COH Contrôle de cohérence des données L’une ou plusieurs données sont incohérentes. Tableau 10 - Liste des motifs de rejet de données réglementaires Plusieurs facteurs peuvent expliquer le rejet de données réglementaires : • Premier cas : le rejet relève d’anomalies lors de la constitution du fichier de données réglementaires à partir d’une facture conforme. La plateforme agréée d’émission peut alors générer à nouveau le fichier de données réglementaires corrigé (portant alors le même numéro de facture) pour transmission au PPF. • Deuxième cas : le rejet relève d’anomalies fonctionnelles au niveau des données de la facture (F2) dont les données sont issues. L’entreprise doit être informée de ce rejet, avec les motifs fonctionnels associés, et doit effectuer une analyse de ce rejet afin de prendre les mesures nécessaires (mise en œuvre d’une génération de numéro de facture conforme, correction des anomalies au niveau du système d’information facturier, …).

3.6.9 Les motifs de rejet des objets métiers du type statuts obligatoires

Le rejet de statuts obligatoires est associé à un ou plusieurs motifs, et l’emplacement des anomalies est indiqué, afin de permettre au partenaire de réaliser les actions correctives adaptées. Les motifs de rejet des statuts obligatoires sont : Code Libellé Description REJ_INC Contrôle de cohérence des statuts L’un ou plusieurs statuts sont incohérents. REJ_INEX Contrôle de conformité des statuts L’un ou plusieurs statuts sont incorrects ou non autorisés. REJ_RG Contrôle des règles de gestion L’une ou plusieurs règles de gestion ne sont pas respectées. REJ_HAB Contrôle des droits et habilitations L’une des requêtes n’est pas autorisée et/ou requiert une habilitation. REJ_ENCAISSEMENT Contrôle des encaissements L’un ou plusieurs montants encaissés ne sont pas conformes à la répartition par taux de TVA déclarée. Tableau 11 - Liste des motifs de rejet de statuts obligatoires

3.7 La bulle e-reporting

Coller ici le texte original de la section 3.7 La bulle e-reporting.

3.7.1 Les principes directeurs

Le dispositif prévoit que les plateformes agréées (PAE et PAR) transmettent à l’administration fiscale les données réglementaires115 des opérations internationales entre entreprises116 (B2Bi, Bi2B et Bi2Bi) et/ou d’opérations avec particulier ou d’une personne morale privée non assujettie117 (B2C). Il est en outre prévu que les plateformes transmettent les données de paiement118 attendues. Le portail public de facturation (PPF) assure le contrôle de ces données réglementaires, puis les transmet à l’administration fiscale. 115 Les données réglementaires sont définies à l’article 290 du CGI. 116 Les opérations concernées sont celles effectuées à destination ou en provenance d’une personne morale assujettie non établie en France (liste définie à l’article 290-I du CGI), ainsi que les opérations entre assujettis non établis en France qui sont soumises à la TVA en France (article 290-II du CGI). 117 Par exemple, une association. 118 Les données réglementaires sont définies à l’article 290 A du CGI. 119 Cf. chapitre dédié 3.4.4.Le cycle de vie d’un flux 120 Cf. chapitre dédié 3.7.9.

3.7.2 La cartographie des flux

Il existe différents types de flux qui interviennent lors de la transmission des données réglementaires et des statuts obligatoires de facture à l’administration fiscale : • les flux e-reporting (données de transaction et de paiement, factures et statuts obligatoires) ; • les flux de cycle de vie (flux119, données de transaction et de paiement120). Figure 33 - La cartographie des flux e-reporting et Cycle de vie échangés Le flux de transmission des données de transaction et de paiement (F10) est le format121 conçu pour assurer les échanges entre les plateformes agréées (PAE et PAR), le portail public de facturation et l’administration fiscale. 121 Fichier au format XML. Le flux de transmission (F10) est composé de 4 blocs, qui permettent de véhiculer différents types de données. Figure 34 - La structure d'un flux de transmission (F10) En fonction de leur offre de services, les plateformes agréées peuvent accepter et s’échanger des flux de factures électroniques et leurs statuts, relevant d’opérations interentreprises internationales (B2Bi, Bi2B et Bi2Bi) et/ou d’opérations auprès de non-assujettis (B2C), et les traiter de manière analogue aux factures électroniques des opérations interentreprises domestiques (B2B). Figure 35 - La structure d'un flux de transmission (F10) Dans ce cas, les plateformes agréées ont l’obligation d’exploiter les flux (F8, F9 et F6) pour constituer le flux de transmission de données de transaction et de paiement (F10), en amont de leur émission au portail public de facturation (PPF). Figure 36 - Exploitation des flux de factures (B2Bi, Bi2B et Bi2Bi) et leurs statuts pour constituer un flux de transmission Figure 37 - Exploitation des flux de factures (B2C) et leurs statuts pour constituer un flux de transmission

3.7.3 Les données de facture d’opérations internationales

Le bloc de données de facture (10.1) permet de transmettre à l’administration les données des opérations internationales entre entreprises122 (B2Bi, Bi2B et Bi2Bi) ayant donné lieu à une facture (F8). Chaque occurrence du bloc de données de facture (10.1) correspond à une unique facture. 122 Les opérations auprès de non-assujettis (B2C) doivent être transmises via le bloc de données de transaction (10.3), qu’elles aient fait l’objet d’une facture (F9) ou non. 123 Les données de paiement ne doivent être transmises qu’en cas de prestations de services, hors opérations donnant lieu à autoliquidation de la TVA et option de TVA sur les débits. 124 Les opérations avec des non-assujettis (B2C) doivent être transmises via le bloc de données de transaction (10.3), qu’elles aient fait l’objet d’une facture électronique (F9) ou non.

3.7.4 Les données de paiement des factures des opérations internationales

Le bloc de données de paiement de facture (10.2) permet de transmettre à l’administration les données de paiement (statut « Encaissée » - F6) d’opérations123 internationales entre entreprises (B2Bi, Bi2B et Bi2Bi) ayant donné lieu à une facture124. Chaque occurrence du bloc de données de facture (10.2) correspond à l’encaissement d’une unique facture.

3.7.5 Les données des opérations avec des non-assujettis

Le bloc de données de transaction (10.3) permet de transmettre à l’administration les données des opérations auprès de non-assujettis (B2C) qu’elles aient fait l’objet d’une facture électronique (de type F9) ou non. Chaque occurrence du bloc de données de transaction (10.3) correspond à un jour d’activité, une devise et un type de transaction. En effet, le bloc de données de transaction (10.3) permet de transmettre les données agrégées de l’ensemble des transactions quotidiennes réalisées125, et éventuellement les compléter des données de transaction relevant d’opération auprès de non-assujettis (B2C) ayant fait l’objet de factures (de type F9) émises le même jour. 125 Peut correspondre aux données d’un récapitulatif journalier édité par un système de caisse, dit « ticket Z » ou « Z de caisse » 126 Le bloc de données de paiement peut être utilisé pour déclarer un paiement perçu en amont de son rapprochement avec la facture correspondante. Lorsque ce rapprochement est réalisé, alors la déclaration des encaissements perçus doit être rectifiée (10.4), et le paiement de la facture doit être transmis via un cycle de vie de factures (F6), ou via le bloc de données de paiement de facture (10.3) s’il s’agit d’une facture relevant d’opérations interentreprises internationales (B2Bi, Bi2B, Bi2Bi). 127 Le déclarant est l’acteur de l’opération qui est assujetti à la TVA française. En fonction des cas, le déclarant peut être le fournisseur (B2Bi, Bi2Bi, B2C) ou l’acheteur (Bi2B). 128 Les délais et fréquences de transmission des données de transactions et de paiement ont été précisés dans les textes réglementaires en date du 7 octobre 2022 publiés le 9 octobre 2022 (impots.gouv.fr) 129 Le fait générateur de la transmission des données de transaction est la date de réalisation de l’opération, et celui de la transmission des données de paiement est la date d’encaissement du paiement (hors paiement par chèque bancaire et autres cas prévus dans la doctrine administrative BOI TVA BASE 20 20).

3.7.6 Les données de paiement des opérations avec des non-assujettis

Le bloc de données de paiement de transaction (10.4) permet de transmettre à l’administration les données à l’encaissement des opérations avec des non-assujettis (B2C), qu’elles aient fait l’objet d’une facture (de type F9) ou non. Chaque occurrence du bloc de données de transaction (10.4) correspond à un jour d’activité. En effet, le bloc de données de paiement de transaction (10.4) permet de transmettre l’ensemble des encaissements perçus126 au titre d’une journée.

3.7.7 Les modalités de transmission

Les plateformes agréées doivent transmettre au portail public de facturation (PPF) les données de transaction et de paiement (F10) agrégées : • par déclarant127, à la maille SIREN et selon son rôle dans l’opération ; • par période de transmission, déterminée à partir du régime de TVA du déclarant128 et en fonction de la date de l’opération129. Une image contenant capture d’écran, texte, cercle, diagramme Le contenu généré par l’IA peut être incorrect. Figure 38 - Exploitation des flux de factures (B2C) et leurs statuts pour constituer un flux de transmission Don Données de paiement Période Délai Date limite de transmission à l’administration fiscale Période Délai Date limite de transmission à l’administration fiscale Régime réel normal mensuel Décade : - du 1 au 10 du mois - du 11 au 20 du mois - du 21 à la fin du mois 10 jours après la fin de la période : - le 20 du mois - la fin du mois - le 10 du mois suivant - 1ère décade : le 21 du mois à 8h00 - 2ème décade : le 1er du mois suivant à 8h00 - 3ème décade : le 11 du mois suivant à 8h00 Mensuelle Le 10 du mois suivant Le 11 du mois suivant à 8h00 Régime réel normal trimestriel Mensuelle Le 10 du mois suivant Le 11 du mois suivant à 8h00 Mensuelle Le 10 du mois suivant Le 11 du mois suivant à 8h00 Régime simplifié d’imposition TVA Mensuelle Entre le 25 et 30 du mois suivant Le 1er du deuxième mois à venir, à 8h00 Mensuelle Entre le 25 et 30 du mois suivant Le 1er du deuxième mois à venir, à 8h00 Régime de de TVA Bimestrielle (tous les bimestres civils)130 Entre le 25 et 30 du mois suivant Le 1er du deuxième mois à venir, à 8h00 Bimestrielle (tous les bimestres civils) Entre le 25 et 30 du mois suivant Le 1er du deuxième mois à venir, à 8h00 130 Les bimestres civils commencent à l’une des dates suivantes : 1er janvier, 1er mars, 1er mai, 1er juillet, 1er septembre et 1er novembre. Tableau 12 - Les périodes de transmission par régime de TVA Pour certains régimes de TVA, les périodes de transmission des données de transaction sont différentes des périodes de transmission des données de paiement. De ce fait, les plateformes agréées doivent transmettre au portail public de facturation (PPF) les données de transaction et de paiement (F10) de manière distincte, à l’issue des périodes correspondantes à chaque type de données. Une image contenant texte, capture d’écran, diagramme, Police Le contenu généré par l’IA peut être incorrect. Figure 39 - Transmission distinctes des données de facture et transaction des données de paiement En cas d’erreur sur des données de transaction ou de paiement transmises au titre d’une période, la plateforme agréée peut transmettre un flux de transmission rectificatif (type RE) au portail public de facturation (PPF). Ce flux de transmission rectificatif annule et remplace l’ensemble des données agrégées131 et précédemment transmises au titre de cette période. 131 Distinguées par type de données et en fonction du rôle du déclarant. Une image contenant texte, capture d’écran, diagramme Le contenu généré par l’IA peut être incorrect. Figure 40 - Les modalités de rectification d'une transmission au titre d’une période révolue Afin de faciliter l’intégration des flux de transmission dans le portail public de facturation (PPF) et leur prise en compte par l’administration fiscale, les plateformes agréées les adressent au portail public de facturation (PPF) dans un délai de 8h à l’issue du dernier jour du délai de dépôt au titre de la période.

3.7.8 Les contrôles fonctionnels des données de transaction et de paiement

Si les contrôles techniques et applicatifs ne retournent aucune anomalie sur le flux (et les fichiers qu’il contient), alors la bulle métier e-reporting va réaliser des contrôles fonctionnels132 sur chaque fichier133 : 132 Ces contrôles sont décrits au travers de schematrons 133 Chaque fichier est « mono-objet », c’est à dire qu’il ne contient qu’un objet métier. 134 Contrôles des règles de gestion de la norme européenne (EN16931) et celles spécifiques à la réforme française de facturation électronique. 135 L’unicité est déterminée à partir du numéro de transmission, de l’identifiant du déclarant (SIREN) et de la période de la transmission. • des contrôles sémantiques134 ; • des contrôles de structure de données ; • des contrôles de cohérence de données ; • des contrôles d’unicité135.

3.7.9 Le cycle de vie des données de transaction et de paiement

Le résultat des contrôles fonctionnels détermine le statut de chaque objet métier136 : 136 En l’occurrence, pour chaque transmission de données de transaction et de paiement. • dès lors que le résultat des contrôles fonctionnels est en échec, alors l’objet métier est rejeté et ne sera pas intégré ; • si les contrôles fonctionnels ne relèvent aucune anomalie, l’objet métier est accepté et intégré. Figure 41 - Le cycle de vie d’un objet métier Toute plateforme est informée via un cycle de vie, du caractère accepté ou rejeté des objets métiers qu’elle a transmis. Objet Code Libellé Caractère Définition Données de transaction et paiement 300 Déposée Obligatoire Les données sont contrôlées comme conformes par le PPF et transmises à l’administration fiscale. Données de transaction et paiement 301 Rejetée Obligatoire Les données sont contrôlées comme non conformes par le PPF et ne sont pas transmises à l’administration fiscale. Tableau 13 - Liste des statuts de données de transaction et de paiement

3.7.10 Les motifs de rejet des objets métiers du type données de transaction et de paiement

Le rejet de données de transaction et de paiement est associé à un ou plusieurs motifs, et la source des anomalies est indiquée, afin de permettre à la plateforme agréée de réaliser les actions correctives adaptées. Les motifs de rejet des données de transaction et de paiement sont : Code Libellé Description REJ_SEMAN Contrôle du format sémantique Le format sémantique d’une ou plusieurs données n’est pas conforme. REJ_UNI Contrôle d’unicité Les données ont déjà été transmises et traitées. REJ_COH Contrôle de cohérence des données L’une ou plusieurs données sont incohérentes. REJ_PER Contrôle de période La date de la transmission de données n’est pas cohérente avec la période déclarée. Tableau 14 - Liste des motifs de rejet de données de transaction et de paiement

3.3.2.1 Le protocole SFTP

Le Secure File Transfert Protocol (ou SSH File Transfert Protocol) est un protocole permettant le transfert de fichiers entre un serveur (le PPF) et un partenaire (aussi appelé « client »), en assurant le cryptage de l’intégralité de la connexion, y compris des mots de passe et du contenu des transferts. Il constitue une variante du protocole FTP qui sécurise la session au travers d’une connexion Secure Shell (SSH). Pour requérir une connexion au système d’échange du portail public de facturation (PPF) à travers le protocole SFTP, les partenaires doivent : • disposer d’un client SFTP ; • disposer d’un utilitaire d’affectation de numéro de séquence ; • définir une procédure d’émission et de réception. L’authentification du partenaire se fait via l’utilisation de sa clé41 publique. Cette clé doit être communiquée42 à l’AIFE lors de la phase de raccordement, conformément aux modalités en cours pour les flux TLS. La sécurité du protocole doit au préalable être assurée par : • la clé publique du serveur AIFE mise à disposition43 du partenaire ; • les algorithmes de chiffrement44 dont le support par le partenaire doit être assuré ; • les paires de clés RSA utilisées pour l’authentification du partenaire. Chaque partenaire dispose de son SAS de dépôt et récupération des fichiers : • le partenaire doit déposer sur le serveur SFTP dédié les fichiers qu’il souhaite remettre au portail public de facturation (PPF) ; • le partenaire doit retirer sur le serveur SFTP dédié les fichiers qui lui sont mis à disposition par le portail public de facturation (PPF) dans le respect du délai de retrait45. Un fichier mis à disposition ne peut être récupéré qu’une seule fois. Pour ce faire, le partenaire est autorisé à utiliser des automates (scripts ou utilitaires) effectuant le dépôt ou la récupération de fichiers. Chaque partenaire transmet des fichiers dont le nommage doit respecter les règles décrites46 dans le présent document. 46 Cf. chapitre dédié 3.4.6.Le nommage des flux

3.3.2.2 Le protocole AS/2

Toute manipulation de fichier mis à disposition (hors récupération) ou du répertoire de récupération (hors listage) est interdite. La cinématique d’un transfert SFTP est la suivante : Figure 5 – Cinématique d’un flux entrant par protocole SFTP Figure 6 – Cinématique d’un flux sortant par protocole SFTP Le protocole Applicable Statement 2 (AS/2) est un protocole de transfert de fichiers fonctionnant en mode « push », permettant au partenaire d’envoyer directement et de sa propre initiative un fichier au destinataire. L’AS/2 spécifie le mode de connexion, de livraison, de validation et d'acquittement des données. Ce protocole a la particularité d’intégrer un système d’acquittement protocolaire appelé MDN. Pour requérir une connexion au système d’échange du portail public de facturation (PPF) à travers le protocole AS/2, les partenaires doivent : • disposer d’un serveur AS/2 pour la réception des messages ; • disposer d’un client AS/2 pour l’émission ; • disposer de serveurs en mesure de gérer les MDN synchrones ; • disposer d’un utilitaire d’affectation de numéro de séquence ; • définir une procédure d’émission et de réception. L’authentification du partenaire se fait via l’utilisation du mécanisme de signature électronique fourni par le protocole AS/2. Ce certificat47 doit être communiquée à l’AIFE lors de la phase de raccordement. 47 X509v3. 48 La couche de transport ne nécessite pas de TLS. 49 SHA-2. 50 AES 256. 51 SMIME. 52 Cf. chapitre dédié 3.4.6.Le nommage des flux 53 L’AS/2 n’inclut pas de mécanisme de reprise automatique. En cas de non-réception des acquittements de transferts, il est nécessaire de contacter le correspondant technique support du portail public de facturation (PPF). La sécurité du protocole48 doit au préalable être assurée par : • un utilitaire d’affectation de numéro de séquence ; • une procédure d’émission et de réception définie ; • Un certificat pour les opérations d’authentification, signature49 et chiffrement50. Chaque partenaire transmet : • le fichier encapsulé dans la requête AS/2, sous forme de pièce jointe51, dont le nommage doit respecter les règles décrites52 dans le présent document ; • l’enveloppe de données est ensuite envoyée par Internet en utilisant les protocoles standards ; • les données sont transmises par le protocole http, en requête POST, à un nom de domaine complètement qualifié (FQDN) ; • des acquittements (MDN) sont générés en mode synchrone53 pour signifier au client le succès (OK) ou l’échec (NOK) du transfert. En cas d’échec (NOK), le transfert doit être rejoué.

3.3.2.3 Le protocole AS/4

La cinématique d’un transfert AS/2 est la suivante : Figure 7 - Cinématique d’un flux entrant par protocole AS/2 Figure 8 - Cinématique d’un flux sortant par protocole AS/2 Le protocole Applicable Statement 4 (AS/4) est un protocole de transfert de fichiers fonctionnant en mode « push » ou « pull ». Le protocole AS/4 spécifie le mode de connexion, de livraison, de validation et d'acquittement des données. Ce protocole a la particularité d’intégrer un système d’acquittement protocolaire appelé MDN. Pour requérir une connexion au système d’échange du portail public de facturation (PPF) à travers le protocole AS/4, les utilisateurs doivent : • disposer d’un serveur AS/4 pour la réception des messages ; • disposer d’un client AS/4 pour l’émission ; • disposer de serveurs en mesure de gérer les messages signaux d’acquittement (SOAP) signés ; • disposer d’un utilitaire d’affectation de numéro de séquence ; • définir une procédure d’émission et de réception. L’authentification du partenaire se fait via l’utilisation du mécanisme de signature électronique fourni par le protocole AS/4. Ce certificat54 doit être communiquée à l’AIFE lors de la phase de raccordement. 54 X509v3. 55 La couche de transport ne nécessite pas de TLS. 56 SHA-2. 57 AES 256. 58 PJ SOAP (attachment). 59 Cf. chapitre dédié 3.4.6.Le nommage des flux La sécurité du protocole55 doit au préalable être assurée par : • un utilitaire d’affectation de numéro de séquence ; • une procédure d’émission et de réception définie ; • un certificat pour les opérations d’authentification, signature56 et chiffrement57. Chaque partenaire transmet : • le fichier encapsulé dans la requête AS/4, sous forme de pièce jointe58, dont le nommage doit respecter les règles décrites59 dans le présent document ; • l’enveloppe de données est ensuite envoyée par Internet en utilisant les protocoles standards ; • les données sont transmises par le protocole http, en requête POST, à un nom de domaine complètement qualifié (FQDN) ; • des acquittements (SOAP) sont générés en mode synchrone60 et signés pour signifier au client le succès (OK) ou l’échec (NOK) du transfert. En cas d’échec (NOK), le transfert doit être rejoué. 60 L’AS/4 n’inclut pas de mécanisme de reprise automatique. En cas de non-réception des acquittements de transferts, il est nécessaire de contacter le correspondant technique support du portail public de facturation (PPF). 61 Cf. Chapitre 7 -.Documentation applicable : Présentation de la plateforme PISTE. 62 En cas d’évolutions, au-moins deux versions de chaque API seront maintenues afin de faciliter l’adaptation des clients. La cinématique d’un transfert AS/4 est la suivante : Figure 9 - Cinématique d’un flux entrant par protocole AS/4 Figure 10 - Cinématique d’un flux sortant par protocole AS/4

3.5.5.3 L’actualisation de l’annuaire par le service d’immatriculation

Figure 12 - L'actualisation des lignes en vigueur à la suite du retrait du caractère assujetti et/ou la cessation d’activité Figure 13 - Le masquage de lignes non entrées en vigueur à la suite du retrait du caractère assujetti et/ou la cessation d’activité L’administration du registre des plateformes agréées (PA) immatriculées est réalisée par le service dédié de l’administration fiscale. Des services sont prévus de manière à transmettre toutes les mises à jour de ce registre et actualiser les informations de l’annuaire en conséquence lorsque : • une plateforme est nouvellement immatriculée ; • une plateforme perd son immatriculation. Figure 14 - L'actualisation de l'annuaire par le service d'immatriculation Dans le cas d’une plateforme nouvellement immatriculée, aucune actualisation de l’annuaire ne sera réalisée. Néanmoins, une fois cette plateforme raccordée et habilitée, elle pourra actualiser l’annuaire. Dans le cas d’une plateforme ayant perdu son immatriculation et/ou ayant cessé son activité, les lignes d’annuaire existantes attribuées à cette plateforme sont actualisées : • une date de fin effective est attribuée à chaque ligne d’annuaire en vigueur, correspondant à la date de la perte d’immatriculation ; • une ligne d’annuaire de type « masquage » est générée automatiquement pour chaque ligne d’annuaire dont la date de début d’effet est postérieure à la perte d’immatriculation ou à la cessation d’activité.

3.5.5.4 L’actualisation de l’annuaire par le portail de services Chorus Pro

Figure 15 - L'actualisation de lignes en vigueur à la suite d’une perte d'immatriculation Figure 16 - Le masquage de lignes non entrées en vigueur à la suite d’une perte d'immatriculation L’administration du registre des structures publiques est réalisée par le portail de services Chorus Pro. Des services sont prévus de manière à transmettre toutes les mises à jour de ce registre et actualiser les informations de l’annuaire en conséquence lorsque : • une structure publique modifie son organisation (création ou suppression de services) ; • une structure publique réduit son rôle à la maîtrise d’ouvrage (MOA uniquement), et ne peut alors recevoir que des factures de travaux. Figure 17 - L'actualisation de l'annuaire par le portail de services Chorus Pro Dans le cas d’une modification de l’organisation au sein d’une structure publique (exemple : la création d’un service), une ligne d’annuaire à la maille adaptée est créée, et Chorus Pro est attribuée comme plateforme de réception à cette ligne. Figure 18 - La création d'une ligne d'annuaire pour un nouveau service Dans le cas d’une structure publique réduisant son rôle à la maîtrise d’ouvrage (MOA), les lignes d’annuaire existantes pour cette structure publique sont actualisées : • une date de fin effective est attribuée à chaque ligne d’annuaire en vigueur ; • une ligne d’annuaire de type « masquage » est générée automatiquement pour chaque ligne d’annuaire dont la date de début d’effet est postérieure à la réduction du rôle à la maîtrise d’ouvrage (MOA).

3.5.5.5 L’actualisation de l’annuaire par les plateformes agréées (PA)

Figure 19 - L'actualisation de lignes à la suite d’une réduction du rôle d'une structure publique à la maîtrise d'ouvrage (MOA) L’article 28 du PLF 2026 vient préciser les modalités d’actualisation de l’annuaire par les plateformes agréées en proposant de modifier le III de l’article 289 bis du CGI comme suit : « iii) Au dernier alinéa, après les mots : « d’identifier », la fin de l’alinéa est remplacée par les dispositions suivantes : « les plateformes agréées intéressées, ainsi que les modalités de recueil, auprès des assujettis destinataires des factures, et de transmission de ces informations. Il précise également les modalités de changement de plateforme agréée ainsi que la nature et la durée, qui ne peut être inférieure à six mois, des services minimums devant être fournis par l’ancienne plateforme agréée lorsqu’un tel changement intervient. » Sous réserve de son adoption, le dispositif sera précisé par voie réglementaire. Le contenu du dispositif a, d’ores et déjà, été partagé avec l’ensemble des plateformes agréées et les organisations professionnelles représentatives, incluant notamment la nécessité de disposer de l’accord formel de l’assujetti destinataire des factures et les modalités pour changer de plateforme agréée. Le recueil du consentement de l’assujetti pour désigner la plateforme de réception et les informations d’adressage choisies peut se faire au-travers de la complétion d’un « accord formel » sur le modèle suivant (exemple de formulaire), signé par l’entreprise manuellement ou électroniquement : Figure 20 - Exemple d'accord formel de choix de plateforme agréée L’article 28 du PLF 2026 précise également, sous réserve de son adoption, les conséquences en cas de non-respect du dispositif en complétant le I de l’article 1788 E du CGI de l’alinéa suivant : « 3° Lorsque l’administration a constaté le non-respect par la plateforme agréée de ses obligations relatives à l’actualisation, dans l’annuaire central prévu au III de l’article 289 bis, des informations nécessaires à l’adressage des factures à recevoir, au changement de plateforme agréée de réception des factures, ainsi qu’aux services minimums devant être fournis par l’ancienne plateforme agréée en cas de changement, et que, l’administration l’ayant mise en demeure de se conformer à ses obligations dans un délai de quinze jours ouvrés, cette plateforme agréée ne lui a pas communiqué dans ce délai tout élément de preuve de nature à établir qu’elle s’est conformée à ses obligations ou qu’elle a pris les mesures nécessaires pour assurer sa mise en conformité dans un délai raisonnable. » . Les plateformes agréées de réception (PAR) ont la responsabilité de mettre à jour les informations d’adressage et de routage des entreprises privées destinataires de factures pour lesquelles elles agissent. Pour cela, une plateforme agréée de réception (PAR) peut : • actualiser des lignes d’annuaire existantes86, quelle que soit leur maille, et les attribuer à son matricule • ajouter des lignes d’annuaire ; o à la maille établissement (SIRET) pour tout établissement actif de l’entreprise ajouté à l’annuaire dans le cadre de l’initialisation ou de la mise à jour depuis le répertoire des entreprises, o à la maille code routage, pour s’adapter au plan d’adressage de l’entreprise en créant les codes routage nécessaires au préalable, o à la maille suffixe87, pour exploiter des adresses réseau ou codes d’adressages spécifiques. • créer des codes routages ; • mettre fin à des lignes d’annuaire en vigueur et masquer des lignes d’annuaire qui devaient entrer en vigueur88. 86 Seule une PA qui a formellement contractualisé avec un client privé est autorisée à remplacer la ligne d’annuaire par défaut à la maille SIREN par une ligne d’annuaire portant son matricule de plateforme de réception. 87 Il est fortement recommandé de créer des suffixes à la signification claire qui permettent de facilement distinguer leur utilisation prévue pour les utilisateurs habilités du PPF. Il est également fortement recommandé de veiller à ne pas nommer un suffixe avec un numéro SIRET. 88 Par exemple, en cas d’une rupture précipitée de contrat entre un client et sa PA. Il est alors conseillé à la PA de clôturer les lignes d’annuaire en vigueur qui lui sont attribuées pour ce client (et le cas échéant, de masquer les lignes d’annuaire dont la date d’entrée en vigueur n’était pas encore échue), puis de créer une ligne d’annuaire pour ce client, à la maille SIREN, attribué au matricule de la plateforme fictive. 89 La structure du flux d’actualisation (F13), et les données qu’il contient, sont décrites dans l’annexe 3. Il est recommandé que les modifications soient véhiculées via un unique fichier, et qu’un bloc code routage (DG-5) ou un bloc ligne d’annuaire (DG-7) soit renseigné a minima. Toute plateforme agréée de réception (PAR) habilitée et raccordée peut actualiser l’annuaire via : • le canal EDI en adressant un flux d’actualisation89 contenant l’ensemble des modifications qu’elle souhaite apporter aux lignes d’annuaire des entreprises pour lesquelles elle agit. Si aucune anomalie ou non-conformité n’est détectée par les contrôles techniques et fonctionnels, le flux est intégré et l’annuaire actualisé en conséquence ; • le canal API en utilisant les ressources : o code routage (méthode POST, PUT et PATCH) ; o ligne d’annuaire (méthode POST, PUT, PATCH et DELETE). Toute actualisation de l’annuaire, quel que soit le canal utilisé, sera consultable dès le lendemain (J+1). Exemple : Une entreprise (SIRET : 123 456 789 000001) a contractualisé avec une plateforme agréée (Matricule : 0005) depuis le 01/02/2027, et possède une ligne d’annuaire à la maille SIREN et une ligne d’annuaire à la maille SIRET. Le 31/03/2027, l’entreprise met fin à ce contrat, et contractualise avec une nouvelle plateforme agréée (Matricule : 9997) jusqu’au 31/12/2027. Figure 21 - L’actualisation de l’annuaire par une nouvelle PA La nouvelle plateforme agréée de réception actualise donc les lignes d’annuaire de l’entreprise pour : • clôturer les lignes d’annuaire en vigueur attribuées à la précédente plateforme agréée de réception ; • s’attribuer les lignes d’annuaire. Figure 22 - L’actualisation des lignes à la suite de la réduction du rôle d'une structure publique à la maitrise d'ouvrage (MOA) L’entreprise se réorganise et souhaite adapter la maille d’adressage de ses factures en fonction : • à partir du jour 15/04/2027 l’ensemble de ses factures sont traitées par le service A ; • à compter du 01/09/2027, les factures de prestations de services seront traitées par le service B et les achats de marchandises seront traitées par le service C. Une image contenant texte, capture d’écran, Police, ligne Le contenu généré par l’IA peut être incorrect. Figure 23 - La création de services et des lignes d'annuaire correspondantes La plateforme agréée de réception actualise donc les lignes d’annuaire de l’entreprise pour : • créer les services A, B et C ; • créer les lignes d’annuaire correspondantes. Figure 24 - La création de lignes à la suite de la mise en place d'une nouvelle maille d'adressage Le 02/06/2027, l’entreprise adapte son projet d’organisation et souhaite finalement que ses factures soient adressées à une ligne d’annuaire à la maille suffixe (suffixe : ABCD01) : Une image contenant texte, capture d’écran, Police, nombre Le contenu généré par l’IA peut être incorrect. Figure 25 - La création d'une nouvelle maille d'adressage La plateforme agréée de réception actualise donc les lignes d’annuaire de l’entreprise pour : • apposer une date de fin d’effet à chaque ligne d’annuaire en vigueur (la ligne d’annuaire du service A) ; • créer une ligne d’annuaire de type « masquage » pour chaque ligne d’annuaire dont la date de début d’effet est postérieure à la date de réorganisation (la ligne d’annuaire des services B et C) ; • créer une ligne d’annuaire de type « définition » à la maille suffixe qui rentrera en vigueur à la date souhaitée. La plateforme agréée de réception peut également, si c’est le souhait de l’entreprise, inactiver les services A, B et C. Figure 26 - L'actualisation des lignes à la suite de la mise en place d'une nouvelle maille d'adressage