SAF-T reporting in Europe: a country-by-country guide

What SAF-T is

SAF-T, the Standard Audit File for Tax, is an XML format defined by the OECD for exporting a company's accounting records, from the general ledger and chart of accounts to customers, suppliers, invoices, payments and often stock and fixed assets, so that a tax authority can analyse them by machine. It matters because several European countries now require the file, either on request in an audit or as a regular filing.

The OECD's Forum on Tax Administration published the first SAF-T guidance in 2005 and version 2.0 in 2010. The OECD schema is a model, not a law: each country that adopts it publishes its own national schema, validation rules and legal obligation, and the national versions differ enough that a file built for one country will not pass validation in another.

SAF-T is not a tax return and not an e-invoice. A return summarises; an e-invoice carries one transaction to one customer. A SAF-T file carries the underlying records for a whole period, which is why it tests the quality of the ledger rather than the quality of a single document.

What is inside a SAF-T file

In the OECD 2.0 structure a file has four blocks. The header identifies the company, the software, the period and the currency. The master files hold the reference data every transaction points to. The general ledger entries hold every journal with its lines. The source documents hold the commercial documents behind the entries. National schemas add or drop sections; Romania, for example, files its assets section once a year and its stock section only on request.

Because every transaction refers back to master data by identifier, the file only validates if those identifiers exist and are consistent. A journal line on a receivables account that does not name a customer, or a tax code on an invoice line that is not in the tax table, is a validation error rather than a style point.

• Header: company, tax number, software, period, currency
• Master files: general ledger accounts with opening and closing balances, customers, suppliers, tax table, products
• Optional master data: physical stock and fixed assets, where the national schema requires them
• General ledger entries: journals, transactions and lines, with control totals of entries, debits and credits
• Source documents: sales invoices, purchase invoices, payments, movements of goods, asset transactions

Three ways countries use SAF-T

European countries use SAF-T in three broad ways, and the model decides how much pressure falls on the finance team each month.

On request is the lightest: the business must be able to produce the file within a set time when an auditor asks. Austria, Luxembourg and Norway work this way. Periodic filing is the heaviest: the file is sent on a fixed calendar whether or not anyone asked, as in Romania and for Polish VAT. Between them sit hybrids, where one variant is filed routinely and another on request or once a year, as in Portugal and Poland's corporate income tax files. A related family, invoice-level reporting such as Lithuania's monthly i.SAF registers, uses the same data discipline for a narrower set of records.

Countries that file SAF-T routinely, as of September 2026

Portugal. SAF-T (PT), defined by Portaria 321-A/2007 and currently in version 1.04_01, has an invoicing variant and an accounting variant. Invoice data must be communicated to the tax authority by the 5th day of the month after issue, by uploading the invoicing SAF-T file, through a web service or on the portal. The accounting file is joining the annual IES return; as of September 2026 the first mandatory accounting files relate to the 2026 financial year and are submitted in 2027, with descriptions and personal data masked using a key from the national mint under Decreto-Lei 48/2020.

Poland. Since 1 October 2020 VAT taxpayers have sent JPK_V7M or JPK_V7K files that combine the VAT return with the full VAT records, generally by the 25th of the following month. Other JPK structures, such as the books of account, are produced on request. Corporate income taxpayers are now being required to send their books as structured files, JPK_CIT, phased in by taxpayer group for tax years beginning after 31 December 2024; in February 2026 the Ministry extended the first deadlines to the end of the seventh month after the year end for years ending before 1 April 2026.

Romania. The SAF-T declaration D406, under ANAF President's Order 1783/2021 as amended, applied to large taxpayers from 1 January 2022, medium taxpayers from 1 January 2023 and small taxpayers from 1 January 2025. It follows the VAT period and is due by the last calendar day of the following month; the assets section is filed once a year and the stock section only on request, within at least 30 calendar days.

Countries that ask for SAF-T on request or through the bookkeeping system

Norway requires businesses with a bookkeeping obligation whose accounts are available digitally to be able to export them as SAF-T Financial, for accounting periods starting on or after 1 January 2020; businesses with turnover under NOK 5 million are exempt. The file is submitted only when the Tax Administration asks, typically in an audit. As of September 2026 version 1.30 can be used until 31 December 2026, and version 1.40, already accepted, is the only valid format from 1 January 2027.

Austria's Federal Fiscal Code requires computerised books to be handed over on data carriers in an audit, and the Ministry of Finance accepts SAF-T AT, with its own schema version 1.01 and a standard chart for mapping. Luxembourg's tax authority can require its SAF-T version, the FAIA, during a VAT audit, and has asked for it since the close of the 2011 financial year. Lithuania's i.SAF-T subsystem receives accounting files in the OECD format, alongside the monthly i.SAF invoice registers due by the 20th.

Denmark takes a different route: its digital bookkeeping rules require the bookkeeping system itself to be able to generate a SAF-T file in the Danish Business Authority's format, among other functions. The requirement has been phased in since 2024 by type of business and by whether the company uses a registered standard system or one built for it, so check the Danish Business Authority's timeline for your accounting class. France does not use SAF-T at all; its equivalent is the fichier des écritures comptables (FEC), which a business keeping computerised accounts must hand over in a tax audit under article L47 A of the Livre des procédures fiscales.

Worked example: one sale, from ledger to file

A distributor in a country with a 21% VAT rate issues invoice INV-2026-0142 on 14 March 2026 to customer C0457 for EUR 1,000 of goods plus EUR 210 of VAT. The journal in the ledger is Dr Trade receivables 1,210 / Cr Sales of goods 1,000 / Cr VAT output 210. In a SAF-T file the same event appears in three places, and each must agree with the others.

The file-level control totals then prove completeness. If March has 3,480 journal entries with total debits of EUR 2,914,650.00, the general ledger block must declare 3,480 entries and total debits and credits of EUR 2,914,650.00 each, and the closing balance of each account in the master files must equal its opening balance plus the movements in the entries. A validator checks these sums before a human ever reads the file.

• Master files: customer C0457 with name, address and VAT number; tax code for 21% VAT; accounts 1200, 4000 and 2200 with their standard or national mapping
• General ledger entries: transaction with ID, period 3, date 2026-03-14, source document INV-2026-0142
• Line 1: account 1200 debit 1,210.00, customer C0457
• Line 2: account 4000 credit 1,000.00, tax code 21%
• Line 3: account 2200 credit 210.00, tax code 21%, tax amount 210.00
• Source documents: invoice INV-2026-0142, one line, net 1,000.00, tax 210.00, gross 1,210.00

What an accounting system must be able to export

Whatever the national schema, the same capabilities decide whether a SAF-T file comes out of the ledger cleanly or has to be rebuilt by hand. Most of them are about the data model, not the export button. A system that lets a posted entry be edited in place, or that holds customers as free text on journal lines, will produce files that fail validation or fail the auditor's questions.

• Unique, permanent transaction identifiers and gap-free document numbering
• Posting date, document date and period on every entry
• Customer or supplier identifier on every receivable, payable and invoice line
• Tax codes per line that map to the national tax table
• A chart of accounts mapped to the national standard accounts or grouping codes
• Opening balances, movements and closing balances that reconcile for every account
• Corrections by reversal and new entry, never by overwriting a posted journal
• Exports split by period, with control totals, for large files

A readiness plan for finance teams

Start from the country's obligation, not from the software. Read the national schema and the tax authority's validation rules, and list which sections apply to your business and on what calendar. Then map your chart of accounts to the national standard accounts or grouping codes, and your tax codes to the national tax table, and keep both mappings as maintained master data rather than a one-off spreadsheet.

Next, clean the master data: every customer and supplier with a tax number, address and country code; every product with a unit of measure; every fixed asset with its acquisition data. Then run a trial export for a closed month, validate it with the authority's tool, and reconcile the file's control totals to the trial balance. Fix the causes, not the file.

Finally, build the export into the close. A period is ready for SAF-T when every document is posted, the bank is reconciled, the VAT accounts agree with the return, and the period is locked so that the figures in a filed or requested file cannot move afterwards.

Common validation failures

The same errors recur across countries, and almost all of them start in the ledger rather than in the export.

• Account closing balances that do not equal opening balance plus movements
• Journal lines on control accounts without a customer or supplier identifier
• Tax codes used on invoices that are missing from the tax table
• Opening balances that differ from the previous year's closing balances
• Duplicate or reused transaction and document numbers
• Entries dated outside the period the file declares
• Deleted documents leaving unexplained gaps in a numbering series
• Customer VAT numbers stored in free-text fields instead of the tax number field

SAF-T, e-invoicing and ViDA

SAF-T sits beside, not instead of, the e-invoicing and real-time reporting mandates spreading through Europe. Poland's KSeF, Romania's RO e-Factura and Portugal's monthly invoice communication already give tax authorities invoice data; SAF-T adds the ledger that the invoices were posted to, so the authority can check that the two agree. Under the EU's VAT in the Digital Age package, digital reporting of cross-border business-to-business supplies starts on 1 July 2030, and national real-time systems must align with the EU model by 1 January 2035.

For a business the consequence is that the invoice, the ledger and the audit file become three views of one set of records. Any difference between them, a credit note in the e-invoicing system that never reached the ledger, or a manual journal with no source document, becomes visible to the tax authority by machine.

Doing this in Skyline Nexus ERP

Skyline Nexus ERP keeps its records in the structure a SAF-T file draws on. Accounts carry unique GL codes and account types with a classification and normal balance, and the chart of accounts can be imported and exported with its codes and parent accounts, so a mapping to national standard accounts can be maintained against stable codes. Accounts can be flagged Requires Party, so a manual journal line on a receivable or payable account is refused without a customer or supplier. Journals are numbered by a configurable sequence, only drafts can be deleted, posted journals are corrected by reversal, and fiscal periods can be closed and locked, with the Accounting Audit Trail recording every change with old and new values.

For an auditor or a tax inspection, the Audit Pack exports one Excel workbook for a calendar year with sheets for the chart of accounts, trial balance, journal entries, journal lines, general ledger, sales, purchases, returns, payments and receipts, customer and supplier dues and the VAT summary. Native SAF-T exports for each national schema, such as SAF-T (PT), JPK, D406 and SAF-T Financial, are being rolled out market by market; tell us your country and we will confirm your go-live date. Until then, a mapping tool or integration partner can build the national file from these exports.