Le NOUVEL ACHAT

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

Tag - B2B

Fil des billets

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.

mardi, octobre 13 2020

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

B2B

Vers un modèle e-Reporting centralisé ou distribué ; à autorisation déléguée ou régulée ?

Dans le précédent billet, nous avons vu les questions soulevée par la facturation interentreprises notamment dans le contexte de Chorus Pro. En raison de la criticité et de l'impact potentiel de telles décisions pour les entreprises (dans un contexte de crise sanitaire déjà suffisamment tendu) le choix pourrait être de ne pas faire porter tout l'effort sur un seul point mais de répartir la charge sur un maillage dont la nature reste à déterminer. Un système mixte combinant plateforme centrale et réseau d’opérateurs accrédités par délégation de service pourrait alors voir le jour. Ce modèle régulé offrirait l’avantage de laisser libre la concurrence sur le marché, de préserver l'existant, de créer une organisation plus résiliente, moins dépendante d'un guichet unique et finalement plus souple dans sa capacité de montée en charge.

Dans cette logique, Chorus Pro pourrait rester le point d’entrée pour certaines factures et deviendrait aussi point de réception des données fiscales. Chorus Pro pourrait alors collecter les données depuis les factures déposées directement par les entreprises dans le portail. Ce n'est pas un enjeu considérable, dans la mesure où Chorus Pro effectue déjà cette transformation vers le flux pivot qui sert de format pour l'intégration des données vers les collectivités. Ce flux pivot contient sans doute la majorité des données utiles pour le reporting.

En parallèle, Chorus Pro effectuerait la collecte des données des prestataires accrédités. L'émetteur de facture utiliserait les services de son prestataire pour produire sa facture, lequel valide et collecte les données, crée le document fiscal et assure sa transmission à l'administration.
La cible pourrait donc inclure une bonne part de l’écosystème actuel. Cette délégation de service pourrait exister sous condition d'une accréditation préalable de la DGFiP. On imagine qu’une spécification technique ferait alors l’objet d’un arrêté fixant les conditions d'accréditation assorties d’un programme minimal de tests. Pour les grandes entreprises, la mise en place d’une solution pour leur propre compte parait peu probable dans la mesure où, seul un tiers de confiance habilité pourrait être mandaté pour effectuer ce travail et éviter ainsi à l'entreprise toute suspicion de fraude.

Pour garantir l’originalité de cette transaction, le flux pourrait être signé et archivé électroniquement. Demain d'autres fonctions pourraient être allouées à un système blockchain couplée à un registre distribué (DLT) à fins de sécurisation, vérification ou communication des données. Les dossiers d’archives (AIP) en plus des éléments constitutifs de la piste d’audit fiable (PAF) devraient sans doute inclure le fichier de données fiscales et l’attestation de traitement fiscal.

Finalement, l’obligation ne devant pas contraindre l’opérateur économique à passer par un opérateur de service en particulier, celui-ci devrait conserver la possibilité à un portail gratuit avec Chorus Pro ou la solution payante d'un opérateur de services. Chorus Pro devenant plate-forme d'intermédiation pour le B2B devrait donc aussi pouvoir permettre la mise à disposition de la facture auprès de l’acheteur privé invité à la télécharger directement dans le portail comme le font les entités publiques ou en EDI par le truchement d'un opérateur de service raccordé en réception à Chorus Pro. L'expérimentation récente (conduite entre février et juin 2020) a prouvé que cela ne devrait poser aucune difficulté à Chorus Pro.