SoftbooqAccounting handoff / France
The file the DGFiP asks for, and the deadline you do not control
On a tax inspection, a business keeping its accounts in France must hand over its entire general ledger as a FEC: eighteen mandatory columns, in a fixed order, under the exact names the DGFiP publishes. Here is what the file contains and where an export goes wrong.
What the file actually is
- 1A header line with the exact DGFiP namesEighteen columns, spelled as published: JournalCode, JournalLib, EcritureNum, EcritureDate, CompteNum, CompteLib, CompAuxNum, CompAuxLib, PieceRef, PieceDate, EcritureLib, Debit, Credit, EcritureLet, DateLet, ValidDate, Montantdevise, Idevise. Renaming or reordering one of them invalidates the file.
- 2One row per journal LINENot per entry. A three-line entry produces three rows sharing an EcritureNum. This is the opposite of the DATEV convention, where a booking is an account pair, and it is the single most common mistake when an export is adapted from another market.
- 3A file named for your SIREN and your closing dateThe DGFiP convention is {SIREN}FEC{clôture as YYYYMMDD}.txt. The SIREN is not a column inside the file; it identifies the file itself.
The five things that go wrong
None of these are exotic. Each one is a default that is correct almost everywhere else in software, and wrong here.
The file is tab separated. A semicolon or a comma is a different format, and no text field may contain a tab or a newline of its own. A description carrying either one silently shifts every following column on that row, which is worse than a rejection because the file still parses.
Amounts use a decimal comma. Debits and credits are positive numbers in two separate columns, so a negative value in Debit is not a credit, it is an error.
EcritureDate, PieceDate, DateLet and ValidDate are YYYYMMDD with no separators. Not the French DD/MM/YYYY a human would write, and not ISO with hyphens.
Every row carries a journal code and its label. An inspector expects the French abbreviations rather than invented ones: VT for Ventes, AC for Achats, BQ for Banque, PAI for Paie, OD for Opérations diverses.
CompteNum carries the number alone and CompteLib carries the name. An export that writes "706 - Prestations de services" into CompteNum has filled one required column with two pieces of data and left the other one wrong.
Why the row shape matters more than the formatting
The formatting rules above are mechanical: get the separator, the comma and the date pattern right and they stay right. The row shape is where an export adapted from another market quietly breaks.
A FEC row is a journal LINE. The general ledger it comes from is already a list of lines, so the mapping is direct and nothing has to be decomposed or paired. If your export was built for a format that stores bookings as account and counter-account, the temptation is to reuse that pairing here, and the result is a file that balances but does not describe your ledger.
Foreign currency
Montantdevise and Idevise exist for lines posted in a currency other than the euro. They carry the original amount and its currency code while Debit and Credit stay in euro at the rate on the posting date. Leaving them empty on a euro line is correct; filling them with the euro amount is not.
Lettrage
EcritureLet and DateLet record reconciliation between entries, a customer payment matched against the invoice it settles. They are legitimately empty on unmatched lines. An export that never fills them for a business that does reconcile is discarding information an inspector expects to be able to follow.
The DGFiP publishes a free validator, Test Compta Demat. It checks structure, column names, formats and the overall debit and credit balance, and it takes minutes.
Run it on a real export before an inspection makes it urgent. A file that fails during an inspection is a procedural problem on top of whatever the inspection was about.
Two things Softbooq’s export does not do yet. It writes EcritureLet and DateLet empty on every line, so lettrage you do in Softbooq does not appear in the file. And it writes Montantdevise and Idevise empty, so the original amount of a foreign-currency line is not in the file. Both are worth knowing before an inspection.
Common questions
When exactly do I have to produce a FEC?
On a tax inspection. Under Article L47 A-I of the Livre des procédures fiscales, a business keeping computerised accounts in France hands over its general ledger as a FEC when the inspection begins. It is not filed periodically, which is why it is easy to discover the export is wrong at the worst moment.
Is one row per entry or per line?
Per line. A journal entry with three lines becomes three rows sharing the same EcritureNum. Exports adapted from formats that store bookings as account pairs get this wrong and produce a file that balances without describing the ledger.
What should the file be called?
The DGFiP convention is {SIREN}FEC{closing date as YYYYMMDD}.txt, for example 123456789FEC20261231.txt. The SIREN identifies the file rather than appearing as a column inside it.
Does Softbooq use the French chart of accounts?
Yes. PCG is one of five statutory charts included, alongside SKR03 and SKR04 for Germany, PGC for Spain and SYSCOHADA. CompteNum carries the PCG account number and CompteLib its label, as two separate columns.
Softbooq exports this file directly from posted journal entries, with the encoding, the sign convention, the date format and both decomposition shapes handled explicitly. The behaviour is covered by automated tests that run before every release.
See the Finance module