Un ERP ne parle pas directement à l'e-MCF : il lui faut un système de facturation d'entreprise (SFE) qui contrôle les règles de la DGI, numérote, envoie la facture et renvoie le code DEF et le QR. Trois voies : le module de votre éditeur, un développement interne, ou une passerelle reliée par API, SDK ou fichier CSV. Dans tous les cas, le SFE doit être homologué.
Le principe : l'ERP envoie le document, jamais le résultat
Dans une intégration correcte, l'ERP envoie la vente (client, lignes, groupes de taxation, paiements) et reçoit le numéro, le code DEF, le NIM, les compteurs, l'heure et le code QR. Il ne calcule ni numéro, ni taux, ni total définitifs : ce sont le dispositif et le SFE qui font foi. Les règles de la DGI sont contrôlées avant l'envoi (par exemple : pas de montant nul ou négatif, un code pour chaque article, NIF et nom pour les clients personnes morales, paiements égaux au total) et le total calculé est comparé au centime à celui du dispositif ; au moindre écart, la facture est annulée au dispositif et non confirmée.
Trois voies pour relier un ERP
1. Le module de votre éditeur ou de son revendeur
Plusieurs prestataires proposent des modules pour Odoo, SAP ou d'autres ERP. Certains annoncent une solution « homologuée DGI ». Ne vous fiez pas à l'annonce : demandez l'attestation de conformité de la DGI, son numéro et sa date, et cherchez le système sur la liste que la DGI publie (site de la DGI). Demandez aussi à qui l'homologation a été délivrée (l'éditeur ou une entreprise cliente) et si elle couvre vos groupes de taxation, car les SFE déjà homologués doivent revenir pour une ré-homologation (FEC, commission mixte du 27 octobre 2026).
2. Un développement interne
Possible, mais l'entreprise devient son propre éditeur de SFE : protocole e-MCF et MCF, règles SFE, numérotation sans trou, journal inviolable, reprise après incident, tests, dossier d'homologation. C'est lourd pour une équipe dont le métier n'est pas l'édition de logiciels.
3. Une passerelle entre l'ERP et la DGI
Voyager Fiscal est une passerelle de ce type. Votre ERP l'appelle de trois manières :
- API REST : un appel
POST /api/v1/invoicesavec le document ; la réponse contient les éléments de sécurité, ou la liste des problèmes. Le même appel renouvelé après un délai dépassé renvoie la même réponse (clé de référence source) : pas de double facture. - SDK : un paquet .NET, et des SDK JavaScript et Python sans dépendance.
- Dossier d'échange (sans code) : l'ERP dépose un fichier JSON ou CSV dans un dossier ; la passerelle écrit le résultat et un texte prêt à imprimer, puis range le fichier. Un dossier SFTP peut y mener.
#FV;TTC;PM;B7654321C;ABC SARL;Jacques;; LAIT;Lait 1L;BIE;B;2900;2 EAU;Eau 1.5L;BIE;B;1200;3 $MOBILEMONEY;5000 $ESPECES;4400
Cet exemple de fichier CSV est tiré de la documentation de Voyager Fiscal : une facture de vente (FV) en TTC pour un client personne morale, deux articles, deux moyens de paiement.
Schémas types par ERP (à valider sur votre installation)
- SAP Business One : à la comptabilisation de la facture, une extension ou un composant appelle l'API (Service Layer ou DI API côté SAP) et écrit le code DEF, le NIM et le QR dans des champs utilisateur de la facture.
- Odoo : une action serveur ou un module appelle l'API à la validation de la facture et enregistre les éléments de sécurité sur la pièce, puis imprime le QR sur le modèle de facture.
- Sage : selon la version, un export planifié au format CSV ou un appel de services web depuis le module de vente alimente le dossier d'échange.
- Microsoft Dynamics 365 Business Central : une extension appelle l'API à la validation de la vente.
- Caisses et boutiques en ligne : appel direct de l'API ; les connecteurs pour Shopify et WooCommerce sont prévus.
À propos de nos connecteurs : ceux pour Odoo, SAP Business One, Dynamics 365 Business Central, Sage, Shopify et WooCommerce sont préparés d'après la documentation publique de chaque produit, et validés sur votre propre export pendant un pilote. Ils ne sont pas « certifiés » par ces éditeurs.
Ce que l'ERP doit conserver
- La référence source de chaque vente (clé qui empêche les doublons).
- Le code DEF/DGI, le NIM, la date et l'heure, le QR de chaque facture, pour l'impression et le contrôle.
- Pour chaque note de crédit : le code DEF de la facture d'origine et la nature (COR, RAN, RAM ou RRR). La correction d'une facture normalisée passe par une note de crédit, jamais par une modification.
- Les groupes de taxation, à jour après la mise à jour de la DGI de février 2026.
Cinq questions à poser à tout fournisseur
- Pouvez-vous me montrer l'attestation d'homologation, son numéro et sa date, et le nom du titulaire ?
- Que se passe-t-il quand l'e-MCF ne répond plus (voir le guide sur les pannes) ?
- Comment gérez-vous la limite de 10 factures en attente avec mes dix caisses ?
- Comment gérez-vous les notes de crédit et les nouveaux groupes de taxation ?
- Qui voit l'état de tous mes magasins depuis le siège, et comment sont tracées les actions ?
Questions fréquentes
Faut-il changer d'ERP pour émettre des factures normalisées ?
Non. Un ERP peut rester en place si une couche de facturation (SFE) homologuée le relie à l'e-MCF ou au MCF, par API, SDK ou dossier d'échange de fichiers CSV ou JSON.
Peut-on utiliser un fichier Excel ou CSV ?
Oui avec une passerelle qui lit un dossier d'échange : l'ERP ou la caisse dépose un fichier CSV ou JSON, la passerelle le transforme en facture normalisée et renvoie un résultat et un texte prêt à imprimer. Un tableur seul ne remplace pas un dispositif de la DGI.
Mon revendeur dit que sa solution est homologuée : comment vérifier ?
Demandez l'attestation de conformité de la DGI avec son numéro et sa date, puis cherchez le système sur la liste des SFE homologués et des DEF agréés publiée sur le site de la DGI.
Sources
Ce guide est informatif et ne remplace ni les textes officiels ni un conseil juridique ou fiscal. Les numéros de textes et les montants repris de la presse ou de cabinets sont signalés comme tels : vérifiez-les auprès de la DGI ou de votre conseil avant d'agir.