SAF-T Romania: we build and file your D406 from any source system

SAF-T in Romania: what the D406 file actually is

SAF-T stands for Standard Audit File for Tax — an XML format defined by the OECD, which Romania adopted through ANAF Order 1783/2021, later amended, including by Order 407/2025. The file is submitted as informative declaration D406 through the Virtual Private Space, the electronic channel every Romanian taxpayer uses to reach ANAF.

The difference between SAF-T and a VAT return is one of order of magnitude. A VAT return has a few dozen boxes. A monthly D406 for a mid-sized company runs to tens of thousands of lines, and it has to be internally consistent: every invoice in SourceDocuments must point to a partner in MasterFiles, every account used must exist in GeneralLedgerAccounts, every VAT rate must come from the ANAF nomenclature. The tax authority uses the file to reconcile what you declare against what your counterparties declare, automatically. That makes SAF-T the single most revealing filing in the Romanian system.

Who has to file the D406

The obligation was phased in and now covers effectively everyone keeping double-entry accounts.

The criterion is double-entry bookkeeping. Every Romanian commercial company files, regardless of turnover, including dormant ones. Permanent establishments of foreign companies file. And, in a reduced form, so do foreign companies that hold nothing in Romania but a VAT number.

Outside the scope: authorised individuals and family enterprises keeping single-entry accounts, and non-profit entities carrying out no economic activity.

What double-entry bookkeeping means for a foreign entity

This is the question we are asked most often by group controllers, and the confusion is understandable. The Romanian obligation is drafted around taxpayers who keep double-entry accounts, and a foreign company that never opened a Romanian ledger reasonably assumes the criterion cannot apply to it.

It does. The test looks at the entity, not at where the ledger sits. A German GmbH, a Dutch BV or a US corporation keeps double-entry books at home; that satisfies the criterion. What the entity does not have — and is not required to build — is a Romanian statutory chart of accounts. This is exactly why the simplified file exists: it is populated from the transactions carried out under the Romanian VAT number, not from a Romanian general ledger.

Practically, that means the GeneralLedgerEntries section is not the centre of gravity of a non-resident file. The centre of gravity is SourceDocuments — the invoices — supported by the master data needed to make them readable.

The simplified SAF-T for non-residents

If your company is established in another country and holds a Romanian VAT number for a warehouse, for marketplace sales, for local supplies or for a project, the SAF-T obligation has applied to you since 1 January 2025, in a reduced form: you report the operations carried out through the Romanian VAT number — sales invoices and purchase invoices — together with the master data those documents reference: tax codes, units of measure, products. ANAF’s taxpayer guide (section 4.6) lists exactly these sections for non-resident companies with no bookkeeping obligation in Romania; there are no accounting entries, no payments, no assets and no stocks. You do not report the parent company’s accounting. The article on SAF-T for non-resident companies goes through the legal basis, the grace period on a calendar and the build routine.

The practical difficulty is never the volume. It is that the data arrives from a foreign ERP, in a structure that has nothing in common with the Romanian nomenclatures: tax codes named in another language, document types that do not map cleanly onto Romanian categories, partner records without a Romanian tax identification number. Translating that once, correctly, is the whole job. See also the guide to VAT in Romania for foreign companies for how SAF-T fits with the rest of the cycle.

Only a Romanian VAT number? Send us your ERP or marketplace export: we convert it into the simplified D406, validate it and file it for you. Get a quote

What the file contains

The structure is split into five blocks, and not all of them are reported at the same rhythm:

1. Header — identification data, reporting period, schema version.
2. MasterFiles — the nomenclatures: chart of accounts with balances, customers, suppliers, the tax table, units of measure, analysis and movement types, products, owners.
3. GeneralLedgerEntries — the accounting journal for the period, every debit and credit line.
4. SourceDocuments — sales invoices, purchase invoices, payments, goods movements and asset transactions.
5. Assets and Stocks — the asset register is reported annually, by the financial statements deadline; inventory is reported on request, within 30 days.

The most frequent source of errors is not data entry. It is mapping: transposing your analytical accounts onto the ANAF reference chart, your VAT rates onto the codes in the official nomenclature, and your document types onto the required categories. A mapping error made at the start propagates into every monthly file after it.

Deadlines and the grace period

The filing deadline is the last calendar day of the month following the reporting period:

• companies with a monthly VAT period file the D406 monthly;
• companies with a quarterly VAT period, and those not registered for VAT, file quarterly.

For the first submissions the legislation grants a grace period: six months for the first monthly report and three months for the first quarterly report. A company that entered the obligation on 1 January 2025 with monthly reporting could therefore submit the January to June files by the end of July 2025. After the grace expires, each period carries its own deadline. The full deadline map is in the Romanian tax calendar.

Penalties

The Fiscal Procedure Code provides:

• RON 1,000 – 5,000 for failing to submit the D406 within the deadline;
• RON 500 – 1,500 for submitting an incorrect or incomplete file.

The amounts are not large. The real exposure is different: a missing or inconsistent SAF-T tells ANAF precisely which taxpayers are worth visiting. The consolidated text of the Fiscal Procedure Code is published by ANAF.

How we prepare and file your SAF-T

We built two tools internally and use them on every engagement.

The mapping tool takes your data from any source — an export from SAP, Oracle, NetSuite, Dynamics or a Romanian package, or trial balances and journals in Excel — and transposes it onto the D406 structure. The mapping is configured once, at onboarding, and reused every period. When new accounts, tax codes or products appear, the tool flags them so they are mapped before generation rather than after rejection.

The validation tool checks the file before it reaches ANAF: consistency between sections, trial balance against journal, existence of partners and accounts, format of tax identification numbers, VAT codes drawn from the correct nomenclature. We then run the official DUKIntegrator validator, and the file is submitted only with zero errors.

The monthly cycle, in three steps:

1. We receive the closed data — your ERP export or Excel files, by email or shared folder.
2. We generate and validate — usually the same day; differences are cleared with you before submission.
3. We file through the Virtual Private Space with our digital certificate and send you the ANAF receipt plus a short summary of the period.

Your team never has to learn the D406 specification or run the validator: the file is our work, from the first mapping to the receipt.

Specific situations

Marketplace sellers. Sales data arrives from the platform rather than from an invoicing system, often aggregated. The D406 needs document-level detail, so the first step is agreeing a reliable document granularity with the platform export. This connects directly with RO e-Factura, which stores the invoices your Romanian suppliers issue to you.

Groups with a shared service centre. The data is clean but the chart of accounts is a group chart. We map group accounts to the Romanian reference chart once and keep a change log, so a group-level restructuring does not silently break the Romanian file.

Companies registered mid-year. The obligation starts with the registration, and the grace period runs from there. Registration itself is covered on the page about VAT registration for non-residents.

The errors we see most often

• Unmapped analytical accounts. The file validates, but ANAF sees balances on accounts that do not exist in the reference chart.
• VAT rates written as percentages instead of the codes from the ANAF nomenclature — more sensitive since the move to 21% and 11% in August 2025.
• Partners without a tax identification number, or with an identifier written differently from the one used in the domestic transactions report, so the two filings no longer reconcile.
• Wrong period for companies that switch VAT period from quarterly to monthly during the year.
• Skipped nil filings by dormant companies — the obligation exists even with no transactions.
• Corrective files sent as deltas rather than complete replacements for the period.

Each of these is checked automatically by our validation tool before the file leaves.