Un contrôle fiscal commence. L'avis de vérification arrive. Vous avez 15 jours pour remettre le FEC. Votre ERP est SAP — le plus répandu dans les grandes entreprises françaises — et personne en interne ne sait exactement comment DART fonctionne, ni même si les notes SAP nécessaires ont été implémentées. Ce scénario est loin d'être théorique : sur un système ECC6, la génération d'un FEC conforme exige l'implémentation préalable de jusqu'à 39 notes SAP dans un ordre précis. Un seul prérequis manqué, et le fichier remis à l'administration sera incomplet, mal structuré, ou tout simplement rejeté.
Cet article fait partie d'une série consacrée à l'extraction du FEC par ERP. Pour une vue d'ensemble des différentes plateformes et de leurs spécificités, consultez le panorama général de l'extraction du FEC par ERP.
Avertissement : cette fiche couvre SAP ECC 6.0 (DART classique, transactions FTW*) et SAP S/4HANA (on-premise et cloud). Les chemins de navigation peuvent varier selon votre version, votre niveau de support package et votre configuration spécifique. En cas de doute, faites-vous accompagner.
Contexte
SAP ECC et SAP S/4HANA sont les ERP les plus déployés dans les groupes français de taille intermédiaire et les grandes entreprises. L'obligation de remise du FEC, posée par l'article L. 47 A du LPF, s'impose à tout contribuable tenant sa comptabilité au moyen de systèmes informatisés — SAP compris. Le format du fichier est défini par l'article A. 47 A-1 du LPF : 18 champs obligatoires, encodage UTF-8 (ou ISO 8859-15, ou ASCII), convention de nommage SirenFECAAAAMMJJ.
Le défaut de présentation du FEC dans les formes requises expose l'entreprise à l'amende prévue par l'article 1729 D du CGI : 5 000 € par exercice, ou 10 % des droits rappelés si ce montant est plus élevé. Le Conseil d'État a confirmé la constitutionnalité de cette sanction dans une décision du 30 janvier 2026 (n° 506887), jugeant le montant non disproportionné au regard de l'objectif de lutte contre la fraude fiscale.
L'extraction du FEC depuis SAP n'est donc pas un sujet IT. C'est un acte à portée juridique, dont les erreurs se mesurent en euros et en crédibilité face au vérificateur.
DART : l'outil standard SAP pour produire le FEC
DART (Data Retention Tool) est la solution native SAP pour générer le FEC. SAP recommande d'utiliser la version 2.7 de DART. L'outil fonctionne en deux étapes distinctes : d'abord l'extraction des données comptables dans des fichiers séquentiels, puis la transformation de ces données en fichier FEC conforme au format légal.
Sur SAP ECC, DART repose sur un ensemble de transactions dédiées (préfixe FTW*). La transaction FTW0 offre un aperçu de toutes les transactions DART disponibles — c'est le point d'entrée pour les équipes Basis et comptables qui découvrent l'outil.
Sur SAP S/4HANA Cloud, DART est progressivement remplacé par l'application Run Statutory Reports (ou Run Compliance Reports selon la version). Cette application intégrée à l'interface Fiori simplifie le processus, mais le principe reste le même : extraction, transformation, validation. Sur S/4HANA on-premise, DART reste disponible et fonctionnel.
La distinction entre ECC et S/4HANA n'est pas qu'une question de version logicielle. Elle détermine quels outils, quelles notes SAP et quelle approche utiliser pour générer un FEC conforme. Un DAF ou un avocat fiscaliste qui accompagne un client sous SAP doit connaître cette distinction, car elle conditionne la stratégie de réponse en cas de contrôle.
Prérequis techniques : ce qui bloque avant même de commencer
Avant toute extraction, trois prérequis impératifs doivent être vérifiés. Un seul manquement suffit à produire un FEC non conforme — avec les conséquences fiscales qui en découlent.
Implémentation des notes SAP
La note SAP 2162977 définit l'ordre d'implémentation des notes nécessaires à DART pour le FEC. Sur un système ECC6, cela peut représenter jusqu'à 39 notes SAP à implémenter dans le bon ordre. L'implémentation séquentielle est critique : une note appliquée dans le désordre peut corrompre la configuration DART sans message d'erreur explicite.
La note 1923322 détaille la configuration de la vue DART spécifique France (2FR_FI01). Les notes 1933144 et 1951943 complètent le dispositif en apportant le cadre légal (article L. 47 A-I du LPF) et les réponses aux questions fréquentes dans le contexte SAP.
En pratique, la première tâche de toute équipe confrontée à une demande FEC sur SAP ECC est de vérifier la version de DART installée (minimum 2.6, recommandé 2.7) et le statut d'implémentation de la note 2162977. Sans cette vérification, tout le reste est construit sur du sable.
Exercice fiscal complètement clôturé
DART ne peut extraire un FEC fiable que sur un exercice clôturé. Toute extraction sur un exercice non clôturé expose à un fichier incomplet : écritures d'inventaire absentes, provisions non comptabilisées, comptes de résultat non soldés. L'administration exige un fichier reflétant l'intégralité des écritures de l'exercice, y compris les écritures de clôture.
Report à nouveau (soldes d'ouverture)
Le FEC doit inclure les écritures de report à nouveau, conformément à l'article A. 47 A-1 du LPF. Sous SAP, cette étape passe par la transaction FAGL_FR_03 (GL classique) ou le programme RFOPENPOSTING_FR (exécutable via SE38), qui comptabilise des documents statistiques (statut BSTAT 'O') en période '00'. Ces écritures ne mettent pas à jour les soldes comptables — elles alimentent exclusivement le fichier DART.
Cette étape doit être réalisée après la clôture annuelle et avant l'extraction DART. Un report à nouveau manquant est une anomalie immédiatement détectable par le vérificateur et par l'outil Test Compta Demat.
Un prérequis manqué ne produit pas toujours un message d'erreur. DART peut générer un fichier apparemment complet mais juridiquement non conforme. Le risque n'est pas le crash technique — c'est le faux sentiment de conformité.
Procédure d'extraction pas à pas
Le workflow DART pour générer un FEC depuis SAP ECC se décompose en quatre étapes.
Étape 1 — Création de l'extrait de données (FTW1A)
La transaction FTW1A crée l'extrait de données brut. Les paramètres de sélection sont la société (company code), l'exercice fiscal, la langue clé FR, et la zone d'extraction "Documents financiers (FI) et postes non soldés". Cette étape génère des fichiers séquentiels stockés sur le serveur d'application SAP.
Étape 2 — Génération du fichier FEC (FTWH)
La transaction FTWH planifie l'exécution de la vue 2FR_FI01 ("DART : données de transaction FI pour les exigences légales de la France") sur l'extrait créé à l'étape précédente. C'est cette vue qui transforme les données SAP brutes en fichier structuré conforme aux 18 champs du FEC. Le nom du fichier généré doit respecter la convention SirenFECAAAAMMJJ (exemple : 123456789FEC20251231).
Étape 3 — Vérification
Afficher les données via la liste DART (transaction FTWN) et contrôler la cohérence : nombre de lignes, présence des écritures de report à nouveau, absence de lignes vides ou de champs manquants. Ce premier contrôle visuel permet de détecter les anomalies grossières avant toute validation formelle.
Étape 4 — Export
Exporter le fichier en .txt depuis le serveur d'application (transaction CG3Y) avec le format "Format de fichier français" — séparateur pipe (|) ou tabulation selon la configuration. L'encodage doit être UTF-8.
La transaction FTWY permet de créer ou modifier les vues de données si la vue standard 2FR_FI01 ne couvre pas les besoins spécifiques de l'entreprise (champs supplémentaires, filtres particuliers). Cette flexibilité est utile, mais toute modification de la vue doit être documentée et justifiable face au vérificateur.
Nommage et format du fichier
Le fichier FEC doit respecter la convention de nommage SirenFECAAAAMMJJ, où AAAA est l'année de clôture, MM le mois et JJ le jour. Le séparateur de champs est le caractère pipe (|) ou la tabulation, selon le choix du contribuable. Le séparateur décimal est la virgule (pas le point). L'encodage doit être UTF-8 (alternatives autorisées : ISO 8859-15 ou ASCII).
Un fichier mal nommé ou utilisant un encodage incorrect sera rejeté par l'outil Test Compta Demat avant même que le vérificateur n'examine le contenu comptable. Ces erreurs de forme sont les plus faciles à éviter — et les plus fréquentes.
Les pièges classiques qui exposent à un rejet
Quatre erreurs spécifiques à SAP reviennent de manière récurrente dans les contrôles fiscaux. Chacune a des conséquences directes en termes de conformité.
Ruptures de séquence EcritureNum
Les plages de numéros de documents SAP sont configurées par type de document : factures fournisseurs, notes de crédit, écritures manuelles, écritures de clôture. Chaque type de document dispose de sa propre séquence de numérotation. Résultat : le champ EcritureNum dans le FEC présente des "sauts" que l'outil Test Compta Demat signale systématiquement comme des ruptures de séquence.
Ces sauts ne sont pas en eux-mêmes des anomalies comptables — ils reflètent l'architecture de numérotation de SAP. Mais le vérificateur, lui, attend une continuité ou, à défaut, une explication documentée. À défaut d'explication, il peut suspecter des suppressions d'écritures.
La réponse passe par une analyse préalable : identifier les plages de numéros par type de document, vérifier que toutes les pièces comptables sont présentes, exclure les documents d'affectation CO (qui ne relèvent pas de la comptabilité générale), et s'assurer de l'absence de documents préenregistrés en attente. Pour une analyse détaillée des 18 champs obligatoires et de leurs contraintes, consultez l'article sur la structure du FEC et ses 18 champs.
Comptes alternatifs GL français manquants
De nombreux groupes sous SAP utilisent un plan comptable interne (groupe, IFRS, US GAAP) comme plan comptable opérationnel. Pour les entités françaises, des comptes alternatifs conformes au PCG doivent être définis en correspondance. Les comptes alternatifs manquants sont l'une des erreurs les plus courantes sur les données de base GL : elles conduisent à des données FEC manquantes ou incorrectes, notamment des champs CompteNum vides ou non conformes à la nomenclature PCG.
Le BOI-CF-IOR-60-40-20 (§130 à §150) précise que le numéro de compte dans le FEC doit répondre aux normes du PCG. Cette exigence s'applique même si le plan comptable opérationnel de l'entreprise n'est pas le PCG. Les succursales d'entreprises étrangères peuvent fournir une table de correspondance, mais les entités françaises doivent produire des CompteNum conformes.
Documents préenregistrés (parked documents)
Les documents préenregistrés (ou "parkés") dans SAP sont des écritures saisies mais non encore validées comptablement. Ils perturbent la chronologie des pièces et ne doivent pas figurer dans le FEC, qui ne comprend que les écritures validées. Un filtre défaillant dans l'extraction DART peut laisser passer ces documents, introduisant des pièces dont la ValidDate est postérieure à la période d'extraction ou dont le statut comptable est incohérent.
Volumes excessifs
DART peut échouer sur des volumes très importants. Les entreprises générant plus de 20 millions de lignes comptables par exercice constatent régulièrement des crashs du programme DART, des fichiers tronqués, ou des temps d'extraction incompatibles avec les délais de réponse à l'administration. Dans ces cas, des alternatives existent (cf. section dédiée plus bas).
Pour un panorama complet des anomalies rencontrées tous ERP confondus, consultez le guide des anomalies FEC fréquentes.
Migration ECC → S/4HANA : un moment critique pour le FEC
La migration de SAP ECC vers S/4HANA n'est pas une simple mise à jour technique. C'est une conversion complète de système qui affecte directement la structure des données comptables — et donc la génération du FEC.
Ce que dit la doctrine BOFIP
Le BOI-CF-IOR-60-40-20 (Section VII-A, §400) traite spécifiquement le cas d'un changement de logiciel comptable en cours d'exercice. L'administration accepte, par mesure de tempérament, la remise de deux fichiers FEC distincts au titre d'un même exercice, sous réserve du respect de conditions cumulatives : les deux fichiers doivent permettre de reconstituer la totalité des écritures comptables de l'exercice, leur remise doit être simultanée, chacun doit respecter le format de l'article A. 47 A-1 du LPF, et des tables de correspondance et de réconciliation comptable entre les deux systèmes doivent accompagner la remise.
Concrètement, si la migration a lieu à une date T au cours de l'exercice Y : un premier FEC est généré depuis ECC (du 1er janvier à la date T), un second depuis S/4HANA (de la date T au 31 décembre).
Exercices antérieurs à la migration
Pour tous les exercices antérieurs à la migration, le FEC doit être généré depuis ECC, système source des données comptables originales. Tenter de générer rétroactivement un FEC depuis S/4HANA pour des exercices comptabilisés sous ECC expose à des incohérences structurelles (renumérotation des comptes, conversion du plan comptable, perte de la séquence de numérotation d'origine).
Impacts techniques de la migration
Trois changements structurels de S/4HANA affectent directement le FEC :
La renumérotation des fiches clients/fournisseurs résulte du passage au modèle Business Partner, qui fusionne les fiches KD (clients) et KK (fournisseurs) en un identifiant unique. Le champ CompAuxNum du FEC est directement impacté.
La conversion du plan comptable peut entraîner des fusions ou restructurations de comptes. Un CompteNum valide sous ECC peut ne plus exister sous S/4HANA, ou correspondre à un compte différent.
La modification des séquences de numérotation des documents comptables crée un risque de rupture de l'intégrité séquentielle du FEC — précisément le type d'anomalie que le vérificateur recherche en priorité.
Recommandation opérationnelle : extraire et archiver les FEC depuis ECC avant la migration. Si le système ECC d'origine n'est plus disponible après la migration, la situation devient considérablement plus complexe et nécessite un accompagnement spécialisé. Le coût d'une extraction préventive est dérisoire comparé au coût d'une reconstitution a posteriori.
L'architecture technique de l'ERP : un argument du vérificateur
Ce point est le vrai sujet de fond pour les avocats fiscalistes et les DAF. L'administration fiscale ne se limite pas à analyser le contenu du FEC : elle examine aussi l'environnement informatique dans lequel il a été produit.
Le BOI-CF-IOR-60-40-30 identifie explicitement les risques liés aux logiciels "permissifs" : brouillards permanents, suppression d'enregistrements sans trace, clôture apparente des exercices. Ces caractéristiques, lorsqu'elles sont constatées, peuvent fonder un rejet de la valeur probante de la comptabilité.
Illustration terrain : lors d'un contrôle fiscal, l'administration a tenté de rejeter la comptabilité d'une société au motif que son ERP (une version SAP sur base SQL Server) constituait un environnement "permissif". L'argument du vérificateur : le choix d'une base de données relationnelle standard permettait un accès facilité aux données comptables brutes — ajout, modification, suppression — sans conservation de traces par défaut. Le service a qualifié ce choix d'"inhabituel" par rapport à la complexité du système natif SAP, estimant qu'il créait un contexte propice à l'altération des données sans traces. Après négociations, l'argument a été écarté, mais le cas illustre une réalité nouvelle : l'administration examine désormais l'architecture technique de l'ERP, pas seulement les chiffres du FEC. [À VÉRIFIER : la dénomination exacte de l'ERP concerné — SAP Business One sur SQL Server ≠ SAP ECC]
L'enseignement est clair : le choix de l'ERP, de sa base de données, de la gestion des droits d'accès et des logs de traçabilité est un enjeu fiscal autant que technique. La transition vers les versions récentes de SAP (S/4HANA), dotées d'une meilleure traçabilité native (HANA database, journaux d'audit intégrés), constitue aussi une réponse à ce type de risque.
Validation du FEC avant remise à l'administration
Ne jamais attendre l'avis de vérification pour tester son FEC. L'extraction et la validation doivent être réalisées dès la clôture de chaque exercice. Trois niveaux de contrôle sont nécessaires.
Niveau 1 — Test Compta Demat
L'outil gratuit de la DGFiP, téléchargeable sur economie.gouv.fr, vérifie la structure technique du fichier : présence des 18 champs, format des dates, encodage, convention de nommage. C'est le premier filtre — et c'est exactement l'outil que le vérificateur utilisera en premier.
Attention : Test Compta Demat ne vérifie pas la cohérence comptable de fond. Un fichier peut passer tous les tests de structure tout en contenant des anomalies comptables majeures (écritures déséquilibrées, comptes inexistants, doublons).
Niveau 2 — Rapprochement avec les balances SAP
Utiliser la transaction S_ALR_87012082 pour extraire les soldes fournisseurs et les rapprocher avec le FEC. Faire de même pour les soldes clients et les soldes GL. Vérifier que le solde au niveau de chaque pièce comptable est nul (principe de la partie double). Tout écart entre la balance SAP et le FEC signale une erreur d'extraction ou un problème de périmètre (exercice non entièrement clôturé, report à nouveau manquant, filtre d'extraction trop restrictif).
Niveau 3 — Contrôle de cohérence global
Vérifier que les totaux débit/crédit du FEC correspondent au bilan et au compte de résultat de l'exercice. C'est le premier contrôle de cohérence que fera le vérificateur. Un écart entre le FEC et les comptes annuels déposés déclenche immédiatement une demande d'explications — et installe un doute qui accompagne toute la durée du contrôle.
Le FEC est la photographie numérique de votre comptabilité. Si cette photographie ne correspond pas aux comptes annuels déposés au greffe, le vérificateur en tirera les conséquences. Testez votre FEC à chaque clôture, pas à chaque avis de vérification.
Alternatives à DART pour les cas complexes
DART reste l'outil standard, mais il ne couvre pas tous les cas de figure. Trois alternatives méritent d'être mentionnées, sans recommandation de l'une sur l'autre — le choix dépend du contexte (volume, version SAP, ressources internes, budget).
Les solutions tierces certifiées SAP offrent une alternative clé en main. TJC Group (solution FEC 4.0, plus de 400 clients SAP, interface Fiori, compatible ECC6 à S/4HANA) et Applium (intégrateur spécialisé SAP, accompagnement projet FEC estimé entre 8 et 12 jours ouvrés) sont les acteurs les plus visibles sur ce segment.
Les approches data pour les très gros volumes répondent aux cas où DART échoue sur la volumétrie. Certaines entreprises utilisent des architectures BW + HANA pour extraire et transformer les données FEC, en contournant les limitations de performance de DART sur les bases dépassant 20 millions de lignes par exercice.
L'application Run Statutory Reports (S/4HANA Cloud) est l'alternative native SAP à DART pour les environnements cloud. Elle intègre la génération du FEC dans un workflow plus large de conformité réglementaire, avec une interface Fiori moderne.
Quand faire appel à un spécialiste
L'extraction du FEC depuis SAP n'est pas qu'un sujet de paramétrage technique. Chaque décision — le choix de la vue DART, le traitement du report à nouveau, la gestion des ruptures de séquence, la stratégie de migration — a des conséquences directes sur la conformité fiscale du fichier remis au vérificateur.
Trois situations justifient particulièrement un accompagnement spécialisé : la réception d'un avis de vérification alors que le FEC n'a jamais été testé, une migration ECC → S/4HANA en cours ou récente avec des exercices antérieurs non encore extraits, et la détection d'anomalies par Test Compta Demat sans capacité interne à en diagnostiquer l'origine.
Le lecteur doit retenir une règle simple : l'extraction du FEC est un acte à portée juridique, pas une tâche IT de routine. La qualité du fichier remis conditionne le déroulement du contrôle — et les risques financiers associés à un fichier non conforme dépassent très largement le coût d'un audit préventif.
Pour trouver un avocat spécialisé en fiscalité informatique capable d'auditer votre FEC et de vous accompagner en contrôle, consultez la rubrique juriste-fiscal.
