In a recent webinar, Fonoa's tax, engineering, and implementation teams walked through the full lifecycle of getting e-invoicing live in four African markets. This post turns that conversation into a step-by-step playbook.

Phase 1: Figure out if you're in scope (and who needs to own this)

Scoping is harder than it sounds

Ralph van Coevroden, who leads Fonoa's customer implementations, flagged this as a genuine sticking point:

The first step is to even realize you're in scope, and that's something a lot of companies aren't sure or clear about."

The scope across these four markets is broader than many businesses expect. Kenya includes all businesses operating in the country, even those that are not VAT-registered. Ghana, Nigeria, and Zimbabwe extend obligations to non-resident digital service providers. Nigeria is currently focused on large taxpayers (roughly €3M+ turnover), but plans to expand to all VAT-registered businesses.

If you're a digital platform, marketplace, or SaaS company with customers in any of these markets, you're likely in scope, even without a physical presence.

Know your volumes and transaction types before you design anything

Which entities issue invoices in each country? B2B, B2C, or both? What's the volume? This matters because it determines whether device-based or API-based integration is viable (in Zimbabwe, for example, physical devices become unreliable at high transaction volumes) and how much even a small error rate will cost you in manual cleanup.

No single team can own this alone

Antonio K, Fonoa's Senior Engineering Manager for e-invoicing, was clear on this:

Once the companies understand that they're in scope, they also need to know what are they currently doing, what are their current operations, what flows, what use cases, what documents they issue. And it's very hard to find a single person who can give you an answer to all of this."

At minimum, you need tax, engineering, and finance talking from the start. In some organizations, operations and product teams also need to be involved, especially if invoices originate upstream in a billing system rather than the ERP. We've written about how leading enterprises organize their tax tech function to keep these teams from working in silos.

Phase 2: Audit your data before you build anything

This is where most projects hit their first wall. The gap between "data that works internally" and "data that passes a tax authority's real-time validation" is where the real work lives.

Customer master data: tax IDs, names, and addresses

These are the most common failure points. Ralph was specific:

Nigeria is very clear about the data quality. You could miss the zip code, or the city, or the state. Nigeria also has a concept of a local government, which isn't easily detectable, and many of our clients just don't have that in store."

In Ghana, the tax authority links each TIN to a single business partner name. Use "Company ABC" on one invoice and "Company ABC Group" on another with the same TIN, and you'll get clearance failures. Validating tax IDs upfront catches these mismatches before they cause rejections.

Product codes: more granular than you expect

Nigeria requires product specification codes drawn from a list of tens of thousands of entries. If your ERP classifies products at a higher level than the tax authority expects, you'll need to do that mapping work before you integrate.

Rounding: a core business logic problem, not a quick fix

Different tax authorities have different rounding rules. Some allow only two decimal points, others four to six, others have no limit. If your system rounds differently than the authority expects, every invoice fails validation.

And unlike a wrong tax ID or name, which you can fix in your master data, rounding errors sit deep in your business logic. As Antonio put it, "You have to go back to your engineering teams and tell them that their calculations are wrong, and then they'll try to convince you for a month and a half that they're right."

If you suspect a mismatch, start early. Fixing rounding means changing core billing logic. Expect development cycles and regression testing, not a quick config update.

Credit notes: use them the way the tax authority expects

There are creative ways to handle corrections without issuing credit notes, like sending negative values through other document types. 

But tax authorities in these markets have specific requirements for how corrections should flow, and matching those requirements from the start is simpler than maintaining workarounds. 

Build credit note support into your integration early and save yourself the extra engineering.

Phase 3: Integration and testing

Build vs. buy: a decision that gets more important with every country

Ralph put it simply:

If you need to comply with one, maybe even two countries, it could be worth exploring building it in-house or going with a local provider. But the moment you need to do two or more countries, if you're trying to build each one separately, it is very difficult."

For a single market, building in-house can absolutely work. The math changes when you're maintaining multiple country-specific integrations with different schemas, validation rules, and transmission models. The e-invoicing procurement guide walks through the full set of questions to ask, including when a provider like Fonoa's e-invoicing solution makes sense versus when it doesn't.

Design for the two-way flow from day one

Your integration needs to handle responses from the tax authority, not just submissions. In Kenya, that means receipt numbers, signature numbers, and QR codes flowing back into your ERP. Build this into the architecture from the start. Bolting it on later is a much bigger job.

Test against the tax authority's actual environment

This is the single most useful thing you can do before go-live. Ralph was clear:

Ideally, you want to go with a vendor that has a sandbox or a test environment connected to the tax authority's test environment. That really allows you to get success rate from 80, 85% to 98% and above, and that's where you want to be when you go live."

Don't settle for internal-only testing. The errors that matter most are the ones the tax authority catches, and you want to find those before you're processing live transactions.

Build for failure, not just success

Antonio's advice:

You really need to make sure that you're not just building for the happy path, where everything is working, but also stress test your system and make sure that it works under circumstances that you might not necessarily expect."

Network timeouts, tax authority system outages, device failures, unexpected validation rejections: these are everyday realities, not edge cases. Your system needs to handle all of them without falling over.

Phase 4: Go-live is the starting line, not the finish

Target near-100%, because "good enough" breaks down at scale

Ralph described the post-go-live trajectory:

After go-live, it's getting from the starting point of 90-something percent success rate, and you're trying to aim as close as possible to that 100% rate."

At high transaction volumes, even a 1-2% failure rate creates a significant manual workload. Build monitoring and alerting from day one.

Make your first integration count for the next one

The timeline improves with each additional country, but only if your first integration is built with reuse in mind:

For the first country, it takes about 60 days. Second country, about 40, then 30. And we even saw companies that are able to go live within a week or less."

Limehome saw this play out when they moved from fragmented local providers to a single platform, going live in Italy in 26 working days and then adding new markets in a fraction of that time.

If you know you'll need multiple markets, build for that from the start. Our tax maturity roadmap covers how to plan these investments so each one sets up the next.

Get ahead of accounts payable mandates now

Ghana already requires domestic purchase reporting. Nigeria requires B2B invoice receipt through accredited access points. The AP side of e-invoicing is becoming mandatory, and most organizations haven't started preparing for it.

"In most companies, the AP and the AR teams are so far apart, they don't even know each other," Ralph noted. "But when mandates are coming for both AR and AP, those teams need to start understanding how the other part of the business works."

Plan for change, because the mandates will evolve

Ralph described what happens when maintenance gets ignored:

If you're gonna build every country as a reactive solution, you're going to have different builds that don't necessarily align with the business, and you're going to waste a lot of resources."

The cost of maintaining siloed, country-specific implementations grows with every mandate change. If you're not sure whether your current setup can handle that kind of ongoing change, our tax tech maturity assessment is a good place to start.

The one-paragraph version

Start before you're forced to. Get tax and engineering talking early. Fix your data before you build your integration. Test against real tax authority environments. Design for multi-country from day one. And don't treat go-live as the finish line.

Watch the full conversation

This playbook covers the highlights, but the full webinar goes deeper into each country, the panel's live Q&A, and specific implementation stories from customers. Watch the full webinar recording for everything.