Accueil › Les formats

Les formats d’import comptable français, documentés

Quatre formats servent à faire entrer des écritures dans un logiciel de comptabilité français. Trois ont une spécification publique ; le quatrième n’en a plus. Voici ce que chacun transporte, ce qu’il ne transporte pas, et surtout ce qui fait rejeter un fichier — la partie que les documentations d’éditeurs passent sous silence.

Cette page est écrite à partir des textes eux-mêmes, cités à chaque affirmation. Elle n’est pas une brochure : les points incertains y sont signalés comme incertains.

Si vous cherchez lequel de ces formats produire à partir de relevés PDF — reprise d’historique, banque qui ne rejoue plus la période — la question se tranche ailleurs : reconstituer un CFONB 120 ou un OFX plutôt qu’un FEC, et pourquoi ça change la suite du dossier. Cette page-ci ne décrit que les formats, sans dire lequel choisir.

FEC — Fichier des Écritures Comptables

C’est le seul format d’import dont la structure est fixée par un texte réglementaire : Article A. 47 A-1 du Livre des procédures fiscales (arrêté du 29 juillet 2013) (Légifrance). Commentaire administratif : BOI-CF-IOR-60-40-20 — commentaire administratif du FEC (BOFiP-Impôts). C’est ce qui en fait le format à viser en priorité : un éditeur peut refuser un dialecte maison, il ne peut pas ignorer l’arrêté.

Ce que le texte impose

• 18 champs, dans cet ordre exact, nommés sur la première ligne :
  JournalCode · JournalLib · EcritureNum · EcritureDate · CompteNum · CompteLib · CompAuxNum · CompAuxLib · PieceRef · PieceDate · EcritureLib · Debit · Credit · EcritureLet · DateLet · ValidDate · Montantdevise · Idevise
• Séparateur : tabulation ou barre verticale |. L’arrêté n’en admet pas d’autre. C’est | que nous écrivons. (Ne pas confondre avec ce que l’outil de contrôle sait lire — voir ci-dessous, c’est la nuance qui coûte le plus cher.)
• Dates en AAAAMMJJ, sans séparateur.
• Fichier texte à longueur variable — ni format fixe, ni XML — codé ASCII, ISO 8859-15 ou UTF-8. Les trois sont légaux, et ce détail compte : certains logiciels français exigent l’ANSI sous peine d’accents abîmés.
• Nomenclature de dépôt : SirenFECAAAAMMJJ.txt (SIREN + date de clôture).

Ce qui fait rejeter un FEC

La DGFiP publie son propre outil de contrôle, Test Compta Demat — outil de contrôle des FEC de la DGFiP, code source publié (CeCILL) (DGFiP), sous licence libre. Son code source dit précisément ce qui passe et ce qui casse — et ce n’est pas toujours ce qu’on croit :

• Un FEC en point-virgule est examinable, mais il n’est pas conforme. Ce sont deux règles distinctes, et les confondre est l’erreur la plus répandue sur ce format. L’arrêté n’admet que la tabulation et |. L’outil de contrôle, lui, sait en lire quatre : trt_txt.pl, lignes 226 à 229, associe un séparateur aux codes T (tabulation), P (|), V (virgule) et PV (point-virgule), et ce code est un paramètre passé par l’opérateur (l. 85) — précisément parce que l’outil sert aussi à examiner des fichiers qui ne sont pas conformes. Pouvoir l’ouvrir ne veut donc pas dire qu’il est recevable. Cette page a longtemps écrit l’inverse — que l’outil de la DGFiP « ne reconnaît pas » le point-virgule. C’était faux, et c’est son code source, que nous citions déjà, qui nous a détrompés.
• Un point décimal dans un montant est une erreur bloquante, pas une tolérance. Le séparateur décimal doit être la virgule. Le texte de l’arrêté, lui, dit seulement « format numérique à deux décimales » sans trancher : c’est le code de l’outil qui tranche.
• Sept champs vides déclenchent une erreur : EcritureNum, EcritureDate, CompteNum, CompteLib, EcritureLib, Debit, Credit. Un libellé d’opération vide — un virement que la banque n’a pas nommé — suffit donc à faire refuser l’écriture.
• ValidDate vide n’est pas une erreur, c’est un signalement « valeur absente ». Un fichier d’import d’écritures non validées est donc légitime — à condition de ne pas les dater comme validées, ce qui serait faux.
• Le total des débits doit égaler le total des crédits. C’est la seule vérification comptable que l’outil fait sur le fond.

Ce que le texte ne fixe pas, et qu’il faut donc décider

CFONB 120 — relevé de compte sur support informatique

Format historique des banques françaises, toujours servi par les modules de rapprochement bancaire. Source : Relevé de compte sur support informatique — Transfert de fichiers, juillet 2004 (CFONB). Enregistrements de longueur fixe, 120 caractères, de quatre types : 01 ancien solde (obligatoire), 04 mouvement, 05 complément de libellé, 07 nouveau solde (obligatoire).

Les deux pièges du format

1. Le signe est surimprimé sur le dernier chiffre du montant. Héritage du COBOL : au crédit, { puis A…I pour 0…9 ; au débit, } puis J…R. Un montant de 1 250,00 € au crédit se termine donc par { et non par 0. Un fichier dont le signe est mal codé est rejeté sans explication utile.
2. Les accents sont interdits. La brochure renvoie à la circulaire FBF 88/327 du 15 septembre 1988 : chiffres, LETTRES MAJUSCULES, * - . / ) ( et l’espace, rien d’autre. DÉCEMBRE doit devenir DECEMBRE — et translittérer, jamais remplacer par un octet faux.

Ce qui fait rejeter un CFONB 120 — mesuré, pas supposé

Trois de ces points nous ont été appris par un lecteur écrit par d’autres, qui a refusé nos propres fichiers. Ils sont ici parce qu’aucune documentation ne les met en avant :

• La zone 2-I « code opération interbancaire » ne peut pas rester à blanc. Laisser une zone obligatoire vide n’est pas un silence prudent : c’est le rejet du fichier entier, avant qu’un seul montant soit lu. Le code 91, famille DIVE, valable au débit comme au crédit, est celui de l’opération dont la nature n’est pas précisée — exactement ce qu’on sait d’une ligne lue sur un PDF. Source : Codes opérations interbancaires, version 5.1, novembre 2022 (CFONB).
• Le numéro de compte (zone 2-H) est obligatoire, sur onze caractères. Onze blancs font rejeter le fichier. Un relevé PDF ne l’imprime pas toujours : il faut alors le demander, et refuser de produire tant qu’il manque.
• Le libellé fait 70 caractères, et il se chaîne. La brochure est explicite : le nombre d’enregistrements 05 pour un mouvement donné n’est pas limité. Un seul enregistrement, et tout ce qui dépasse 70 caractères part en silence — c’est-à-dire les références SEPA, qui sont précisément ce qui sert à rapprocher.
• Ancien et nouveau solde sont obligatoires, et la règle 2 de la brochure impose que le second soit la somme algébrique du premier et de tous les mouvements. Sans les deux, mieux vaut refuser que d’inventer un zéro : le fichier paraîtrait valide.

Ce qu’un PDF ne permet pas de reconstituer

Un relevé imprimé ne porte pas tout ce que le format attend. Les zones concernées : code banque, code guichet et numéro de compte (lisibles seulement si un IBAN français complet est imprimé — un IBAN masqué FR76 XXXX… ne compte pas), la date de valeur (souvent confondue avec la date d’opération), et la date de l’ancien solde (jamais imprimée telle quelle ; la veille de la première opération est une approximation assumée, imposée par la règle 3 de la brochure).

OFX 1.0.2

Format international, celui que la plupart des banques proposent en téléchargement direct. Source : Open Financial Exchange Specification 2.0.2, 2 septembre 2003 (consortium OFX) — sections 11.4.1.2, 11.4.3, 11.3.1 et 3.2.8.

• 1.0.2 et non 2.x, et c’est délibéré. Les fichiers .ofx que les banques livrent et que les logiciels acceptent sont en SGML (OFXHEADER:100). La 2.x est du XML, mieux spécifiée, bien moins acceptée à l’import. La hiérarchie des balises est identique entre les deux — observation, pas clause du texte : c’est ce qui autorise à s’appuyer sur la spécification 2.0.2 pour produire du 1.0.2.
• Les montants sont signés du point de vue du client (§ 11.4.3) : un débit est négatif. Une erreur de signe ici inverse tout un relevé sans qu’aucun contrôle de structure ne s’en aperçoive.
• <NAME> est facultatif, et ne doit jamais être écrit vide. En SGML à balises de fin omises, une balise vide n’a plus où s’arrêter : le lecteur rejette le fichier entier. Une seule opération sans libellé fait donc perdre toutes les autres. Le libellé complet va dans <MEMO> ; <NAME> est borné à 32 caractères.
• L’en-tête déclare CHARSET:1252 : le fichier s’écrit en Windows-1252, pas en UTF-8, sinon les accents arrivent illisibles chez celui qui importe.
• FITID doit être stable : réimporter le même relevé ne doit pas créer de doublons. Construit sur la date, le sens, le montant et le rang parmi les opérations identiques du même jour — jamais sur la position de la ligne ni sur le libellé. Corriger un libellé, supprimer une ligne, retrier ou fusionner plusieurs relevés laisse donc les identifiants intacts — à une exception près, que nous préférons écrire : deux opérations strictement identiques (même jour, même sens, même montant — deux paiements par carte de 2,10 € le même jour) ne sont distinguées que par leur rang. Supprimer l’une renumérote l’autre, et les retrier échange leurs identifiants. Rien ne permet de les distinguer : un relevé bancaire ne porte aucun numéro d’opération. Conséquence pratique : si vous convertissez un relevé en deux fois et qu’une de ces jumelles arrive au second passage, vérifiez ce couple-là.

Une rupture de continuité, une seule fois, le 27/08/2026. Les identifiants d’opération ont changé de forme ce jour-là. Si vous aviez déjà importé un relevé avant cette date, ne le réimportez pas : il entrerait en double. Les relevés exportés à partir d’aujourd’hui sont stables entre eux.

Aucun schéma stable ne peut naître stable par rapport à un schéma qui ne l’était pas. Ce qui n’était pas inévitable, en revanche, c’est le sens de la casse, et il a été vérifié : un identifiant de la nouvelle forme ne peut jamais coïncider avec un ancien. La migration produit donc des doublons visibles et supprimables, jamais des opérations que votre logiciel croirait déjà importées et passerait sous silence. Un doublon se voit ; une ligne absente, non. C’est désagréable une fois, et c’est le sens le moins coûteux.

QIF

Intuit ne publie plus de spécification. C’est le seul des quatre formats dont la référence n’est pas normative, et c’est pour cela qu’il vient en dernier. Les descriptions publiques concordantes utilisées ici : Finance::QIF — implémentation de référence, faute de spécification publiée par Intuit (CPAN).

Le piège tient en une phrase : QIF ne transporte aucune indication de langue ni de format de date. La convention d’origine est américaine (MM/JJ/AAAA), l’usage européen est JJ/MM/AAAA. Les logiciels sérieux demandent le format à l’import ; les autres peuvent intervertir jour et mois sans rien signaler. Un relevé de janvier à décembre passe alors inaperçu jusqu’au 13 du mois.

Deuxième piège, celui-là mesuré : une bibliothèque de lecture QIF répandue divise par mille tout montant portant un séparateur de milliers — T-1,000.00 est relu -1, sans erreur ni avertissement. Le format n’y est pour rien ; il n’a simplement pas d’autorité pour trancher.

Les comptes du plan comptable général

Un fichier d’import doit poser un numéro de compte en face de chaque libellé. Les intitulés utilisés ici sont recopiés à l’identique du Plan de comptes de l’article 1121-1 du règlement ANC n° 2014-03 (Autorité des normes comptables).

Deux règles de prudence, appliquées sans exception :

1. Ce qu’aucune règle ne reconnaît va en 471 — compte d’attente. Jamais dans un compte « à peu près juste ». Un comptable corrige vite un 471 ; il ne voit pas passer une charge rangée dans le mauvais poste.
2. Aucune règle sur un motif trop général. Pas de règle « VIREMENT », pas de règle « PRÉLÈVEMENT » : elles imputeraient massivement et faussement. Une règle « carburant » a été envisagée puis retirée — le compte 60622 couramment employé par les logiciels ne figure pas dans le plan de comptes de l’ANC, et une enseigne pétrolière vend aussi bien du carburant que de l’électricité.

Les formats que nous avons écartés, et pourquoi

Quadratus / Quadra (ASCII) est très répandu dans les cabinets français, et c’était le candidat n° 1 avant recherche. Il a été écarté faute de spécification publique : aucune des sources consultées ne donne les positions et longueurs de zones. Le seul élément concret trouvé est un exemple d’enregistrement posté sur un forum, dont les espaces ont été normalisés par le forum lui-même — donc inutilisable pour un format positionnel, où une zone décalée d’un caractère fait rejeter le fichier en bloc, ou pire, le fait importer de travers.

Sage, Cegid, Isacompta, ACD : mêmes motifs, documentation non publiée par les éditeurs. Le contournement est meilleur que huit dialectes reconstitués — ces logiciels importent le FEC, qui est spécifié par un texte opposable.

← Convertir un relevé · Comment nous vérifions nos fichiers