This is not a trends report
The subscribe line on this site promises a briefing twice a year. This is the September 2026 edition. It is not a survey of the ERP market, and it does not contain a percentage we did not measure. It is what we are seeing on Dynamics 365 programmes we are asked to design: in the United States, in Europe, in India, in Kenya, in South Africa and in Australia.
Three patterns keep arriving in the same order. Tax is still written in code. E-invoicing still sits beside the ledger. A new country's bank file is still quoted as an X++ project. Each one is an architecture decision that was cheaper to refuse in Discover than to unwind after go-live.
Tax is still dying in code
A rate change is a dated tax code, a settlement period and a test posting. We are still inheriting tenants where 16% lives in X++, where an AL extension assumed one tax group, and where an integration sends a tax string a bank no longer accepts. That is not a Kenyan problem or a European one. A US sales-tax change and a German VAT change fail the same way when the number was typed into a developer artefact.
The rule we are holding: if a revenue authority can change the number, finance owns a dated code. Developers do not. Go-live is not done until finance can move the rate in a sandbox without us. The article behind that rule is the tax piece on this site. The one-page check is whether your team can do it on Tuesday.
Signing still happens beside the ledger
Kenya eTIMS is the strictest proof we run. When the Control Unit call sits inside posting, an unsigned invoice never becomes a ledger fact. When it sits in a tool beside Dynamics 365, month-end is a reconciliation and a credit note that does not point at the original.
The same shape is what we tell a European PEPPOL rollout and a US or Indian authority file. The chart, the sales order and the till stay shared. The signing call is the country layer. A design that says "we will bolt e-invoicing on later" has already accepted a second system in the country where enforcement is strictest.
A new country is a mapping, not a build
Vendor payments and employee payments are leaving through one gateway on the global core, the Universal Disbursement Gateway, to the bank the country actually uses. Account validation uses IBAN rules for 89 countries. The file is ISO 20022 pain.001. A maker checks and a second person releases. The status log cannot be edited.
What we are refusing is a new X++ payment format every time a bank, or a country, is added. That work is a file mapping in Azure. Payroll for Kenya, Nigeria and South Africa stays a product on the core. It calculates. The gateway pays. A US or European entity does not commission a second payroll engine to get a bank file.
What we refused this half-year
A Business Central licence sold as a stepping stone to Finance & Operations. A donor report that is an export from four country workbooks. A marketplace settlement that "just sends the net" and skips the tax engine. A preference-point score kept in a spreadsheet beside a public-sector ledger. A second chart for IFRS.
Delivery of this work is from Australia, Kenya, South Africa, India and Europe. The method does not change with the city. The next edition, March 2027, will be the same kind of note: what changed in the design, and what we still will not build. It will not grow a chart of market share.