When changing ERP, accounting recovery is often summarized in one sentence:"we will import the FEC into Odoo".
It makes sense: the FEC is standardized, available, and widely used in France.
But the FEC is primarily a tax format. It is excellent for recovering accounting history…provided you know its limits (multi-currency, business objects, quality of organization).
At Auguria, we perform migrations to Odoo from Sage 100, Sage X3, Cegid, Business Central, etc. Our approach is simple : FEC when it is relevant, CSV when it needs to be better, and often a mix of both.
1) The FEC: a tax standard above all
The FEC is designed for audit and control: it reflects accountingkept in euros.
It is very suitable for:
importing a history of entries,
reconstructing journals,
finding reliable balances,
maintaining compliant traceability.
It is less suitable for:
rebuilding business objects (invoices, payments),
ensuring a piece-readable organization,
ensuring functional continuity inmulti-currency.
2) Imperative condition for an FEC import in Odoo
For an import to work correctly:
Entries must be grouped by accounting piece and be balanced
(total debits = total credits).
Without this, the import may fail or produce unusable entries.
Common problem: FEC "correct" but poorly ordered
In many exports (notably some Sage), the lines of the same piece are scattered.
A poorly organized FEC is not bad: it is simply poorly ordered... and this can prevent the import into Odoo.
Recommended sorting:
journal → date → piece reference → entry number
3) Third-party accounts: structure collective and auxiliary
In many FECs, the third party is coded in CompteNum (401AMAZON, 411OTMORTA, etc.).
In Odoo, we prefer a collective account + an auxiliary.
Example of transformation (third party)
| Before (source FEC) | After (FEC prepared for Odoo) |
|---|---|
| CompteNum = 401AMAZON | CompteNum = 40110000 |
| CompAuxNum empty | CompAuxNum = AMAZON(if AMAZON is the third party code) |
| CompteLib = AMAZON EU | CompAuxLib = AMAZON EU |
Same logic on the client side:
| Before | After |
|---|---|
| AccountNum = 411OTMORTA | AccountNum = 41110000 |
| CompAuxNum empty | CompAuxNum = OTMORTA |
| AccountLib = OTMORTA | CompAuxLib = OTMORTA |
4) How Odoo uses CompAuxNum and CompAuxLib
During import:
if Odoo finds an existing third party with the same reference, it reuses it,
otherwise, it canautomatically create the contactusing CompAuxNum and CompAuxLib.
5) The FEC reaches its limits, especially in multi-currency
The FEC is designed in euros: it does not allow for properly handling a live multi-currency accounting (continuity of amounts in currency, exchange rate differences, consistent matching, etc.).
6) When the FEC is not enough: CSV imports and 'business objects'.
When we want functional continuity (especially in currencies), we complement or replace the FEC with Odoo CSV imports (invoices, payments, balances).
Decision support table: FEC / CSV / mix
| Objective | Recommended approach | Why |
|---|---|---|
| 'Frozen' accounting history in euros | FEC | Fast, complete, compliant |
| Continuity of customers/suppliers (open items) | FEC + CSV | Odoo needs objects (invoices/payments) |
| Multi-currency (invoices, currency banks) | CSV (often) + possibly FEC for the rest | The FEC is not enough for currency continuity |
| Management-oriented recovery (invoices, deadlines, payments) | CSV | We take back business objects, not just entries |
7) Journals: make codes readable and sustainable
Journal codes are not necessarily long, but oftennot very meaningful(R2, VT, etc.).
Migration is the right time to choose shortand explicit codes.
We also encounter default codes like MISC(used by Odoo and other software).
In France, we often choose OD for “Miscellaneous Operations”, which is more descriptive.
Journal mapping model (examples)
| Observation in the FEC | Target Odoo code | Example / logic |
|---|---|---|
| Sales: code VT, label “SALES” | VEorFA | VE if global sales journal, FA if customer invoices journal |
| Bank: technical code R2 | SG (or another real bank) | We rename according to the bank: SG, CA, BNP… |
| Bank: code BQ used for SG | SG | We specialize: one journal = one bank |
| Miscellaneous operations: MISC | OD | Harmonization in French, readable |
8) Checklist before choosing “FEC… or not”
minimize surprises:
| Point to check | If “yes” | If “no” |
|---|---|---|
| Entries grouped by document and balanced | FEC possible | Mandatory reprocessing |
| Accounting only in euros | FEC often sufficient | CSV recommended (or mix) |
| Need for business continuity (invoices/payments) | Mix FEC + CSV | CSV priority |
| Readable journal codes | Simpler import | Take advantage of the migration to clarify |
Conclusion
The FEC is an excellent tool…when it meets the need.
But in an Odoo project, the right question is not“can we import the FEC?”— it is:
What strategy allows us to start with readable, usable, and sustainable accounting?
At Auguria, we use the FEC when it is relevant, and we supplement it with CSV imports when we need to retrieve business objects (especially in multi-currency) — to deliver clearer accounting after migration than before.