Localisation, the tax engine and statutory reporting

How D365 layers country and region functionality against a single legal entity, how a tax amount is actually determined through sales tax groups, item tax groups and ledger posting groups, the honest delta from M3's tax-class and CRS-style country-version model, and how Electronic Reporting, e-invoicing and SAF-T answer 'how do we produce this statutory file' in place of MEC/ION document flows and Streamserve output.

What you will be able to do

Introduction

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.

How D365 layers country and region functionality

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 — conceptually the same idea as an M3 company taking on an Infor country version,…

The D365 tax engine: how a tax amount actually gets determined

D365's indirect-tax framework covers sales tax, VAT, GST and withholding tax through one shared set of building blocks, related to each other in a fixed way:

The M3 side in equivalent detail — and the honest delta

M3's tax determination is, in shape, closer to D365's group-intersection model than most other M3-to-D365 comparisons on this site: a tax class assigned to the customer or supplier and a tax class assigned to the item are intersected to select the applicable VAT code, which carries the rate and a reference to where the amount posts.

Withholding tax on both platforms

M3 handles withholding tax through country-version-specific setup, typically involving a withholding rate or code applied at customer or vendor level and certificate tracking that is often more manual than an implementation team expects going in — the rules are country-specific down to the certificate format, and M3 does not offer one…

EU obligations: Intrastat, EC sales list and VAT declarations

Three recurring EU statutory obligations sit on top of the tax engine rather than inside it, and this is an area where M3's distribution customer base tends to have real, deep, long-standing requirements rather than a nice-to-have.

Electronic invoicing, Electronic Reporting and statutory audit files

Electronic Reporting (ER) is the framework underneath nearly everything else in this section: a declarative, model-driven stack — data model, model mapping, format, format mapping — that produces a statutory output without writing a custom program or building a custom document flow for it.

Multi-country rollout: CONO/DIVI versus legal entities

A single-country D365 implementation rarely has to make the next decision explicitly. A multi-CONO M3 estate rolling out to several countries cannot avoid it, and it has to be made once, early, because it shapes the sequencing of every country that follows.

Knowledge check

Summary

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.