The expensive way to change a tax rate
A finance minister announces a VAT change. In a well-designed Dynamics 365 tenant, that is a dated tax code, a settlement period, and a test posting. In a poorly designed one it is a project: find the X++ that hard-coded 16%, the AL that assumed one tax group, the report that multiplied line amount by a constant, and the integration that sent a tax string a bank no longer accepts.
We have inherited programmes where a statutory change meant six weeks of development. That is not a tax problem. That is an architecture problem. If your next rate change needs a developer, the last partner built you a custom application that happens to sit on Dynamics 365.
Tax belongs in configuration, not in code
Dynamics 365 already has the objects: tax codes, tax groups, item tax groups, withholding, exemption, reverse charge, tax periods, and, on Finance & Operations, tax calculation service and Electronic Reporting. The job of a global rollout is to use them. Customisation is for the gap the product does not express, and it follows a workshop rather than replacing one.
On every programme we run a rule: if a lawyer or a revenue authority can change the number, it must live in a dated configuration. Developers do not own tax rates. Finance does, with an approval trail.
One tax engine, many books
A Kenyan entity, a South African entity and a German entity do not need three tax designs. They need one tax design with country-specific codes, dates and reporting layouts. The chart, the dimensions and the posting profiles stay shared. What changes at the border is the statutory layer: VAT versus GST versus withholding, the return format, the e-invoicing call.
That is how a group rolls a rate change in Nairobi without reopening the German template. Software Dynamics publishes eTIMS inside posting for Kenya and payroll for KE, NG and ZA for the same reason: the statutory piece is a configured product, not a one-off. Your next country should plug into the same pattern.
What we refuse to customise
We will not hard-code a rate, a threshold, or a return line in X++ or AL. We will not calculate tax in an Excel file that posts a journal. We will not let an integration bypass the tax engine so a marketplace or a POS can "just send the net". Those decisions feel fast in month two and become a programme in year two, when the authority changes the rule and nobody remembers which interface assumed the old one.
How a Software Dynamics rollout is built to absorb change
Discover names every tax the group actually files, not the ones on a slide. Design puts each of them on a dated code with an owner. Deploy tests a rate change in the sandbox as a go-live criterion: finance changes 16% to 18% without us, and that is the go-live test. Support is a configuration update, not a change request for code.
If you are choosing a partner for a multi-country Dynamics 365 programme, ask them to show you the last statutory change they shipped as configuration. If the answer is a development estimate, keep looking. If you want the design that survives the next budget speech, talk to us.