SAF-T (the Standard Audit File for Tax), filed with Romania's ANAF through the D406 return, has been mandatory for large taxpayers since 2022, for medium ones since 2023, and for small ones since 2025. In practice almost any company with its own accounting is now in scope. I implemented the full D406 generation from a system that runs in production.

Who files, and by when

Scope arrived by taxpayer category under OPANAF 1783/2021, as amended: large taxpayers from January 2022, medium from January 2023, small from January 2025. Two details sit inside that timetable. Companies that entered the large-taxpayer category on 1 January 2022 without having been in it during 2021 started on 1 July 2022. Credit institutions, non-bank financial institutions, financial institutions and insurers classified as large at the end of 2021 started on 1 January 2023, not 2022. Non-resident companies registered for VAT in Romania have no reference date of their own and default to the small-taxpayer one.

The grace periods that softened the first filings expired in 2025, on 30 June for quarterly filers and 31 July for monthly ones. Since then the sanctions in article 337^1 of the Fiscal Procedure Code apply on their own terms: 1,000 to 5,000 lei for a return not filed on time, 500 to 1,500 lei for one filed incorrectly or incompletely. A company registered after its category's reference date still gets the grace ladder on its own first filings.

Under Annex 4 of the order the deadline is the last calendar day of the month after the reported period, moving to the next working day when it falls on a weekend or a public holiday. The period follows the VAT period, so monthly filers file monthly and quarterly filers quarterly; a semi-annual or annual VAT period, or no VAT registration at all, means quarterly. The fixed-asset sections are annual and do not belong in every submission: they go in a single D406 Active filing, due at the deadline for the annual financial statements rather than at month end. The stock sections are produced only on ANAF's request.

Current versions, checked 29 August 2026

On 19 February 2026 ANAF republished the schema definition workbook and the validator. The XSD itself has not moved since July 2025:

Schema (XSD): Ro_SAFT_Schema_v249_2025.xsd, unchanged since July 2025
Validator package: duk_SAFT_an_luna_20260216.zip, republished 19 February 2026
Schema definition workbook: RO_SAFT_SchemaDefCod_16.02.2026.xlsx, republished 19 February 2026

On 26 August 2026 ANAF announced two further tools: TestSaftT.jar and TestSaftW.jar for checking the consistency of the XML, and D300_2026.jar, which fills a form in the shape of the VAT return from D406 data so the two can be compared. ANAF has said these are in testing between September and November 2026, so their output is indicative rather than final. Passing the validator is not the same as being accepted: ANAF correlates D406 against the VAT returns D300 and D301, and a mismatch there surfaces weeks after filing, when it is more expensive to fix.

A republished validator is the kind of change that turns a filing which worked last month into a rejection this month, which is why the generator has to be built against the schema and re-run against the current tool rather than against last year's output.

What I deliver

A valid D406 is not a table export. It is a structured XML file that reconstructs the company's accounting in a standardised format that ANAF can audit automatically. I generate:

Header - company identification, the declarant, the period, and the VAT regime.
MasterFiles - the chart of accounts mapped to the ANAF nomenclature, customers and suppliers, the tax table, units of measure, products, and, annually, the fixed-asset register.
GeneralLedgerEntries - the accounting entries, by journal, with debit/credit totals that have to balance.
SourceDocuments - issued and received invoices with line detail, receipts and payments, stock movements, and asset transactions.

Where most systems trip

A D406 is not hard to generate badly. It is hard to generate so it passes validation:

Chart-of-accounts mapping. Your analytic accounts have to be linked to the standardised ANAF accounts. If the mapping is incomplete, the validator rejects the file.
Tax codes. Every rate and every direction (collected/deductible) has an ANAF nomenclature code. 21% on a sale and 21% on a purchase are not the same code.
Reporting cadence. Monthly or quarterly depending on the VAT period, with the asset sections only in the annual filing. You have to know what belongs in each submission and what does not.
Partner registration numbers are encoded differently for partners from Romania, from the EU, and from outside the EU.
Validation with the DUK Integrator, the official ANAF tool. If the internal architecture is not built around the schema, you end up patching the XML by hand on every filing.

I build the file against the ANAF schema (the current D406 structure version) and keep errors separate from warnings, so before filing you know what is blocking you and what is merely worth checking.

Built into a real product

D406 is generated inside Manag.Web, the business-management platform I build and maintain as my own product. Because the return draws on every module - accounts, partners, journals, inventory, fixed assets - the real advantage is that the data comes from one coherent place, not collected by hand from several sources before each filing.

The documentation on the ANAF ledgers and returns is public: manag.zbconsulting.eu.

Who it is for

If you have an in-house accounting system or an ERP that does not yet produce D406, or one that produces a file that does not pass the DUK Integrator, I can take the generation end to end: account mapping, tax codes, every schema section, and validation. I integrate into your system rather than asking you to switch accounting software.

I build the software that produces these files. I am not a tax advisor, and nothing here replaces advice from your accountant. Dates and file versions on this page were checked against the ANAF sources on 29 August 2026.

See also e-Factura integration with ANAF, the other compliance obligation I implement from the same system.