Localisation begins at the tax office, not in the translation file

When a software company in Singapore decides to expand into Malaysia, Indonesia and the Philippines, its localisation plan usually begins with language. The interface is translated, prices appear in ringgit, rupiah and pesos, and a marketing team in each capital adapts the website. For many products that is most of the job.

For a product that issues invoices, keeps books and collects payments, it is the smallest part. Rimbunara learnt this expensively. Until 2021 we had grown by building a separate version of the product for each country, each with its own code, its own release calendar and its own idea of what an invoice was. Our first attempt to merge them treated country differences as configuration, a set of switches inside one shared product. It failed within six months, and the reasons it failed are the argument of this essay.

Four countries, four definitions of an invoice

An invoice looks like a universal document. In practice each of our four markets defines it differently. In Malaysia the tax authority has been phasing in e-invoicing by business size, and an e-invoice must be submitted to its system and validated before it counts. Indonesia's VAT-registered businesses have issued electronic tax invoices through the tax directorate's systems for years, under registration rules unlike Malaysia's. In the Philippines invoices must meet the tax bureau's requirements for numbering and registration, and its electronic invoicing programme began with the largest taxpayers. Singapore's rules for businesses registered for goods and services tax differ again, and most of our Singapore customers are professional firms that care chiefly about how their accountants receive the data.

These differences reach deep into the product. They decide which fields an invoice must carry, when it can be edited or cancelled, how credit notes work, how numbers must run, and what must be kept and for how long. They change with notice periods that range from generous to very short, and timetables are sometimes revised after businesses have prepared for them. Treating all this as configuration meant that every country's requirements competed for the same engineers in the same release, and the country with the nearest deadline always won.

Language, by contrast, proved to be the easier problem, though not a trivial one. Our screens run in English, Malay, Indonesian and Filipino, and the hard words are accounting words. A direct translation of a term such as accrual or credit note can be accurate and still mean nothing to the owner of a market stall. Accountants in each market now review our terminology and test it with customers, and in some places we use the word owners already use, with the formal term beside it.

Give the country team the pen

The structural change that worked was to give each country a compliance product manager with authority rather than a voice. Each one reads the authority's published guidance and consultation papers, works with our external tax advisers in that country, writes the requirements for the country layer and can stop a release that would leave customers out of line with the rules. They report to the country product director, not to the central platform team, and their objectives are written in terms of customers' compliance, not features shipped.

This creates tension, and it should. The central platform team wants one way of doing things; the country teams want exceptions. In 2024, when Malaysian e-invoicing needed thirty-one engineers and product staff for three quarters, the trade-off was visible to everyone, because it delayed our bookkeeping assistant in all four markets. Because the compliance owner held the pen, that argument took place in the open, at the executive committee, with the cost written down. Under the earlier model it would have happened quietly in sprint planning, and the deadline would simply have won.

Country authority changes research as well. Each country team runs its own studies with customers and accountants, and its findings carry weight in central decisions. Our offline-first rebuild began with research in East Java and the Visayas, not with a platform plan written in Singapore.

We also changed how country teams are judged on language. Instead of counting translated strings, each team reports how many support questions in its market arise from a term that customers misunderstood. In Indonesia that number halved within a year of accountants rewriting the labels on our tax screens.

A shared core with a visible border

None of this means building four products again. The shared core handles what is genuinely common: customers and suppliers, items and prices, the ledger, payments, permissions and the mobile application's offline storage. Each country layer handles what the law and local practice decide: invoice formats and numbering, tax calculations, submission to an authority, retention periods and the vocabulary of accounting. The border between the two is drawn in the code and in the organisation, and any change that crosses it needs both sides to agree.

The test of the border is how a new country would be added. We are not entering one soon, but we keep a written estimate of what a fifth market would require and update it every year. If the estimate grows, the core is absorbing country rules that belong outside it, and we move them back.

The border shapes testing too. Each country layer carries its own suite of cases, written from the authority's published examples and from real invoices that customers have had questioned, and a change to the shared core must pass all four suites before it ships. When we adjusted shared calculation code for a Malaysian requirement, the Indonesian suite caught a side effect in how amounts were rounded that nobody had predicted. Without the border, that defect would have reached Indonesian customers' tax invoices first, and their accountants would have found it before we did.

I would offer three questions to other product leaders and to boards overseeing regional expansion. Who in the company can stop a release because it would put customers in breach of a local rule? How long does it take to reflect a change in a tax authority's requirements, from publication to customers' screens? And when two countries' deadlines collide, where is that decision made and who sees its cost? A company that can answer those questions has localised. One that can point only to its translations has done the easier half.