Structure du FEC : les 18 champs obligatoires (et leurs pièges)

Un FEC qui passe TestComptaDemat n'est pas un FEC conforme. Le test détecte le format ; il ne détecte ni les incohérences de dates, ni les libellés génériques, ni les ruptures de séquence — c'est-à-dire précisément ce que regarde le vérificateur en premier. La structure des 18 champs est encadrée par un cadre réglementaire dense (article A. 47 A-1 du LPF, BOI-CF-IOR-60-40-20) qu'un DAF doit lire avec les yeux du contrôleur, pas ceux du paramétreur ERP.

Cet article complète notre guide complet du fichier des écritures comptables en proposant une lecture champ par champ orientée pièges : pour chacun, la règle BOFIP, ce que cherche le vérificateur, et le réflexe à adopter avant qu'un avis de vérification n'arrive.

Le cadre technique du fichier avant les champs

Avant d'aborder les 18 champs, trois points de cadrage technique posent le décor.

Fondement réglementaire. L'obligation de remise du FEC découle du I de l'article L. 47 A du LPF (issu de l'article 14 de la loi n° 2012-1510 du 29 décembre 2012). Les normes techniques sont fixées par l'article A. 47 A-1 du LPF, résultant de l'arrêté du 29 juillet 2013. Le BOFIP de référence — celui qu'il faut connaître par cœur — est BOI-CF-IOR-60-40-20, qui détaille chaque champ paragraphe par paragraphe avec des exemples officiels.

Format du fichier. Le contribuable a le choix entre deux formats (VI de l'art. A. 47 A-1) : un fichier à plat (.txt ou .csv) à organisation séquentielle et structure zonée, ou un fichier structuré au format XML conforme aux XSD publiés sur impots.gouv.fr. En pratique, le format à plat domine très largement. Pour ce format, la première ligne doit obligatoirement comporter le nom des champs ; sans cet en-tête, le fichier est non conforme et tombe sous l'amende de l'article 1729 D du CGI.

Nomenclature. Le fichier est nommé SirenFECAAAAMMJJ, où AAAAMMJJ est la date de clôture de l'exercice (IX de l'art. A. 47 A-1). En cas de volumétrie importante, le découpage en plusieurs fichiers (mensuel, trimestriel) est admis en accord avec le service vérificateur — chaque fichier doit alors reprendre la première ligne d'en-tête (BOI-CF-IOR-60-40-20 §370).

Règle d'or à retenir : la règle dite "à blanc si non utilisé" (BOI-CF-IOR-60-40-20 §70). Pour les 6 champs conditionnels, la colonne reste toujours obligatoire dans le fichier — c'est la valeur qui peut être vide. Remplir par défaut avec "0" ou un espace rend le fichier non conforme. La cellule doit rester strictement vide.

Descriptif d'accompagnement. Toute codification interne (codes journaux, codes devise, valeurs conventionnelles, mode de numérotation) doit être expliquée dans un descriptif joint au FEC (XI de l'art. A. 47 A-1, BOFIP §390). Le format est libre — Word, Excel, PDF, papier — mais l'absence de ce descriptif est un défaut de conformité en soi.

Identification du journal : JournalCode et JournalLib

JournalCode (alphanumérique, obligatoire) reprend le code interne du journal — chiffres, lettres ou combinaison. Aucune norme n'est imposée par l'administration : chaque entreprise utilise sa propre codification. JournalLib (alphanumérique, obligatoire) donne le libellé complet du journal ("Journal des ventes", "Journal des achats hors groupe").

Ce que cherche le vérificateur. D'abord la cohérence entre code et libellé. Surtout, la nature réelle des journaux. Un journal "OPDIV" ou "DIVERS" qui contient en réalité des écritures de TVA, des écritures manuelles correctrices, ou des reclassements significatifs est immédiatement suspect. La liste exhaustive des codes journaux doit figurer dans le descriptif d'accompagnement — son absence est en soi un point d'appel.

Piège fréquent. Les filiales françaises de groupes étrangers reportent parfois les libellés dans la langue du groupe ("Sales Journal", "Purchasing Journal"). Depuis les exercices clos en 2015, ces libellés étrangers ne sont plus admis (BOI-CF-IOR-60-40-20 §350 et article 54, dernier alinéa, du CGI). La traduction française est exigée.

Identification de l'écriture : EcritureNum et EcritureDate

C'est le couple le plus scruté du fichier. Il matérialise la chronologie de la comptabilité — et donc sa sincérité.

EcritureNum (alphanumérique, obligatoire) est le numéro séquentiel de l'écriture en partie double, au sens de l'article 921-1 du PCG. Toutes les lignes d'une même écriture portent le même numéro. La numérotation doit être chronologique croissante, sans rupture ni inversion (BOI-CF-IOR-60-40-20 §100). Deux modes sont admis :

• Mode unique : une séquence continue sur l'ensemble du fichier (1, 2, 3…).
• Mode par journal : une séquence propre à chaque journal (AN0001, AC0001…). Dans ce cas, l'existence de plusieurs écritures portant le même numéro mais des codes journaux différents n'est pas un motif de non-conformité — à condition que la spécificité soit documentée dans le descriptif.

Les premiers numéros doivent correspondre aux écritures d'à-nouveau (reprise des soldes de l'exercice antérieur), sauf exception fonctionnelle à documenter.

EcritureDate (date AAAAMMJJ, obligatoire) est la date de comptabilisation de l'écriture. Le BOFIP §120 est explicite et piégeux : ce n'est pas systématiquement la date de saisie dans l'ERP. C'est la date de l'événement comptable lui-même (date de la facture, date du règlement, etc.). Si un décalage existe entre événement et saisie, c'est la date de l'événement qui doit être retenue. Si le logiciel ne dispose pas d'un mode brouillard, EcritureDate = ValidDate.

Réflexe DAF : les ruptures de séquence et les incohérences chronologiques (écritures de juillet intercalées entre des écritures de mars) sont les premiers points testés par le vérificateur dès l'import du FEC dans l'outil d'analyse Alto. Sur les factures de vente, les ruptures de séquence emportent une pénalité de 15 € par facture manquante.

Pour une typologie complète des anomalies identifiées par les vérificateurs sur ces champs, consultez notre article sur les anomalies les plus fréquentes dans un FEC.

Identification du compte : CompteNum et CompteLib

CompteNum (alphanumérique, obligatoire) est le numéro de compte selon le PCG. Les trois premiers caractères doivent être numériques et correspondre à la nomenclature du Plan Comptable Général français (BOI-CF-IOR-60-40-20 §130). Les subdivisions internes (extensions à 6, 7, 8 chiffres) sont admises tant qu'elles déclinent un compte PCG existant. Pour les secteurs réglementés (établissements de crédit, assurances), le plan de comptes sectoriel s'applique.

CompteLib (alphanumérique, obligatoire) est le libellé du compte, conforme à la nomenclature PCG ou aux libellés internes pour les déclinaisons. Les libellés génériques ("AUTRES", "DIVERS COMPTES") sur des montants significatifs constituent un signal d'alerte.

Position juridique. Depuis les exercices clos en 2015, ni le transcodage de masse ni les libellés en langue étrangère ne sont admis (BOI-CF-IOR-60-40-20 §350). La comptabilité doit être tenue en français selon les normes françaises. La tolérance subsiste pour les succursales françaises d'entreprises étrangères, qui peuvent remettre une table de correspondance avec le PCG (BOI-CF-IOR-60-40-10 §390) — mais cette tolérance ne couvre pas les filiales françaises de groupes étrangers, qui doivent tenir une vraie comptabilité PCG.

Une filiale dont la comptabilité opérationnelle est tenue dans l'ERP groupe avec libellés en mandarin et plan de comptes chinois s'est trouvée dans l'impossibilité de produire un FEC nativement conforme. L'administration a admis, par tolérance, la remise du FEC avec libellés en mandarin accompagné d'une table de correspondance mandarin/PCG complète. La conformité de principe a été sauvée, mais sur une base contractuelle bilatérale avec le vérificateur — pas sur un droit acquis. La table de mapping est un filet de sécurité, pas une stratégie : la voie structurelle reste la tenue d'une réelle double comptabilité (ERP groupe + module statutaire français).

Identification du tiers : CompAuxNum et CompAuxLib

CompAuxNum (alphanumérique, conditionnel) et CompAuxLib (alphanumérique, conditionnel) identifient le compte auxiliaire (clients 411xxx, fournisseurs 401xxx) et la désignation littérale du tiers. Ces champs sont obligatoires si et seulement si l'entreprise utilise une comptabilité auxiliaire dans son système. Si la comptabilité est tenue uniquement en générale, les colonnes existent mais les valeurs restent vides — strictement vides, pas remplies avec "0".

Ce que cherche le vérificateur. Trois choses : des libellés tiers exploitables (raison sociale lisible, non un code interne illisible) ; l'absence de tiers fictifs ou suspects (libellés génériques type "CLIENT DIVERS", "FOURNISSEUR PASSAGE") sur des montants significatifs ; la cohérence entre comptes généraux et comptes auxiliaires (un débit sur 401001 doit se retrouver dans le grand-livre auxiliaire).

Pièce justificative : PieceRef et PieceDate

Couple stratégique. Il matérialise le chemin de révision exigé par l'article 911-3 du PCG — l'un des fondements probants de toute comptabilité informatisée.

PieceRef (alphanumérique, obligatoire) est la référence de la pièce justificative : soit un numéro séquentiel interne, soit la référence figurant sur la pièce (n° de facture, ticket, etc.). PieceDate (date AAAAMMJJ, obligatoire) est la date figurant sur la pièce justificative, ou à défaut la date d'enregistrement.

Cas des écritures sans pièce. Pour les écritures d'à-nouveau ou certaines régularisations, le BOFIP admet (§180-190) le recours à une valeur conventionnelle définie par l'entreprise. Cette valeur doit impérativement être explicitée dans le descriptif d'accompagnement. À défaut, le vérificateur traite ces lignes comme des écritures sans justificatif.

Ce que cherche le vérificateur. Le contrôle est ici redoutable :

• Un champ PieceRef vide sur des écritures de charges entraîne le rejet de la charge en IS et de la TVA déductible correspondante. Sur des comptes 6xx significatifs, l'enjeu est massif.
• Des PieceRef anormalement répétitives (80 % des écritures du compte 622 portant la même référence) signalent un défaut de chemin de révision ou un usage abusif des valeurs conventionnelles.
• Une incohérence entre PieceDate et EcritureDate (pièce datée de janvier N+1 comptabilisée en décembre N, par exemple) remet en cause le cut-off — donc le rattachement à l'exercice.

En cours de vérification, sur certains comptes de charges externes (62x) ou de prestations (61x), l'administration identifie des montants significatifs pour lesquels PieceRef est soit vide, soit rempli par une référence générique répétée sur des dizaines d'écritures. La demande tombe : production des factures correspondantes, au nom de l'obligation de chemin de révision (PCG art. 911-3). En cas d'incapacité à produire, la charge est rejetée en IS et la TVA déductible correspondante remise en cause. PieceRef n'est pas un champ de remplissage — il doit être exploitable.

Libellé et montants : EcritureLib, Debit, Credit

EcritureLib (alphanumérique, obligatoire) identifie littéralement le motif de l'écriture. Le libellé doit être suffisamment précis pour permettre la compréhension. Une codification interne lapidaire ("FRE ICF S/EST LOY.10/2011 SN") est admissible si la grille de lecture est documentée dans le descriptif d'accompagnement — pas autrement.

Debit et Credit (numériques, obligatoires) portent les montants en euros. Si l'écriture est au débit, Credit = 0,00 — et inversement. Le séparateur décimal est le point ou la virgule, à documenter dans le descriptif. Pas de séparateur de milliers.

Alternative Montant + Sens. Si l'ERP ne distingue pas nativement débit et crédit, le X de l'article A. 47 A-1 admet une codification alternative : Montant (signé) + Sens ("D"/"C" ou "+1"/"-1"). Pour la codification "+1/-1", il est impératif qu'aucun espace ne sépare le signe du chiffre — sans quoi le fichier est rejeté au test technique.

Ce que cherche le vérificateur.

• Libellés génériques (DIVERS, OPDIV, REGUL) sur des montants significatifs : demande de justification systématique.
• Écritures déséquilibrées (somme des débits ≠ somme des crédits pour une même EcritureNum) : rejet automatique au test technique.
• Format numérique non standard : montants à trois décimales (cas observé sur certains paramétrages SAP), séparateur incohérent entre lignes. Le paramétrage de l'ERP conditionne directement la qualité de ces champs — voir notre panorama des procédures d'extraction par ERP.

Lettrage : EcritureLet et DateLet

EcritureLet (alphanumérique, conditionnel) est le repère d'appariement entre deux écritures (typiquement règlement ↔ facture). DateLet (date AAAAMMJJ, conditionnel) est la date de validation du lettrage. Champs conditionnels : obligatoires si l'entreprise pratique le lettrage dans son système. Si non, colonnes présentes, valeurs strictement vides.

Signaux d'alerte côté vérificateur. Trois cas typiques :

• Des comptes de tiers non lettrés alors que l'entreprise est censée pratiquer le lettrage dans son ERP.
• Des DateLet postérieures à la clôture, qui remettent en cause la matérialité du lettrage à la date de production des comptes.
• L'absence systématique de lettrage (vide partout) alors que l'entreprise déclare en pratiquer.

Validation : ValidDate, le champ le plus juridique du fichier

ValidDate (date AAAAMMJJ, obligatoire) est la date à laquelle l'écriture en mode brouillard a été transformée en écriture définitive — c'est-à-dire la date à laquelle elle est devenue intangible au sens de l'article 921-3 du PCG. Si le logiciel ne dispose pas de mode brouillard, ValidDate = EcritureDate.

C'est ici que la lecture du FEC devient véritablement juridique. Le vérificateur croise systématiquement ValidDate avec deux autres dates : la date de l'événement (EcritureDate) et la date de dépôt de la liasse fiscale.

Trois pièges majeurs :

• ValidDate postérieures à la date de dépôt de la liasse. Conséquence directe : remise en cause des amortissements et provisions, l'administration considérant qu'ils n'étaient pas régulièrement comptabilisés à la date de dépôt. Le fondement juridique est l'article 39, 1, 2° du CGI, qui impose l'enregistrement des amortissements avant l'expiration du délai de déclaration des résultats.
• ValidDate unique pour l'ensemble de l'exercice. Indice fort d'une comptabilité non validée jour par jour, contraire à l'article 921-2 du PCG (enregistrement opération par opération).
• Incohérence entre ValidDate et EcritureDate. Écriture comptabilisée en mars, validée en novembre : confusion fréquente entre clôture de période et validation d'écriture. Sur des provisions ou des amortissements, ce décalage peut suffire à motiver un rappel.

Réflexe à adopter : générer le FEC au moment de l'arrêté fiscal, pas après. C'est la seule manière de figer des ValidDate cohérentes avec la liasse — et donc défendables.

Devises : Montantdevise et Idevise

Montantdevise (numérique, conditionnel) porte le montant signé exprimé en devise étrangère. Idevise (alphanumérique, conditionnel) identifie la devise — code interne ou code ISO. En cas de codification interne, une table de correspondance doit accompagner le fichier (BOFIP §270).

L'activation des champs intervient dès qu'une opération est facturée en devise étrangère. Pour les opérations en zone euro, les colonnes restent vides. Cas particulier : lorsque seul le montant en devise est enregistré (et non sa contre-valeur euro), Debit et Credit peuvent être à 0,00 et Montantdevise porte la valeur réelle.

Ce que cherche le vérificateur. La concordance entre les montants en euros (qui figurent au compte de résultat) et les montants en devise (qui justifient la conversion). Pour les groupes internationaux, c'est aussi un point d'entrée pour les analyses de prix de transfert : un écart de taux entre lignes de même devise sur des périodes proches déclenche des questions.

Au-delà des 18 champs : extensions et cas particuliers

Deux extensions méritent d'être mentionnées sans les développer ici. Un 19e champ "code établissement" est prévu pour les comptabilités centralisant les données de plusieurs établissements (BOFIP §410). Il est recommandé pour les entreprises multi-sites afin de pouvoir tracer l'origine de chaque écriture. Pour les bénéfices agricoles, c'est une structure à 22 champs qui s'applique — régime spécifique, hors scope du présent article.

Les cas particuliers (fusions, migrations d'ERP, succursales étrangères, établissements multiples) sont traités en détail dans notre guide complet du fichier des écritures comptables, de même que le détail des sanctions de l'article 1729 D du CGI — récemment confirmées dans leur constitutionnalité par le Conseil d'État (CE 30 janvier 2026, n° 506887).

Checklist DAF : les 7 points de vérification prioritaires

Avant qu'un avis de vérification n'arrive, sept contrôles doivent être passés sur le FEC :

1. En-tête présent et complet sur la première ligne (format à plat) — sans en-tête, le fichier est non conforme.
2. Numérotation EcritureNum croissante sans rupture, et mode de numérotation (unique ou par journal) documenté dans le descriptif d'accompagnement.
3. ValidDate antérieures à la date de dépôt de la liasse pour toutes les écritures, en particulier les amortissements et provisions.
4. PieceRef exploitable sur les comptes 6xx significatifs — pas de référence générique répétée sur des dizaines d'écritures.
5. CompteNum aligné sur le PCG (trois premiers caractères numériques conformes à la nomenclature française), CompteLib en français.
6. Champs conditionnels strictement vides quand non utilisés (pas de "0", pas d'espace), avec mention dans le descriptif.
7. Descriptif d'accompagnement à jour : codes journaux, valeurs conventionnelles, mode de numérotation, séparateur décimal, codification devises.

Pour un audit complet du FEC ou la préparation d'un contrôle fiscal informatisé, retrouvez nos ressources en fiscalité informatique.