Lors d’un changement d’ERP, la reprise comptable est souvent résumée à une phrase : « on va importer le FEC dans Odoo ».
C’est logique : le FEC est normé, disponible, et largement utilisé en France.
Mais le FEC est d’abord un format fiscal. Il est excellent pour reprendre un historique comptable… à condition de connaître ses limites (multi-devises, objets métier, qualité d’organisation).
Chez Auguria, nous réalisons des reprises vers Odoo depuis Sage 100, Sage X3, Cegid, Business Central, etc. Notre approche est simple : FEC quand c’est pertinent, CSV quand il faut faire mieux, et souvent un mélange des deux.
1) Le FEC : une norme fiscale avant tout
Le FEC est conçu pour l’audit et le contrôle : il reflète une comptabilité tenue en euros.
Il est très adapté pour :
importer un historique d’écritures,
reconstituer des journaux,
retrouver des soldes fiables,
conserver une traçabilité conforme.
Il est moins adapté pour :
reconstruire des objets métier (factures, paiements),
garantir une organisation lisible par pièce,
assurer une continuité fonctionnelle en multi-devises.
2) Condition impérative pour un import FEC dans Odoo
Pour qu’un import fonctionne correctement :
Les écritures doivent être regroupées par pièce comptable et être équilibrées
(total des débits = total des crédits).
Sans ça, l’import peut échouer ou produire des écritures inutilisables.
Problème fréquent : FEC “juste” mais mal ordonné
Dans de nombreux exports (notamment certains Sage), les lignes d’une même pièce sont dispersées.
Un FEC mal organisé n’est pas mauvais : il est simplement mal ordonné… et cela peut empêcher l’import dans Odoo.
Tri recommandé :
journal → date → référence de pièce → numéro d’écriture
3) Comptes tiers : structurer collectif et auxiliaires
Dans beaucoup de FEC, le tiers est codé dans CompteNum (401AMAZON, 411OTMORTA, etc.).
Dans Odoo, on préfère un compte collectif + un auxiliaire.
Exemple de transformation (tiers)
| Avant (FEC source) | Après (FEC préparé pour Odoo) |
|---|---|
| CompteNum = 401AMAZON | CompteNum = 40110000 |
| CompAuxNum vide | CompAuxNum = AMAZON (si AMAZON est le code tiers) |
| CompteLib = AMAZON EU | CompAuxLib = AMAZON EU |
Même logique côté clients :
| Avant | Après |
|---|---|
| CompteNum = 411OTMORTA | CompteNum = 41110000 |
| CompAuxNum vide | CompAuxNum = OTMORTA |
| CompteLib = OTMORTA | CompAuxLib = OTMORTA |
4) Comment Odoo exploite CompAuxNum et CompAuxLib
Lors de l’import :
si Odoo trouve un tiers existant avec la même référence, il le réutilise,
sinon, il peut créer automatiquement le contact grâce à CompAuxNum et CompAuxLib.
5) Le FEC atteint ses limites, notamment en multi-devises
Le FEC est pensé en euros : il ne permet pas de reprendre correctement une comptabilité multi-devises vivante (continuité des montants en devise, écarts de change, lettrage cohérent, etc.).
6) Quand le FEC ne suffit pas : imports CSV et “objets métier”
Quand on veut de la continuité fonctionnelle (surtout en devises), on complète ou on remplace le FEC par des imports CSV Odoo (factures, paiements, soldes).
Tableau d’aide à la décision : FEC / CSV / mix
| Objectif | Approche recommandée | Pourquoi |
|---|---|---|
| Historique comptable “figé” en euros | FEC | Rapide, complet, conforme |
| Continuité clients/fournisseurs (pièces ouvertes) | FEC + CSV | Odoo a besoin d’objets (factures/paiements) |
| Multi-devises (factures, banques en devises) | CSV (souvent) + éventuellement FEC pour le reste | Le FEC ne suffit pas pour une continuité devise |
| Reprise orientée gestion (factures, échéances, paiements) | CSV | On reprend des objets métier, pas seulement des écritures |
7) Journaux : rendre les codes lisibles et durables
Les codes journaux ne sont pas forcément longs, mais souvent peu significatifs (R2, VT, etc.).
La migration est le bon moment pour choisir des codes courts et explicites.
On rencontre aussi des codes par défaut comme MISC (utilisé par Odoo et d’autres logiciels).
En France, on choisit souvent OD pour “Opérations diverses”, plus parlant.
Modèle de mapping des journaux (exemples)
| Constat dans le FEC | Code Odoo cible | Exemple / logique |
|---|---|---|
| Ventes : code VT, libellé “VENTES” | VE ou FA | VE si journal ventes global, FA si journal factures clients |
| Banque : code technique R2 | SG (ou autre banque réelle) | On renomme selon la banque : SG, CA, BNP… |
| Banque : code BQ utilisé pour SG | SG | On spécialise : un journal = une banque |
| Opérations diverses : MISC | OD | Harmonisation en français, lisible |
8) Checklist avant de choisir “FEC… ou pas”
minimiser les surprises :
| Point à vérifier | Si “oui” | Si “non” |
|---|---|---|
| Écritures regroupées par pièce et équilibrées | FEC possible | Retraitement obligatoire |
| Comptabilité uniquement en euros | FEC souvent suffisant | CSV recommandé (ou mix) |
| Besoin de continuité métier (factures/paiements) | Mix FEC + CSV | CSV prioritaire |
| Codes journaux lisibles | Import plus simple | Profiter de la migration pour clarifier |
Conclusion
Le FEC est un excellent outil… quand il correspond au besoin.
Mais dans un projet Odoo, la bonne question n’est pas “peut-on importer le FEC ?” — c’est :
Quelle stratégie permet de repartir avec une comptabilité lisible, exploitable et durable ?
Chez Auguria, nous utilisons le FEC quand il est pertinent, et nous le complétons par des imports CSV quand il faut reprendre des objets métier (notamment en multi-devises) — pour livrer une comptabilité plus claire après migration qu’avant