SAF-T (Standard Audit File for Tax) is an international standard defined by the OECD for electronic exchange of accounting data between companies and tax authorities. Created in 2005, revised in 2010, it remained largely under the radar for years. Not anymore. In 2026, a dozen European countries have implemented or are implementing SAF-T, with overlapping timelines, divergent national formats, and escalating penalties.
For CFOs, accounting managers, and IT directors of companies operating across multiple European countries, the question is concrete: does your ERP know how to export a compliant SAF-T file in each jurisdiction where you operate? If the answer is unclear, this guide provides you with the calendar, data blocks to master, and configuration methodology for each major vendor.
What is SAF-T and why it concerns your ERP
The OECD standard: XML format for digital tax auditing
SAF-T is an XML-structured file containing a company’s accounting and tax data in a readable, standardized, and portable format, independent of the software used (EDICOM, What is SAF-T). The OECD published the first version in May 2005, then version 2.0 in April 2010 which extended the scope to inventory and fixed assets, and converted the DTD format to XML Schema (Wikipedia, SAF-T).
The standard covers five data categories:
- Header: taxpayer identification, reporting period, schema version, software details
- Master Files: chart of accounts, customer/supplier lists, tax types, VAT rates, bank data
- General Ledger and Sub-ledgers: journal entries, invoices, receivables/payables
- Inventory: inventory movements (added in v2.0)
- Fixed Assets: fixed asset register (added in v2.0)
The objective is to enable tax authorities to conduct faster and more reliable digital audits, replacing paper-based controls with automated analysis of structured data.
Difference between SAF-T and electronic invoicing
SAF-T and electronic invoicing are complementary, not interchangeable. Electronic invoicing (e-invoicing) concerns the issuance and receipt of individual invoices in a structured format (UBL, CII, Factur-X). SAF-T concerns bulk export of all accounting data, not just invoices, intended for tax authorities for audit purposes.
A country can impose both simultaneously. Poland is the most striking example: the KSeF system manages real-time electronic invoicing, while JPK files (Poland’s SAF-T implementation) cover VAT returns, general ledger, fixed assets, and income (EDICOM, SAF-T Poland).
In France, the FEC (Fichier des Écritures Comptables) is often presented as the “cousin” of SAF-T. This is historically accurate: the FEC was created in response to the 2005 OECD standard. But the FEC is a French proprietary format, limited to accounting entries, whereas OECD SAF-T covers a broader scope including inventory and fixed assets (TJC Group, FEC).
Country-by-country SAF-T calendar in Europe
Countries where SAF-T is already in force
Portugal (since 2008): SAF-T pioneer country. The SAF-T (PT) file must be submitted monthly to the Autoridade Tributária e Aduaneira, no later than the 5th of the month following the reporting period. Portugal progressively integrates SAF-T with its e-Fatura portal (Sovos, Portugal SAF-T). Penalties for non-compliance are significant: fines for non-compliant invoicing range from €150 to €3,750 (PwC, Tax Penalties Portugal).
Norway (since 2020): SAF-T Financial is mandatory for companies with turnover exceeding 5 million NOK (approximately €430,000). The file is submitted on request from Skatteetaten during an audit, not periodic submission. Version 1.30 has been required since January 1, 2025 (Skatteetaten, SAF-T Financial).
Lithuania (since 2020): SAF-T is mandatory for all VAT-registered companies. The complete file is produced on request from the State Tax Inspectorate (VMI). In parallel, the i.SAF system requires monthly submission of invoice data (sales and purchases) before the 20th of the following month (RTC Suite, SAF-T Lithuania).
Austria (since 2009): on-demand approach only. The tax administration (BMF) can require a SAF-T file during a tax audit. The scope covers chart of accounts, customer/supplier data, accounting entries, and fixed assets (Wikipedia, SAF-T).
Luxembourg (since 2013): FAIA (Fichier Audit Informatisé AED) is Luxembourg’s SAF-T implementation. Submission on request from the Administration de l’enregistrement et des domaines, typically during an audit (RTC Suite, SAF-T Luxembourg).
Poland (since 2016, continuously extended): The JPK system is one of Europe’s most comprehensive. JPK_VAT (integrated VAT return, monthly JPK_V7M or quarterly JPK_V7K files) is submitted no later than the 25th of the following month. Since 2026, JPK_KR (general ledger) and JPK_ST_KR (fixed assets) are progressively moving to regular submission, with extension to all taxpayers by December 31, 2026 (Accace, JPK CIT Poland, VATupdate, Poland JPK).
Recent and upcoming deployments
Romania (since 2022, extended in 2025): Romanian SAF-T is submitted as declaration D406. After a phased rollout (large companies in 2022, mid-size in 2023), submission has been mandatory for SMEs and VAT-registered non-residents since January 1, 2025. Monthly or quarterly submission depending on VAT regime. Fines for non-filing range from 1,000 to 5,000 RON (approximately €200 to €1,000), and 500 to 1,500 RON for incomplete data (Sovos, Romania SAF-T, Deloitte, SAF-T Romania).
Bulgaria (2026): launch in progress. Bulgaria plans progressive SAF-T introduction from 2026, currently in technical consultation phase (VATupdate, SAF-T countries overview).
Denmark (2023-2026): Denmark requires digital accounting by phases, according to company type and turnover. Danish SAF-T adoption (based on OECD v2.0) has been effective since November 2022, with progressive operational deployments until 2026 (Wikipedia, SAF-T).
France: FEC remains the national standard. This is not strictly speaking an OECD SAF-T, but an accounting export format required since 2014 during any tax audit. French companies operating in SAF-T countries must nevertheless manage both formats in parallel in their ERP.
Comparison table
| Country | Local name | Since | Frequency | Scope |
|---|---|---|---|---|
| Portugal | SAF-T (PT) | 2008 | Monthly | All companies |
| Norway | SAF-T Financial | 2020 | On demand | Turnover > 5M NOK |
| Lithuania | SAF-T + i.SAF | 2020 | On demand + monthly (i.SAF) | VAT-registered |
| Austria | SAF-T AT | 2009 | On demand | All companies |
| Luxembourg | FAIA | 2013 | On demand | Standard chart of accounts companies |
| Poland | JPK | 2016 | Monthly (JPK_VAT), progressive (JPK_KR) | All taxpayers |
| Romania | D406 | 2022 | Monthly/quarterly | All categories since 2025 |
| Denmark | SAF-T (DK) | 2022 | Progressive | By phases |
| Bulgaria | SAF-T (BG) | 2026 | TBD | Under consultation |
| France | FEC | 2014 | On demand | Accounting entries only |
What SAF-T requires from your ERP: data blocks
General Ledger Entries
This is the heart of SAF-T. Each accounting entry must be exportable with its date, description, debit and credit accounts, amount, currency, reference to source document, and identifier of the user who entered it. The local chart of accounts must be mapped to the SAF-T taxonomy of the relevant country.
Accounts Receivable / Payable
Customer and supplier invoices, credit notes, payments, and adjustments must be traceable with their gross amount, applied VAT details, cross-references (order number, delivery number), and due dates.
Inventory
For ERPs with inventory management, inventory movements (receipts, issues, inter-site transfers, adjustments) must be exportable with quantities, valuations, and product references. This module is particularly scrutinized in industrial and distribution sectors.
Local chart of accounts mapping to SAF-T taxonomy
This is the most frequent trap. Each country has its own SAF-T taxonomy, which may differ from the internally used chart of accounts. Portugal uses the SNC (Sistema de Normalização Contabilística), Poland its own accounting framework, Romania the OMFP plan. An ERP that doesn’t maintain a correspondence table between the internal chart of accounts and the local SAF-T taxonomy of each jurisdiction will produce a file rejected at validation.
ERP configuration for SAF-T compliance: step-by-step guide
Check your vendor’s native coverage
Not all ERPs are equal when facing SAF-T.
SAP has a native module, SAP DRC (Document and Reporting Compliance), which supports SAF-T for Portugal, Lithuania, Norway, Poland, and Romania. Data extraction and submission to tax authorities are automated in SAP S/4HANA (SAP, Document and Reporting Compliance).
Microsoft Dynamics 365 Finance offers SAF-T localization modules for Norway, Poland, and Portugal, with native XML export. Other countries require ISV partners (Microsoft Learn, SAF-T Norway).
Sage UK and Odoo don’t integrate native SAF-T modules in their standard offering for most countries. Third-party solutions (Melasoft, TJC Group, SNI Technology) fill the gap with certified connectors (Melasoft, SAF-T Compliance).
Recommendation: before any project, ask your vendor or integrator: “For each country where we operate, does your SAF-T module cover the current version of the national XSD schema, with direct submission or validated export?”
Configure compliant XML export
The reference XSD schema is published by the OECD, but each country imposes its own variant. Portuguese SAF-T doesn’t have the same schema as Polish JPK, which differs from Romanian D406.
Configuration steps:
- Get the official XSD schema from the target country (published on the tax authority’s website)
- Map ERP fields to XML fields of the national schema
- Configure validation rules: some fields are conditional depending on transaction type
- Test export with representative dataset (anonymized real transactions)
- Validate XML file with the country’s official tool (when available)
Validation tests with tax administration tools
Several countries provide free validation tools:
- Portugal: Autoridade Tributária offers an online validator on the e-Fatura portal
- Norway: Skatteetaten provides complete XSD documentation and test files (Skatteetaten, SAF-T Financial)
- Poland: Ministry of Finance publishes JPK schemas with compliant file examples
- Romania: ANAF provides a downloadable D406 validation program
Validation testing must be systematic: a SAF-T file that “compiles” locally but fails at the tax authority triggers explanation requests within a constrained timeframe (20 days in Romania, for example).
Automate periodic generation
Depending on the country, submission is monthly, quarterly, annual, or on demand. Two approaches:
- Countries with periodic submission (Portugal, Poland, Romania): configure a scheduled job in the ERP that generates the SAF-T file at D+1 after accounting period close, automatically validates it, and stores it in a secure directory. Submission can be manual (web portal) or automated via API when available.
- Countries with on-demand submission (Norway, Austria, Luxembourg): ensure the ERP can generate a compliant file at any time, for any period. The process must be documented and tested at least once a year, otherwise on audit day, nobody knows how to run the export.
Common errors and pitfalls to avoid
Unmapped chart of accounts
This is the most common and costliest error. The company uses its internal chart of accounts (group plan, customized analytical plan) without creating the correspondence table to the national SAF-T taxonomy. Result: the XML file is generated with accounting codes that the tax authority doesn’t recognize. The file is rejected.
Solution: create and maintain a mapping table “internal chart of accounts → national SAF-T plan” for each jurisdiction. Test this mapping with each chart of accounts modification.
Incomplete historical data
Some countries require data over several fiscal years. If the ERP was recently migrated (vendor change, cloud migration), historical data may be partial or in an incompatible format. Portugal, for example, may request a SAF-T covering previous fiscal years during an audit.
Solution: during any ERP migration, explicitly include historical data recovery necessary for SAF-T in the specifications. Don’t settle for migrating opening balances only.
Confusion between SAF-T, e-invoicing, and FEC
Three acronyms, three different scopes:
- SAF-T: global export of accounting data for tax audit
- E-invoicing: real-time issuance/receipt of individual invoices
- FEC: French accounting entries export format (SAF-T subset)
A French company operating in Poland and Portugal must simultaneously manage: FEC for France, JPK_VAT + JPK_KR for Poland, SAF-T (PT) for Portugal, and potentially KSeF (electronic invoicing) for Poland and Chorus Pro/PDP for France. The ERP must be configured for each country/obligation combination.
Anticipate rather than endure
SAF-T is not a one-time IT project; it’s a recurring obligation that extends over time. Each new country adopting the standard, each XSD schema update, each national taxonomy revision generates an update cycle in the ERP.
Companies that anticipate structure their approach around three axes: an inventory of concerned SAF-T jurisdictions, an audit of their ERP’s native coverage for each country, and a test/validation process integrated into accounting close.
To deepen the subject of digital tax compliance and its impact on ERPs, consult our complete European electronic invoicing calendar, our dedicated guide to Polish KSeF, and our article on GDPR compliance in ERPs.
Download our ERP evaluation grid to benchmark your candidate vendors’ SAF-T coverage on 30 criteria and 100 points.
