Noms de colonnes non conformes dans un FEC : retrouver les libellés exacts

Ce que signifie l’erreur

L’article A47 A-1 du LPF impose que la première ligne du fichier comporte le nom des champs, et donne dans un tableau la liste des zones, dans l’ordre. Pour le cas général, ce sont 18 noms écrits d’une seule traite, avec des majuscules à des endroits précis :

JournalCode|JournalLib|EcritureNum|EcritureDate|CompteNum|CompteLib|CompAuxNum|CompAuxLib|PieceRef|PieceDate|EcritureLib|Debit|Credit|EcritureLet|DateLet|ValidDate|Montantdevise|Idevise

Pour rapprocher chaque colonne d’une zone, le validateur compare les noms sans tenir compte des majuscules, des espaces, des tirets bas et des tirets. Quand il trouve une correspondance mais que l’orthographe n’est pas exactement celle du texte, il signale l’écart, colonne par colonne : « Colonne 17 : « MontantDevise » au lieu de « Montantdevise » ».

Il accepte aussi quelques variantes courantes, en les signalant de la même façon : « MontantEnDevise » ou « Montant devise » pour Montantdevise, « Devise » pour Idevise, « Lettrage » pour EcritureLet, « DateLettrage » pour DateLet.

Un exemple dans un fichier FEC

Un en-tête produit par un export qui met tout en majuscules et ajoute des tirets bas :

JOURNALCODE|JOURNALLIB|ECRITURE_NUM|ECRITUREDATE|COMPTENUM|...|MontantDevise|IDevise

Le fichier est lu sans difficulté, mais chaque colonne mal orthographiée est signalée. À l’inverse, un nom accentué ou traduit, comme « Débit » ou « Code journal », n’est pas rapproché : la zone est considérée comme absente, et le libellé comme une colonne supplémentaire.

D’où viennent les écarts

• Un export « maison » écrit par un prestataire ou généré depuis une base de données, où les noms de colonnes suivent les conventions du programme (majuscules, tirets bas) plutôt que celles du texte.
• Les zones de devise, souvent orthographiées « MontantDevise » ou « IDevise » par analogie avec les autres noms. Le texte écrit « Montantdevise » et « Idevise ».
• Un espace invisible en fin de nom, par exemple « Credit » suivi d’un espace avant le séparateur. Le nom paraît juste, mais ne l’est pas.
• Un en-tête retapé à la main dans un tableur, parfois traduit en français ou accentué.
• La reprise des exemples du BOFiP, qui écrivent CompteAuxNum et CompteAuxLib alors que l’article retient CompAuxNum et CompAuxLib.

Comment corriger

1. Comparez votre première ligne avec la liste ci-dessus, en vous aidant du détail affiché par le validateur : il donne pour chaque colonne le nom trouvé et le nom attendu.
2. Corrigez à la source si le fichier est produit par un programme ou un modèle d’export : les mêmes noms reviendront à chaque export sinon.
3. À défaut, corrigez uniquement la première ligne dans un éditeur de texte, sans ouvrir le fichier dans un tableur. Remplacez-la par la ligne de référence, en respectant le séparateur utilisé dans le reste du fichier et l’ordre réel des colonnes.
4. Vérifiez l’ordre : si vos colonnes ne suivent pas l’ordre du texte, le validateur le signale séparément par le contrôle « Ordre des colonnes non conforme ». Renommer ne suffit pas, il faut réordonner les données.
5. Relancez le validateur FEC.

Est-ce grave ?

Le validateur classe ce contrôle en erreur : les écritures sont lues, mais l’en-tête ne respecte pas le format prévu. Le risque est qu’un outil d’analyse moins tolérant, qui cherche chaque zone par son nom exact, ne retrouve pas la colonne et considère l’information comme absente.

La correction est l’une des plus simples à faire, puisqu’elle ne touche qu’une ligne et aucune écriture. Les fichiers qui utilisent la structure Montant/Sens ou les structures de comptabilité de trésorerie (BA, BNC) ont leurs propres noms de zones, également fixés par l’article ; le validateur détecte la structure utilisée et applique la liste correspondante.