Le Fichier des Ecritures Comptables (FEC) est l’une des obligations légales les plus mal maîtrisées des DSI et DAF français. Depuis 2014, toute entreprise qui tient sa comptabilité sous forme informatisée doit être capable de produire un FEC dès le premier jour d’une vérification de comptabilité DGFiP. Si votre ERP ne génère pas un fichier conforme aux 18 champs définis par l’arrêté du 29 juillet 2013, vous vous exposez à une amende de 5 000 euros prévue à l’article 1729 D du Code général des impôts, voire au rejet de votre comptabilité et à une reconstitution d’office par l’administration.
Ce guide détaille ce qu’est le FEC, les cinq erreurs de configuration ERP qui le rendent irrecevable, et les procédures d’export pour les principaux éditeurs du marché.
Qu’est-ce que le FEC et pourquoi votre ERP en est responsable
L’obligation légale depuis 2014
Le FEC est défini par l’article A. 47 A-1 du Livre des procédures fiscales (LPF), issu de l’arrêté du 29 juillet 2013. Il s’applique à toute entreprise qui tient sa comptabilité sous forme informatisée : soit la quasi-totalité des PME et ETI françaises depuis plus d’une décennie.
En pratique, lors d’une vérification de comptabilité (article L. 13 du LPF) ou d’un examen de comptabilité à distance (article L. 47 AA du LPF), le vérificateur peut exiger la remise du FEC dès le premier jour du contrôle. Ce fichier représente l’intégralité des écritures comptables de l’exercice vérifié, exporté depuis votre ERP dans un format normalisé.
Deux sanctions sont prévues par l’article 1729 D du CGI (Légifrance, art. 1729 D CGI) :
- Une amende de 5 000 euros par exercice si le FEC n’est pas présenté ou s’il n’est pas conforme aux exigences réglementaires.
- En cas de redressement, un supplément de 10 % des droits rappelés si ce montant dépasse les 5 000 euros.
Le Conseil d’Etat a validé la constitutionnalité de cette amende dans une décision de janvier 2026 (legifiscal.fr). La note BOFIP de janvier 2026 précise par ailleurs que la pénalité s’applique une seule fois par contrôle, quel que soit le nombre d’exercices vérifiés.
Les 18 champs obligatoires du FEC
Le FEC est un fichier texte délimité par des tabulations ou des pipes (|), encodé en UTF-8 ou ISO-8859-15. Il contient obligatoirement 18 colonnes par ligne d’écriture, dans l’ordre exact défini en annexe de l’article A. 47 A-1 du LPF. La documentation de référence est la fiche BOFIP BOI-CF-IOR-60-40-20.
| N° | Champ | Description |
|---|---|---|
| 1 | JournalCode | Code journal (ex. VT pour ventes, AC pour achats) |
| 2 | JournalLib | Libellé du journal |
| 3 | EcritureNum | Numéro séquentiel et continu de l’écriture |
| 4 | EcritureDate | Date de l’écriture au format AAAAMMJJ |
| 5 | CompteNum | Numéro de compte PCG à huit chiffres minimum |
| 6 | CompteLib | Libellé du compte |
| 7 | CompAuxNum | Numéro de compte auxiliaire (code tiers) |
| 8 | CompAuxLib | Libellé du compte auxiliaire |
| 9 | PieceRef | Référence de la pièce comptable |
| 10 | PieceDate | Date de la pièce au format AAAAMMJJ |
| 11 | EcritureLib | Libellé de l’écriture |
| 12 | Debit | Montant débit au format 0.00 (point décimal obligatoire) |
| 13 | Credit | Montant crédit au format 0.00 |
| 14 | EcritureLet | Code de lettrage de l’écriture |
| 15 | DateLet | Date du lettrage au format AAAAMMJJ |
| 16 | ValidDate | Date de validation comptable au format AAAAMMJJ |
| 17 | Montantdevise | Montant en devise d’origine (vide si euro) |
| 18 | Idevise | Code devise ISO 4217 (ex. USD, GBP) |
Un champ vide n’est autorisé que si la règle spécifique du champ le permet (CompAuxNum vide pour un compte non-tiers, Montantdevise vide pour une écriture en euros).
Qui vérifie quoi lors d’un contrôle fiscal ?
Le vérificateur n’analyse pas votre FEC manuellement. Il utilise des outils automatisés développés par la DGFiP, dont le logiciel Test Compta Demat. Les contrôles de premier niveau portent sur :
- La présence des 18 colonnes dans le bon ordre.
- La séquentialité des numéros EcritureNum sans trou ni doublon dans chaque journal.
- L’équilibre débit/crédit sur l’ensemble de l’exercice et journal par journal.
- La cohérence des dates (EcritureDate antérieure ou égale à ValidDate).
- L’absence de caractères interdits dans les champs texte (retours à la ligne, guillemets non échappés).
Les contrôles approfondis croisent ensuite les données FEC avec les déclarations de TVA, les liasses fiscales déposées et les flux bancaires.
Les 5 erreurs de configuration ERP qui rendent votre FEC irrecevable
Erreur 1 : numérotation non séquentielle des écritures
Le champ EcritureNum doit être une séquence continue sans saut de numéro, journal par journal. Deux problèmes fréquents : la suppression logique d’écritures dans l’ERP (qui laisse des trous dans la séquence) et la numérotation qui repart à zéro lors d’un changement d’exercice ou d’une migration.
Correctif : activer le verrouillage séquentiel des écritures dans votre ERP et interdire toute suppression après validation. En cas de migration, exiger une table de correspondance entre les anciens et nouveaux numéros.
Erreur 2 : comptes auxiliaires non renseignés
Les champs CompAuxNum et CompAuxLib sont obligatoires pour toutes les écritures de comptes de tiers (classe 4 du PCG : fournisseurs, clients). Beaucoup d’ERP les laissent vides lorsque la codification des tiers n’est pas synchronisée avec le plan comptable général.
Correctif : configurer la correspondance entre le référentiel tiers (CRM, fichier fournisseurs) et le plan comptable de l’ERP. Vérifier que chaque compte 401 et 411 est systématiquement associé à un code auxiliaire non vide.
Erreur 3 : incohérence entre EcritureDate et ValidDate
La ValidDate représente la date à laquelle l’écriture a été irrévocablement validée dans la comptabilité. Si votre ERP permet de modifier des écritures après leur validation, ou si la ValidDate est automatiquement fixée à la date de saisie sans blocage des exercices clos, la DGFiP peut conclure à une comptabilité non probante.
Correctif : verrouiller les exercices clôturés dans l’ERP. Aucune écriture appartenant à un exercice N ne doit être modifiable après la date de clôture validée par le responsable comptable.
Erreur 4 : écritures d’extourne mal tracées
Les extournes doivent être rattachées à l’écriture d’origine via le champ EcritureLet. Un ERP qui génère des contre-passations par saisie manuelle sans lien de lettrage produit un FEC où des mouvements restent inexpliqués.
Correctif : utiliser uniquement la fonction d’extourne native de l’ERP, qui assure automatiquement le lien de lettrage vers l’écriture d’origine.
Erreur 5 : écritures en devises sans conversion correcte
Pour toute écriture impliquant une devise étrangère, Montantdevise (colonne 17) et Idevise (colonne 18) doivent être renseignés avec le montant en devise d’origine et le code ISO 4217 correspondant. Un champ vide ou un code devise non normalisé suffit à rendre irrecevables toutes les lignes concernées.
Correctif : activer la gestion multidevise dans votre ERP et vérifier que le module de conversion de devises alimente systématiquement ces deux champs pour toute opération hors zone euro.
Comment extraire un FEC conforme depuis les principaux ERP du marché
SAP S/4HANA et SAP ECC
SAP utilise l’outil DART (Data Retention Tool) pour générer le FEC. La version recommandée est DART 2.7, compatible avec S/4HANA et l’ancienne plateforme ECC (SAP Community). Le FEC est configuré via une vue de sélection dédiée “France FEC”.
Point de vigilance lors d’une migration vers S/4HANA : tester impérativement la génération du FEC sur les données historiques reprises, car les règles de numérotation peuvent avoir évolué lors de la migration. La documentation de configuration est disponible sur le SAP Help Portal.
Sage 100 Comptabilité et Sage X3
Le FEC est natif dans Sage 100 Comptabilité. Procédure : menu Traitements > Vérification comptable DGFiP > Export FEC (Sage Knowledge Base). Sélectionner l’exercice clos, choisir le répertoire de sortie, lancer l’export. Le fichier produit porte le nom normalisé SirenFECAAAAMMJJ.txt.
Pour Sage X3 (Sage Enterprise Management), le module France inclut un export FEC natif accessible depuis les fonctions de clôture comptable. Vérifier que la version installée est conforme aux dernières mises à jour réglementaires DGFiP.
Dynamics 365 Finance
Microsoft Dynamics 365 Finance dispose d’une localisation France avec export FEC natif via le module de rapports électroniques (Electronic Reporting), documenté sur Microsoft Learn.
Note importante : cette documentation concerne Dynamics 365 Finance (ERP pour ETI et grandes entreprises). Pour Dynamics 365 Business Central, la disponibilité d’un export FEC natif dépend de la version et des modules installés : confirmer avec votre partenaire Microsoft avant un déploiement en France.
Cegid XRP Flex
Cegid XRP Flex intègre nativement les obligations réglementaires françaises, dont le FEC. L’export est accessible depuis les fonctions de clôture comptable et Cegid maintient la conformité via ses mises à jour réglementaires continues. Lors d’une migration vers XRP Flex depuis une version antérieure, vérifier que l’historique comptable repris est entièrement accessible à la fonction d’export FEC.
Odoo 18
Odoo intègre l’export FEC dans sa localisation France standard via le module l10n_fr_fec. Procédure : Comptabilité > Reporting > FEC (documentation Odoo 18). Sélectionner l’exercice fiscal et télécharger le fichier. L’OCA (Odoo Community Association) propose également un module alternatif l10n_fr_fec_oca pour les déploiements sur Odoo Community Edition.
EBP Compta
EBP Compta intègre un export FEC DGFiP natif depuis les versions conformes à la loi de 2013. La génération se fait depuis les fonctions de clôture d’exercice. EBP étant fréquemment utilisé par les TPE et PME qui s’appuient sur un expert-comptable, vérifier que la version installée intègre les dernières mises à jour réglementaires.
Checklist de validation FEC avant tout contrôle (12 points)
Avant de remettre un FEC à l’administration ou de clôturer un exercice comptable, vérifier systématiquement ces 12 points :
- Séquentialité sans trou : EcritureNum est une suite continue par journal, sans saut de numéro.
- Pas de doublon : aucun numéro EcritureNum n’apparaît deux fois dans le même journal.
- Equilibre débit/crédit : la somme des Debits est égale à la somme des Credits sur l’ensemble de l’exercice et journal par journal.
- CompAuxNum renseigné : tous les comptes de tiers (classe 4) ont un code auxiliaire non vide.
- Dates cohérentes : EcritureDate est antérieure ou égale à ValidDate pour chaque ligne.
- Format date correct : toutes les dates sont au format AAAAMMJJ (huit chiffres, sans séparateur).
- Absence de caractères spéciaux : aucun retour à la ligne, guillemet ou pipe non échappé dans les champs texte.
- Séparateur uniforme : le fichier utilise exclusivement la tabulation ou exclusivement le pipe, sans mélange.
- Encodage cohérent : le fichier est intégralement en UTF-8 ou intégralement en ISO-8859-15, sans mélange d’encodages.
- Nom de fichier normalisé : SirenFECAAAAMMJJ.txt (neuf chiffres SIREN, “FEC”, date de clôture de l’exercice).
- Soldes d’ouverture présents : les écritures de report à nouveau (journal AN) figurent en tête de fichier.
- Montantdevise et Idevise renseignés : pour toute écriture en devise étrangère, ces deux champs sont non vides et conformes ISO 4217.
Outil de vérification recommandé
La DGFiP met à disposition l’outil Test Compta Demat, téléchargeable gratuitement sur impots.gouv.fr. Cet outil reproduit les contrôles de cohérence que le vérificateur applique en début de mission. Il est recommandé de l’utiliser dès la clôture de chaque exercice, sans attendre un avis de contrôle.
Que faire si votre ERP ne génère pas de FEC natif ?
Extraction manuelle et ETL
Certains ERP non localisés pour la France (solutions d’origine nord-américaine ou asiatique, anciens systèmes maison) ne produisent pas de FEC nativement. La seule voie légale est alors de construire une extraction ETL qui reconstitue les 18 champs depuis les tables comptables de l’ERP.
Cette approche présente deux risques majeurs. D’abord, la reconstitution a posteriori est difficile à justifier devant un vérificateur : comment prouver que les données extraites correspondent exactement aux écritures enregistrées au moment des faits ? Ensuite, l’absence de séquentialité native force à reconstruire le champ EcritureNum, ce qui constitue un point de fragilité documentaire.
Risques légaux et recommandations
Un ERP incapable de générer un FEC conforme expose l’entreprise à l’amende de 5 000 euros de l’article 1729 D du CGI, même si la comptabilité sous-jacente est irréprochable. Ce point doit être traité avant toute migration ou tout changement d’ERP : exiger contractuellement que le nouvel ERP génère un FEC natif conforme, le tester sur un exercice complet avant le go-live, et ne jamais reporter cette vérification à la survenue d’un contrôle réel.
FEC et piste d’audit fiable : quelle différence ?
Le FEC et la piste d’audit fiable (PAF) sont deux obligations complémentaires, souvent confondues.
Le FEC est un fichier comptable : il couvre les écritures validées dans la comptabilité générale d’un exercice clos. La PAF est une obligation de traçabilité documentaire, imposée par l’article 289 VII du CGI : elle consiste à pouvoir relier une facture au paiement correspondant, du premier au dernier maillon, avec conservation des pièces justificatives. Elle s’applique à la chaîne procure-to-pay et order-to-cash de l’ERP, pas seulement à la comptabilité générale.
En pratique, un ERP qui génère un FEC conforme ne satisfait pas nécessairement à la PAF, et inversement. Ce sont deux couches de conformité fiscale distinctes qui doivent être vérifiées séparément.
Pour approfondir la conformité fiscale et documentaire de votre ERP, consultez notre guide sur l’archivage des données ERP et les durées légales de conservation et notre article sur les contrôles SoD ERP avant l’audit annuel.
Pour valider la conformité FEC de votre ERP actuel, l’approche la plus efficace est un audit ciblé de quatre à huit semaines : extraction d’un FEC sur l’exercice en cours, test via l’outil DGFiP Test Compta Demat, identification des écarts de configuration. Budget typique : 8 à 15 000 euros selon la complexité de l’ERP. Résultat : une liste priorisée de correctifs à apporter avant d’être exposé à un contrôle réel.
