ERP conforme COBAC et OHADA : pourquoi Dynamics 365 Business Central ?

La plupart des ERP vendus en Afrique centrale sont conformes. Sur la plaquette.

L’épreuve de vérité arrive au premier paiement fournisseur soumis à retenue, ou au premier contrôle de la DGI. À ce moment-là, une question très concrète se pose : le logiciel a-t-il comptabilisé la retenue à la facturation ou au règlement ? S’il s’est trompé, ce ne sont pas quelques écritures à reprendre — c’est la déclaration mensuelle qui est fausse, et le redressement qui suit.

Voici ce que « conforme » veut réellement dire en zone CEMAC, et pourquoi Business Central s’en sort mieux que la plupart — à une condition qu’aucun éditeur n’aime mettre en avant.

1. Deux référentiels qu’on confond constamment

OHADA est le cadre comptable. Il couvre 17 pays et s’impose à toutes les entreprises, du commerçant à l’industriel. Sa norme comptable en vigueur est le SYSCOHADA Révisé, applicable depuis 2018. Elle fixe le plan de comptes, les états financiers et les règles d’évaluation.

COBAC est le régulateur bancaire de la CEMAC. Ses exigences — reporting prudentiel, ratios, pistes d’audit, conservation des données — ne s’appliquent qu’aux établissements de crédit et de microfinance. Elles se superposent à OHADA, elles ne le remplacent pas.

La conséquence pratique est simple. Une PME de négoce, une industrie ou un cabinet de services a besoin d’un ERP conforme OHADA. Une banque ou un établissement de microfinance a besoin des deux — et son système d’information devra en plus produire des états que son ERP de gestion ne fournit pas seul.

Un fournisseur qui vous vend « la conformité COBAC » sur un ERP de gestion généraliste vous vend au mieux une partie du chemin.

2. Les quatre endroits où les ERP standards échouent

Le plan de comptes n’est pas un paramètre cosmétique

SYSCOHADA impose une structure à huit classes et des comptes précis. Un ERP conçu pour le plan comptable français ou anglo-saxon peut l’imiter, mais les automatismes restent câblés sur autre chose : les lettrages, les états financiers, les contreparties automatiques.

Le signal d’alarme : si le numéro de compte apparaît en dur dans un paramétrage ou un développement, le système est fragile. Un plan comptable évolue — au fil des exercices, ou parce que l’entreprise change de convention. Tout compte doit venir d’une table de paramétrage, jamais d’une ligne de code.

La retenue à la source se constate au règlement, pas à la facture

C’est le point où le plus grand nombre d’ERP se trompent, parce que la logique par défaut d’un progiciel international est de constater la taxe au moment de la facture.

Au Cameroun, la retenue à la source est due au moment du paiement. Ses taux varient selon la nature de la prestation, le régime fiscal du fournisseur, le montant du marché et la loi de finances de l’année. C’est précisément pourquoi ils doivent vivre dans une table de paramétrage, jamais dans le code.

Une erreur de moment de constatation ne se voit pas dans le grand livre : les montants y sont justes. Elle se voit dans la déclaration du mois, décalée d’une période. C’est précisément ce qu’un contrôle fiscal cherche.

La retenue de TVA est de 100 %, et elle change qui paie l’État

Le mécanisme du collecteur agréé (CGI, art. 149) désigne certaines entités — État, établissements publics, grands comptes désignés par la DGI — qui retiennent l’intégralité de la TVA figurant sur les factures de leurs fournisseurs et la reversent elles-mêmes au Trésor.

Pour le fournisseur, la conséquence est brutale : il encaisse le TTC diminué de toute la TVA, et se retrouve avec une créance fiscale à imputer sur sa TVA à payer du mois. Un ERP qui ne modélise pas cette créance produit une trésorerie fausse et une déclaration de TVA fausse.

Subtilité que peu de systèmes gèrent : une même entreprise peut être collecteur sur ses achats et retenue sur ses ventes, simultanément. Les deux flux doivent coexister sans se contaminer.

Le franc CFA n’a pas de décimale, et la TVA se calcule en cascade

Deux détails qui provoquent des écarts à répétition.

Le XAF s’arrondit à l’unité. Un ERP qui conserve deux décimales accumule des écarts de centimes qui finissent par empêcher le lettrage d’une facture avec son règlement — un solde d’un franc qui bloque une clôture.

Et lorsqu’un droit d’accise s’applique, la base de la TVA inclut l’accise. L’erreur classique consiste à calculer la TVA sur le montant hors taxes seul :

Montants en XAF
HT                  10 000 000
Accise (2 %)           200 000
Base TVA = HT + accise
                    10 200 000
TVA à 19,25 %        1 963 500
  et non             1 925 000

Trente-huit mille cinq cents francs d’écart sur une seule facture. Répété sur un exercice, c’est un redressement.

Le taux camerounais de 19,25 % est lui-même composite : 17,5 % de TVA plus 10 % de centimes additionnels communaux.

3. Pourquoi Business Central, alors

Trois raisons, dans cet ordre.

Le paramétrage plutôt que le code. Business Central expose les comptes, les taux et les matrices de taxe dans des tables de configuration. C’est ce qui permet de suivre une évolution réglementaire sans rouvrir un chantier de développement — et en zone CEMAC, la réglementation bouge.

Une piste d’audit native. Chaque écriture conserve son origine, son utilisateur et son horodatage, sans module additionnel. C’est le socle de ce qu’un contrôleur, fiscal ou prudentiel, viendra chercher.

Une capacité d’extension propre. Les points de la section précédente ne sont pas couverts en standard. Aucun ERP international ne les couvre complètement en standard : ce sont des spécificités CEMAC. La vraie question n’est donc pas « votre ERP est-il conforme d’origine ? » — aucun ne l’est — mais « peut-on lui ajouter la conformité sans le dénaturer ? ».

Business Central le permet par extension : le code métier ajouté vit à côté du standard, et survit aux mises à jour de Microsoft. C’est ce qui distingue une adaptation durable d’un ERP modifié dans ses entrailles, qu’on ne pourra plus mettre à jour.

4. Ce que ça donne en production

SIGA exploite aujourd’hui, chez un client camerounais du secteur de l’énergie, une extension Business Central qui prend en charge les retenues à la source et la retenue de TVA selon la doctrine du règlement, avec la ventilation par nature exigée pour la déclaration mensuelle.

Ce qu’on en retient après plusieurs versions en production :

• Les sous-comptes par nature valent la peine. Ventiler les retenues honoraires, loyers, BTP et dividendes sur des comptes distincts plutôt que sur un compte agrégé transforme la préparation de la déclaration mensuelle et rend l’audit lisible.
• Le paiement partiel est le vrai test. Régler 40 % d’une facture doit produire 40 % de la retenue, au franc près. C’est là que les implémentations approximatives se révèlent.
• L’arrondi doit être verrouillé au niveau du système, pas laissé à l’appréciation de chaque saisie.

5. Cinq questions à poser avant de signer

À tout éditeur ou intégrateur qui vous propose un ERP « conforme » :

1. La retenue est-elle constatée au règlement ou à la facturation ? Faites-le démontrer sur un paiement réel, pas sur une plaquette.
2. Que se passe-t-il sur un règlement partiel ? Demandez une démonstration à 40 %.
3. Les comptes sont-ils paramétrables, ou écrits dans le code ? Demandez à en changer un devant vous.
4. Les montants en XAF sont-ils arrondis à l’unité par le système lui-même ?
5. L’adaptation survivra-t-elle aux mises à jour de l’éditeur ? C’est la question qui coûte le plus cher trois ans plus tard.

Si les cinq réponses ne sont pas immédiates et démontrables, la conformité annoncée est une intention.

SIGA IT Consulting déploie Dynamics 365 Business Central en zone CEMAC, avec les adaptations OHADA nécessaires. Découvrez notre offre Applications d’entreprise, ou la méthode de déploiement que nous appliquons en 90 jours.