Cas n°3 : Comment peut-on indiquer dans une facture qu’elle doit être payée par un tiers PAYEUR connu ?

par | Fév 3, 2026 | Cycle de vie, EN16931, Facturation électronique

Ce cas d’usage traite de la situation où une facture, bien que libellée au nom de l’ACHETEUR (le client légal), doit être réglée par une entité tierce appelée le PAYEUR. Cette configuration se rencontre fréquemment dans les groupes de sociétés (une centrale de trésorerie payant pour les filiales) ou dans des contextes spécifiques comme la sous-traitance avec paiement direct par le maître d’ouvrage.

Voici les détails approfondis pour comprendre ce thème :

1. Le rôle du profil EXTENDED-CTC-FR

La norme sémantique européenne EN16931 ne prévoit pas de bloc spécifique pour identifier un tiers payeur distinct de l’acheteur. C’est pourquoi la réforme française utilise le profil EXTENDED-CTC-FR, qui ajoute le bloc PAYEUR DE LA FACTURE (EXT-FR-FE-BG-02) pour permettre cette identification précise tout en respectant le standard européen.

2. Informations contenues dans le bloc PAYEUR

Pour que le tiers payeur soit correctement identifié et puisse éventuellement agir dans le système, le vendeur peut renseigner plusieurs données structurées dans ce bloc :

  • Identité : La raison sociale du payeur (EXT-FR-FE-43) et son identifiant légal SIREN (EXT-FR-FE-48).
  • Identifiants complémentaires : Il est possible d’ajouter d’autres codes comme un GLN ou un SIRET (EXT-FR-FE-46).
  • Adresse électronique : Une adresse spécifique (EXT-FR-FE-52) peut être renseignée pour permettre d’atteindre le payeur directement via les réseaux d’échange comme PEPPOL.

3. Cinématique des échanges (Cycle de vie)

Dans ce cas de figure, la facture suit un circuit précis entre le vendeur, l’acheteur et le payeur :

  1. Émission : Le VENDEUR émet la facture vers l’acheteur via sa plateforme (PA-E).
  2. Validation : L’ACHETEUR reçoit la facture, la valide (statut « Approuvée ») et informe son PAYEUR que la facture est prête pour règlement.
  3. Paiement : Le tiers PAYEUR effectue le virement au vendeur et en informe l’acheteur.
  4. Information de paiement : L’acheteur transmet le statut « Paiement Transmis » au vendeur pour confirmer que le payeur a exécuté l’ordre.
  5. Clôture : Une fois les fonds reçus, le vendeur émet le statut obligatoire « Encaissée », qui est transmis à l’acheteur et au Portail Public de Facturation (PPF) pour les besoins fiscaux.

4. Recommandations et limites

  • Unicité : Un seul bloc tiers payeur peut être renseigné par facture.
  • Transparence pour le vendeur : Bien que le vendeur puisse nommer le payeur dans la facture, il est souvent recommandé que l’acheteur gère cette relation de manière transparente pour le vendeur, afin de ne pas obliger ce dernier à modifier ses fichiers clients.
  • Gestion des droits : Pour que ce processus fonctionne, le payeur doit être référencé sur la plateforme de l’acheteur (PA-R) avec des droits de délégation lui permettant d’accéder à la facture et à ses statuts.

En résumé, l’utilisation du bloc EXT-FR-FE-BG-02 est l’outil technique qui permet de séparer la responsabilité comptable de l’achat (l’acheteur) de la responsabilité financière du règlement (le payeur) tout en garantissant une traçabilité totale pour l’administration fiscale.

Cas n°2 : Dans une facture déjà payée, le ‘Montant payé’ (BT-113) doit être égal au ?

par | Fév 2, 2026 | Cycle de vie, Facturation électronique

Le Cas d’usage n°2 défini par les spécifications techniques de la réforme, qui traite des factures émises pour des transactions ayant déjà fait l’objet d’un règlement intégral au moment de la génération du document,.

Voici une explication détaillée des règles de gestion et des implications fiscales de ce cas de figure à la suite de l’article Cas n°2 : Pour une facture déjà payée, quelle doit être la valeur du champ ‘Montant à payer’ (BT-115) ? :

1. La logique arithmétique : BT-113 et BT-112

Dans une facture électronique structurée, l’équilibre financier est vérifié par des champs précis :

  • BT-112 (Montant total TTC) : Il représente la somme totale de la facture, incluant le montant hors taxes (BT-109) et la TVA (BT-110),.
  • BT-113 (Montant déjà payé) : Pour une facture déjà soldée, ce champ doit être complété avec une valeur strictement égale au montant total TTC (BT-112),.
  • BT-115 (Montant net à payer) : Par voie de conséquence, puisque la totalité a été réglée, le reste à payer doit être égal à 0,,.

Cette configuration indique aux systèmes comptables de l’acheteur qu’aucun décaissement supplémentaire n’est requis pour ce document.

2. L’identification réglementaire (BT-23)

Pour que l’administration et les plateformes identifient correctement ce flux, le vendeur doit utiliser un Cadre de facturation (BT-23) spécifique :

  • Les codes B2 (biens), S2 (services) ou M2 (mixte) signifient explicitement « Dépôt d’une facture déjà payée »,.
  • La date d’échéance (BT-9), si elle est renseignée, doit correspondre à la date effective du paiement (qui est antérieure ou égale à la date de la facture),.

3. L’obligation fiscale de reporting (Le statut « Encaissée »)

Le simple fait d’indiquer que la facture est payée dans les données structurées (BT-113/BT-115) ne suffit pas pour l’administration fiscale dans certains cas.

  • TVA sur les encaissements : Si la transaction concerne des prestations de services pour lesquelles la TVA est due au moment du paiement, le vendeur a l’obligation de transmettre un statut de cycle de vie « Encaissée » (via le flux 6) au Portail Public de Facturation (PPF),.
  • Transmission simultanée : Ce statut peut être envoyé en même temps que la facture,. C’est ce message de cycle de vie qui permettra à l’administration de pré-remplir les déclarations de TVA,.
  • Automatisation : Certaines Plateformes Agréées (PA) proposent de générer automatiquement ce statut « Encaissée » en détectant la valeur « 0 » dans le champ BT-115 et les codes B2/S2/M2.

4. Exemples de situations réelles

Ce cas d’usage se rencontre fréquemment dans les scénarios suivants :

  • Paiement à la commande : L’acheteur règle la totalité sur un site internet ou lors de la commande, et la facture est émise quelques jours plus tard lors de la livraison,.
  • Factures d’acompte déjà payées : Lorsqu’un premier versement ferme est effectué avant la prestation, le vendeur émet une facture d’acompte (codetype 386) où le montant payé est égal au TTC de l’acompte,,.
  • Ventes avec détaxe : Dans le cas où un bien est vendu à un particulier qui demande ensuite une facture B2B pour son entreprise (par exemple via un opérateur de détaxe), la facture est émise alors que le règlement a déjà eu lieu,.

Cas n°2 : Pour une facture déjà payée, quelle doit être la valeur du champ ‘Montant à payer’ (BT-115) ?

par | Jan 27, 2026 | Cycle de vie, Facturation électronique

Le Cas d’usage n°2 défini les spécifications techniques de la réforme : la gestion d’une facture déjà payée par l’acheteur (ou un tiers payeur) au moment de son émission.

Ce scénario se produit couramment lors d’un paiement à la commande suivi d’une livraison rapide, où le règlement est effectué avant que la facture finale ne soit générée dans le système du vendeur.

Voici les détails techniques et fonctionnels pour approfondir ce sujet :

1. Paramétrage des champs de la facture

Pour que cette facture soit traitée correctement par les systèmes d’information (celui du client et celui de l’administration), des règles de gestion strictes s’appliquent aux données structurées :

  • BT-115 (Montant à payer) : Sa valeur doit être égale à 0. Cela indique au logiciel de comptabilité de l’acheteur qu’aucune sortie d’argent supplémentaire n’est attendue pour ce document.
  • BT-113 (Montant déjà payé) : Ce champ doit être complété avec une valeur égale au montant total TTC de la facture (BT-112).
  • BT-23 (Cadre de facturation) : Le vendeur doit utiliser des codes spécifiques pour signaler la nature de l’envoi : B2 (biens), S2 (services) ou M2 (mixte), signifiant explicitement « Dépôt d’une facture déjà payée ».
  • BT-9 (Date d’échéance) : Si elle est renseignée, elle doit être égale à la date effective du paiement, qui est forcément antérieure ou égale à la date de la facture.

2. L’obligation de transmission du statut « Encaissée »

Le fait d’indiquer « 0 » dans le montant à payer sur la facture ne suffit pas à informer l’administration fiscale de la collecte de la taxe.

  • TVA à l’encaissement : Pour les prestations de services (où la TVA est due au moment du paiement), le vendeur a l’obligation de transmettre un message de cycle de vie portant le statut « Encaissée » (via le flux 6).
  • Rôle du PPF : Ce statut doit être transmis par la Plateforme Agréée (PA) au Concentrateur de Données du PPF afin que l’administration puisse pré-remplir la déclaration de TVA du vendeur (TVA collectée) et celle de l’acheteur (TVA déductible).
  • Simultanéité : Ce statut peut être envoyé en même temps que la facture elle-même.

3. Fonctionnalités des plateformes

Certaines Plateformes Agréées (PA) peuvent proposer une automatisation pour ce cas précis. Elles peuvent, par exemple, générer automatiquement le message de cycle de vie « Encaissée » pour le compte du vendeur en détectant simplement les codes B2/S2/M2 dans le cadre de facturation et la valeur « 0 » dans le champ BT-115.

En résumé, la valeur « 0 » dans le champ BT-115 est le signal technique qui permet d’éviter les doubles paiements chez l’acheteur tout en déclenchant, pour les services, les flux de reporting de paiement nécessaires à la conformité fiscale.

Dans le cas d’une facture avec escompte pour une livraison de biens, quelle action le VENDEUR peut-il entreprendre pour ajuster la TVA pré-remplie ?

par | Jan 22, 2026 | Cycle de vie, Facturation électronique

Ce thème traite de la gestion des escomptes (remises pour paiement anticipé) dans le cadre de la réforme, en distinguant les livraisons de biens des prestations de services. La problématique centrale est de garantir que l’administration fiscale dispose de la bonne information pour le pré-remplissage de la TVA, alors que le montant final payé est inférieur au montant initialement facturé.

Voici une explication détaillée des enjeux et de la procédure pour les livraisons de biens :

1. Le problème spécifique des livraisons de biens (TVA sur les débits)

Pour les livraisons de biens (ou les services avec option pour les débits), la TVA est exigible dès l’émission de la facture.

  • Absence de transmission des données de paiement : Contrairement aux services « à l’encaissement », l’administration ne reçoit pas (et ne prend pas en compte) les données de paiement pour les livraisons de biens.
  • Incapacité de l’administration à « voir » l’escompte : Comme l’administration ne voit pas le montant effectivement encaissé, elle ne peut pas savoir qu’un escompte a été appliqué et reste sur la base du montant HT initial pour calculer la TVA collectée pré-remplie.

2. La solution : L’émission d’un avoir (une « faculté »)

Pour corriger cet écart et ajuster la TVA collectée dans le système de l’administration, le VENDEUR a la faculté d’émettre un avoir correspondant au montant de l’escompte.

  • Rôle du Flux 1 : L’émission de cet avoir génère un nouveau « Flux 1 » (données fiscales) transmis au Portail Public de Facturation (PPF). Ce flux vient mécaniquement réduire la TVA collectée pré-remplie pour le vendeur et la TVA déductible pour l’acheteur.
  • Justification comptable : Cet avoir permet de justifier l’écart entre le montant de la facture initiale et le paiement réellement reçu dans la comptabilité des deux parties.

3. Les modalités techniques de l’avoir sur escompte

Le vendeur peut choisir entre deux approches pour cet avoir :

  • Avoir portant TVA : L’avoir réduit le montant HT et la TVA au prorata du taux applicable sur la facture initiale. Il doit obligatoirement référencer la facture d’origine (bloc BG-3).
  • Avoir net de taxe (Escompte net de taxe) : Cette option est autorisée. Dans ce cas, l’avoir indique un montant de TVA égal à 0 en utilisant le code d’exonération spécifique VATEX-FR-CNWVAT dans le bloc de ventilation de TVA (BG-23).

4. Rappel sur la facture initiale

Même si un avoir est prévu ultérieurement, la facture initiale doit obligatoirement contenir une mention détaillant les conditions de l’escompte.

  • Cette mention doit figurer dans une note de facture (champs BT-21/BT-22).
  • Le code sujet utilisé pour cette note doit être AAB.

Comparaison avec les prestations de services

Il est utile de noter que pour les prestations de services (sans option pour les débits), l’avoir n’est pas nécessaire car la TVA est due à l’encaissement. L’administration ajuste automatiquement la TVA sur la base du statut « Encaissée » transmis par le vendeur, qui déclare le montant réellement perçu (TTC moins escompte). C’est parce que ce mécanisme automatique n’existe pas pour les biens que le vendeur doit passer par l’émission d’un avoir.

Quel format de message est utilisé pour l’échange des statuts de cycle de vie ?

Quel format de message est utilisé pour l’échange des statuts de cycle de vie ?

par | Jan 22, 2026 | Cycle de vie, Facturation électronique

Le format de message UN/CEFACT Cross Domain Acknowledgement and Response (CDAR) est la pierre angulaire technique qui permet de faire vivre le concept de cycle de vie (CDV) de la facture dans la réforme française. Alors que l’UBL ou la Factur-X servent à transporter les données de facturation, le message CDAR sert exclusivement à transporter les changements d’état (les statuts) de ces factures.

Voici les détails approfondis pour comprendre l’importance et le fonctionnement de ce format :

1. Un format de messagerie normalisé

Le CDAR est un format structuré défini par la norme technique française XP Z12-012. Il a été choisi car il permet une standardisation complète des échanges : chaque acteur du système (entreprises, Plateformes Agréées et administration) utilise exactement le même « langage » pour dire qu’une facture a été reçue, approuvée ou payée. Cela garantit une exploitation automatique des informations sans erreur d’interprétation entre les différents logiciels de gestion.

format de message statuts de cycle de vie

2. Qui échange des messages CDAR ?

Le circuit d’échange de ces messages est multiple :

  • Entre les entreprises et leurs Plateformes Agréées (PA) : Lorsqu’un comptable clique sur « Approuver » dans son outil, le système génère un message CDAR envoyé à la PA.
  • Entre Plateformes Agréées : Les PA s’échangent ces messages pour informer la contrepartie (le vendeur ou l’acheteur) de l’avancement du dossier.
  • Vers le Portail Public de Facturation (PPF) : Pour les quatre statuts obligatoires (Déposée, Rejetée, Refusée, Encaissée), la PA transmet les données au Concentrateur de Données du PPF via ce format.

3. La richesse des données d’horodatage

L’une des fonctions critiques du message CDAR est de fournir une traçabilité temporelle incontestable grâce à plusieurs champs « date et heure » :

  • MDT-8 : La date et l’heure de création du message de statut lui-même.
  • MDT-78 : La date et l’heure où l’utilisateur a effectivement posé le statut dans son application.
  • MDT-95 : La date et l’heure de réception de la facture par celui qui émet le statut. Cette précision est indispensable pour résoudre d’éventuels litiges sur les délais de paiement ou pour le contrôle fiscal.

4. Un support pour les cas d’usage complexes

Le format CDAR n’est pas limité aux statuts de base ; il est conçu pour transporter des données métiers additionnelles dans des blocs spécifiques (notamment le bloc MDG-43) :

  • Paiement et Encaissement : Le message précise le montant payé ou encaissé (code MPA ou MEN) et peut même ventiler ces montants par taux de TVA.
  • Affacturage : Il permet d’annoncer officiellement à l’acheteur qu’une facture a été cédée à un factor (statut « Affacturée« , code 225) et de lui transmettre de nouvelles coordonnées bancaires (IBAN) de manière sécurisée.
  • Litiges et Rectifications : Il peut porter des motifs de refus précis (ex: « Taux de TVA erroné ») ou signaler qu’une facture est désormais « Annulée » suite à l’émission d’une facture rectificative.

5. Structure type d’un message CDAR

Techniquement, un message CDAR identifie toujours précisément les parties prenantes :

  • Le Créateur (Issuer) : L’entité qui génère le statut (ex: le vendeur ou l’acheteur).
  • L’Émetteur (Sender) : La plateforme qui transmet techniquement le message.
  • Le Destinataire (Recipient) : La partie qui doit être informée du changement de statut.
  • L’Objet : Le numéro et la date de la facture concernée pour assurer un rapprochement parfait.

En résumé, le message UN/CEFACT CDAR est le « journal de bord » numérique et universel de chaque facture, permettant à l’administration de suivre la collecte de la TVA et aux entreprises de piloter leur trésorerie en temps réel.

Quelle est la conséquence d’un statut « Rejetée » ou « Refusée » sur le cycle de vie d’une facture pour le PPF?

par | Jan 21, 2026 | Cycle de vie, Facturation électronique

Le cycle de vie d’une facture dans le cadre de la réforme française est jalonné par différents statuts, dont quatre sont dits « obligatoires » car ils doivent être systématiquement transmis au Concentrateur de Données du Portail Public de Facturation (CdD PPF) par les Plateformes Agréées (PA).

Comme l’indique le précèdent article, les statuts « Rejetée » et « Refusée » ont une caractéristique majeure : ils sont terminaux pour le CdD PPF. Voici une explication détaillée de ce mécanisme et de ses conséquences.

1. Des statuts considérés comme « terminaux »

Dans l’architecture technique de l’administration fiscale, une facture sur laquelle un statut « Rejetée » ou « Refusée » a été posé est considérée comme ayant atteint la fin de son existence fiscale.

  • Pour le CdD PPF : Aucun autre statut obligatoire (notamment « Encaissée ») ne peut plus être enregistré ou traité pour cette facture précise dans le système central.
  • Neutralisation fiscale : La conséquence immédiate est que le Flux 1 (données fiscales extraites de la facture) initialement transmis est ignoré par l’administration fiscale pour le pré-remplissage de la TVA.

2. Le statut « Rejetée » (Automatique ou Technique)

Ce statut intervient généralement durant la phase de transmission et est posé par les plateformes (PA-E ou PA-R).

  • Cause : Il résulte d’un échec aux contrôles réglementaires, techniques (virus, structure XML corrompue) ou fonctionnels (numéro de facture en doublon, adresse de facturation électronique introuvable).
  • Conséquence : La facture est réputée n’avoir jamais existé fiscalement. Le vendeur doit procéder à une annulation comptable (via un avoir interne non transmis au client) et réémettre une nouvelle facture avec un nouveau numéro pour relancer le circuit.

3. Le statut « Refusée » (Métier ou Humain)

Contrairement au rejet, le refus est une action déclenchée par l’acheteur (le destinataire) lors de la phase de traitement.

  • Cause : L’acheteur refuse la facture pour un motif précis (vendeur inconnu, absence de bon de commande, taux de TVA erroné, etc.).
  • Règle stricte : Ce statut ne doit pas être utilisé pour un simple litige commercial (désaccord sur le prix ou la qualité) mais uniquement pour des motifs empêchant le traitement ou la comptabilisation légale.
  • Conséquence : L’administration annule la TVA pré-remplie pour cette transaction. Le vendeur doit normalement annuler sa facture dans ses comptes et en créer une nouvelle si la transaction doit toujours avoir lieu.

4. Pourquoi interdire le statut « Encaissée » après un rejet ou un refus ?

Le système interdit la pose du statut « Encaissée » (qui déclenche l’exigibilité de la TVA pour les prestations de services) sur une facture rejetée ou refusée pour garantir la cohérence des données fiscales.

Si une facture est rejetée ou refusée, elle est sortie du circuit légal. Toute transaction financière liée à cette opération devra être rattachée à une nouvelle facture conforme qui, elle, pourra recevoir le statut « Encaissée » à la fin de son propre cycle de vie.

En résumé, ces deux statuts agissent comme un « point final » technique : ils informent l’administration fiscale que la tentative de facturation a échoué, empêchant ainsi toute taxation ou déduction de TVA erronée sur un document non valide.