The SAF-T File Structure Explained: A Visual Guide for Finance Teams

If your company operates in a country that requires SAF-T (Standard Audit File for Taxation), your accounting system needs to produce a structured data export that the tax authority can read and audit electronically. But what actually goes into one of these files?

This guide walks through the structure of a SAF-T file in plain terms, no XML knowledge required. Whether you are a CFO preparing for your first submission, a controller reviewing an export from your ERP, or an accountant trying to understand why a file failed validation, this overview will give you the full picture.

The Big Picture: Four Sections

Every SAF-T file is organised into four main sections. Think of it like a well-structured financial report: it starts with who you are, lists all your reference data, then provides the accounting entries and the original business documents behind them.

The green boxes are the four main sections. The blue boxes show the sub-tables within MasterFiles (12 reference data tables) and SourceDocuments (5 transaction types). Every transaction in the file points back to a record in MasterFiles, making the file self-contained and auditable.

1. Header: Who, When, and What System

The Header identifies your company, the reporting period, and the accounting software that generated the file. Tax authorities use it to confirm they are looking at the right entity, the right time period, and the right file version.

It covers the basics: your company name, registration number, VAT ID, registered address, the reporting start and end dates, the default currency (e.g. EUR), and the software that produced the export. In Luxembourg, it also indicates which of the three FAIA schema variants (Full, Reduced A, Reduced B) was used.

2. MasterFiles: Your Reference Data

MasterFiles is the reference data layer, the “dictionary” that every transaction in the file looks up against. It contains 12 tables covering everything from your chart of accounts to your product catalogue. If a transaction references a customer, a tax code, or a GL account, the details must be defined here.

Financial reference data

• •Chart of accounts (GeneralLedgerAccounts): Every GL account with its type (asset, liability, income, expense), opening and closing balances, and optional mapping to a standardised chart of accounts.
• •Tax codes (TaxTable): All tax types and rates used in the file. For example, Luxembourg’s standard 17% VAT, reduced 8% and 3% rates, and exempt categories. Every tax line on an invoice must reference a code defined here.
• •Cost centres and analysis codes (AnalysisTypeTable): Dimensional analysis codes for departments, projects, or profit centres used in management reporting.
• •Taxonomies: Optional mappings from your internal accounts to external reporting frameworks like XBRL.

Business partner data

• •Customers: Every customer referenced in your sales invoices and payments, including name, address, VAT number, bank details, and associated GL account with opening/closing balances.
• •Suppliers: The mirror image: every supplier referenced in purchase invoices and payments, with the same structure.
• •Owners: Shareholders and company owners, supporting corporate transparency requirements.

Inventory and asset data

• •Products: Product and service catalogue with descriptions, product groups, units of measure, valuation methods, and applicable tax codes.
• •Physical stock: Inventory positions at the start and end of the reporting period, broken down by warehouse, product, and stock status.
• •Assets: Your fixed asset register, listing each asset with its acquisition date, depreciation method, book value, and valuation details for both commercial and tax purposes.
• •Units of measure and movement types (UOMTable, MovementTypeTable): Supporting lookup tables that define measurement units and stock movement categories used elsewhere in the file.

3. General Ledger Entries: Your Accounting Journals

This section contains every journal entry posted during the reporting period. It is the core accounting record. Every financial transaction in the business ultimately flows through the general ledger.

Entries are grouped by journal type (sales journal, purchase journal, cash journal, general journal, etc.). Each entry includes a unique transaction ID, the posting date, a description, and individual debit/credit lines referencing accounts from your chart of accounts.

4. Source Documents: The Business Detail Behind the Numbers

While the general ledger shows the accounting impact, Source Documents provide the commercial detail: who bought what, from whom, at what price, and with what tax treatment. There are five types:

• •Sales Invoices: All invoices issued to customers, including line items, quantities, prices, tax breakdowns, and document totals in both local and foreign currencies.
• •Purchase Invoices: All invoices received from suppliers, with the same level of detail. These are critical for input VAT verification.
• •Payments: Records of all payments made and received, linked to the invoices or accounts being settled, with payment method details.
• •Movement of Goods: Stock movements tracking the physical flow of goods: receipts, dispatches, warehouse transfers, and inventory adjustments.
• •Asset Transactions: Fixed asset acquisitions, disposals, transfers, and revaluations, each linked back to the asset register in MasterFiles.

How It All Connects: Referential Integrity

The most important design principle of SAF-T is that the file must be internally consistent. Every reference in a transaction must point back to a valid record in MasterFiles. This is called referential integrity, and it is one of the first things tax authorities check.

Here are the key links the tax authority verifies:

Broken references (for example, a sales invoice that references a customer ID that does not appear in the Customers table) are among the most common validation errors. They typically indicate that the accounting software did not export all required master data.

Country Variations

The OECD published the SAF-T standard, but each country adapts it to local requirements. The four-section structure is the same everywhere, but the details vary:

• •Luxembourg (FAIA): Requires all 12 reference tables in the Full variant. Tax codes must use the term “TVA”. Account types must be in French. Three schema variants offer different levels of detail.
• •Portugal: Splits the file into separate billing and accounting exports with different submission schedules.
• •Norway: Focuses on financial data and enforces referential integrity directly at the schema level.
• •Poland (JPK): Breaks SAF-T into separate file types for VAT, accounting books, bank statements, warehouse records, and invoices.
• •Romania (D406): Cross-validates SAF-T data against VAT returns to verify that declared tax matches the underlying transactions.

For a full country-by-country comparison, see our SAF-T adoption across Europe overview.

What This Means for Your Finance Team

You do not need to understand XML to manage SAF-T compliance. But understanding the structure helps you anticipate, and avoid, the most common problems:

• •Master data quality drives everything. Incomplete or inconsistent charts of accounts, customer records, or tax codes will cause the entire file to fail validation. Clean master data is not just good practice; it is a compliance requirement.
• •Archived or merged records break references. If you merge two customer accounts or archive a supplier, historical transactions still reference the old IDs. Your ERP must retain these records in the SAF-T export.
• •ERP updates can change what gets exported. A new version of your accounting software may alter field mappings or which tables are populated. Always re-validate after system updates.
• •Control totals must reconcile. The file includes summary totals (total debits, total credits, number of entries) that must match the sum of individual records. These are automated checks that tax authorities run first.
• •Validate early, validate often. The best time to catch issues is during your regular period-end close, not when a tax authority requests the file.