Le SAF-T (Standard Audit File for Tax) est un standard international défini par l’OCDE pour l’échange électronique de données comptables entre les entreprises et les administrations fiscales. Créé en 2005, révisé en 2010, il est resté longtemps discret. Plus maintenant. En 2026, une dizaine de pays européens l’imposent ou l’ont imposé, avec des calendriers qui se chevauchent, des formats nationaux qui divergent et des sanctions qui augmentent.
Pour les DAF, responsables comptables et DSI d’entreprises présentes dans plusieurs pays européens, la question est concrète : votre ERP sait-il exporter un fichier SAF-T conforme dans chaque juridiction où vous opérez ? Si la réponse est floue, ce guide vous donne le calendrier, les blocs de données à maîtriser et la méthode de paramétrage pour chaque éditeur majeur.
Qu’est-ce que le SAF-T et pourquoi il concerne votre ERP
Le standard OCDE : un format XML pour l’audit fiscal numérique
Le SAF-T est un fichier structuré en XML qui contient les données comptables et fiscales d’une entreprise dans un format lisible, standardisé et portable, indépendant du logiciel utilisé (EDICOM, What is SAF-T). L’OCDE a publié la première version en mai 2005, puis une version 2.0 en avril 2010 qui a étendu le périmètre aux stocks et aux immobilisations, et converti le format DTD en XML Schema (Wikipedia, SAF-T).
Le standard couvre cinq catégories de données :
- En-tête (Header) : identification du contribuable, période de reporting, version du schéma, détails du logiciel
- Fichiers maîtres (Master Files) : plan comptable, liste clients/fournisseurs, types de taxes, taux de TVA, données bancaires
- Grand livre et sous-livres : écritures de journal, factures, créances/dettes
- Stocks (Inventory) : mouvements d’inventaire (ajouté en v2.0)
- Immobilisations (Fixed Assets) : registre des actifs immobilisés (ajouté en v2.0)
L’objectif est de permettre aux administrations fiscales de réaliser des audits numériques plus rapides et plus fiables, en remplaçant les contrôles sur pièces par des analyses automatisées de données structurées.
Différence entre SAF-T et facturation électronique
Le SAF-T et la facturation électronique sont complémentaires, pas interchangeables. La facturation électronique (e-invoicing) concerne l’émission et la réception de factures individuelles dans un format structuré (UBL, CII, Factur-X). Le SAF-T concerne l’export en bloc de l’ensemble des données comptables, pas uniquement les factures, à destination de l’administration fiscale pour audit.
Un pays peut imposer les deux simultanément. La Pologne en est l’exemple le plus marquant : le système KSeF gère la facturation électronique en temps réel, tandis que les fichiers JPK (l’implémentation polonaise du SAF-T) couvrent les déclarations TVA, le grand livre, les immobilisations et les revenus (EDICOM, SAF-T Poland).
En France, le FEC (Fichier des Écritures Comptables) est souvent présenté comme le “cousin” du SAF-T. C’est historiquement juste : le FEC a été créé en réponse au standard OCDE de 2005. Mais le FEC est un format propriétaire français, limité aux écritures comptables, là où le SAF-T OCDE couvre un périmètre plus large incluant stocks et immobilisations (TJC Group, FEC).
Calendrier SAF-T pays par pays en Europe
Pays où le SAF-T est déjà en vigueur
Portugal (depuis 2008) : pays pionnier du SAF-T. Le fichier SAF-T (PT) doit être soumis mensuellement à l’Autoridade Tributária e Aduaneira, au plus tard le 5 du mois suivant la période de reporting. Le Portugal intègre progressivement le SAF-T avec son portail e-Fatura (Sovos, Portugal SAF-T). Les sanctions pour non-conformité sont significatives : les amendes pour défaut de facturation conforme vont de 150 à 3 750 € (PwC, Tax Penalties Portugal).
Norvège (depuis 2020) : le SAF-T Financial est obligatoire pour les entreprises dont le chiffre d’affaires dépasse 5 millions de NOK (environ 430 000 €). Le fichier est soumis sur demande de Skatteetaten lors d’un audit, pas de soumission périodique. La version 1.30 est requise depuis le 1er janvier 2025 (Skatteetaten, SAF-T Financial).
Lituanie (depuis 2020) : le SAF-T est obligatoire pour toutes les entreprises enregistrées à la TVA. Le fichier complet est produit sur demande de l’Inspection nationale des impôts (VMI). En parallèle, le système i.SAF impose une soumission mensuelle des données de factures (ventes et achats) avant le 20 du mois suivant (RTC Suite, SAF-T Lithuania).
Autriche (depuis 2009) : approche sur demande uniquement. L’administration fiscale (BMF) peut exiger un fichier SAF-T lors d’un contrôle fiscal. Le périmètre couvre le plan comptable, les données clients/fournisseurs, les écritures comptables et les immobilisations (Wikipedia, SAF-T).
Luxembourg (depuis 2013) : le FAIA (Fichier Audit Informatisé AED) est l’implémentation luxembourgeoise du SAF-T. Soumission sur demande de l’Administration de l’enregistrement et des domaines, typiquement lors d’un audit (RTC Suite, SAF-T Luxembourg).
Pologne (depuis 2016, étendu en continu) : le système JPK est l’un des plus complets d’Europe. Le JPK_VAT (déclaration TVA intégrée, fichiers JPK_V7M mensuel ou JPK_V7K trimestriel) est soumis au plus tard le 25 du mois suivant. Depuis 2026, le JPK_KR (grand livre) et le JPK_ST_KR (immobilisations) passent progressivement en soumission régulière, avec une extension à tous les contribuables au 31 décembre 2026 (Accace, JPK CIT Poland, VATupdate, Poland JPK).
Déploiements récents et à venir
Roumanie (depuis 2022, étendu en 2025) : le SAF-T roumain est soumis sous la forme de la déclaration D406. Après un déploiement par paliers (grandes entreprises en 2022, ETI en 2023), la soumission est obligatoire pour les PME et les non-résidents enregistrés à la TVA depuis le 1er janvier 2025. Soumission mensuelle ou trimestrielle selon le régime TVA. Les amendes pour non-dépôt vont de 1 000 à 5 000 RON (environ 200 à 1 000 €), et de 500 à 1 500 RON pour données incomplètes (Sovos, Romania SAF-T, Deloitte, SAF-T Romania).
Bulgarie (2026) : en cours de lancement. La Bulgarie prévoit une introduction progressive du SAF-T à partir de 2026, actuellement en phase de consultation technique (VATupdate, SAF-T countries overview).
Danemark (2023-2026) : le Danemark impose la tenue de comptabilité numérique par phases, selon le type d’entreprise et le chiffre d’affaires. L’adoption du SAF-T danois (basé sur la v2.0 OCDE) est effective depuis novembre 2022, avec des déploiements opérationnels progressifs jusqu’en 2026 (Wikipedia, SAF-T).
France : le FEC reste le standard national. Il ne s’agit pas à proprement parler d’un SAF-T au sens OCDE, mais d’un format d’export comptable imposé depuis 2014 lors de tout contrôle fiscal. Les entreprises françaises opérant dans des pays SAF-T doivent néanmoins gérer les deux formats en parallèle dans leur ERP.
Tableau comparatif
| Pays | Nom local | Depuis | Fréquence | Périmètre |
|---|---|---|---|---|
| Portugal | SAF-T (PT) | 2008 | Mensuelle | Toutes les entreprises |
| Norvège | SAF-T Financial | 2020 | Sur demande | CA > 5 M NOK |
| Lituanie | SAF-T + i.SAF | 2020 | Sur demande + mensuelle (i.SAF) | Assujettis TVA |
| Autriche | SAF-T AT | 2009 | Sur demande | Toutes les entreprises |
| Luxembourg | FAIA | 2013 | Sur demande | Entreprises au plan comptable normalisé |
| Pologne | JPK | 2016 | Mensuelle (JPK_VAT), progressive (JPK_KR) | Tous les contribuables |
| Roumanie | D406 | 2022 | Mensuelle/trimestrielle | Toutes catégories depuis 2025 |
| Danemark | SAF-T (DK) | 2022 | Progressive | Par paliers |
| Bulgarie | SAF-T (BG) | 2026 | À définir | En consultation |
| France | FEC | 2014 | Sur demande | Écritures comptables uniquement |
Ce que le SAF-T exige de votre ERP : les blocs de données
Écritures du grand livre (General Ledger Entries)
C’est le cœur du SAF-T. Chaque écriture comptable doit être exportable avec sa date, son libellé, les comptes débit et crédit, le montant, la devise, la référence au document source et l’identifiant de l’utilisateur qui l’a saisie. Le plan comptable local doit être mappé vers la taxonomie SAF-T du pays concerné.
Créances et dettes (Accounts Receivable / Payable)
Les factures clients et fournisseurs, les avoirs, les paiements et les ajustements doivent être traçables avec leur montant TTC, le détail de la TVA appliquée, les références croisées (numéro de commande, numéro de livraison) et les dates d’échéance.
Stocks (Inventory)
Pour les ERP avec gestion de stock, les mouvements d’inventaire (entrées, sorties, transferts inter-sites, ajustements) doivent être exportables avec les quantités, les valorisations et les références produits. Ce module est particulièrement scruté dans les secteurs industriel et distribution.
Mapping du plan comptable local vers la taxonomie SAF-T
C’est le piège le plus fréquent. Chaque pays a sa propre taxonomie SAF-T, qui peut diverger du plan comptable utilisé en interne. Le Portugal utilise le SNC (Sistema de Normalização Contabilística), la Pologne son propre cadre comptable, la Roumanie le plan OMFP. Un ERP qui ne maintient pas une table de correspondance entre le plan comptable interne et la taxonomie SAF-T locale de chaque juridiction produira un fichier rejeté à la validation.
Paramétrage ERP pour la conformité SAF-T : guide étape par étape
Vérifier la couverture native de votre éditeur
Tous les ERP ne sont pas égaux face au SAF-T.
SAP dispose d’un module natif, SAP DRC (Document and Reporting Compliance), qui prend en charge le SAF-T pour le Portugal, la Lituanie, la Norvège, la Pologne et la Roumanie. L’extraction des données et la soumission aux autorités fiscales sont automatisées dans SAP S/4HANA (SAP, Document and Reporting Compliance).
Microsoft Dynamics 365 Finance propose des modules de localisation SAF-T pour la Norvège, la Pologne et le Portugal, avec export XML natif. D’autres pays nécessitent des partenaires ISV (Microsoft Learn, SAF-T Norway).
Odoo et Sage n’intègrent pas de module SAF-T natif dans leur offre standard pour la plupart des pays. Des solutions tierces (Melasoft, TJC Group, SNI Technology) comblent le vide avec des connecteurs certifiés (Melasoft, SAF-T Compliance).
Recommandation : avant tout projet, posez la question à votre éditeur ou intégrateur : “Pour chaque pays où nous opérons, votre module SAF-T couvre-t-il la version courante du schéma XSD national, avec soumission directe ou export validé ?”
Configurer l’export XML conforme
Le schéma XSD de référence est celui publié par l’OCDE, mais chaque pays impose sa propre variante. Le SAF-T portugais n’a pas le même schéma que le JPK polonais, qui diffère lui-même du D406 roumain.
Étapes de configuration :
- Récupérer le schéma XSD officiel du pays cible (publié sur le site de l’administration fiscale)
- Mapper les champs ERP vers les champs XML du schéma national
- Configurer les règles de validation : certains champs sont conditionnels selon le type de transaction
- Tester l’export avec un jeu de données représentatif (transactions réelles anonymisées)
- Valider le fichier XML avec l’outil officiel du pays (quand il existe)
Tests de validation avec les outils des administrations fiscales
Plusieurs pays fournissent des outils de validation gratuits :
- Portugal : l’Autoridade Tributária propose un validateur en ligne sur le portail e-Fatura
- Norvège : Skatteetaten fournit une documentation XSD complète et des fichiers de test (Skatteetaten, SAF-T Financial)
- Pologne : le ministère des Finances publie les schémas JPK avec des exemples de fichiers conformes
- Roumanie : ANAF fournit un programme de validation D406 téléchargeable
Le test de validation doit être systématique : un fichier SAF-T qui “compile” localement mais échoue côté administration fiscale déclenche des demandes d’explication dans un délai contraint (20 jours en Roumanie, par exemple).
Automatiser la génération périodique
Selon le pays, la soumission est mensuelle, trimestrielle, annuelle ou sur demande. Deux approches :
- Pays à soumission périodique (Portugal, Pologne, Roumanie) : configurer un job planifié dans l’ERP qui génère le fichier SAF-T à J+1 après la clôture comptable de la période, le valide automatiquement et le stocke dans un répertoire sécurisé. La soumission peut être manuelle (portail web) ou automatisée via API quand elle existe.
- Pays à soumission sur demande (Norvège, Autriche, Luxembourg) : s’assurer que l’ERP peut générer un fichier conforme à tout moment, sur n’importe quelle période. Le processus doit être documenté et testé au moins une fois par an, sinon le jour du contrôle, personne ne sait faire tourner l’export.
Erreurs fréquentes et pièges à éviter
Plan comptable non mappé
C’est l’erreur la plus courante et la plus coûteuse. L’entreprise utilise son plan comptable interne (plan groupe, plan analytique personnalisé) sans avoir créé la table de correspondance vers la taxonomie SAF-T nationale. Résultat : le fichier XML est généré avec des codes comptables que l’administration fiscale ne reconnaît pas. Le fichier est rejeté.
Solution : créer et maintenir une table de mapping “plan comptable interne → plan SAF-T national” pour chaque juridiction. Tester ce mapping à chaque modification du plan comptable.
Données historiques incomplètes
Certains pays exigent des données sur plusieurs exercices. Si l’ERP a été migré récemment (changement d’éditeur, passage au cloud), les données historiques peuvent être partielles ou dans un format incompatible. Le Portugal, par exemple, peut demander un SAF-T couvrant les exercices antérieurs lors d’un audit.
Solution : lors de toute migration ERP, inclure explicitement la reprise des données historiques nécessaires au SAF-T dans le cahier des charges. Ne pas se contenter de migrer les soldes d’ouverture.
Confusion SAF-T, e-invoicing et FEC
Trois acronymes, trois périmètres différents :
- SAF-T : export global des données comptables pour audit fiscal
- E-invoicing : émission/réception de factures individuelles en temps réel
- FEC : format français d’export des écritures comptables (sous-ensemble du SAF-T)
Une entreprise française qui opère en Pologne et au Portugal doit gérer simultanément : le FEC pour la France, le JPK_VAT + JPK_KR pour la Pologne, le SAF-T (PT) pour le Portugal, et potentiellement le KSeF (facturation électronique) pour la Pologne et Chorus Pro/PDP pour la France. L’ERP doit être paramétré pour chaque combinaison pays/obligation.
Anticiper plutôt que subir
Le SAF-T n’est pas un projet informatique ponctuel, c’est une obligation récurrente qui s’inscrit dans la durée. Chaque nouveau pays qui adopte le standard, chaque mise à jour de schéma XSD, chaque révision de la taxonomie nationale génère un cycle de mise à jour dans l’ERP.
Les entreprises qui anticipent structurent leur approche autour de trois axes : un inventaire des juridictions SAF-T concernées, un audit de la couverture native de leur ERP pour chaque pays, et un processus de test/validation intégré à la clôture comptable.
Pour approfondir le sujet de la conformité fiscale numérique et de son impact sur les ERP, consultez notre calendrier complet de la facturation électronique en Europe, notre guide dédié au KSeF polonais et notre article sur la conformité RGPD dans les ERP.
Téléchargez notre grille d’évaluation ERP pour benchmarker la couverture SAF-T de vos éditeurs candidats sur 30 critères et 100 points.
