SAF-T—the Standard Audit File for Tax—is a structured way to export accounting data for tax audit and compliance purposes. The OECD published the original guidance as a model that revenue bodies could adapt. That distinction matters: SAF-T is not one global return, one universally accepted XML file or one common submission process. Each jurisdiction decides whether to adopt it, which taxpayers and records are in scope, the required schema, reporting period, filing trigger and delivery channel.
What is SAF-T?
SAF-T is a structured electronic audit file used by tax authorities to receive accounting, tax and transactional data. It is not one universal format: each country can define different schemas, filing frequencies and data requirements. SAP readiness therefore requires country-specific mapping, validation, reconciliation and evidence controls.
For an SAP team, a SAF-T project is therefore a country-specific data and controls programme. The safe starting point is the current tax-authority specification—not an assumption that a file accepted in one country can be reused unchanged in another.
What a SAF-T file can contain
The OECD model groups information such as a file header, accounting master data, general-ledger entries and source documents. The version 2.0 guidance also covers inventory and fixed-asset information. A national implementation may use only part of that model, add local fields, prescribe tax codes or account mappings, split the data into several files, or apply its own validation rules.
- Master data: customers, suppliers, general-ledger accounts, tax tables, products and units of measure.
- Transactions: journal entries, sales and purchase invoices, payments, movements or other source documents required locally.
- Control information: document identifiers, dates, currencies, debit and credit values, tax amounts and links between records.
- Local additions: authority-specific classifications, numbering, reason codes, declarations or technical fields.
These are categories, not a promise that every jurisdiction requests every element. The current national schema and filing guidance remain authoritative.
Keep obligation, format and submission separate
Three questions are often collapsed into one. First, when is data required: periodically, on request, or as part of an audit? Second, what must be generated: a named XML schema, another structured file, supporting attachments, or several datasets? Third, how is it delivered: portal upload, API, secure file transfer or another authority-defined channel? A valid data structure does not by itself prove that the filing obligation or transport requirement has been met.
What SAF-T means for SAP
The main work is to map the legal data model to the actual SAP design. Company codes, charts of accounts, tax codes, document types, customer and supplier records, material data, currencies and posting logic may differ across systems or business units. Historical migrations and local interfaces can create additional gaps.
A readiness assessment should identify the relevant SAP product and release, the country and filing scenario, the source tables or released interfaces, the volume of records, and the expected correction process. It should then determine whether applicable SAP-delivered functionality covers the scenario, whether configuration is sufficient, or whether a country-specific extension or extraction is required. SAP Document and Reporting Compliance provides capabilities for electronic documents and statutory reporting, but coverage and prerequisites must be checked for the exact country, scenario and system release.
SAP Integration Suite is an integration platform as a service. It may support connectivity, mapping or orchestration in an approved architecture, but it is not the definition of SAF-T and should not be presented as the automatic runtime for every SAF-T implementation.
Controls to design before the first file
- Reconcile file totals to the general ledger and the relevant tax or statutory reports.
- Test required fields, code lists, date formats, signs, currencies and record relationships.
- Define how reversals, late postings, reopening periods and resubmissions are represented.
- Keep the generated file, validation evidence, source parameters and submission receipt under controlled retention.
- Assign ownership for rejected files and for changes to authority schemas or validation rules.
A representative test set should include ordinary postings and difficult cases: credit notes, prepayments, foreign currency, partial payments, cancellations, tax adjustments and high-volume periods. Passing an XSD check is only one control; reconciliation and business-rule validation are equally important.
A practical readiness sequence
- Confirm the legal entity, period, obligation and current authority documentation.
- Inventory the SAP systems, releases, company codes and relevant data owners.
- Map each required field to a governed source and record unresolved gaps.
- Select the delivery model only after standard coverage and technical prerequisites are assessed.
- Build reconciliation, validation, exception handling and evidence retention into the process.
- Run a full-volume rehearsal before the statutory deadline or audit request.
The outcome should be an evidence-based fit decision for the specific country—not a generic “SAF-T supported” label.
Sources
- OECD — Guidance for the Standard Audit File – Tax, Version 2.0
- SAP — SAP Document and Reporting Compliance
- SAP — SAP Integration Suite
Verified on: 10 July 2026. Requirements can change; confirm the latest tax-authority schema and guidance before implementation or filing.
Planning a country-specific SAF-T assessment? Contact S4FN to review scope, data mapping, controls and the appropriate SAP delivery model.