Le fonctionnement d’une comptabilité en partie triple

La comptabilité en partie triple a été présenté par Ian Grigg dans le papier suivant : Ian Grigg - TEA

Une signature électronique sur un document équivaut à dire : “à un certain moment, cette information a été vu et signée par l’ordinateur signataire”.

Il imagine la procédure de facturation suivante :

  • Alice crée une facture, la signe éléctroniquement et l’envoi sur un serveur « neutre » nommé Yvan qui la transmet au destinataire Bob
  • Si Bob accepte la facture et signe à son tour la facture, il signifie sa décision à Yvan
  • Yvan possède alors une facture acceptée et signée par les deux parties : c’est le « reçu partagé »

BLC

Le “reçu partagé” constitue l’enregistrement de la transaction, c’est une preuve de la transaction dans la mesure où elle matérialise l’accord des deux parties et qu’il n’est pas possible de modifier le contenu de la transaction.

Afin de mettre en place ce système, Grigg met en avant plusieurs pré-requis :

  • Un mécanisme d’identification des parties
  • Un mécanisme de signature : il suggère l’utilisation d’une signature par clé publique
  • Un mécanisme de transmission des instruction : le serveur se contente de transmettre
  • Un mécanisme pour ajouter ou mettre à jour le registre au fur et à mesure que les échanges sont réalisés (proposition d’une transaction, acceptation, paiement, accusé de réception)
  • Un mécanisme de stockage et de consultation des données
  • Un mécanisme de paiement à intégrer au coeur de l’architecture du système dans un soucis d’efficacité
  • Un mécanisme de messagerie entre les parties

Supposons que :

  • La facturation éléctronique soit rendue obligatoire en B2B
  • Le format hybride Factur-X soit retenu parmis les standard acceptés
  • L’ensemble des entreprises disposent d’une signature éléctronique certifiée par l’Etat

Factur-X est un format hybride associant en même temps une facture lisible sous format PDF et des données de facture présentées sous forme de fichier structuré, permettant aux systèmes d’information de procéder à une intégration et un rapprochement automatisé.

Il s’agit d’un standard franco-alleman conforme à la norme EN16931. Il s’agit d’une facture sous format PDF-A3 associé à un fichier xml sous syntaxe UN/CEFCT CII D16B. Il est particulierement adapté au TPE/PME.

Le format est disponible à l’adresse suivante : Factur-X

Définitions

  • La blockchain est une technologies de stockage et de transmission d’informations, permettant la constitution de registres répliqués et distribués, sécurisées grâce à la cryptographie, et structurées par des blocs liés les uns aux autres.

  • Une fonction de hachage est un procédé à sens unique permettant d’obtenir une empreinte caractérisant un ensemble de données, c’est un identifiant unique.

Caractéristiques

  • Une transaction inscrite sur la blockchain ne peut plus être supprimée
  • Les données sont liées les unes aux autres
  • Les données sont stockées de manière pérennes
  • Les données sont stockées de manière confidentielle grâce à la cryptographie

La blockchain semble donc totalement appropriée à la mise en place de la comptabilité en partie triple.

Schemas d’une blockchain de factures

Voici comment fonctionnerait une telle blockchain :

BLC

  • HR20 : le hash de référence du bloc (HR19 + HF20)
  • HR19 : le hash de référence du bloc précédent
  • HF20 : le hash de la facture F20, son empreinte numérique
  • F20 : la facture F20 au format éléctronique

HF20 est plus qu’un simple numéro de facture, il s’agit d’une empreinte, un identifiant unique de la facture, garant de son intégrité.

On peut très bien imaginer indiquer HF20 à la place de la référence habituelle en comptabilité, liant ainsi l’ERP et la blockchain

Les blocs sont liés entre eux au travers des références au bloc précédent (HR19 ici) Une fois le bloc ajouté, il est impossible de modifier le contenu de F20 sans modifier toute la chaine.

Aller plus loin avec l’ensemble des transactions

BLC2

Il est possible d’imbriquer plusieurs blockchains à différents niveaux pour inclure l’ensemble des échanges habituels entre les partenaires commerciaux.

Par exemple :

  • Le bon de commande
  • Le bon de livraison
  • La facture
  • L’avis de mise en paiement

La piste d’audit fiable

La piste d’audit doit permettre de reconstituer, dans un ordre chronologique la totalité du processus documenté depuis son origine jusqu’à la facture (bons de commande, bons de livraisons, facture).

Le système présenté permettrait de répondre aux principales exigences de l’administration en garantissant :

  • L’authenticité de l’orgine de par la signature éléctronique apposée par chaque partie
  • L"intégrité du contenu : la blockchain permet de s’assurer qu’il n’y a pas d’alteration du contenu des factures, et si c’est le cas, celà saute aux yeux.
  • La lisibilité : le format factur-X répond à cette caractéristique (format PDF/A)

Le schémas présenté précédament permet de documenter la piste d’audit fiable. En effet une telle documentation doit être mis en place par les entreprises et permettre d’établir une piste d’audit fiable entre la facture émise ou reçue et la livraison de biens ou prestation de services qui en est le fondement.

Les avantages attendus d’un tel système

  • Permet de stocker la piste d’audit et notamment les factures
  • La facture représente une vérité unique, partagée entre les parties. On évite ainsi la redondance.
  • L’ERP de chaque partie peut se connecter à la blockchain et ainsi alimenter la Comptabilité
  • Un système de paiement pourrait être intégrer au système
  • L’éxécution de smart contrat sur la blockchain pourrait permettre d’automatiser certains traitements. On peut ainsi imaginer le passage d’une écriture en comptabilité lors de la reception du bon de livraison pour constater une facture non parvenue.
  • La manipulation des comptes est rendu plus difficile car la blockchain présente une vérité partagée et est difficilement alterable.

Les limites

  • S’agissant d’une blockchain privée avec des droits d’accès entre des parties réalisant des échanges commerciaux le mécanisme de consensus serait simplifié. En effet, les mécanismes de consensus de la blockchain suppose en principe une absence de confiance entre les noeuds. Cette absence de confiance oblige les développeurs à mettre en place des protections pour empecher les noeuds malveillants d’inscrire une transaction sans fondement sur le registre. On peut par exemple citer le minage utilisé par le bitcoin.

  • Le bon fonctionnement du système suppose l’acceptation de la blockchain par les deux parties. Celà suppose donc l’émérgence d’un logiciel blockchain adapté et répondant à des normes.