SAF-T is usually described as a report. That framing causes most of the trouble, because a report is something you generate at the end and this is not that.
It is an export of your accounting reality in a fixed structure. Which means the question is not "can our software produce D406". It is "does our software hold, in a form it can export, everything D406 asks for". Those are different questions and the second one is answered a year earlier than people expect.
The shape of the thing
D406 is XML, based on the OECD Standard Audit File for Tax, adapted by ANAF. Broadly it carries:
Master data. Your chart of accounts, your customers, your suppliers, your products, your tax table, your units of measure. Not transactions. The reference lists that transactions point at.
General ledger entries. Journals, with the entries in them, each tied to accounts.
Sales and purchase invoices. Headers and lines, with tax detail per line.
Payments.
Assets, in the annual submission, with movements and depreciation.
Stock, which is not part of the routine filing but is produced on request.
Read that list as a set of demands on your data model rather than a set of tabs. Every one of those needs stable identifiers, because the file is not a snapshot in isolation. It is one in a series, and ANAF can compare them.
The part that actually breaks
It is not the XML. Generating XML is a solved problem and any competent developer does it in a week.
What breaks is that SAF-T asks your system for things it was never asked for before.
Stable identifiers for partners. Each customer needs an identifier that does not change between filings. If your system has been deduplicating customers by merging records, or if somebody renames a client and the key is the name, your January and February files describe different companies. Nothing in your business notices. The file does.
A tax code on every line. Not a rate, a code, from a controlled list, with an exemption reason where the rate is zero. Systems that store 19 or 21 as a number, and derive everything else in the invoice template, have to grow a column and then backfill it, and backfilling it means somebody deciding what the code was for every historical line.
Units of measure from a standard list. Same problem as e-Factura, same list, same discovery that "buc" is not a code.
Accounts that reconcile. The ledger section has to agree with itself. If your accounting is partly in the software and partly in an accountant's parallel spreadsheet, the export will show the software's version, which is not the version filed.
Notice the pattern, because it is the same one every Romanian compliance mandate has produced: the requirement is not really a reporting requirement. It is a data quality requirement with a deadline attached.
Who files, and when
Large taxpayers came first, then medium, and small taxpayers and non-resident VAT-registered entities from 1 January 2025. Frequency follows your VAT regime: monthly filers file monthly, quarterly filers quarterly. The submission deadline is the last calendar day of the month following the reporting period, and there is a separate annual submission covering assets.
ANAF granted grace periods for the first filings of newly-obliged taxpayers, which for the 2025 intake meant the earliest returns could be filed late without penalty. Those were transitional. Do not plan around a grace period that has expired.
Check the current position with ANAF rather than with a blog, including this one. These dates have moved more than once, and the cost of being wrong is not a missed article, it is a penalty.
What to do if you are looking at this for the first time
Do not start by shopping for a SAF-T tool. Start by asking your existing system four questions:
- Can you export a list of every customer and supplier with a stable internal id, a fiscal code, and a full address?
- Does every invoice line carry a tax code, not just a rate?
- Are your units of measure from a standard list, or free text?
- Can you produce the general ledger for one month, with every entry tied to an account, from the system alone?
If the answer to all four is yes, the file is a fortnight of work. If any is no, that is your project, and the XML is the last week of it.
This is also the honest reason SAF-T and e-Factura projects should be scoped together. They demand the same cleanliness from the same tables. Doing them separately means paying for the same data cleanup twice, and we have watched companies do exactly that, eighteen months apart, without noticing they were the same job.
The upside nobody mentions
Once your system can produce this file, it can answer questions it previously could not. A clean, coded, reconciled export of every transaction is the raw material for every piece of analysis somebody has been asking for and not getting: margin by product line, ageing by customer, what actually happened in March.
The mandate is not optional and nobody enjoys it. But the thing it forces you to build is a thing worth having, which is more than can be said for most compliance work.