What is SAF-T? How to Validate Your Files Before a Tax Audit

SAF-T (Standard Audit File for Taxation) is an XML-based format developed by the OECD for exchanging accounting data between businesses and tax authorities. It provides a standardised way for tax inspectors to access financial records electronically, replacing manual document requests with structured, machine-readable files. Since the OECD first published the standard in 2005, over a dozen countries have adopted it, each with their own local requirements.

This FAQ covers the questions that finance teams and CFOs most commonly ask about SAF-T: what the file contains, which countries require it, how long you have to respond, whether your ERP is ready, and how to validate files before they reach the tax authority.

Frequently Asked Questions

What does a SAF-T file contain?

A SAF-T file is an XML export of your accounting data. The OECD base standard defines four main sections: a header (company identification, fiscal year, reporting period, software), master files (chart of accounts, customers, suppliers, tax codes, products), general ledger entries (journal entries with account references and amounts), and source documents (sales invoices, purchase invoices, payments, goods movements, and asset transactions).

Each country defines which sections are mandatory and may add fields specific to their tax system. For example, Luxembourg’s FAIA requires French-language account type labels (Actif, Passif, Produit, Charge), while Poland’s JPK splits SAF-T into multiple file types for VAT, corporate income tax, and accounting books.

Which countries require SAF-T?

As of 2026, the following countries have active SAF-T mandates or are in the process of launching them:

Denmark is developing SAF-T 2.0 under its new Bookkeeping Act. For a detailed breakdown of each country’s requirements, see our SAF-T adoption across Europe overview.

How much time do I have to respond to a SAF-T request?

Response windows vary significantly by country. Some specify a fixed statutory deadline; others leave it to the tax authority’s discretion.

Can my ERP generate compliant SAF-T files?

ERP readiness is the single biggest compliance challenge for most businesses. Having a SAF-T export function in your ERP does not guarantee that the output is compliant with your country’s specific requirements. Many ERP systems ship with a generic SAF-T template that needs configuration for local code lists, tax codes, and field mappings.

• •Check with your vendor: Ask whether your ERP has a native SAF-T export for your specific country. A generic OECD export is not sufficient.
• •Verify country-specific code lists: Each country defines its own tax codes, account type classifications, and currency requirements. For Luxembourg, this means TVA codes (TVA-NOR, TVA-INT, TVA-RED, TVA-SPR) and French account type labels (Actif, Passif, Produit, Charge).
• •Test with a real period’s data: Export a full month or quarter and validate the result. Test data often passes where real data fails, because it lacks edge cases such as credit notes, foreign-currency transactions, or archived customer records.
• •Confirm performance for high-volume months: Large files (above 25 MB) can expose issues that do not appear with smaller exports: memory limits, truncated records, and timeout errors.

Romania’s SAF-T pilot programme has produced useful lessons on ERP readiness across different accounting systems. See our guide to the Romania SAF-T pilot for details.

What if I operate in multiple SAF-T countries?

Each country has its own XML schema, code lists, submission channel, and reporting frequency. A single ERP configuration is rarely sufficient to cover multiple jurisdictions.

• •Schema differences: Luxembourg FAIA v2.01 and Portugal SAF-T PT use different XML structures, even though both derive from the OECD template. Field names, mandatory elements, and nesting rules differ.
• •Code list conflicts: Tax codes valid in one country are rejected in another. Your ERP must map to the correct local codes per entity or VAT registration.
• •Submission channels: Some countries accept files via a web portal, others via API, and some via encrypted email. Each channel has its own authentication and format requirements.
• •Frequency mismatches: Portugal and Lithuania require monthly submissions, while Luxembourg and Austria are on-demand only. Your reporting calendar must account for each jurisdiction separately.

The EU’s ViDA (VAT in the Digital Age) initiative aims to harmonise digital reporting across member states, which may reduce fragmentation over time. For a current overview, see our SAF-T adoption across Europe overview.

Do I need SAF-T if my country already requires e-invoicing?

Yes, in most cases. SAF-T and e-invoicing serve different purposes and are not interchangeable:

• •E-invoicing covers the structured exchange of individual invoices between trading partners (B2B) or between businesses and the tax authority (B2G). It focuses on transaction-level data.
• •SAF-T is a broader accounting extract that includes the full general ledger, master data (chart of accounts, customers, suppliers), and all transaction types, not just invoices.

Several countries require both. Poland mandates KSeF (e-invoicing) alongside JPK (SAF-T). Romania requires RO e-Invoice for B2B transactions and D406 (SAF-T) for comprehensive accounting data. France is introducing mandatory e-invoicing from September 2026 while the FEC (its SAF-T equivalent) remains a separate on-demand obligation.

The EU’s ViDA initiative will further expand digital reporting requirements. For more on how these obligations interact, see our guide to e-reporting and digital tax.

What happens if my SAF-T file is rejected during an audit?

Consequences vary by country but typically include:

• •Delays: The audit cannot proceed until a compliant file is provided. This extends the audit timeline and increases the administrative burden on your finance team.
• •Fines: Some countries impose penalties for late or non-compliant submissions. Bulgaria fines range from BGN 500 to BGN 15,000. Mozambique locks the taxpayer’s account for 5 days, blocking invoicing and imports.
• •Increased scrutiny: Repeated file rejections may trigger more intensive audits or follow-up investigations.

What are the most common SAF-T file errors?

Based on common validation patterns across SAF-T implementations, these errors appear most frequently:

• •Missing master data references: Transactions reference customers, suppliers, or accounts that do not exist in the master data section of the file.
• •Invalid tax codes: Tax codes that do not match the country’s official code list. In Luxembourg, this means using codes other than the TVA- prefix convention.
• •Incorrect date formats: Dates not in YYYY-MM-DD (ISO 8601) format. Regional date formats such as DD/MM/YYYY or MM/DD/YYYY cause immediate rejection.
• •Schema validation failures: Missing required fields, elements in the wrong order, or incorrect data types. These are structural errors that prevent the file from being parsed.
• •Decimal precision: Tax rates and monetary values without the required number of decimal places (typically two).

The FAIA Validator categorises each error by severity (critical, important, or warning) and provides specific guidance on how to fix it, so finance teams can prioritise the issues that will cause file rejection before addressing lower-severity warnings. For Luxembourg-specific examples, see our guide to common FAIA validation errors and how to fix them.

How can I validate my SAF-T files before a tax audit?

Pre-audit validation means checking your SAF-T files regularly rather than waiting for a tax authority request. There are three levels of validation to consider:

1. Schema validation (structure checks)

This checks whether your file conforms to the XML Schema Definition (XSD) published by the relevant tax authority. It catches missing required fields, incorrect element ordering, wrong data types, and namespace errors. Schema validation can run locally without sending any data to a server.

2. Business rule validation

This checks country-specific rules that go beyond the XML structure. Examples include verifying that tax codes match the country’s official code list, that account type labels use the correct language, that tax rates fall within valid ranges, and that monetary values have the correct decimal precision.

3. Cross-reference validation

This checks the internal consistency of the file. Every customer, supplier, and account referenced in a transaction must exist in the master data section. Opening and closing balances must reconcile with transaction totals. Invoice references must match across related documents.

The FAIA Validator covers all three levels in a single tool. Schema checks run instantly in the browser using WebAssembly, with results in seconds. Business rules and cross-reference checks provide detailed line-number references for each error and visual charts showing error distribution by category and severity, making it straightforward to identify patterns and prioritise fixes.

Can I validate SAF-T files without uploading them?

Yes. SAF-T files contain sensitive financial data including customer records, supplier details, transaction amounts, and full general ledger entries. Uploading them to third-party servers creates data protection risks.

The FAIA Validator runs schema validation entirely in your browser. Your file is read locally and never uploaded. This approach offers several practical advantages:

• •No file size limits for client-side schema checks, since the processing happens locally on your device
• •Works offline once the page has loaded, so you can validate files without an internet connection
• •No GDPR data processing agreement needed for local validation, since no personal data is transmitted to a third party
• •Instant results with no upload wait time, even for large files

For deeper checks (business rules and cross-references), data is transmitted securely and processed in memory only, with no file content stored. For more on this approach, see our article on privacy in tax file validation.

Where can I find the official SAF-T specifications for my country?

• •Luxembourg (FAIA): pfi.public.lu (AED)
• •Portugal (SAF-T PT): portaldasfinancas.gov.pt (AT)
• •Norway (SAF-T Financial): skatteetaten.no (Skatteetaten)
• •Poland (JPK): podatki.gov.pl (KAS)
• •Romania (D406): anaf.ro (ANAF)
• •Bulgaria (SAF-T BG): nra.bg (NRA)
• •OECD base standard: oecd.org

How do I get started?

The FAIA Validator offers tiered access so you can start validating immediately:

• •Free tier: XSD schema validation with no file size limits. Sign in with LinkedIn and validate your FAIA files against the official Luxembourg schemas straight away. All processing happens in your browser.
• •Paid tiers: Add business rules validation, cross-reference integrity checks, and visual analytics dashboards with error categorisation by severity, line-number references, and distribution charts.

Visit the pricing page to compare tiers, or go directly to the validator to start with a free schema check.