Building Software That Scales Across Borders

Expanding a working system from one country to three looks like copy and paste. It is not. I have spent more than fifteen years building and rescuing enterprise systems across East and West Africa, and the same lesson keeps arriving: what breaks at the border is almost never the code. It is the assumptions baked into the code.

The temptation is to treat the continent as one market that simply has not been unified yet. The African Continental Free Trade Area gives that story a headline: a market of about 1.3 billion people and roughly US$3.4 trillion in combined GDP, with trading under AfCFTA beginning on 1 January 2021. But a free-trade framework is not one operating environment.

Underneath the headline sit distinct tax authorities, currencies, languages, payment rails and legal regimes. Revio’s Nicole Dunn captured the operating reality in one useful line: Africa has more than 54 regulatory schemes, 42 currencies and more than 280 registered payment service providers. McKinsey makes the same point from another angle: the continent has over a thousand languages and “bewildering scale and complexity.” That is the gap between the brochure and the build.

What breaks at the border

Tax fails first because it has become real-time

Tax is usually the first border failure because every country now wants its own real-time fiscal integration and implements it differently. Kenya requires businesses to onboard eTIMS and issue electronic tax invoices. Uganda’s EFRIS connects electronic receipts and invoices to URA. Rwanda’s Electronic Billing Machine model links certified invoicing to the tax authority. Tanzania has its own electronic fiscal device regime.

Cross into Francophone West Africa and the model changes again. Côte d’Ivoire’s Facture Normalisée Électronique is a clearance-style system: the tax authority sits inside the invoicing flow rather than simply receiving a report afterwards. Senegal and Cameroon are also moving deeper into mandatory e-invoicing through recent finance-law changes. Even where standard VAT rates look familiar, the schema, validation, retries, credentials and audit trail differ.

The design implication is blunt: do not build “VAT” as a field. Build tax as a country module. Each country needs its own rate table, fiscal invoice schema, authority integration, queueing and failure-handling rules. A system that assumes one tax regime is a system that cannot legally issue invoices in the second country.

Money breaks when the ledger thinks in one currency

A regional business buys, pays and invoices in several currencies within a single week. Most systems are quietly designed for one. The classic West and Central African bug is the CFA franc. XOF, used in WAEMU, and XAF, used in CEMAC, share the CFA name and euro peg, but carry different ISO codes and are not interchangeable. Treat them as one and the ledger lies.

The engineering discipline is unglamorous and decisive. Store money as integers in the smallest unit, never as floating-point numbers. Hold a separate balance per currency on double-entry logic. Make a cross-currency movement post fully in both currencies or not at all. Decide, deliberately, how you round and when you recognise exchange-rate differences. The silent profit-and-loss leak in every multi-currency system lives in that decision.

Language is more than translated strings

The third failure is language, and it runs deeper than a translated interface. Business across Africa runs in English, French, Portuguese, Arabic, Swahili and many local languages. Swahili is now an African Union and East African Community working language, and the EAC’s language mix changed again when the DRC joined in 2022 and Somalia in 2024.

The interface language and the data language are separate problems. Names sort differently. Arabic needs mirrored layout, not only translated text. Date formats can invert meaning. Number and currency display rules affect invoices, statements and receipts. A system that hard-codes one language’s assumptions looks perfect in the first country and breaks quietly in the second.

Data residency and e-signature change the legal shape

The fourth failure is quiet and dangerous: where your data may legally live, and whether your digital contract is valid. Rwanda’s Law No. 058/2021 requires personal data to be stored in Rwanda unless transfer is authorised. Kenya has local-storage requirements for defined strategic-interest data. Nigeria does not impose one blanket rule in its Data Protection Act, but sector rules such as BVN storage and domestic card-switching obligations can still affect architecture. Tanzania, South Africa and Senegal focus more on transfer restrictions than blanket localisation.

E-signatures are the same story in miniature. Many markets recognise electronic signatures, but often with a two-tier model where higher-assurance signatures are needed for certain documents. Your one-country contracting flow may be valid for routine acceptance and weak for board resolutions, employment documents, regulated financial instructions or public-sector procurement.

The design principle: separate the universal from the local

Every one of these failures has the same root and the same cure. The root is a single-country assumption hard-coded where it should have been configured. The cure is an architecture that draws a clean line between what is universal to your product and what is local to a market.

In practice: hard-code no currency, no tax rate, no language, no date format, no hosting region and no fiscal authority. Make each a per-country setting. Build tax integration as a plug-in. Keep the core workflow stable, but let each market carry its own rules. And design for the infrastructure that is actually there. GSMA reported mobile internet penetration of 27% in Sub-Saharan Africa at the end of 2023, with a large usage gap. IEA and World Bank reporting still shows hundreds of millions in the region without electricity access. Offline-first behaviour is therefore not polish; it is operating reality.

What the companies that travelled well actually did

The firms that scaled across African borders did not find a shortcut around localisation. They industrialised it. Flutterwave’s response to fragmented currencies, licensing requirements, mobile money systems and regulators was a unified API on top of local payment infrastructure. The complexity was absorbed, not denied.

Wave’s move from Senegal into Côte d’Ivoire shows the same discipline at the product edge. It bypassed incumbent USSD dependence with app-to-app payments and gave customers without smartphones physical QR-code cards. The technology matched the market instead of demanding that the market become a brochure version of itself.

The cautionary tales teach the same thing. Jumia’s repeated restructuring shows how logistics, market density and local operating reality can punish remote assumptions. Tyme’s expansion from South Africa to the Philippines was possible because the banking concept could lift and shift, but even there the regulatory landscape was “very different.” The product may travel. Tax, currency, language and law do not.

The pre-expansion checklist

Expanding across borders is one of the most valuable moves an African firm can make, and one of the most reliably underestimated. The system that travels well is rarely the one with the cleverest features. It is the one whose builders drew the line between universal and local early, and refused to hard-code a single assumption a border could break.

This article belongs with two practical next steps: understand the ERP migration risks in the cloud ERP migration guide, and use custom software deliberately when off-the-shelf systems cannot handle local rules. To pressure-test a multi-country rollout before you build for the second market, get in touch.