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 Workday's tax-code-and-third-party-engine model, and how Electronic Reporting, e-invoicing and SAF-T answer 'how do we produce this statutory file without code'.

What you will be able to do

• Explain how a legal entity's country/region context activates Microsoft-shipped localisation features automatically
• Trace how a tax amount is determined from a transaction's sales tax group and item sales tax group down to a ledger posting
• Map Workday's Tax Code, Tax Applicability, Tax Recoverability and Tax Option Group model onto its D365 equivalent, and state honestly where the mapping is conceptual rather than mechanical
• Compare withholding tax configuration and mechanics on both platforms
• Explain what Electronic Reporting is for, and why it replaces country-specific custom reports and third-party tax-engine output rather than merely reformatting them
• Decide, for a multi-country rollout, between a shared and a local chart of accounts, and translate a Workday company hierarchy into a D365 legal entity structure

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 similar to how a Workday Company inherits its country's statutory…

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 Workday side in equivalent detail — and the honest delta

Workday Financial Management's tax model is built from four constructs. A Tax Code carries the rate and type. Tax Applicability rules evaluate a transaction's attributes — company, Worktag, Spend Category, deliverable type — to decide which Tax Codes apply, functioning closer to an evaluated rule set than a fixed lookup.

Withholding tax on both platforms

Workday configures Withholding Tax through applicability rules that determine, per transaction, whether an amount must be withheld on behalf of a Tax Authority, at invoice or at payment time, with certificate and rate handling that is genuinely country-specific.

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 all three are produced the same way in D365: through Electronic Reporting, not through a bespoke report per country.

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 custom code for it.

Multi-country rollout: Workday companies vs D365 legal entities

A Workday Company Hierarchy, with every company sharing one Account Set, can make a multi-country rollout's hardest question look like it has already been answered — it has not.

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.