France FEC: Fichier des Écritures Comptables Compliance Guide

The Fichier des Écritures Comptables (FEC) is France's mandatory standardized tax audit data file. Required since January 1, 2014 under Article L47 A-1 of the Livre des procédures fiscales, the FEC compels every French company that maintains computerized accounting records to produce a structured export of all accounting journal entries for a closed fiscal year. When the Direction Générale des Finances Publiques (DGFiP) initiates a tax audit, the business has 15 days from the date of notification to deliver this file.

The format is precise: a tab-delimited or pipe-delimited text file containing exactly 18 mandatory fields that map every journal entry in the company's general ledger. Account codes, posting dates, journal references, debit and credit amounts, document numbers, and settlement dates are all specified down to the field name, data type, and maximum length. There is no room for interpretation or proprietary formatting.

Within the broader European context, the FEC serves a similar purpose to the Standard Audit File for Tax (SAF-T) adopted by countries like Norway, Portugal, and Luxembourg, or the Netherlands' Auditfile Financieel (XAF). The difference is that France defined its own format through the DGFiP rather than adopting the OECD's SAF-T schema directly. The result is a France-specific structure that reflects the country's own accounting framework, the Plan Comptable Général.

One distinction catches many multinational organizations off guard: unlike SAF-T filings in countries such as Portugal, where businesses submit audit files periodically to tax authorities, the FEC is not filed on a recurring schedule. Instead, companies must maintain the capability to generate it on demand. The obligation is readiness. If a tax inspector arrives and the accounting system cannot produce a compliant FEC within the 15-day window, the company faces penalties regardless of whether the underlying accounting data is accurate.

This guide covers every aspect of FEC compliance: the 18 mandatory fields, file format and naming conventions, how the Plan Comptable Général shapes the data structure, validation using the DGFiP's own Test Compta Demat tool, the penalty regime for non-compliance, and how the FEC intersects with France's 2026 electronic invoicing mandate.

Legal Framework and Who Must Comply

The FEC obligation traces its legal authority to Article L47 A-1 of the Livre des procédures fiscales (Code of Tax Procedures), which requires any taxpayer maintaining computerized accounting records to provide those records in a standardized digital format when requested by the tax administration. The Direction Générale des Finances Publiques (DGFiP) further defines the technical specification the file must conform to, including field definitions, accepted encodings, and delimiter rules.

The scope of this requirement is broad. Every entity established in France that uses accounting software to maintain its books falls within the FEC mandate. This includes:

Large enterprises and mid-caps subject to statutory audit
Small and medium-sized businesses (PMEs) using any form of computerized bookkeeping
Sole traders and auto-entrepreneurs who record transactions through accounting software rather than by hand

The determining factor is not company size, revenue threshold, or legal form. It is whether accounting records are maintained electronically. In practice, this captures nearly every business operating in France today. The only entities exempt are those keeping purely paper-based, manual accounts, a scenario that has become exceedingly rare.

A critical distinction for compliance professionals: the FEC is not a file businesses submit routinely or on a fixed schedule. It is produced only upon request during a contrôle fiscal (tax audit). When the DGFiP initiates an audit, the business receives a formal notification called an avis de vérification de comptabilité. From the date of receipt, the entity has 15 days to deliver the FEC file to the auditor. Missing this deadline or delivering a non-conformant file exposes the business to penalties.

The FEC must contain a complete, unaltered export of every accounting journal entry for the closed fiscal year or years under examination. Selective exports, filtered datasets, or summaries do not satisfy the requirement. The file represents the full digital ledger as recorded in the accounting system, preserving every posting exactly as it was entered. This obligation parallels structured audit data requirements emerging across Europe, such as Germany's Betriebsprüfung tax audit preparation requirements, where tax authorities similarly demand machine-readable access to accounting records during audit proceedings.

For multinational organizations, the FEC requirement applies to each French-established entity independently. A foreign parent company with a French subsidiary must ensure that subsidiary can produce a conformant FEC from its local accounting system, regardless of whether group-level consolidation happens in a different jurisdiction or on a different platform.

The 18 Mandatory FEC Fields

The FEC file structure is fixed. Every record must contain exactly 18 fields, presented in the exact sequence defined by the tax administration. Deviating from this order is one of the most common reasons FEC files fail validation, even when the underlying data is correct. The field names themselves are prescribed and must appear as the header row of the file exactly as specified below.

Here is the complete field-by-field reference for the 18 mandatory FEC fields.

1. JournalCode — Journal code

Identifies the accounting journal to which the entry belongs: purchases (HA), sales (VE), bank (BQ), general operations (OD), and so on. The codes are not standardized across all companies, but they must be consistent throughout the file and must match the journal structure in your accounting system.

2. JournalLib — Journal label

The human-readable name of the journal referenced by JournalCode. For example, where JournalCode is "BQ," JournalLib might read "Banque Société Générale." This field exists so auditors can interpret journal codes without needing access to your chart of journals.

3. EcritureNum — Entry number

A sequential identifier for the journal entry. Each entry number must be unique within a given journal, and the numbering sequence must be continuous with no gaps. Gaps in entry numbering will raise questions during a tax audit, as they may suggest deleted transactions.

4. EcritureDate — Entry date

The date the transaction was recorded in the accounting system, formatted as YYYYMMDD. Not the date of the underlying commercial transaction (that is captured separately in PieceDate). EcritureDate must fall within the fiscal year covered by the FEC file.

5. CompteNum — Account number

The general ledger account number for the entry. This must follow the Plan Comptable Général numbering system. Class 1 through 5 accounts cover balance sheet items, classes 6 and 7 cover expenses and revenues, and class 0 is reserved for off-balance-sheet items. The relationship between CompteNum and the PCG structure is covered in detail in the Plan Comptable Général section of this guide.

6. CompteLib — Account label

The descriptive name associated with the account number in CompteNum. For account 401000, this might read "Fournisseurs" (Suppliers). The label must correspond accurately to the account number; mismatches between CompteNum and CompteLib are flagged during validation.

7. CompAuxNum — Auxiliary account number

Used for sub-ledger accounts that provide detail beneath a general ledger control account. This is where individual customer accounts (under the 411 control account) and individual supplier accounts (under the 401 control account) appear. CompAuxNum links your accounts payable and accounts receivable sub-ledgers directly to the FEC. This field may be left blank for general ledger entries that have no sub-ledger detail.

8. CompAuxLib — Auxiliary account label

The name associated with the auxiliary account number. When CompAuxNum contains a supplier code, CompAuxLib would contain the supplier's name. This field must be blank whenever CompAuxNum is blank.

9. PieceRef — Supporting document reference

The reference number of the source document that justifies the accounting entry. This is typically the invoice number, receipt number, credit note number, or bank statement reference. PieceRef is the primary link between the FEC and your supporting documentation. Because tax auditors use this field to trace entries back to source documents, the integrity of your invoice numbering directly affects FEC accuracy. If your invoice references contain errors or inconsistencies, those problems propagate into the FEC. Beyond numbering, the invoices themselves must satisfy France's mandatory invoice fields known as mentions obligatoires, and any reference identifiers on those documents should align with what appears in PieceRef.

10. PieceDate — Supporting document date

The date that appears on the source document itself. For a purchase invoice, this is the date printed on the invoice by the supplier. PieceDate often differs from EcritureDate, since invoices may be recorded days or weeks after they are issued. Both dates are required precisely so auditors can identify recording delays.

11. EcritureLib — Entry description

A free-text description of the transaction. While there is no mandated format, the description should be specific enough that an auditor can understand the nature of the transaction without referring to the source document. Vague descriptions like "Opération diverse" across hundreds of entries will draw scrutiny.

12. Debit — Debit amount

The debit amount for this line of the journal entry, expressed as a decimal number. If the line is a credit entry, this field must contain zero. Debit and Credit are mutually exclusive per line: both fields cannot contain non-zero values on the same record.

13. Credit — Credit amount

The credit amount for this line of the journal entry, following the same rules as the Debit field. When Debit contains a non-zero value, Credit must be zero, and vice versa. Each journal entry as a whole must balance, meaning the sum of all Debit amounts for a given EcritureNum must equal the sum of all Credit amounts.

14. EcritureLet — Lettrage code (reconciliation code)

A matching code that links related debit and credit entries together. Lettrage is the French accounting practice of reconciling corresponding entries, such as matching a supplier invoice to its payment. Entries sharing the same EcritureLet value are understood to be reconciled. This field may be blank for entries that have not yet been matched.

15. DateLet — Lettrage date (reconciliation date)

The date on which the reconciliation identified by EcritureLet was performed. This field must be blank whenever EcritureLet is blank. If EcritureLet contains a value, DateLet must also contain a value. The format is YYYYMMDD, consistent with all other date fields in the FEC.

16. ValidDate — Validation date

The date on which the journal entry was validated or definitively posted in the accounting system. ValidDate must not be earlier than EcritureDate. Under French accounting rules, once an entry is validated it becomes permanent and cannot be modified, only corrected with a new entry. This field provides auditors with evidence that the principle of irreversibility has been respected.

17. Montantdevise — Foreign currency amount

The transaction amount expressed in its original foreign currency. This field is relevant only for transactions denominated in a currency other than EUR. For euro-denominated transactions, this field should be left blank or set to zero. When populated, the value here represents the amount before currency conversion, while the Debit or Credit field contains the EUR equivalent.

18. Idevise — Currency code

The ISO 4217 currency code for the foreign currency amount in Montantdevise. Examples include USD, GBP, or CHF. This field must be blank for euro-denominated transactions. When Montantdevise contains a value, Idevise must contain the corresponding currency code.

Field ordering is not optional. The 18 fields must appear in precisely this sequence, from JournalCode through Idevise, both in the header row and in every data row. A technically correct file with fields in the wrong order will fail validation outright.

File Format, Naming Convention, and Encoding

The FEC is a plain text file with a .txt extension. No XML, no CSV, no proprietary format. The DGFiP accepts two field delimiters: the tab character (\t) or the pipe character (|). Both pass validation, and the choice typically depends on what your accounting system supports natively. Pick one and use it consistently throughout the file.

Character encoding must be UTF-8. This matters more than it might seem. French accounting entries routinely contain accented characters in journal labels, account names, and entry descriptions. A file encoded in Latin-1 or Windows-1252 that happens to contain an écriture label with accents will fail validation or produce garbled output during the audit.

The first row of the file is a mandatory header containing the 18 field names in their exact specification form: JournalCode, JournalLib, EcritureNum, EcritureDate, and so on through the complete list. These names are not flexible. They must appear verbatim, in the prescribed order, with the prescribed casing. The header row uses the same delimiter as the data rows.

Naming Convention

The filename follows a rigid structure:

{SIREN}FEC{YYYYMMDD}.txt

Three components, no separators between them:

SIREN is the company's 9-digit SIREN identification number, issued by INSEE. Not the SIRET (which adds a 5-digit NIC suffix), not the VAT number. The 9-digit SIREN only.
FEC appears as a literal string, uppercase.
YYYYMMDD is the closing date of the fiscal year the file covers.

A company with SIREN 123456789 closing its fiscal year on December 31, 2025, names the file:

123456789FEC20251231.txt

A company operating on a non-calendar fiscal year ending June 30, 2025, would produce:

123456789FEC20250630.txt

Decimal Separators

The Debit, Credit, and Montantdevise fields contain numeric values that may include decimals. The DGFiP accepts either a period (.) or a comma (,) as the decimal separator, but the choice must be consistent across the entire file. Mixing formats within a single FEC is a validation error. If your ERP defaults to periods for monetary amounts, keep periods everywhere. If it uses commas, keep commas everywhere.

One File per Fiscal Year

Each FEC file covers exactly one complete fiscal year. When a tax audit spans multiple fiscal years, you produce a separate FEC file for each year, each with its own filename reflecting the relevant closing date. A three-year audit of fiscal years 2023 through 2025 requires three distinct files, not one concatenated export.

How the Plan Comptable Général Shapes Your FEC

The Plan Comptable Général (PCG) is France's mandatory standardized chart of accounts. Unlike Anglo-Saxon frameworks where companies have significant freedom to design their own account numbering, the PCG prescribes a rigid hierarchical structure that every French entity must follow. This distinction matters directly for FEC compliance because the CompteNum field (field 5 in the FEC) must contain account numbers that conform to the PCG's numbering scheme. If they do not, validation fails.

The PCG organizes all accounts into seven classes, each identified by its leading digit:

Class 1 — Comptes de capitaux. Equity, reserves, and long-term liabilities. Accounts beginning with 1 capture share capital, retained earnings, provisions, and long-term borrowings.
Class 2 — Comptes d'immobilisations. Fixed assets, both tangible and intangible, along with their accumulated depreciation and amortization.
Class 3 — Comptes de stocks. Inventories, work in progress, and goods held for resale.
Class 4 — Comptes de tiers. Third-party accounts covering receivables and payables. This is where supplier balances (accounts starting with 401) and customer balances (accounts starting with 411) reside.
Class 5 — Comptes financiers. Cash, bank accounts, and short-term financial instruments.
Class 6 — Comptes de charges. All expense accounts. Purchased goods fall under 607, external services under 61 and 62, personnel costs under 64, and so on.
Class 7 — Comptes de produits. Revenue accounts, including sales of goods (701), sales of services (706), and other operating income.

Within each class, sub-accounts follow standardized numbering conventions that carry specific meaning. Account 401000 is a generic supplier account, while 401001 might designate a specific vendor. Account 411000 represents a generic customer receivable. Account 607100 refers to purchases of raw materials. The first three digits typically identify the account category, and businesses extend the numbering to suit their level of detail, provided they preserve the PCG root structure.

This rigid hierarchy is precisely what creates problems for multinational companies. An organization running SAP, Oracle, or another global ERP will typically maintain an internal chart of accounts designed around IFRS or US GAAP conventions. When that company has a French subsidiary or permanent establishment, it must map its internal account numbers to PCG-compliant codes for the FEC. A U.S. parent company using account 5000 for cost of goods sold, for instance, needs to ensure that entry maps to a Class 6 account (likely 607xxx) in the French FEC output. Getting this mapping wrong is one of the most common causes of FEC validation failure, and the errors are not always obvious until the tax authority runs its analysis tools against the file.

The PCG is maintained and periodically updated by the Autorité des Normes Comptables (ANC), France's accounting standards authority. Amendments can introduce new sub-accounts, reclassify existing ones, or adjust numbering conventions. Businesses and their ERP teams must verify that their account mapping reflects the current version of the PCG, not a historical snapshot embedded in a configuration file years ago. A mapping built for the 2020 PCG may produce invalid CompteNum values under subsequent revisions.

Validating Your FEC with Test Compta Demat

The DGFiP provides a free validation tool called Test Compta Demat that checks FEC files for structural compliance before they reach a tax auditor's hands. Available as a downloadable application from the DGFiP's website (impots.gouv.fr), the tool evaluates field count, field ordering, delimiter consistency, naming conventions, character encoding, and date formatting.

Waiting until a vérificateur sends an avis de vérification is the wrong time to discover your accounting system produces a malformed FEC. Businesses should proactively run Test Compta Demat against a current-year export on a periodic basis. This confirms that the FEC generation module in your ERP or accounting software is configured correctly and that no upstream data quality issues have crept in since the last check.

Common Validation Errors

Test Compta Demat flags a predictable set of structural problems. The most frequent include:

Incorrect field count per row. Every data row must contain exactly 18 fields. Extra delimiters, missing fields, or unescaped characters within text values can throw the count off.
Field ordering mismatch. The 18 fields must appear in the exact sequence defined by the specification. Swapping CompteNum and CompteLib, for instance, will fail validation even if both values are individually correct.
Invalid date formats. All date fields must follow the YYYYMMDD format with no separators. Values like 2025-01-15 or 15/01/2025 are rejected.
Non-numeric values in Debit or Credit fields. These two columns accept only numeric data. Currency symbols, thousand separators, or text placeholders cause immediate failures.
Missing or malformed header row. The first row of the file must contain the official field names exactly as specified. Translated headers, missing columns, or altered casing can trigger errors.
File naming violations. The filename must follow the {SIREN}FEC{YYYYMMDD}.txt convention, where the date corresponds to the closing date of the fiscal year. A misplaced character or wrong date renders the file non-compliant before the contents are even evaluated.
Encoding issues. Characters outside the declared encoding (typically UTF-8 for pipe-delimited files) produce failures. Accented characters in journal labels or account descriptions are common culprits when a system defaults to a legacy encoding like ISO 8859-1.

What Test Compta Demat Does Not Check

Structural validation is necessary but not sufficient. The tool confirms that your file is well-formed, not that its contents are accurate. It will not verify whether total debits equal total credits across the file, whether account numbers correspond to valid PCG classifications, or whether journal entry sequences are complete and unbroken.

These accounting accuracy checks remain your responsibility. Reconcile the FEC totals against your general ledger trial balance. Verify that every account number maps to a legitimate PCG category. Confirm that the EcritureNum sequence contains no gaps that could raise auditor questions about deleted entries.

Recommended Practice

Generate and validate a test FEC export at least once per year, even when no audit is pending. An annual dry run catches configuration drift early. Software updates, chart of accounts modifications, or changes in journal entry workflows can silently alter FEC output in ways that only surface during validation. Discovering a structural defect during routine testing costs nothing. Discovering it during a tax audit costs time, credibility, and potentially EUR 5,000 or more per fiscal year in penalties. Assign clear ownership of FEC readiness to a specific team member or function. When an avis de vérification arrives, the 15-day clock is non-negotiable, and having a validated test export already on file means the response is mechanical rather than a scramble.

Penalties for Non-Compliance

Failing to produce a valid FEC when requested during a tax audit triggers a fixed penalty of EUR 5,000 per fiscal year under examination, or 10% of the reassessed tax amount, whichever is higher. The "whichever is higher" rule is critical to understand: for routine audits with minor adjustments, the flat EUR 5,000 may apply. But when the DGFiP identifies significant underreporting or misstatements, 10% of the reassessment can dwarf the fixed amount. A EUR 500,000 tax adjustment, for example, would carry a EUR 50,000 penalty on top of the taxes owed.

The penalty applies per fiscal year. When auditors examine three or four years simultaneously, which is standard practice, each year that lacks a valid FEC incurs its own penalty. Three years without a compliant file means three separate charges at minimum.

Format matters as much as availability. An FEC that contains structural errors, missing mandatory fields, incorrect encoding, or a non-compliant naming convention is treated identically to no file at all. The DGFiP does not distinguish between refusal and inability. Submitting a file that fails validation in Test Compta Demat exposes you to the same penalty as never producing the file in the first place.

Beyond the financial penalty, failure or refusal to provide the FEC can constitute opposition à contrôle fiscal, the formal charge of obstructing a tax audit. This triggers a separate penalty track with its own consequences, including the possibility of taxation d'office, where the administration estimates your tax liability unilaterally. The burden of proof then shifts entirely to the taxpayer, a procedurally difficult position.

The enforcement environment makes these risks concrete rather than theoretical. According to DGFiP's 2024 activity report, France's Direction Générale des Finances Publiques notified a record 16.7 billion euros in rights and penalties from tax audits in 2024, a 1 billion euro increase over 2023, with artificial intelligence deployed in 56% of professional audits. The DGFiP is investing heavily in detection capabilities, and FEC analysis is a primary tool in that arsenal. Auditors routinely run automated consistency checks against submitted FEC files before a single human reviewer examines the data.

For companies operating in France, the arithmetic is straightforward: annual FEC validation costs a few hours of staff time. A three-year audit without compliant files costs EUR 15,000 minimum in fixed penalties alone, and potentially multiples of that if tax adjustments trigger the 10% rule.

The FEC and France's 2026 E-Invoicing Mandate

A common misconception among compliance teams planning for France's e-invoicing rollout is that the new mandate will eventually absorb or replace the FEC obligation. It will not. The FEC and mandatory e-invoicing are separate compliance requirements with distinct legal foundations, different technical formats, and fundamentally different purposes. Understanding how they coexist is essential for any business operating in France.

The FEC obligation, rooted in the Livre des Procédures Fiscales, governs how accounting entries are exported for tax audit. The e-invoicing mandate, governed by the Loi de Finances framework and its implementing decrees, governs how invoices are issued, transmitted, and received between businesses. One structures the audit output. The other structures the transactional input. Neither substitutes for the other.

Under France's 2026 e-invoicing mandate and its compliance timeline, all VAT-registered businesses will progressively be required to issue and receive invoices in structured electronic formats such as Factur-X, UBL, or CII. These invoices will flow through approved Partner Dematerialization Platforms (PDPs) or the public portal. Businesses already using France's Chorus Pro e-invoicing portal for public-sector invoicing have some familiarity with this infrastructure, but the mandate extends to all B2B transactions on a phased timeline beginning September 2026.

The accounting system sits squarely between these two obligations. E-invoicing determines how invoice data enters the system. The FEC determines how accounting entries leave it for audit. The data must remain consistent and traceable across both boundaries.

This creates specific integration concerns. Structured data arriving from Factur-X invoices, for example, carries fields that must map cleanly to the FEC's 18-field structure. The invoice reference embedded in Factur-X metadata needs to populate PieceRef accurately. The invoice date must flow through to PieceDate without transformation errors. If the accounting software ingests e-invoice data but truncates, reformats, or misaligns these values during posting, the resulting FEC export will contain discrepancies that surface during validation or audit.

Businesses should verify their accounting software handles this mapping correctly by running test FEC exports against transactions that originate from e-invoicing workflows. Specific points to check:

PieceRef alignment. Does the FEC reference field match the invoice identifier from the e-invoicing platform, or has the system appended internal prefixes or altered the format?
PieceDate accuracy. Does the FEC reflect the original invoice date from the structured e-invoice, or the date the accounting system recorded the entry?
Journal assignment. Verify that e-invoice transactions post to the correct journals and that those journals appear with consistent codes in the FEC export.

The phased rollout gives businesses time to address these issues, but only if FEC readiness is treated as a parallel workstream rather than an afterthought. Teams focused exclusively on e-invoicing platform selection, format compliance, and PDP connectivity risk neglecting the downstream impact on their FEC exports. Both obligations will be enforced independently, and passing e-invoicing validation does not guarantee a clean FEC.

For organizations managing both transitions simultaneously, the practical approach is to test end to end: issue or receive a structured e-invoice, let it flow through the accounting system, generate a FEC export, and validate the output with Test Compta Demat. Any breakage in that chain needs to be resolved before either deadline arrives.