Legislations, tax determination and statutory reporting
How X3 legislations drive localised behaviour that D365 expresses through legal-entity country/region, feature management, tax configuration, Electronic Reporting and e-invoicing — and where an X3 vertical or legislation-specific behaviour has no Microsoft localisation at all.
What you will be able to do
Explain how an X3 legislation code drives localised behaviour and how D365 achieves the same through legal-entity country/region, feature management and regulatory configuration updates
Trace how a tax amount is determined in D365 from sales tax group and item sales tax group intersection through to a ledger posting group
Map X3 tax parameterisation to D365 sales tax codes, groups and the Tax Calculation Service, stating honestly where the mapping is conceptual rather than mechanical
Describe Electronic Reporting as the framework that replaces bespoke statutory output, and differentiate it from electronic invoicing
Identify where an X3 legislation-specific behaviour has no Microsoft localisation and articulate the decision between ISV, Electronic Reporting configuration and bespoke build
Introduction
Sage X3 delivers localised statutory behaviour through a single concept: the legislation code, applied at the company level. That code determines tax rules, number sequences, statutory reporting formats, withholding obligations and document layouts — all bundled together and resolved at runtime from the legislation parameter.
How X3 legislations drive localised behaviour
A Sage X3 legislation is not merely a label — it is a parameterisation axis that activates and configures an entire set of country-specific behaviours. The legislation code is assigned at the company level and inherited by the sites within that company. It governs:
How D365 layers country and region functionality
Setting the country/region on a D365 legal entity is not cosmetic: it activates country-specific features, forms, processes and regulatory configurations automatically. But what "activates automatically" actually contains is not one bundled thing.
The D365 tax engine versus X3 tax parameterisation
A sales tax code carries the rate and calculation rule for one specific tax obligation. Every sales tax code links to a sales tax settlement period (defining reporting frequency) and a sales tax authority (the entity the tax is reported and paid to).
Electronic Reporting and statutory output
In X3, statutory output — VAT returns, Intrastat declarations, SAF-T files, payment formats — is delivered through Crystal Reports, L4G programs, or export templates maintained per legislation. Each statutory requirement has its own bespoke output mechanism.
Electronic invoicing
Electronic invoicing in D365 is handled through the Electronic Invoicing service, part of Globalization Studio. It is structurally separate from Electronic Reporting, although both share the Globalization Studio umbrella:
The honest part: where X3 has no Microsoft localisation
Every X3 legislation carries behaviours that may or may not have a D365 equivalent. The gap register (GAP-X3-010) flags vertical pre-builds as a general risk, but the localisation-specific risk is narrower and more consequential: an X3 legislation may deliver a statutory obligation that D365 simply does not address natively for that…
Sequencing localisation in the migration programme
Localisation configuration is a Wave 1 deliverable in the canonical 8-wave model: it is part of the financial foundation that must be locked before any transactional data can land. Specifically:
Knowledge check
Summary
Localisation is the domain where X3's bundled legislation model meets D365's distributed, multi-mechanism approach. The translation is neither simple nor mechanical, but it is tractable if the programme treats each legislation-driven behaviour as a separate requirement to be routed to the correct D365 mechanism — native feature, TCS,…