Comment préparer son ERP à la facturation électronique
- min de lecture
- 7 min de lecture
- Publié le
- Publié le
- Mis à jour le
- Mis à jour le
- Écrit pour :
- DSI, chefs de projet et directions financières en amont d’un projet de facturation électronique.
Réponse courte
Que faut-il vérifier dans son ERP avant un projet de facturation électronique ?
Avant un projet de facturation électronique, il faut vérifier que l'ERP détient réellement toutes les données exigées par le format cible — et non seulement celles qui figurent sur le PDF actuel —, que les référentiels clients contiennent des identifiants exploitables et à jour, que le système sait recevoir des documents entrants et pas seulement émettre, et qu'il peut stocker et restituer les statuts de cycle de vie de chaque facture. Dans la majorité des cas, l'ERP contient déjà l'essentiel : ce qui manque est la couche qui extrait, met au format et gère les retours.
La question à poser en premier : et non « faut-il changer d’ERP ? »
Changer d'ERP pour émettre des factures électroniques est rarement justifié. Dans la plupart des cas l'ERP contient déjà les données nécessaires ; ce qui manque est la couche qui les extrait, les met au format attendu et gère les retours.
La bonne question est donc : que sait faire l'ERP aujourd'hui, et quel écart reste-t-il avec ce que le format cible exige ? C'est un écart mesurable, pas une décision structurante.
Vérification 1 — Complétude des données
Le piège classique consiste à raisonner sur ce que montre la facture PDF actuelle. Un format structuré exige des informations qui n'apparaissent nulle part sur le document imprimé : identifiants normalisés, références de commande, codes pays, qualifiants de taxe, unités de mesure codifiées.
- Identifiants légaux de l’émetteur et du destinataire, dans un format exploitable et non en texte libre.
- Références de commande et de livraison, quand le destinataire les impose pour le rapprochement.
- Codification des taxes et des unités, alignée sur les jeux de codes attendus.
- Coordonnées de paiement structurées plutôt que rédigées en pied de page.
Vérification 2 — Qualité des référentiels
Un référentiel client approximatif produit des rejets en série dès que l'identifiant du destinataire devient une donnée bloquante. Ce qui passait inaperçu à l'ère du PDF envoyé par mail devient un point d'arrêt.
Il faut aussi vérifier la cohérence entre systèmes : si l'ERP, le WMS et la comptabilité ne s'accordent pas sur l'identifiant d'un même client ou d'un même article, l'automatisation restera partielle.
Vérification 3 — La réception, pas seulement l’émission
La réception est la moitié la plus souvent oubliée. Recevoir des factures structurées suppose de savoir les intégrer, les rapprocher d'une commande et déclencher un circuit de validation.
Un projet qui ne traite que l'émission produit un résultat asymétrique : les factures sortantes sont automatisées, les entrantes s'accumulent dans un portail que personne ne consulte.
Vérification 4 — Statuts et traçabilité
- L’ERP peut-il stocker un statut par facture (déposée, rejetée, acceptée, payée) et l’historiser ?
- Un rejet est-il visible par la personne capable d’agir, ou seulement dans un journal technique ?
- Un flux échoué peut-il être rejoué sans créer de doublon ?
- Dispose-t-on d’une trace de ce qui a été transmis, telle que transmise ?
Vérification 5 — Ce que le projet va révéler
Un projet de facturation électronique met en lumière des faiblesses préexistantes qui étaient tolérables tant qu'un humain relisait chaque document : doublons clients, articles sans codification stable, remises calculées hors système, contournements installés depuis des années.
Anticiper ce constat évite de le découvrir en phase de test, au moment où le calendrier laisse le moins de marge.