Warning: Cannot modify header information - headers already sent by (output started at /home/amadieuc/www/dotclear2/inc/config.php:41) in /home/amadieuc/www/dotclear2/inc/clearbricks/common/lib.http.php on line 222

Warning: Cannot modify header information - headers already sent by (output started at /home/amadieuc/www/dotclear2/inc/config.php:41) in /home/amadieuc/www/dotclear2/inc/clearbricks/common/lib.http.php on line 224

Warning: Cannot modify header information - headers already sent by (output started at /home/amadieuc/www/dotclear2/inc/config.php:41) in /home/amadieuc/www/dotclear2/inc/public/lib.urlhandlers.php on line 65

Warning: Cannot modify header information - headers already sent by (output started at /home/amadieuc/www/dotclear2/inc/config.php:41) in /home/amadieuc/www/dotclear2/inc/clearbricks/common/lib.http.php on line 247
Le NOUVEL ACHAT

Le NOUVEL ACHAT

Aller au contenu | Aller au menu | Aller à la recherche

mardi, novembre 10 2020

France has published an amendment for enforcement of the B2B mandate

SP

An amendment of the financial law 2021 has been published november 6 for enforcement of the B2B eInvoicing mandate and transactions eReporting. This amendment is in conditional form as far as it needs to be voted by the Finance commission of the parliament. Pursuant to those measures, a report has been issued to the parliament, with recommendation regarding envisioned technical features.

This amendment fix a roadmap for deployment since 2023 onward :

  • Obligation of eInvoice reception for all businesses in 2021
  • Obligation of eInvoice issuance, progressive in 2023 for big groups, 2024 for mid size companies and 2025 for SME

The French tax authority aims to achieve 4 objectives :
Fight against fraud, improve service to users subject to VAT by simplification of tax declaration duties, business competitiveness and ongoing knowledge of business activity.

For achieving that goal, the scope of obligation should be expanded to cross-border operations, in fight against fraud like VAT carousel, to ease tax return from exports ; the transmission of data related to B2C transactions. Finally, the payment status feedback is necessary to determine the due date and deductibility of VAT for provision of a service.

On payment status feedback, see PEPPOL BIS 63 INVOICE RESPONSE see also our post

jeudi, octobre 22 2020

Comment la France opte pour la facturation électronique B2B et l'e-Reporting de la TVA ? (7ème partie)

B2B
La réponse à la facture et le profil INVOICE RESPONSE de PEPPOL

Dans le billet précédent nous avons soulevé la question d’une réponse à la facture qui pourrait s’avérer indispensable dans le cadre d’échanges B2B. Une réflexion a ensuite été engagée par PEPPOL sur le développement d’un message (ou profil) spécifique à cette réponse. Ce message PEPPOL BIS 63 INVOICE RESPONSE a l’avantage d’être normalisé, facilitant ainsi sa mise en œuvre.

Petit rappel : Dans le cadre d’une transaction EDI, le message le plus couramment renvoyé par l’application est un AR technique (ACK) lié au protocole de communication de la couche de transport. Dans le cas de PEPPOL le protocole est AS2 ou AS4 et le message ACK est retourné automatiquement par le point d’accès récepteur au point d’accès émetteur à la réception du flux. Un deuxième niveau de message MLR (Message Level Response) a ensuite été développé pour permettre d’informer l’émetteur de la validation par le récepteur de la conformité du message. Cette fonctionnalité facultative n’est pas systématiquement utilisée par les émetteurs et récepteurs PEPPOL car elle fait porter la responsabilité de la validation sur le récepteur. Le message INVOICE RESPONSE de réponse à la facture constitue un troisième niveau de réponse possible ; mais celui-ci est un message métier permettant le retour d’une information statut entre l’ERP du vendeur et celui de l’acheteur. Pour permettre sa généralisation, PEPPOL a développé un message normalisé de réponse à la facture (Invoice Response ) dans le but de fournir à l’émetteur des informations de traitement. Invoice response est un message structuré XML fondé sur UBL 2.1 (ISO IEC 19845:2015).

PEPPOL INVOICE RESPONSE

Ce troisième niveau permet de rendre compte des décisions de l’acheteur au vendeur, validation ou rejet « bon à payer » réconciliation avec la commande jusqu’à la mise en paiement de la facture. Le but de la réponse à la commande est :

  • D’aider le vendeur à engager une action si le traitement d'une facture est contesté ou donne lieu à un litige du côté de l'acheteur. La réponse informe le vendeur si sa facture est en cours de traitement ou si ce processus est interrompu et nécessite une action du vendeur.
  • D’informer le Vendeur lorsque sa facture a été approuvée ou que le paiement a été initié afin que le vendeur puisse gérer ses flux de trésorerie et surveiller la réception du paiement.
  • De fournir à l'acheteur des moyens automatisés pour tenir le vendeur informé de l'état de la facture et ainsi réduire ou éliminer les requêtes répétées et manuelles sur l'état de la demande de paiement.
  • De prendre en charge le traitement automatisé pour le vendeur, même s'il peut encore nécessiter des actions manuelles.
  • De fournir un message informatif de l'acheteur au vendeur.
  • De permettre une rétroaction de l'acheteur vers le vendeur sur le processus de traitement des factures du côté acheteur.
  • De permettre à l'acheteur d'informer le vendeur des décisions de l'acheteur dans le traitement des factures sous une forme structurée, donc directement intégrable par l’ERP du vendeur.

Le retour vers l’ERP du vendeur prend la forme d’un statut de traitement :

  1. IP - En cours de traitement
  2. UQ – Demande en cours (peut être répétée)
  3. CA - Accepté sous condition
  4. RE - Rejeté
  5. AP - Accepté
  6. PD - Payé

Les codes de traitement peuvent être ajoutés et motivés :

  • 1 Facture est en cours
  • 2a Facture est en cours avec attente de références supplémentaires
  • 2b La facture est en cours mais reportée
  • 3 La facture est acceptée
  • 4a La facture est rejetée
  • 4b La facture est rejetée mais peut être recyclée
  • 4c La facture est rejetée avec remplacement
  • 5 La facture est acceptée sous condition
  • 6a La facture est en cours d'investigation pour informations erronées ou manquantes
  • 6b La facture est en cours d'investigation pour référence de bon de commande manquante.
  • 6c La facture fait l’objet d’une demande pour montant erroné, avoir partiel requis.
  • 7 Le paiement de la facture est validé.
  • 8 La facture est acceptée par un tiers agissant au nom de l'acheteur.

Par exemple : une facture est rejetée avec le code de statut RE. Le code de motif de ce rejet est LEG indiquant que la facture ne remplit pas les exigences légales et dans le texte sous le motif que la référence TVA n'est pas trouvée.

mercredi, octobre 14 2020

Comment la France opte pour la facturation électronique B2B et l'e-Reporting de la TVA ? (6ème partie)

B2B

La réponse à la facture et la gestion des statuts indispensables au B2B

Nous avons vu dans le précédent billet le mécanisme du e-Reporting et comment le fichier fiscal de données pouvait être généré avec quelle implications sur les échanges entre les parties prenantes. Dans ce contexte certaines évolutions paraissent souhaitables comme l’acquittement de réception de la facture par le destinataire. Bien plus qu’un acquittement électronique de transmission (application response) il s’agit du retour d’un statut de traitement de la facture qui renseigne l’émetteur sur l’état de la demande de paiement. Cette évolution pourraient constituer une retombée indirecte du cadre de facturation électronique avec e-Reporting TVA pour lequel la réponse à la facture précisant la prise en compte de la livraison ou du paiement deviendrait aussi importante que la facture elle-même. Sur le plan de l’exigibilité de la taxe, la différence est notable entre un bien et un service. Alors que pour un produit ou une fourniture l’exigibilité dépend de la livraison ; pour un service, le fait générateur est de la date d’exécution de la prestation (notion de « service fait » très courante dans le secteur public) et l’exigibilité correspondant à l’encaissement. La complexité augmente encore avec le traitement des acomptes. Pour un bien, la TVA n’est exigible qu’avec la livraison, pas pour une prestation s’inscrivant dans la durée. La facture d’acompte est obligatoire pour pouvoir déduire la TVA au paiement de l’acompte. Chorus Pro nous a habitué à cette gestion des statuts. L’arrêté du 9 décembre 2014 sur le développement de la facturation électronique dans son article 14 détermine différents statuts et les conditions de mise à dispositions auprès des émetteurs de factures.

Si l’on veut tenir compte de ces exigences dans le cadre d’un système d’e-Reporting généralisé, il faudrait donc que la date de livraison puisse être ajoutée. Pour la date d’encaissement le statut est plus difficile à remonter car il est lié à l’ordre de paiement effectif. Alors que la plate-forme Chorus Pro renseigne systématiquement le fournisseur, dans le B2B, le vendeur est plus rarement informé du paiement. Souvent pour des raisons techniques et d’absence d’obligation. Cette information est pourtant utile à l’entreprise qui peut ainsi mieux gérer sa trésorerie et anticiper certaines situations.

Le développement du e-Reporting TVA pourrait donc impulser le déploiement d’un système de réponse à la facture. L’EDI dispose déjà d’un système d’accusé de réception technique (application response) mais cet AR technique (ACK) correspond à la vérification de l’intégrité des données transmises et reçues et reste muet sur le traitement ou le paiement de la facture. Le message réponse facture existe dans Chorus Pro et s’appelle flux CPP statuts. Cette réponse à l’initiative de l’acheteur est générée directement par la plate-forme sous la forme d’un fichier structuré (XML) qui peut être intégré par l’émetteur en EDI. Inconvénient, ce fichier n’est pas normalisé. Partant de ce constat, PEPPOL a développé un profil INVOICE RESPONSE qui pourrait être mis à disposition des émetteurs dans le réseau PEPPOL.

mardi, octobre 13 2020

Comment la France opte pour la facturation électronique B2B et l'e-Reporting de la TVA ? (5ème partie)

B2B

Le modèle eReporting distribué et régulé, un exemple avec PEPPOL CTC

Dans le précédent billet, nous avons évoqué la possibilité d’un modèle mixte alliant plate-forme centrale et modèle distribué où les opérateurs joueraient le rôle de transmetteur de données fiscales. Ce modèle présente plusieurs avantages, plus grande résilience, flexibilité, montée en charge facilitée, respect de la concurrence. PEPPOL, initiative européenne visant à développer la facturation électronique en Europe n’est pas en reste sur ce dossier et a aussi dans ses cartons un modèle de clearance pour le TVA.
Petit rappel : PEPPOL est créé en 2007 à l’initiative de la Commission Européenne pour faciliter les échanges électroniques et préparer la directive eInvoicing de 2015. Dans ce but, il est prévu qu’une infrastructure de réseau facilement implémentable et déployable par les Etats Membres pour faciliter les échanges électroniques avec leurs services publics. PEPPOL a depuis essaimé en Europe (L’Europe du Nord majoritairement, L’Italie, la Pologne, l’Allemagne ont choisi PEPPOL pour desservir leurs secteurs publics) et récemment hors de l'Europe, en Australie, Nouvelle Zélande et Singapour. PEPPOL est un modèle ouvert similaire au modèle d’itinérance (roaming) des opérateurs téléphoniques reposant sur une infrastructure de transmission constituées de plus de 300 points d'accès connectés à Internet. De ce fait, on peut dire que PEPPOL est le premier cloud de facturation en Europe. C’est un système appelé 4 coins car il désigne le nombre d’intervenants dans une transaction, typiquement un couple (fournisseur) associé à un point d'accès émetteur ; un couple destinataire de facture associé à un point d'accès récepteur. Pour faciliter la recherche dans le réseau, un annuaire électronique SML (Service Metadata Locator) centralise toutes les entités enregistrées et comme un DNS, permet de localiser le destinataire dans le réseau via un interrogateur SMP (Service Metadata Publisher) intégré aux points d’accès. Avec l'autorité fiscale, le modèle PEPPOL CTC (Continuous Transaction Control) ajoute une cinquième partie-prenante dans la boucle quatre coins. Ce modèle prévoit ainsi plusieurs possibilités de délégation (delegated control) en fonction du modèle clearance ou eReporting choisi par le Pays. Ainsi dans le schéma ci-dessous, il est prévu que le e-Reporting de C1 et C4 puisse se faire via les points d’accès PEPPOL, ici C2 transmet la facture à C3 ; C2 et C3 envoient les données fiscales à C5 représentant l’autorité fiscale qui reçoit des données.

PEPPOL_CTC_delegated_clearance.JPG
Il est important de noter que le modèle PEPPOL CTC n'est pas exclusif et peut coexister avec d'autres réseaux à valeur ajoutée (très peu d’opérateurs de services sont exclusivement PEPPOL et gèrent les communications avec d’autres réseaux ou en interopérabilité avec d’autres opérateurs.

La France devrait disposer d’un annuaire électronique et d’une autorité PEPPOL

Le déploiement d’une infrastructure réseau reposant sur un modèle e-Reporting CTC pourrait être facilité par un système d’adressage tel que celui de PEPPOL. En effet, un système e-Reporting impliquant plusieurs niveaux d’interactions entre les acteurs ne devrait pouvoir raisonnablement reposer sur les emails et les messageries électroniques. Il faudrait pouvoir disposer d’un annuaire centralisé tel que Chorus Pro, permettant la recherche et l’identification sure des acheteurs, de leurs moyens de réception de facture et les types de messages acceptés, factures, commande, réponse facture etc. Ce service devrait idéalement être couplé à un service de métadonnées permettant l’intermédiation électronique des acteurs. L’annuaire PEPPOL est couplé à un service de métadonnées SMP/SML permettant l’adressage et le routage automatique des messages via le réseau (dans PEPPOL tout émetteur ou destinataire de facture est enregistré au moyen d’un identifiant de réseau unique).

Finalement, ce qui est important en France serait de disposer d’une autorité PEPPOL qui puisse être régulateur de réseau, décider des règles qui puissent être imposées à l’ensemble des acteurs y compris les fournisseurs étrangers, définir le contenu des messages et des informations publiées.

- page 1 de 24