Votre entreprise utilise un ERP Oracle et un contrôle fiscal s'annonce. Première question du vérificateur : où est le FEC ? Sous l'appellation « Oracle Cloud » coexistent en réalité trois univers ERP distincts — NetSuite, E-Business Suite et Fusion Cloud — et chacun traite l'extraction du FEC de manière radicalement différente. L'un dispose d'un module natif, l'autre d'un programme dédié en fin de vie, le troisième… n'a rien de prévu. Ce guide détaille les procédures, les prérequis et les pièges à éviter pour chaque brique de l'écosystème Oracle. Pour une vue d'ensemble des ERP et de leurs capacités FEC, consultez notre panorama complet de l'extraction FEC par ERP.
Périmètre de cet article : Oracle NetSuite, Oracle E-Business Suite (EBS R12) et Oracle Fusion Cloud ERP. PeopleSoft et JD Edwards ne sont pas traités ici.
Trois produits Oracle, trois réalités FEC
Avant de plonger dans les procédures, posons la cartographie. Oracle NetSuite est un ERP cloud natif, racheté par Oracle en 2016, qui cible les PME et ETI. Il dispose d'un module FEC natif — le France Localization SuiteApp — intégré au Tax Reporting Framework. C'est la brique Oracle la plus mature sur le sujet.
Oracle E-Business Suite (EBS) est l'ERP historique on-premise, souvent migré vers Oracle Cloud Infrastructure (OCI). Un programme dédié, le French Accounting Entries Audit File, génère le FEC via BI Publisher. Le support de la version 12.1 a pris fin en décembre 2021, et de nombreuses entreprises migrent vers Fusion Cloud.
Oracle Fusion Cloud ERP est la plateforme SaaS de nouvelle génération, destinée aux grands groupes. Elle ne dispose pas à ce jour d'un module de localisation France dédié au FEC. L'extraction repose sur la configuration de Secondary Ledgers et sur des outils de reporting génériques (BI Publisher, OTBI). C'est le cas le plus complexe et le plus risqué.
NetSuite : extraction FEC via le France Localization SuiteApp
Prérequis
L'extraction FEC depuis NetSuite exige une configuration préalable rigoureuse :
- Installer le Tax Reporting Framework SuiteApp et le France Localization SuiteApp. Vérifier la version à jour via Setup > France Localization > France Localization Overview. Depuis janvier 2023, l'ancien Tax Audit Files SuiteApp n'est plus supporté pour la génération des FEC — seul le France Localization SuiteApp est maintenu.
- Activer le GL Audit Numbering (Setup > Company > Enable Features > Accounting) et configurer une séquence de numérotation. La numérotation doit être croissante dans le temps et sans rupture, conformément au BOI-CF-IOR-60-40-20, §100. Configurer le type « Permanent » et la récurrence « Hourly / 24h » pour garantir une numérotation cohérente.
- Activer les numéros de compte (Setup > Accounting > Accounting Preferences > Use Account Numbers) et configurer un plan comptable conforme au PCG français. Pour les entités OneWorld, utiliser le Statutory Chart of Accounts ou un Accounting Context dédié.
- Configurer les préférences FEC (Setup > France Localization > Preferences) : vérifier les options sur l'onglet FEC Configuration, notamment l'utilisation du Customer/Vendor ID pour CompAuxNum, et les saved searches de conformité.
- Si nécessaire, configurer les Period End Journal Entries pour les écritures d'ouverture et de clôture : activation sur la fiche subsidiary, configuration des comptes de bilan (120/129), paramétrage des préférences Tax Audit Files Filters.
Procédure de génération
La génération du FEC NetSuite passe par le menu Reports > Tax > Country Tax Reports. Sélectionner la subsidiary France — le nexus France se remplit automatiquement. Si une fenêtre de confirmation des préférences apparaît, valider les paramètres (fréquence annuelle pour le FEC Data Extract). Sélectionner le rapport « FEC Data Extract » ou « FEC Lettrage Report ». En cas de Multi-Book Accounting, sélectionner le livre comptable approprié. Un Accounting Context peut être sélectionné pour appliquer un plan comptable localisé aux champs CompteNum et CompteLib.
Renseigner la période (Start Date / End Date couvrant l'exercice fiscal complet), puis cliquer sur Generate. Le fichier est généré en arrière-plan ; une notification par email confirme la disponibilité du fichier.
Convention de nommage : le fichier généré respecte le format réglementaire [SIREN]FEC[AAAAMMJJ].txt, où le SIREN correspond aux 9 derniers chiffres du numéro de TVA intracommunautaire et AAAAMMJJ au dernier jour de l'exercice. Le rapport de lettrage ajoute le suffixe _lettrage au nom du fichier.Mapping des 18 champs et points de vigilance
Le France Localization SuiteApp mappe automatiquement les 18 champs réglementaires du FEC. Pour une explication détaillée de chacun de ces champs, reportez-vous à notre article sur la structure technique du FEC et ses 18 champs obligatoires. Voici les points de vigilance spécifiques à NetSuite :
- EcritureNum : alimenté par le GL Number (onglet GL Impact). Si le GL Audit Numbering n'a pas été exécuté, la génération échoue purement et simplement. Vérifier systématiquement que le batch de numérotation a tourné avant de lancer l'extraction.
- EcritureDate : selon la configuration, NetSuite peut utiliser la Transaction Date ou la GL# Date. Si un workflow d'approbation est en place, la date de transaction peut différer de la date de posting, créant une incohérence avec EcritureNum.
- CompteNum / CompteLib : les valeurs dépendent de l'Accounting Context sélectionné à la génération. Vérifier que le plan comptable est conforme au PCG.
- CompAuxNum / CompAuxLib : alimentés par le Customer ID ou Vendor ID pour les comptes de type A/P ou A/R. Vides pour les autres comptes. La configuration se règle sur la page France Localization (option « Use Customer/Vendor ID for FEC CompAuxNum Field »).
- PieceRef : peut contenir la valeur « N/A » si aucune pièce justificative n'est référencée — une valeur suspecte pour le vérificateur. S'assurer que les documents sont correctement référencés dans NetSuite.
- ValidDate : attention, il ne s'agit pas de la date de validation comptable au sens du PCG, mais de la date d'exécution du GL Audit Numbering. Le fuseau horaire de la subsidiary est utilisé.
- EcritureLet / DateLet : ces deux champs sont systématiquement vides dans le FEC Data Extract. Le lettrage est restitué dans un fichier séparé, le FEC Lettrage Report. Le vérificateur, habitué aux FEC issus de logiciels français, peut s'interroger. Préparer une explication et fournir le rapport de lettrage en complément.
Alerte : transactions annulées. Les transactions annulées (voided) sans activation de la préférence « Void Transactions Using Reversing Journals » sont mises à zéro et incluses dans le FEC. Elles génèrent des lignes à montant nul qui attirent l'attention du vérificateur. Activer les reversing journals pour éviter ce problème.
<!-- CTA_MILIEU : Vous migrez vers Oracle Fusion Cloud et vous interrogez sur la conformité de votre FEC ? Faites auditer votre configuration par un avocat spécialisé en fiscalité informatique. -->
Oracle E-Business Suite (R12) : le programme French Accounting Entries Audit File
EBS dispose d'un programme concurrent dédié, le French Accounting Entries Audit File, qui génère un fichier CSV/TXT contenant les 18 champs réglementaires via BI Publisher et un template RTF au format DVNI.
Les prérequis essentiels sont l'activation de l'Accounting Sequencing pour assurer la numérotation chronologique par date de validation (EcritureNum), le paramétrage d'un plan comptable conforme au PCG, et l'exclusion des comptes hors bilan (classes 8 et 9). Le programme extrait toutes les écritures comptables détaillées — non centralisées — issues de l'ensemble des modules (AP, AR, FA, Inventory, Payroll, GL). Les écritures d'ouverture doivent figurer en première position du fichier.
Point critique : le programme extrait les données depuis le GL et les subledgers. Les écritures centralisées (agrégées) doivent être exclues au profit des écritures détaillées issues des modules métier, conformément au BOI-CF-IOR-60-40-20, §60-65. La numérotation séquentielle doit être vérifiée — elle ne tolère aucune rupture.
Le support d'EBS 12.1 a pris fin en décembre 2021. De nombreuses entreprises migrent vers Fusion Cloud ou hébergent EBS sur OCI. La capacité à produire un FEC depuis EBS reste néanmoins indispensable pour les exercices antérieurs à la migration.
Oracle Fusion Cloud ERP : l'angle mort du FEC
C'est le point central de cet article. À ce jour, Oracle Fusion Cloud ERP ne dispose d'aucun module de localisation France dédié à la génération du FEC, contrairement à NetSuite (France Localization SuiteApp) ou EBS (French Accounting Entries Audit File). L'absence de ce module est un angle mort souvent découvert trop tard dans les projets de migration.
La solution : un Secondary Ledger configuré au bon niveau
La réponse technique passe par la configuration d'un Secondary Ledger dédié à la comptabilité statutaire française (PCG), distinct du Primary Ledger — souvent tenu en normes IFRS ou US GAAP pour les groupes internationaux. Ce Secondary Ledger porte son propre plan comptable (COA mapping), sa devise (EUR), et sa méthode comptable.
Le choix déterminant intervient lors de la configuration du niveau de réplication des données depuis le Primary Ledger. Deux options s'affrontent :
Journal Level : réplique uniquement les écritures GL agrégées. Plus simple à maintenir, mais ne porte pas le détail des transactions sous-jacentes — numéros de factures, noms des fournisseurs et clients, références de paiement. Or, le BOI-CF-IOR-60-40-20 (§60 et suivants) exige que le FEC contienne toutes les écritures comptables retracées, hors écritures de centralisation. Un FEC sans détail subledger expose l'entreprise à un risque de non-conformité.
Subledger Level : réplique l'intégralité du détail transactionnel, c'est-à-dire les écritures générées par le processus Create Accounting d'Oracle Fusion pour chaque module (AP, AR, FA, Projects…). Cette option préserve la piste d'audit exigée par l'article 911-3 du PCG et permet de produire un FEC conforme avec des écritures ligne par ligne.
Recommandation : privilégier le Subledger Level malgré sa complexité de mise en œuvre. L'exception « application métier » du BOI-CF-IOR-60-40-20 (§65), qui autorise la centralisation lorsque le détail est dans une application métier autonome, ne s'applique probablement pas aux subledgers intégrés d'Oracle Fusion (AP, AR, FA…). Ces modules sont des composantes du système comptable général, pas des applications métier autonomes au sens de la doctrine.
Exemple terrain : le choix Subledger Level vs. Journal Level
Une entreprise internationale sous Oracle EBS prépare sa migration vers Fusion Cloud. L'équipe IT, soucieuse de simplifier la maintenance, penche pour le Journal Level. L'analyse fiscale révèle le risque : au Journal Level, le Secondary Ledger ne contient que les écritures GL agrégées, sans le détail des transactions sous-jacentes. En cas de demande de drill-down par le vérificateur, l'entreprise serait dans l'incapacité de fournir les pièces attendues. Le cabinet recommande le Subledger Level. La complexité de mise en œuvre est supérieure, mais le risque de conformité est significativement réduit. L'entreprise intègre cette recommandation dans son cahier des charges Fusion.
L'enseignement est clair : le sujet FEC doit être adressé dès la phase de design de l'implémentation Fusion, pas en aval. Le choix du niveau de réplication du Secondary Ledger a un impact direct sur la capacité à produire un FEC conforme.
Extraction effective
Une fois le Secondary Ledger configuré au bon niveau, l'extraction s'appuie sur BI Publisher (template custom au format FEC) ou sur OTBI (Oracle Transactional BI) pour générer le fichier. Il n'y a pas de bouton « Générer FEC » comme dans NetSuite — c'est un développement spécifique à chaque implémentation. Prévoir ce sujet dès le cahier des charges de la migration et documenter la solution retenue dans la notice descriptive accompagnant le FEC (recommandée par le BOI-CF-IOR-60-40-20, §390).
Conservation des données lors de la migration vers Fusion Cloud
La migration vers Fusion Cloud soulève une question critique : que deviennent les FEC des exercices antérieurs ? L'article L. 102 B du LPF impose une conservation de 6 ans minimum (dont 3 ans sur support informatique d'origine). L'article L. 123-22 du Code de commerce étend cette obligation à 10 ans à compter de la clôture de l'exercice.
Lors du décommissionnement d'EBS, l'entreprise doit pouvoir produire un FEC conforme pour tous les exercices encore dans le délai de conservation — potentiellement les 6 à 10 derniers exercices. Le FEC seul ne suffit pas : les pièces justificatives (factures, relevés bancaires, contrats) doivent aussi rester accessibles et exploitables.
Les solutions pratiques sont les suivantes : générer et archiver les FEC pour chaque exercice avant le décommissionnement ; maintenir un environnement EBS en lecture seule sur OCI ; utiliser la solution EBS Archival sur Oracle Autonomous Data Warehouse (ADW) avec les rapports pré-construits ; vérifier que les données migrées vers Fusion couvrent la fenêtre de 10 ans.
Au-delà de la conservation comptable et fiscale, anticiper la transition des données de gestion (analytique, centres de coûts, projets). La question clé : comment le plan comptable statutaire français (PCG) sera-t-il mappé dans la structure COA de Fusion, et les dimensions analytiques actuelles seront-elles préservées ?
Points de vigilance communs aux trois produits Oracle
Quel que soit le produit Oracle utilisé, les mêmes anomalies reviennent lors de l'analyse du FEC. Pour un traitement exhaustif de ces anomalies, consultez notre article sur les 10 anomalies les plus fréquentes dans un FEC.
- Numérotation EcritureNum : doit être croissante et sans rupture. Dans NetSuite, elle dépend du GL Audit Numbering. Dans EBS, de l'Accounting Sequencing. Dans Fusion, du paramétrage du Document Sequencing sur le Secondary Ledger.
- Cohérence des dates : vérifier la cohérence entre EcritureDate, PieceDate et ValidDate. Les workflows d'approbation créent des écarts entre la date de transaction et la date de posting.
- Lettrage (EcritureLet) : dans NetSuite, le champ est systématiquement vide dans le FEC Data Extract. Le lettrage est dans un rapport séparé. Le vérificateur peut le demander — s'assurer de pouvoir fournir le FEC Lettrage Report.
- Séparateurs et formats : l'administration attend un séparateur de champs par pipe (|) ou tabulation, et une virgule comme séparateur décimal. Vérifier le format de sortie.
- Plan comptable : doit être conforme au PCG. Pour les filiales françaises de groupes internationaux, c'est le plan du Secondary Ledger (ou l'Accounting Context dans NetSuite) qui doit être conforme — pas celui du Primary Ledger IFRS.
- Test obligatoire : avant toute remise, tester le fichier avec l'outil Test Compta Demat mis à disposition par la DGFiP.
Checklist de conformité FEC — écosystème Oracle
Avant de remettre votre FEC au vérificateur, vérifiez ces points essentiels :
- ☐ Le fichier respecte le format réglementaire (18 champs, encodage UTF-8, séparateur pipe ou tabulation)
- ☐ Le nommage suit la convention [SIREN]FEC[AAAAMMJJ].txt
- ☐ La numérotation EcritureNum est séquentielle, croissante et sans rupture
- ☐ Le plan comptable est conforme au PCG (pas au référentiel IFRS du Primary Ledger)
- ☐ Le lettrage est disponible (même dans un fichier séparé pour NetSuite)
- ☐ La notice descriptive du FEC est à jour et mentionne les particularités de l'ERP
- ☐ Le fichier a été testé avec l'outil Test Compta Demat de la DGFiP
Le défaut de présentation du FEC expose l'entreprise à une amende de 5 000 € minimum par exercice (article 1729 D du CGI), ou à une majoration de 10 % des droits rappelés si ce montant est supérieur. Pour les erreurs FEC les plus fréquentes par ERP, consultez notre tableau comparatif dédié. Et si votre configuration Oracle présente des particularités non couvertes par ce guide, n'hésitez pas à consulter un avocat spécialisé en fiscalité informatique.
<!– CTA_FIN : Créer une mission en fiscalité informatique -->
