Le cas barter (ou troc interentreprises), identifié comme le cas d’usage n°41 dans la norme XP Z12-014, concerne une pratique courante dans le secteur de la publicité. Il s’agit de transactions où un annonceur vend des biens ou services en échange de crédits publicitaires à utiliser ultérieurement.
Voici les détails de ce fonctionnement et son implémentation technique dans la réforme :
1. Le cycle des échanges
Le dispositif fait intervenir trois acteurs principaux organisés autour d’un système de compensation :
L’Annonceur vers la société de Barter : L’annonceur vend des produits (ex: du mobilier). La société de Barter paie immédiatement la TVA (et éventuellement une part du prix) et conserve le solde HT « en compte » comme une dette envers l’annonceur.
La société de Barter vers la Régie publicitaire : La société de Barter revend ces produits à une régie. La régie paie la TVA, et le solde HT devient une créance de la société de Barter sur la régie.
La Régie vers l’Annonceur : Lorsque la régie fournit des prestations publicitaires à l’annonceur, le paiement du montant HT se fait par compensation entre la dette de la société de Barter envers l’annonceur et la créance de la société de Barter sur la régie.
2. Implémentation technique des factures
Pour traduire ces flux complexes dans les formats électroniques structurés, les sources recommandent les règles de gestion suivantes :
BT-113 (Montant déjà payé) : On utilise ce champ pour inscrire le montant HT qui sera mis « en compte » (la part faisant l’objet du troc), même s’il n’est pas encore techniquement payé en numéraire.
BT-115 (Net à payer) : Ce champ affichera alors uniquement la somme que l’acheteur doit réellement décaisser, ce qui correspond généralement au montant de la TVA.
Bloc PAYEUR (EXT-FR-FE-BG-02) : Sur la facture de la régie vers l’annonceur, la société de Barter peut être identifiée comme tiers payeur pour la part qu’elle prend en charge via la compensation.
Note de facture (BG-1) : Il est conseillé d’utiliser le code sujet « PAI » pour préciser qu’une partie de la facture fait l’objet d’une compensation barter.
3. Aspects fiscaux et TVA
Bien que le paiement du prix HT soit différé ou compensé, la règle fiscale impose que 100 % de la TVA soit déclarée et payée par le vendeur (et déduite par l’acheteur) dès l’émission de la facture et le premier règlement partiel. Les statuts de cycle de vie d’encaissement doivent donc refléter ce paiement intégral de la taxe pour permettre le pré-remplissage correct des déclarations par l’administration.
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.
Réponse
Réponse
Réponse
Réponse
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.
