SAF-T (D406) reporting to ANAF
The D406 informative return generated straight from accounting, with every section the ANAF schema requires.
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.
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.
The system builds the file against the ANAF schema (the current D406 structure version) and keeps 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.
See also e-Factura integration with ANAF, the other compliance obligation I implement from the same system.