Where the obligation comes from
Two texts carry the obligation. Article 59^1 of the Tax Procedure Code says every taxpayer files with ANAF “a return containing information from the accounting and tax records, called the standard audit file”, electronically, by the deadline set by order of the ANAF president. The order is OPANAF 1783/2021, whose annex 5 lists who files and from when.
Annex 5 was replaced in full by OPANAF 407/2025 (Official Gazette 310 of 8 April 2025). In the version now in force, point 3 letter r) names “non-resident companies that hold a Romanian VAT registration code (taxpayers registered directly, taxpayers registered through a fiscal representative, fixed establishments)”, and point 1.1 letter e) gives the date: they file “starting with the reference date for small taxpayers (1 January 2025)”.
For a company registered after that date, letter g) applies: the obligation “starts from the effective date of registration”, with the first filing on the last day of the month following the reporting period. There is no threshold of turnover or number of invoices below which the obligation does not apply.
The obligation is separate from the VAT return and from RO e-Factura. A non-resident company that reports its B2B invoices in e-Factura still files the D406; the two are separate obligations with separate deadlines.
What a non-resident actually files
The D406 has a large structure: master files, general ledger entries, source documents, assets, stocks. A company with no accounting obligation in Romania cannot fill most of it, and is not asked to.
Section 4.6 of ANAF’s taxpayer guide states which information is reportable “for non-resident companies registered for VAT purposes that have no obligation to keep accounting records in Romania”:
| Section | Content | In the non-resident file |
|---|---|---|
| 1. Header | Company identification, reporting period, currency | Yes |
| 2.5 TaxTable | The tax codes used on the invoices, from the ANAF nomenclature | Yes |
| 2.6 UOMTable | Units of measure used | Yes |
| 2.9 Products | The goods and services invoiced | Yes |
| 4.1 SalesInvoices | Every invoice issued under the Romanian VAT number, by line | Yes |
| 4.2 PurchaseInvoices | Every invoice received under the Romanian VAT number, by line | Yes |
| 2.1 GeneralLedgerAccounts, 2.3 Customers, 2.4 Suppliers, 2.7 AnalysisTypeTable | Chart of accounts, partner master data, analysis dimensions | No |
| 3. GeneralLedgerEntries | Accounting entries | No |
| 4.3 Payments | Receipts and payments | No |
| Assets, Stocks | Annual assets file, stock file on request | No |
One detail catches most foreign finance teams: the invoice structures still ask for an account code. The guide says to use the Romanian general chart of accounts as a reference: account 401 for suppliers and 411 for customers at invoice level, and, on the lines, revenue accounts such as 707 (sale of goods) or 704 (services) for sales, and expense or stock accounts such as 628 (services from third parties) or 371 (goods) for purchases. Your ERP does not need these accounts; the file does. Mapping is done once, per type of transaction.
The reduced structure follows the absence of a bookkeeping obligation, not the VAT registration as such. A Romanian branch or a permanent establishment keeps double-entry books here (annex 5, point 3 letters l) and m)) and files the standard structure. Whether a fixed establishment for VAT purposes also has to keep books in Romania depends on its legal form, and is worth settling in writing before the first filing.
Deadlines, on a calendar
Annex 4 sets the rhythm. The D406 is filed “monthly or quarterly, following the tax period applicable for VAT”; a company with a half-yearly or annual VAT period files quarterly. The deadline for everything except assets and stocks is “the last calendar day of the month following the reporting period”.
A worked example. A German distributor holds a Romanian VAT number for a warehouse near Timișoara and files monthly VAT returns. In September 2026 it issues 12 invoices to Romanian retailers and receives 6 invoices: warehouse rent, transport, its accountant. The D406 for September covers those 18 invoices and is due on 31 October 2026. That day is a Saturday, so under article 75 of the Tax Procedure Code the deadline moves to Monday, 2 November 2026. The VAT return for the same month was due on 26 October (the 25th being a Sunday); the two deadlines are never the same day.
The same company files the D406 for October by 30 November, for November by 31 December, for December by 31 January 2027, and so on, twelve files a year. A quarterly filer files four.
The grace period, and how it really works
The first filings are protected. Annex 4, point 5, grants a grace period of “6 months for the first reporting, 5 months for the second, 4 months for the third, 3 months for the fourth, 2 months for the fifth” for monthly filers, and “3 months for the first reporting” for quarterly filers. The period “is calculated from the last day of the reporting period for which it is granted”. Within it, no fine under article 337^1 is applied, provided a valid D406 is filed before it expires.
Take a company registered for VAT on 15 March 2026, with a monthly VAT period:
| Reporting period | Legal deadline | Grace | No fine if filed by |
|---|---|---|---|
| March 2026 | 30 April 2026 | 6 months from 31 March | 30 September 2026 |
| April 2026 | 31 May 2026 | 5 months from 30 April | 30 September 2026 |
| May 2026 | 30 June 2026 | 4 months from 31 May | 30 September 2026 |
| June 2026 | 31 July 2026 | 3 months from 30 June | 30 September 2026 |
| July 2026 | 31 August 2026 | 2 months from 31 July | 30 September 2026 |
| August 2026 | 30 September 2026 | none | 30 September 2026 |
The five grace periods end on the same day. The design is deliberate: a new filer gets six months to build the process, then catches up on everything at once. A quarterly filer registered on the same date reports the second quarter of 2026 by 31 July, with grace until 30 September.
Two cautions. The grace period covers the fine, not the obligation: the six files still have to exist, valid, by 30 September. And it protects the first filings of a taxpayer, not every period after a change of accountant or ERP.
Fines, notifications, and what ANAF sees
Article 337^1 of the Tax Procedure Code sets two contraventions: not filing the standard audit file by the legal deadline, fined RON 1,000 to 5,000, and filing an incorrect or incomplete file, fined RON 500 to 1,500. Paragraph (3) removes the fine in two cases: the file is corrected before the legal deadline of the next filing, or it is corrected after the deadline because of a fact not attributable to the taxable person.
A rejected file is a separate risk. Under article 59^1 paragraph (3), when the filing “was not validated following the detection of errors”, the valid file keeps the date of the initial message only if it is filed “within 5 working days after the deadline”. Past that window, the period counts as not filed. Uploading on the last day, without having validated the XML first, is how companies lose the deadline while believing they met it.
ANAF does check. On 20 August 2024 it sent 15,023 automatic notifications to taxpayers that had not filed, or had filed a partial or incorrect D406, and, where data mismatches were found, attached “detailed reports of the non-conforming transactions”. The press release does not say which data the D406 was compared with; the sources ANAF holds for the same period are the VAT return, the D394 domestic listing and the invoices in RO e-Factura. An invoice present in one of them and missing from the D406 is the kind of difference such a report lists.
Periods with no invoices
Annex 5 lists the exempt categories exhaustively: authorised individuals, liberal professions, public institutions, and, at point 4 letter o), companies “whose activity is temporarily suspended by registration at the Trade Register”, for the suspended period only. There is no exemption for a period without transactions. A non-resident company that keeps its Romanian VAT number files a D406 for every month or quarter, with the header and the tables it has, and no invoice sections when there is nothing to report.
If the Romanian activity has ended, the answer is not to stop filing but to deregister the VAT number. Until the deregistration takes effect, the D406 and the VAT return are both due.
How to build the file from a foreign ERP
The work is a mapping exercise done once, then a monthly routine. In the order we do it:
- Export. Two tables per period from the ERP or the invoicing platform, filtered on the Romanian VAT number: invoices issued and invoices received, at line level. For each line: document number and date, counterparty name and tax identifier, description, quantity, unit, net amount, VAT rate or tax code, currency.
- Map the counterparties. Romanian customers and suppliers appear with their CUI, the Romanian tax identification number; foreign ones with their country code and VAT number. A missing or malformed identifier is the most frequent validation error.
- Map the tax codes. Each VAT treatment used on your invoices (21% standard, 11% reduced, reverse charge, intra-Community supply, export) is translated to the code from the ANAF nomenclature and listed once in the TaxTable. The same goes for units of measure in the UOMTable.
- Assign the reference accounts. 411 and 401 at document level; 707, 704, 628, 371 or the appropriate account on the lines, following the guide. This is a lookup by transaction type, not bookkeeping.
- Generate and validate. The XML is produced against the current ANAF schema and checked with ANAF’s own validator (DUKIntegrator) before anything is signed. The guide also provides a D406T test return, which we use for the first period of a new client: same structure, no legal effect, immediate feedback on errors.
- Sign and file. The D406 is a PDF with the XML attached, signed with a qualified certificate and uploaded through the Virtual Private Space (annex 3, points 9 and 17). The size limit is 500 MB. The receipt ANAF returns is the proof of filing; we keep it with the XML.
- Reconcile. Before the VAT return is filed, the totals of the D406 are compared with the D300, the D394 and the e-Factura inbox and outbox for the same period. Differences are corrected on the side where the error is, not by adjusting the file.
Corrections after filing follow annex 3: the first validated D406 for a period is the initial return, a second one for the same period is automatically a rectifying return, and it has to contain all the original information plus the corrections, not only the changed lines.
The errors we see most often
- Payments included. The reduced structure has no Payments section; a file built from a “full” template for a non-resident fails validation or reports what is not asked for.
- Tax codes carried over from the home ERP instead of the ANAF nomenclature, so the TaxTable does not match the lines.
- Counterparties without a valid CUI, or the CUI of the fiscal representative instead of the customer’s.
- Period confusion: invoices reported by payment date, or a quarterly filer reporting monthly.
- Filing on the deadline without validation, then discovering the rejection outside the 5 working days.
- Assuming a month without invoices needs no file.
The full service, including the monthly routine and the reconciliation with the other returns, is described on the SAF-T D406 page. If the company is not yet registered, the sequence starts with VAT registration for non-residents, and the D406 obligation runs from the day the number is issued.

