How D365 activates country functionality on the legal entity, how a tax amount is actually determined through sales tax groups and ledger posting groups, the honest delta from Oracle Fusion Tax's genuinely more configurable rules engine, and how Electronic Reporting, Electronic Invoicing and SAF-T answer 'produce this statutory file without code' against Fusion's BI Publisher, Collaboration Messaging Framework and Tax Reporting Ledger.
Every other domain on this site assumes a business event happens the same way regardless of which country it happens in. Localisation is where that assumption breaks — legally, not just technically.
D365 F&O's starting point is a single legal entity with a primary address country/region. Setting that country/region is not cosmetic: it activates the country-specific features, forms and processes associated with that country for the entity automatically, the same way a Fusion legal entity's jurisdiction context brings its Fusion Tax…
D365's indirect-tax framework covers sales tax, VAT, GST and (with its own adjacent structure) withholding tax through one shared set of building blocks, related to each other in a fixed way:
Fusion Tax is regime-driven rather than group-driven, and it is a genuine rules engine, not a fixed lookup. The configuration hierarchy runs Tax Regime → Tax → Tax Status → Tax Rate → Tax Jurisdiction: a tax regime is the set of tax rules and regulations for one governing authority (a country's VAT regime, for instance);
Fusion models withholding tax as its own Tax Regime, inside exactly the same Regime → Tax → Status → Rate → Jurisdiction structure used for every other tax, invoked automatically at the same event — invoice or payment — as any other Fusion tax.
Three recurring EU statutory obligations sit on top of the tax engine rather than inside it, and D365 produces all three the same way: through Electronic Reporting, not a bespoke program per country.
Chapter 3 of the Development & Architecture domain covered the reporting stack from a developer's angle — which tool to reach for when building a transactional document, a statutory file or an analytical dashboard.
A single-country D365 implementation rarely has to make this decision explicitly. A multi-country rollout cannot avoid it, and — per the programme reference material's own migration rationale, which names "regulatory and localization rationalisation" as one of the four drivers for the whole programme — it has to be made once, early,…
Localisation is the one domain where "it works" and "it works and stays compliant" are different bars, and where currentness — not just correctness — is part of the job.