Romania SAF-T D406 Guide: Deadlines and Data Readiness

Romania's SAF-T declaration is D406. For most readers, the immediate question is not whether the filing exists, but how it works in practice: the core D406 file is submitted monthly or quarterly depending on the taxpayer's VAT period, the fixed-assets file is submitted annually, and the inventory file is submitted only when ANAF requests it. As ANAF's July 2025 communication on filing Form D406 explains, this recurring, annual, and on-request structure now applies across the widened taxpayer base, including small taxpayers from January 1, 2025.

If you need a Romania SAF-T D406 guide in plain English, the key point is this: D406 is not just another deadline. It sits on top of structured accounting data, invoice data, VAT logic, asset records, and, when requested, inventory data. A team can understand the rule perfectly and still struggle with the filing if those underlying records are inconsistent across systems.

D406 component	When it is filed	What it covers at a high level	Why teams struggle
D406 General	Monthly or quarterly, based on the VAT period	Core transactional and accounting data used for SAF-T reporting	Ledger structure, VAT coding, and master data often vary across entities and systems
D406 Assets	Annually	Fixed asset data and related records	Asset registers may be incomplete, outdated, or maintained outside the ERP
D406 Inventory	Only when ANAF requests it	Inventory data supplied separately from the recurring file	Stock records and item-level controls are often owned outside finance

That three-part structure matters because each component depends on a different slice of your source data. The recurring file depends on the same controls that shape everyday accounting quality, such as invoice coding discipline, supplier and customer master data, and a chart of accounts that maps cleanly to reporting logic. The annual fixed-assets file depends on whether your asset register is complete and current. The inventory file depends on whether stock records can be assembled in a format that stands up to inspection when ANAF asks for it.

This is why Romania SAF-T requirements create an operational project, not just a compliance memo. The legal question is who files and when. The harder question is whether your AP, accounting, tax, ERP, fixed assets, and inventory records can support a reliable export when the deadline arrives. The rest of this article focuses on that second question: what changed in 2025, how the D406 modules differ, which ANAF materials matter, and what finance teams should clean up before they treat D406 as routine.

Who has to file D406 and what changed in 2025

Romania SAF-T requirements now matter to a broader operational audience because the phased rollout has moved beyond the biggest taxpayers. In practical terms, D406 is no longer just a large-enterprise issue: large and medium taxpayers were already part of the regime, and the important 2025 shift was the inclusion of small taxpayers from January 1, 2025. That pushed D406 into the workflow of businesses and advisers that may previously have treated the regime as something larger organizations had to solve first. For many finance teams, that change is why Romania D406 deadlines became urgent in 2025 and stayed high-priority into 2026.

In practice, the filing question is not limited to "Are we in Romania?" It is usually, "Which Romanian reporting perimeter are we supporting, and which systems feed the records behind it?" That can include local accounting teams, regional controllers supporting Romanian entities, tax managers working with external advisers, and ERP owners who maintain the chart of accounts, VAT mappings, and master data that ultimately feed the declaration. A business may understand that it is in scope and still be unprepared if those data owners are working in silos.

This is also why D406 should be separated from other Romanian reporting streams. A company that already tracks obligations such as Romania's RO e-Transport reporting rules for high-risk goods is not automatically ready for SAF-T. The obligations overlap in the sense that they all reflect Romania's digital reporting direction, but the data burden is different. RO e-Transport is event- and movement-oriented, while Romania's RO e-Factura requirements focus on invoice issuance, submission timing, and RO_CIUS XML validation. For cross-border finance teams, that same data-readiness mindset also shows up in Lithuania's i.SAF register reporting requirements, where invoice-level sales and purchase records need to stay submission-ready throughout the period. D406 is a structured accounting-data regime tied to how transactions, tax codes, fixed assets, and stock records are maintained over time.

You will also see current commentary around the broader reporting environment, including references to OPANAF 407/2025, updated technical materials, and the role of the SPV channel in submission workflows. Those references matter because they signal that D406 is still an actively maintained compliance ecosystem rather than a static one-time rollout. For implementation teams, the takeaway is straightforward: do not rely on an early rollout article from a few years ago and assume nothing important has changed.

The scope question is therefore both legal and operational. Legally, the regime now covers a wider taxpayer base than it did at launch. Operationally, the 2025 expansion means smaller finance functions, outsourced accounting teams, and regional shared-service teams have less room to postpone cleanup of the source data that supports SAF-T reporting.

How D406 General, Assets, and Inventory differ

One reason English-language guidance often feels incomplete is that it mentions "D406" as if it were a single homogeneous file. In reality, finance teams need to distinguish D406 General, D406 Assets, and D406 Inventory because each module has a different cadence, different data owners, and different failure points.

D406 General is the recurring core submission. It follows the taxpayer's monthly or quarterly VAT period and is the part most teams think of when they ask whether Romania SAF-T is monthly or quarterly. This file is closely tied to the quality of your transaction-level accounting data: ledger postings, VAT coding, business partner records, document references, and the mapping logic that turns operational transactions into reportable structures.

D406 Assets is not just an appendix to the recurring return. It is an annual submission linked to the fixed assets register. That means your year-round control environment matters. If asset classes are inconsistent, disposals are not recorded cleanly, depreciation records are fragmented, or fixed assets are maintained in spreadsheets outside the core finance system, Romania D406 fixed assets reporting becomes a separate remediation stream rather than a quick extension of the recurring SAF-T file.

D406 Inventory is different again. It is submitted only when ANAF requests it, but that does not make it optional from a readiness perspective. Inventory data is often maintained in operational systems, warehouse tools, or ERP modules that finance teams do not review as frequently as the general ledger. If stock units, item masters, valuation methods, or warehouse-level records are messy, the Romania SAF-T inventory file can become the moment when long-standing control gaps suddenly surface.

The practical distinction is easier to see when you map each module to the underlying data domain:

• General: transaction and ledger data, VAT logic, supplier and customer records
• Assets: fixed asset register, asset movements, depreciation-related records
• Inventory: stock records, item data, quantities, and inventory support files

For teams comparing SAF-T regimes across jurisdictions, this split is one reason implementation detail matters more than the generic label. Norway's SAF-T Financial compliance requirements also show how local SAF-T rules live or die on accounting-data structure, but Romania's D406 framework makes the separation between recurring, annual, and on-request reporting especially important. Once you see those modules as separate readiness tracks, the next step is obvious: check whether the source data behind each one is clean enough to rely on.

---

The source data you need before D406 is reliable

The clearest gap in the current SERP is that many articles stop after explaining the obligation. That is useful, but it does not answer the question finance teams actually face: what has to be true about our data before a D406 output can be trusted? The answer usually has less to do with the XML generation step than with the records feeding it.

Start with invoice and transaction data consistency. If invoice numbers are stored differently across business units, credit notes are handled inconsistently, tax amounts are overridden without a clear rule, or document references disappear between AP and ERP systems, the recurring D406 file becomes harder to validate. Even when a team can produce an export, mismatched source records make exceptions harder to explain and correct.

Next comes supplier and customer master data. D406 depends on business partner records that are stable enough to support consistent reporting. Duplicate suppliers, inconsistent naming, missing tax identifiers, and weak ownership of master-data updates all create friction. These issues may feel administrative in daily operations, but they become reporting issues when the declaration expects structured, repeatable records.

VAT coding and chart of accounts mapping are usually the biggest technical pain points. A finance team may close the books every month with manual workarounds that feel manageable internally, yet those same workarounds become a problem when SAF-T requires cleaner logic. If the same transaction type is mapped differently by entity, by user, or by system interface, D406 reliability drops. The recurring file reflects the discipline of your posting rules far more than the elegance of your final export routine.

Then there are the readiness streams that many teams underestimate:

• Fixed assets register quality: asset classes, locations, acquisitions, disposals, and depreciation records need to be complete and current before the annual D406 Assets submission becomes straightforward.
• Inventory records: item masters, quantities, valuation support, and warehouse-level controls need to be organized well before any on-request submission arrives.
• Cross-system ownership: AP, accounting, tax, operations, and ERP teams need a shared view of which records are authoritative for each data domain.

For most organizations, the best way to treat this is as a checklist rather than a one-off technical task:

1. Confirm the reporting perimeter and data owners.
2. Review VAT code usage and account mappings for consistency.
3. Test whether supplier, customer, and document-level fields are complete enough for structured reporting.
4. Audit the fixed assets register separately from the recurring ledger workflow.
5. Assess whether inventory records can be assembled quickly if ANAF requests them.

Teams that do this work early usually find that D406 becomes far more manageable. Teams that skip it tend to discover their problems only when a deadline or information request forces them to trace errors back through multiple systems.

Which ANAF technical materials matter most

Once the data-readiness question is clear, the next challenge is navigating the ANAF documentation stack. Readers often know that official materials exist, but not which ones deserve attention first. The practical answer is to separate the materials that explain the rule from the materials that support implementation.

The guidance notes and explanatory materials help you confirm scope, cadence, and module logic. These are where you verify points such as monthly versus quarterly filing, annual fixed-assets reporting, and the fact that inventory reporting is only submitted separately on request. They are useful for aligning finance, tax, and external advisers around the same baseline understanding.

The schema materials, including the XSD schema and related structure documents, matter for a different reason. They help implementation teams understand how the report expects data to be organized. Even if your ERP or local compliance software handles file generation, the schema layer tells you what kinds of mapping and field-structure problems are likely to surface. This is where a project often moves from "we understand the rule" to "we understand why our source systems may not populate the rule cleanly."

The ANAF D406 validator is especially important because it brings technical reality into the process early. Teams that validate exports before the filing deadline can catch issues in structure, mapping, or completeness while they still have time to fix the underlying data. Teams that wait until filing week often discover that the problem is not the submission step itself, but the quality of the ledger logic or master data feeding the file.

The FAQ and assistance materials matter because they often resolve practical edge cases faster than trying to infer everything from top-level summaries. The SPV environment matters because submission should be treated as part of the operating process, not as a final click performed in isolation from finance controls.

If you want a useful parallel, Poland's JPK SAF-T reporting and GTU code framework shows the same broader lesson: digital tax reporting becomes much easier when teams combine official rule reading with early technical testing. For Romania, the best sequence is usually simple: confirm the scope, identify the relevant ANAF guidance, review the schema and structure expectations, run validation tests, and only then treat the filing process as routine.

---

Common implementation mistakes and a practical readiness checklist

Most D406 delays are not caused by one dramatic technical failure. They come from ordinary control weaknesses that were tolerable in day-to-day accounting but become visible once a structured SAF-T regime forces consistency. The most common mistakes tend to fall into five groups.

1. Treating D406 as a deadline problem instead of a data problem.
Teams often focus on the submission date first and the data model second. That creates a rushed implementation where exceptions are patched manually instead of resolved at source.

2. Letting VAT coding drift over time.
If similar transactions are coded differently across entities, users, or systems, the recurring D406 file becomes harder to reconcile. This is one of the fastest ways for reporting confidence to erode.

3. Assuming the chart of accounts already maps cleanly enough.
Local workarounds, historical account usage, and ERP customizations often mean chart-of-accounts mapping looks stable on paper but breaks down when tested against structured reporting requirements.

4. Ignoring the annual and on-request modules until they become urgent.
Incomplete fixed asset records and weak inventory discipline rarely fix themselves quickly. Waiting until the D406 Assets cycle or an ANAF request arrives leaves very little room for cleanup.

5. Leaving ownership fragmented.
Tax, accounting, AP, fixed assets, inventory, and ERP teams may all control part of the answer. If nobody owns the end-to-end readiness plan, issues can sit unresolved even when every team believes it is doing its part.

A more workable approach is to turn those risks into a short readiness sequence:

1. Confirm scope and cadence. Identify whether the recurring D406 filing follows a monthly or quarterly VAT period for the relevant entity, and document the annual and on-request components separately.
2. Review core posting logic. Check VAT coding, account mappings, document references, and business partner fields for consistency.
3. Audit asset and inventory data as separate workstreams. Do not assume the recurring file tells you whether those records are ready.
4. Test with official technical materials early. Use the ANAF guidance, schema materials, and validator before the live filing window becomes the first real test.
5. Assign accountable owners. Make one person or team responsible for coordinating tax, finance, ERP, fixed assets, and inventory dependencies.

Romania D406 deadlines matter, but the filing becomes much more manageable when you treat the obligation as a structured data project. That is the real operational lesson behind Romania SAF-T requirements: if the source records are controlled, the reporting process is far less likely to turn into a scramble.