Aller au contenu

Facturation électronique

Deux sociétés, deux référentiels, et une seule obligation.

Tant que chaque entité facturait dans son coin, la question ne se posait pas. La facturation électronique la pose, avec une date. Voici ce qu'il faut trancher, et dans quel ordre.

Mis à jour le 8 août 20267 minutes de lecture

Ce que le rachat a laissé en suspens

Une acquisition se termine rarement par une unification complète. On fusionne le juridique, on fusionne parfois la paie, et on remet à plus tard ce qui fonctionne encore.

Ce « plus tard » contient à peu près toujours les mêmes choses : deux référentiels fournisseurs, avec des doublons qui portent des identifiants différents. Deux plans de comptes analytiques qui ne se recoupent pas. Deux circuits de validation, avec des seuils différents pour la même dépense. Et souvent une troisième pratique, née entre les deux, que personne n'a formalisée.

Rien de tout cela n'est anormal. C'est même le comportement rationnel : unifier coûte cher, et tant que chaque entité facture de son côté, l'écart ne se voit pas.

La réforme change une chose, et une seule : elle rend cet écart visible et daté.

Les quatre questions que la réforme rend inévitables

Elles paraissent administratives. Elles sont opérationnelles, et chacune peut bloquer une facture.

  1. Quelle entité juridique reçoit la facture, et est-ce la même que celle qui a commandé ?
  2. Sous quel identifiant le fournisseur est-il connu de chaque côté, et savez-vous qu'il s'agit du même ?
  3. Quel circuit de validation s'applique : celui de l'acquéreur, celui de la cible, ou un seuil négocié ?
  4. Qui tranche quand une facture concerne les deux entités ?

Tant que ces réponses vivent dans la tête de deux comptables, elles fonctionnent. Elles ne survivent pas à un départ, et elles ne se transmettent pas à un système.

Le piège du référentiel fournisseur

C'est le point qui coûte le plus, et le plus sous-estimé.

Le même fournisseur existe des deux côtés, sous deux codes internes, souvent avec deux orthographes et parfois deux conditions de paiement négociées séparément. Tant que les deux comptabilités sont séparées, cela ne gêne personne.

Dès qu'un flux normalisé arrive, la question devient : ces deux lignes désignent-elles la même entreprise ? Et si oui, quelles conditions s'appliquent ?

Ce n'est pas une question qu'un outil tranche. C'est une décision de gestion, qui doit être prise avant qu'un système l'applique. Un logiciel qui devine une correspondance produit un rapprochement faux, et un rapprochement faux coûte plus cher qu'un rapprochement absent, parce qu'on ne le cherche pas.

Ce qu'il ne faut surtout pas faire

Ne pas migrer les deux entités sur un seul ERP dans l'urgence. Une migration d'ERP menée sous contrainte de calendrier réglementaire est la meilleure façon d'obtenir les deux problèmes à la fois : un flux non conforme et un système que personne ne maîtrise.

Ne pas non plus attendre l'unification pour agir. Beaucoup d'entreprises repoussent le sujet en se disant qu'elles trancheront « quand les systèmes seront fusionnés ». Cette fusion n'a souvent pas de date.

La voie praticable est ailleurs : garder les deux systèmes, et construire au-dessus la couche qui sait à quelle entité, quel fournisseur et quel circuit rattacher chaque facture. C'est moins ambitieux qu'une fusion, et c'est ce qui tient une échéance.

L'ordre dans lequel trancher

Quatre décisions, et elles se prennent dans cet ordre :

  1. Le référentiel fournisseur commun. Quels doublons, quel identifiant fait foi, quelles conditions s'appliquent.
  2. La règle d'affectation d'entité. À quoi reconnaît-on que cette facture appartient à celle-ci plutôt qu'à celle-là.
  3. Le circuit de validation unifié, avec ses seuils. Un seul jeu de règles, écrit.
  4. Le comportement en cas d'ambiguïté. Que fait le système quand il ne sait pas ? La seule bonne réponse : il s'arrête et le dit.

Les trois premières sont des décisions de gestion. Seule la quatrième est une décision technique, et c'est celle qui détermine si le système sera fiable ou seulement fonctionnel.

Le critère de réussite

Il n'est pas « les factures passent ». Il est : quand une facture ne passe pas, on sait pourquoi en moins d'une minute, et une personne identifiée peut la débloquer.

Un système qui traite quatre-vingt-quinze pour cent des factures sans erreur mais laisse les cinq pour cent restants dans un état indéterminé n'a pas réglé le problème. Il l'a déplacé, et rendu moins visible.

C'est le principe qui guide les systèmes que nous construisons : un résultat est exact, ou il est déclaré non traitable avec sa cause. Jamais une correspondance devinée présentée comme certaine.