5 Feb 2026

Netherlands update: XAF 4.0 (Auditfile Financieel) is coming in January 2026 - and D365 Finance needs prep now

Author: Roman Abilkhatov, D365 Finance Solution Architect

If you support Dutch legal entities, this one isn’t optional.

The Dutch Tax Administration (Belastingdienst) is moving the financial audit file standard from XAF 3.2 (2014) to XML Auditfile Financieel (XAF) 4.0, effective from 1 January 2026. The goal is a cleaner, more modern data structure and better alignment with the Dutch RGS chart of accounts and the broader European digital reporting direction. The practical impact for D365 Finance teams: you need the right application build and the right Electronic Reporting (ER) configurations in place, plus a real mapping to RGS.

Below is what’s changing, what you need to do, and the gotchas I’d rather you hit in DEV than in December.

What’s actually new in D365 Finance for NL

Microsoft’s localisation guidance focuses on three things:

1. ER-based generation of the audit file for Dutch legal entities This feature is only relevant where the legal entity’s primary address is in the Netherlands.
2. A new ER format for XAF 4.0 that is date-driven The documentation distinguishes between:

1. “Audit File Financial XAF 4.0 in XML (NL) - starting January 1, 2026”
2. “Audit file (NL) - before December 31, 2025” (XAF 3.2)

In other words: you don’t just “turn on XAF 4.0”. You choose the format mapping based on the reporting period and the compliance date.

3. RGS mapping becomes meaningful For XAF 4.0, D365 Finance expects you to associate your main accounts with Dutch RGS codes (ReferentieGrootboekSchema). The mechanism Microsoft points to is consolidation account groups (plus additional consolidation accounts) to hold the RGS code per main account.

Required actions (based on the hotfix / issue guidance)

From the hotfix-style guidance (Details for issue 1085536), the “do this first” list is consistent:

1) Upgrade your D365 Finance application build

XAF 4.0 support is tied to specific supported builds / platform update levels - 10.0.44 onwards. If you’re below the required build, you can import all the ER configs you like, but you may still end up with missing parameters, incomplete output, or formats that don’t behave as expected.

Practical advice: plan the application update early, because many teams leave “localisation updates” to the end of the release cycle and then discover they’ve got environment freeze dates, UAT windows, and cutover rehearsals in the way.

2) Import the latest ER configurations

Microsoft is explicit: you must import ER configurations before you can generate the audit file. (Microsoft Learn)

At a minimum, the documentation lists:

1. “Audit file model” (Model) - minimum version 47
2. The relevant Format: “Audit File Financial XAF 4.0 in XML (NL)” for 2026 onward, or “Audit file (NL)” for periods up to 31 Dec 2025 - minimum version 47.5

Also note Microsoft’s hint: import the most recent versions, because the version description often references the KB article that introduced the change.

3) Configure RGS mapping using consolidation account groups

This is the step that gets underestimated.

Microsoft’s approach is:

1. Create a consolidation account group (example name: RGS)
2. Add your main accounts to that group
3. Populate the consolidation account value with the standard account (RGS code) that will be output in the <RGScode> element in XAF 4.0

If you skip this, you’ll still generate a file, but you’re likely to fail downstream validation expectations (or at minimum, you’ll be manually explaining why accounts aren’t classified correctly).

How to generate the audit file in D365 Finance

Once the prerequisites are in place, generation is straightforward:

Path: General ledger > Periodic tasks > Audit file

Key parameters that matter:

1. From date / To date
2. Consolidation account group (optional today, but described as “optionally required” for XAF 4.0 as of 1 Jan 2026)
3. Format mapping:

That last bullet is the one that will catch people: if you’re producing an audit file for a 2025 period after you’ve upgraded, you still need to pick the old format mapping. Don’t assume “latest = correct”.

Gotchas I’d test for (before you ever go near PROD)

1) Date boundary behaviour

You want confidence in three scenarios:

1. A file fully in 2025 (should be XAF 3.2 mapping)
2. A file fully in 2026 (should be XAF 4.0 mapping)
3. A reporting range that straddles year-end (what is your business policy, and which format does your auditor expect?)

The documentation is clear about the compliance date, but your organisation’s reporting practices can create edge cases. (Microsoft Learn)

2) RGS completeness and governance

If RGS codes live in a consolidation account group, who owns that mapping?

If it’s “whoever has time”, you’ll end up with:

1. accounts missing RGS
2. accounts mapped inconsistently (especially new accounts created during projects)
3. no audit trail for why something changed

Treat RGS mapping like master data with a proper owner, change process, and a “new main account checklist”.

3) Environment parity (ER configs are not always identical)

I’ve seen DEV have the latest ER configs and UAT sitting two versions behind because someone imported the configs once and assumed they’d follow the code deployment. They don’t.

Make “ER config version check” part of your deployment readiness routine.

4) Validation expectations

Even if D365 generates the file, the receiving party’s validation rules are what matters.

Plan for:

1. a sample file generated from UAT
2. shared with the auditor / tax advisor early
3. feedback loop while you still have time to adjust mappings (and not during December close)

A sensible rollout plan (low drama)

1. Update the application build in DEV
2. Import ER configs (model + both formats) in DEV
3. Build RGS consolidation account group + mapping for a representative set of accounts
4. Generate sample files for both 2025 and 2026 ranges
5. Repeat steps 1-4 in UAT with deployment discipline (same ER versions)
6. Lock down mapping ownership and change control
7. Only then plan PROD timing (ideally well before year-end)fbuil

Documentation reference

Microsoft Learn article (sign-in may be required in some tenants). If you need to share the link internally, here it is:

https://learn.microsoft.com/en-us/dynamics365/finance/localizations/netherlands/emea-nl-audit-file