À jour au juillet 2026. Une entreprise qui détient, encaisse ou dépense des crypto-actifs finit toujours par se heurter au même mur : la blockchain enregistre des mouvements de jetons entre adresses, l’administration fiscale attend des écritures comptables en euros. Entre les deux, il faut un travail de traduction rigoureux. Ce travail se matérialise dans le Fichier des Écritures Comptables, le FEC, que toute entreprise doit pouvoir remettre lors d’un contrôle. Retranscrire des flux on-chain dans un FEC conforme n’a rien d’automatique, et une comptabilité crypto mal tenue se paie cash le jour d’un examen. Voici la méthode, sans détour.
Le FEC, un fichier obligatoire que la blockchain ne remplace pas
Le Fichier des Écritures Comptables est l’export normalisé de l’ensemble des écritures d’un exercice. Depuis 2014, toute entreprise qui tient une comptabilité informatisée doit être en mesure de le remettre à l’administration en cas de vérification, sur le fondement de l’article L47 A I du livre des procédures fiscales. Sa structure est fixée par l’article A47 A-1 du LPF, complété par la documentation officielle publiée sur impots.gouv.fr.
Ce texte impose un fichier à plat, structuré, avec un séparateur de colonnes stable, des dates au format AAAAMMJJ et un encodage défini. Chaque ligne correspond à une écriture, et chaque écriture comporte 18 champs obligatoires : code et libellé du journal, numéro et date d’écriture, numéro et libellé de compte, référence et date de pièce justificative, libellé de l’opération, montants au débit et au crédit, entre autres. Rien dans ce format ne prévoit d’adresse de wallet, de hash de transaction ni de montant en ether.
C’est le point que beaucoup de dirigeants comprennent trop tard : un explorateur de blocs prouve qu’une transaction a eu lieu, il ne constitue pas une comptabilité. Le vérificateur ne se contentera jamais d’un lien Etherscan. Il exigera le FEC, avec ses journaux, ses comptes du Plan Comptable Général et ses montants en euros. Les données de la chaîne deviennent alors des pièces justificatives rattachées aux écritures, elles ne les remplacent pas. La logique reste celle décrite dans notre article sur les règles PCG applicables aux crypto-actifs : la blockchain alimente la comptabilité, elle ne fait pas office de comptabilité.
Pourquoi les flux on-chain résistent au format FEC
Une écriture comptable classique naît d’une facture ou d’un relevé bancaire libellé en euros. Un flux on-chain, lui, arrive sous une forme structurellement différente, et c’est là que la difficulté commence.
Premier obstacle, la devise. Une transaction blockchain est libellée en ether, en bitcoin ou en un stablecoin, jamais nativement en euros. Or le FEC n’accepte que des montants en devise de tenue de la comptabilité. Il faut donc convertir chaque mouvement au cours du jour, ce qui suppose de figer une méthode de valorisation et une source de cours.
Deuxième obstacle, les frais de réseau. Chaque opération on-chain consomme du gas, réglé dans la crypto native de la chaîne. Ces frais sont une charge à comptabiliser distinctement, souvent en compte 627 ou 6278, avec leur propre conversion en euros. Une entreprise active en DeFi peut générer des centaines de lignes de gas par mois, chacune à valoriser.
Troisième obstacle, la granularité. Un simple achat de jeton peut se décomposer en plusieurs événements on-chain : une approbation de dépense, un swap, un transfert. Un dépôt dans un protocole de prêt ou de staking génère lui aussi une cascade de transactions. Le comptable doit décider quel niveau d’agrégation retenir pour ne pas noyer le grand livre, tout en conservant la traçabilité fine exigée par la piste d’audit. Ces mécanismes sont détaillés dans notre panorama DeFi 101 : staking, yield farming et lending.
Quatrième obstacle, l’identité des contreparties. Une écriture normale rattache un tiers identifié. Sur la chaîne, la contrepartie est une adresse pseudonyme. Documenter à qui correspond une adresse relève d’un travail de rapprochement, indispensable notamment pour les obligations de lutte anti-blanchiment que nous traitons dans l’article sur le KYC et l’AML en entreprise crypto.
Les 18 champs du FEC appliqués à une transaction blockchain
La bonne nouvelle, c’est que le format du FEC est assez souple pour absorber une transaction on-chain, à condition de discipliner le remplissage des champs. Voici comment cadrer les principaux.
Le champ JournalCode gagne à isoler l’activité crypto dans un journal dédié, par exemple un journal CRYPTO ou WEB3. Cette séparation facilite la réconciliation avec les données on-chain et rend le contrôle plus lisible pour le vérificateur.
Le champ EcritureDate porte la date de l’opération au format AAAAMMJJ. Pour un flux on-chain, cette date est celle de la confirmation du bloc, pas celle de l’initiation de la transaction depuis le wallet. La distinction compte lorsqu’une opération est confirmée après minuit ou en fin d’exercice.
Le champ CompteNum reçoit le compte du PCG correspondant à la classification retenue, par exemple le compte 508 pour des crypto-actifs de placement. Le libellé de compte doit rester explicite.
Le champ PieceRef est le plus stratégique pour la crypto : c’est là que doit figurer le hash de transaction, identifiant unique et infalsifiable de l’opération sur la chaîne. Renseigner systématiquement le hash transforme chaque écriture en ligne vérifiable à la source, sur l’explorateur de blocs. C’est le meilleur allié d’une piste d’audit solide.
Le champ EcritureLib, le libellé de l’opération, doit être parlant : nature de l’opération, protocole concerné, adresse de destination abrégée. Un libellé du type swap USDC vers ETH sur Uniswap vaut mieux qu’un laconique operation crypto.
Enfin, les champs Debit et Credit portent les montants en euros après conversion. Le montant en crypto n’a pas sa place dans ces colonnes normées ; il doit être conservé dans la pièce justificative et dans le sous-livre crypto, jamais substitué au montant en euros.
Construire un sous-livre crypto réconcilié à la comptabilité
La méthode robuste ne consiste pas à saisir les transactions blockchain directement dans le FEC, mais à interposer un sous-livre crypto, un registre auxiliaire, qui alimente ensuite la comptabilité générale. Cette architecture protège la comptabilité principale tout en conservant le détail on-chain.
L’article suivant décompose la démarche.
De l'adresse blockchain à l'écriture comptable en 5 étapes
- Recenser toutes les adresses maîtrisées par l’entreprise (wallets, comptes sur exchange agréés, adresses de contrats de dépôt) dans un référentiel unique, mis à jour à chaque création d’adresse.
- Extraire l’historique complet des transactions de ces adresses via l’API d’un explorateur ou un outil de comptabilité crypto, en incluant les frais de gas et les transactions internes.
- Valoriser chaque flux en euros à la juste valeur du jour, en consignant la source du cours et l’horodatage de conversion.
- Classer chaque opération par nature comptable (achat, cession, encaissement client, paiement fournisseur, frais de réseau, produit de staking) et lui affecter le compte du PCG adéquat.
- Agréger les écritures par période dans un journal crypto dédié, puis réconcilier le solde du sous-livre avec le grand livre à l’euro près avant génération du FEC.
Le point de contrôle final, la réconciliation à l’euro près entre le sous-livre crypto et le grand livre, est celui qui fait la différence lors d’un contrôle. Un écart non expliqué entre les deux registres est un signal d’alerte immédiat pour un vérificateur. Cette rigueur vaut particulièrement pour une trésorerie d’entreprise exposée au bitcoin, où les variations de valeur et le volume d’opérations rendent le suivi manuel vite ingérable.
Valorisation, horodatage et piste d’audit fiable
La piste d’audit fiable est l’exigence transversale du contrôle des comptabilités informatisées : chaque écriture doit pouvoir être reliée, sans rupture, à la pièce qui la justifie et à l’opération économique réelle. Pour la crypto, cela impose trois disciplines.
La première est la valorisation documentée. Chaque conversion en euros doit reposer sur un cours de référence traçable, tiré d’un exchange reconnu, avec l’horodatage exact de la transaction. Conserver un export ou une capture du cours à l’instant de l’opération permet d’opposer une valorisation crédible plutôt qu’une estimation reconstituée a posteriori. La méthode de valorisation choisie doit rester constante d’un exercice à l’autre.
La deuxième est l’horodatage cohérent. La date on-chain (confirmation du bloc) et la date comptable doivent être alignées, et l’écart éventuel avec le fuseau horaire local documenté. Cet alignement devient critique au moment de la clôture, quand une transaction confirmée le 31 décembre au soir ou le 1er janvier au matin bascule d’un exercice à l’autre.
La troisième est la conservation des preuves. Le hash de transaction est la clé de voûte : rattaché au champ PieceRef, il permet à tout moment de retrouver l’opération sur la chaîne. À côté du hash, il faut archiver les relevés d’exchange, les captures de cours et le référentiel d’adresses. Cette documentation est la même qui sert à établir la déclaration fiscale via le formulaire 2086 pour les cessions, et à structurer sereinement le patrimoine numérique au sein d’une société holding crypto.
Ce que change le règlement ANC 2026-01
Le cadre comptable français des crypto-actifs a franchi une étape en 2026. Le règlement ANC N°2026-01, adopté le 9 janvier 2026, fixe les règles de comptabilisation des crypto-actifs pour toutes les entreprises et adapte le Plan Comptable Général en intégrant les apports du règlement européen MiCA (UE) 2023/1114. Il succède à la recommandation ANC N°2022-05 qui avait posé les premiers repères.
Pour le FEC, ce règlement ne modifie pas le format du fichier, qui reste régi par l’article A47 A-1 du LPF. Il précise en revanche la classification et l’évaluation des crypto-actifs, donc le contenu des écritures que le FEC retranscrit : quels comptes utiliser selon la nature du jeton, comment traiter les moins-values latentes, comment enregistrer les jetons reçus en paiement ou issus de staking. Une comptabilité crypto tenue en 2026 doit s’appuyer sur ce texte pour arrêter ses schémas d’écritures avant même de penser à l’export du FEC. Le détail des versions officielles figure dans le recueil du règlement publié par l’ANC.
Sanctions : ce que risque une entreprise en cas de FEC non conforme
L’enjeu n’est pas théorique. Le défaut de présentation du FEC, ou la remise d’un fichier non conforme, expose à une amende prévue par l’article 1729 D du code général des impôts. Son montant est fixé à 5 000 euros ; en cas de rectification et si le montant correspondant est plus élevé, l’amende est portée à une majoration de 10 % des droits rappelés. Les modalités de mise en œuvre sont détaillées dans le BOFiP relatif au contrôle des comptabilités informatisées.
Les motifs de rejet d’un FEC sont connus et documentés : structure non conforme, champs manquants ou mal renseignés, dates au mauvais format, séparateurs incohérents, écritures non équilibrées. Pour une comptabilité crypto, s’ajoutent des risques spécifiques : montants laissés en devise crypto au lieu d’euros, absence de hash en pièce justificative, cours de valorisation non documenté, écart non réconcilié entre le sous-livre crypto et le grand livre. Chacun de ces défauts peut suffire à faire écarter la comptabilité comme non probante.
Au-delà de l’amende, un FEC rejeté fragilise toute la défense de l’entreprise. Une comptabilité jugée non probante ouvre la voie à une reconstitution du résultat par l’administration, avec des conséquences fiscales bien supérieures à l’amende initiale. La rigueur du FEC crypto n’est donc pas une contrainte administrative de plus : c’est la condition pour que les choix comptables et fiscaux de l’entreprise restent opposables. Anticiper vaut toujours mieux que corriger sous la pression d’un avis de vérification.
En pratique, une entreprise exposée aux actifs numériques a intérêt à industrialiser sa collecte on-chain, à figer sa méthode de valorisation et à tester la génération de son FEC crypto avant la clôture, plutôt qu’à découvrir les écarts le jour où le vérificateur réclame le fichier. La blockchain garde la mémoire de tout ; encore faut-il la traduire dans le langage que l’administration accepte de lire.