How country context, the tax determination hierarchy and Electronic reporting fit together — and how to decide, for every statutory output your business produces, whether it comes from the standard product, a partner solution, or a configuration you build.
Every other part of a D365 design is signed off by somebody inside the business. Localisation is signed off, ultimately, by somebody outside it: a tax authority, a statistical office, an auditor, a regulator.
D365 does not have a single "country setting". A legal entity's primary address establishes its country or region context, and that context determines which country-specific features, fields, validations and reports become available to it.
Here is the piece that beginners most often model wrongly, because in many mid-market systems tax is a code on the customer and a rate on the code.
Every business has a list of things it must produce for somebody outside it: a VAT return, an intrastat declaration, a statutory annual account layout, a payment file in a bank's required format, an audit file, an electronic invoice.
List every output the business is obliged to produce, and give each row a decision:
Finally, the decisions that this domain pushes back into the rest of the design. Each of these should be settled before the finance design is signed off.
Localisation is the part of a D365 implementation whose acceptance criteria are written by someone outside the business, which is exactly why it cannot be scheduled last.