Ce cas d’usage, identifié comme le Cas n°4 dans les spécifications techniques (norme XP Z12-014), traite des situations où une facture est réglée par deux entités distinctes : l’ACHETEUR légal et un TIERS (comme une compagnie d’assurance ou un organisme de subvention).
Voici une explication détaillée de la gestion technique et fiscale de ce scénario :
1. La problématique technique et le profil étendu
La norme européenne de base (EN16931) ne permet pas nativement de désigner plusieurs payeurs sur un seul document. Pour résoudre cela, la réforme française utilise le profil EXTENDED-CTC-FR, qui permet d’ajouter des informations structurées indispensables :
Le bloc PAYEUR DE LA FACTURE (EXT-FR-FE-BG-02) est utilisé pour identifier nommément le tiers (par exemple, l’assureur).
Une Note de facture (BG-1) avec le code sujet « PAI » doit être ajoutée pour expliciter les modalités de ce paiement scindé.
2. Le mécanisme des champs de montant (BT-113 et BT-115)
L’objectif est que le système comptable de l’acheteur n’affiche que la somme qu’il doit réellement décaisser.
BT-113 (Montant déjà payé) : Par convention, le vendeur y inscrit le montant que le tiers prend à sa charge (même si ce n’est pas encore techniquement « payé » au moment de l’émission).
BT-115 (Net à payer) : Le logiciel calcule alors automatiquement la différence : Montant total TTC (BT-112) moins Montant tiers (BT-113).
Résultat : L’acheteur voit en « Net à payer » uniquement sa part (par exemple, sa franchise et la TVA s’il la récupère).
3. La gestion fiscale de la TVA et de l’encaissement
Ce cas est particulièrement sensible pour les prestations de services où la TVA est due à l’encaissement. L’administration doit recevoir les informations de paiement pour chaque part du règlement afin de pré-remplir correctement les déclarations.
Le vendeur a l’obligation de transmettre au Portail Public de Facturation (PPF) des statuts de cycle de vie « Encaissée » distincts :
Un statut pour la part de l’acheteur : indiquant le montant TTC perçu et le taux de TVA correspondant.
Un statut pour la part du tiers : si le tiers paie une somme nette de taxe (cas fréquent des assurances qui ne paient que le HT), le message d’encaissement doit préciser un taux de TVA à 0 pour cette portion afin de ne pas fausser les calculs de l’administration.
4. Cinématique de l’opération
Émission : Le vendeur émet la facture structurée incluant le bloc tiers payeur et le montant BT-113 ajusté.
Transmission : La plateforme du vendeur (PA-E) extrait les données fiscales (Flux 1) pour le PPF et envoie la facture à la plateforme de l’acheteur (PA-R).
Recouvrement : Le vendeur sollicite le tiers payeur pour sa part, tandis que l’acheteur valide la facture sur sa plateforme.
Reporting final : Une fois les deux paiements reçus, le vendeur émet les statuts « Encaissée » via sa plateforme pour clôturer le cycle fiscal de la facture.
En résumé, ce mécanisme permet de respecter la complexité des relations d’assurance ou de subvention tout en garantissant que l’administration fiscale puisse suivre la collecte de la TVA sur chaque fragment du paiement.
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 profilEXTENDED-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 :
Émission : Le VENDEUR émet la facture vers l’acheteur via sa plateforme (PA-E).
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.
Paiement : Le tiers PAYEUR effectue le virement au vendeur et en informe l’acheteur.
Information de paiement : L’acheteur transmet le statut « Paiement Transmis » au vendeur pour confirmer que le payeur a exécuté l’ordre.
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.
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,.
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,.
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.
Gérer le consentement
Pour offrir les meilleures expériences, nous utilisons des technologies telles que les cookies pour stocker et/ou accéder aux informations des appareils. Le fait de consentir à ces technologies nous permettra de traiter des données telles que le comportement de navigation ou les ID uniques sur ce site. Le fait de ne pas consentir ou de retirer son consentement peut avoir un effet négatif sur certaines caractéristiques et fonctions.
Fonctionnel
Toujours activé
L’accès ou le stockage technique est strictement nécessaire dans la finalité d’intérêt légitime de permettre l’utilisation d’un service spécifique explicitement demandé par l’abonné ou l’utilisateur, ou dans le seul but d’effectuer la transmission d’une communication sur un réseau de communications électroniques.
Préférences
L’accès ou le stockage technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou l’internaute.
Statistiques
Le stockage ou l’accès technique qui est utilisé exclusivement à des fins statistiques.Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
Marketing
L’accès ou le stockage technique est nécessaire pour créer des profils d’internautes afin d’envoyer des publicités, ou pour suivre l’utilisateur sur un site web ou sur plusieurs sites web ayant des finalités marketing similaires.