Inventory what the Acumatica estate satisfies today in tax determination and statutory output, map tax zones and categories onto the D365 tax engine, and decide per requirement between a Microsoft localisation, an ISV and Electronic Reporting.
This is one of the thinner-evidence modules in the path, and it is more useful to say so than to write around it.
Supported by the source package: that Acumatica determines tax through tax zone, tax category and tax account setup; that these cover sales tax, purchase tax, use tax and settlement; that the target design maps onto tax codes, tax groups, item tax groups and settlement accounts by jurisdiction and recoverability;
The target determines tax by intersection: the sales tax group carries the counterparty side, the item sales tax group carries the item side, and the tax codes appearing in both are the ones that apply.
The inventory is the deliverable of this module and it does not come from the system. It comes from finance, tax and — often — from the external accountants.
The target offers three routes and the choice is per output rather than per country.
Electronic invoicing deserves separate treatment for one reason: its deadlines are external and its lead times include things the programme does not control — registration with an authority, certification of a transmission channel, onboarding with a service provider, or testing windows set by a regulator.
Three areas cannot be resolved from the source package and should be labelled as open in any design document that draws on this path:
Acumatica determines tax through tax zones, tax categories and tax account setup. D365 determines it through the intersection of sales tax groups and item sales tax groups, resolving to tax codes that carry rate, recoverability, jurisdiction and settlement behaviour. The mechanical translation is tractable;