The short answer
East Africa has no single e-invoicing system. Uganda uses EFRIS from the Uganda Revenue Authority, Kenya uses eTIMS from the Kenya Revenue Authority, Tanzania uses EFDMS with fiscal devices, including virtual fiscal devices (VFD), from the Tanzania Revenue Authority, and Rwanda uses EBM, with an electronic invoicing system (EIS) alongside it, from the Rwanda Revenue Authority. In each country the sale you record in your software must also reach the tax authority. The scope is wide: URA says EFRIS covers every VAT-registered business plus 12 designated sectors, and KRA says all persons engaged in business must issue electronic tax invoices, VAT-registered or not.
If you sell software into the region, the practical answer is one internal invoice model and a separate adapter per country, scoped against what each authority publishes today. The connection routes, offline rules and correction rules differ, so an integration built for one country does not carry over to the next. For Uganda, start with EFRIS integration for Uganda. Rules change, so treat this page as a map and the tax authority's own website as the source of truth.
The four systems side by side
The table puts the four systems next to each other and shows what a fixed-quote integration costs us to scope. The Uganda and Kenya rows rest on what URA and KRA publish. For Tanzania and Rwanda the table stays general, because specifics such as offline limits and correction steps are the authority's to set and you should confirm them before you design anything.
| Country and system | Our fixed quote | Who it covers, how it runs, where your software connects |
|---|---|---|
| Uganda: EFRIS (Uganda Revenue Authority) | Integration from | Required for every VAT-registered business and for businesses in 12 designated sectors, among them construction, accommodation and food, IT, professional services, real estate and fuel retail. Sales are shared with URA in real time. Offline issuing is allowed for up to five days through the app, desktop software or a system-to-system connection, but not the web portal, and you must reconnect within that window. Corrections are credit notes and debit notes. Your ERP or POS connects through URA's API. |
| Kenya: eTIMS (Kenya Revenue Authority) | Integration from | KRA says all persons engaged in business must onboard, VAT-registered or not, and it names tour operators, schools and hospitals among them. KRA lists seven solution types, from a web portal and a downloadable client to USSD and system-to-system. For third-party software the system-to-system route comes in two versions: VSCU for businesses that are not always online, and OSCU for always-online invoicing. Corrections follow KRA's OSCU and VSCU specification documents. Your software connects at invoicing, item setup and tax categories. |
| Tanzania: EFDMS and VFD (Tanzania Revenue Authority) | Integration from | Covers traders the TRA requires to issue fiscal receipts, so confirm whether you are in scope. The receipt comes from a fiscal device, and a virtual fiscal device is the software-based option. Sales data goes to the TRA's management system, EFDMS. Timing, offline and correction rules are the TRA's to set. Your software connects at checkout, end-of-day reporting and returns. |
| Rwanda: EBM and EIS (Rwanda Revenue Authority) | Integration from | Covers businesses the RRA requires to issue EBM receipts or invoices, and the RRA also runs an electronic invoicing system. Accepted EBM versions, connection methods, offline limits and the refund process are the RRA's to set, so confirm them before design. Your software connects at sales, refunds and stock. |
The prices above are the starting point for a custom build. Your final number is a fixed quote after we read the specification you must follow and the software you already run.
Sending, offline use and corrections
Sending invoices as the sale happens
All four systems are built around the same idea: the authority should see the sale close to when it happens. What differs is the mechanism. In some cases your software calls the authority's service directly through an API. In others a device, or a local module beside your till, signs the sale and passes the data on. That choice shapes your whole design, which is why the route has to be settled before any code is written.
When the connection drops
Tills in Kampala, Nairobi, Dar es Salaam and Kigali all lose their connection at some point. Uganda gives a hard limit, five days offline, and Kenya offers a separate VSCU route for businesses that are not always online. Good integrations queue each sale locally, mark it as sent or unsent, retry on a schedule, and never lose or renumber a sale. Do not assume the rule from one country applies to another.
Corrections and credit notes
The safe pattern in every country is the same: never edit an invoice that was already sent. Raise a credit note or the authority's refund document that points to the original, then issue a new invoice if needed. Your system must store the reference between the two. Uganda also has debit notes for a sale that was understated. For the Uganda case in detail, see our guide to EFRIS credit notes and errors.
Failed submissions need a plan too: a rejected item code, a tax category that does not match, a buyer detail the authority will not accept. Your software should show the cashier a clear message, keep the sale, and let a supervisor fix it without breaking the numbering.
What changes country by country
Uganda
EFRIS ties into how products and tax categories are set up, so your item list and tax mapping need to be clean before you connect. URA says the taxpayer bears the cost of system-to-system integration, and that the API route suits high-volume businesses. If you are a software or IT company in Uganda, you may be in one of the designated sectors yourself: see EFRIS for IT and software companies and do I need EFRIS.
Kenya
The first design question is the route. KRA says you can build and certify a system-to-system integration yourself or use a KRA-verified third-party integrator, and either way it involves development, testing, vetting and certification against a sandbox. The second reason Kenyan customers ask software vendors about eTIMS early is expenses: since 1 January 2024 KRA requires a business expense to be supported by an electronic tax invoice to be claimed, with listed exclusions such as salaries, imports and services from non-residents with no permanent establishment in Kenya. Confirm the current rule on KRA's site.
Tanzania
The fiscal receipt model is built around the fiscal device. A virtual fiscal device is what lets a software product issue a receipt without a physical unit at the counter, subject to the TRA's rules for who may use one. The reporting side runs through EFDMS.
Rwanda
EBM sits at the point of sale. Check which EBM options and connection methods the RRA expects for your type of business before you design the integration, and ask the RRA directly if its published material is unclear.
None of this is a legal opinion. We build to the authority's published specification, and your business still has to register and keep to its own obligations. We are not accredited or approved by any tax authority, and nothing on this page should be read to suggest otherwise. Where an authority runs a certification or vetting step, the result is that authority's decision.
Where your software needs integration
Whatever the country, the same parts of your product tend to need work:
- Item and tax setup: every product or service maps to the tax category and item code the system expects.
- Invoice creation: numbering, buyer details, currency and the data the authority returns, such as a number or QR code, must appear on the document.
- Offline queue: sales are stored, sent later and never duplicated.
- Returns and credit notes: every correction links back to the original sale.
- Reporting and reconciliation: your books and the authority's records should match, with a screen that shows what has not yet been sent.
- Access and audit trail: who issued, changed or retried what, and when.
The right architecture is one internal invoice model with a thin adapter per country, so adding Rwanda after Uganda does not mean rewriting your core. That work sits squarely in API development and integration, and it is a fixed-scope job once the specification and your current code are known.
Our team in Kampala works East Africa Time (UTC+3), which overlaps the UK and European working day and the start of the US East Coast day. A US team member joins client video calls, so your product and compliance owners have one clear conversation instead of a relay.
When you should not hire us
You may not need a custom build. Be honest about these cases first:
- Your ERP or POS vendor already ships a connector for your country and your customers are happy with it. Use that and keep your money.
- You only need to issue your own invoices at low volume. KRA describes eTIMS as free software with a web portal and apps, and URA offers an app and desktop software alongside the API route. A business like that rarely needs an integration.
- You want a legal ruling on whether a specific customer must use a system. Ask the authority or a tax adviser. We build software, not tax rulings.
- Your product is not stable yet. Integrating a tax system into a changing invoice model burns budget. Settle the model first.
Hire us when you have a working product, customers asking for compliant invoices in more than one country, and no spare senior engineers to read four specifications and keep up as they change.
How we quote and work
Growth Informer Software Services is a US-based company with remote teams around the world, including a team in Kampala, Uganda. We have shipped 37 live website and app builds listed on our portfolio, and we run our own products, including a cloud POS and business management system. You get a fixed quote before work starts, a 50/25/25 payment plan, and you own the code and the data.
The first step is small: you send the countries, the software you invoice from and who your end customers are, and we reply with the questions that decide scope. For a custom build the guide price is , and the final fixed quote depends on how many countries and how much of your current code we must touch.
Frequently asked questions
What is the difference between EFRIS and eTIMS?
EFRIS is Uganda's system, run by the Uganda Revenue Authority, and covers every VAT-registered business plus 12 designated sectors. eTIMS is Kenya's, run by the Kenya Revenue Authority, and KRA says all persons engaged in business must use it. Both get sales data to the tax authority, but they have different connection routes, item and tax setup, and correction rules. An integration for one cannot simply be reused for the other.
Does one integration cover Uganda, Kenya, Tanzania and Rwanda?
No. The sensible design is one internal invoice model with a separate adapter for each country. Your core product stays the same, and each adapter handles that authority's connection method, offline handling and correction process.
How much does an East Africa e-invoicing integration cost?
Custom builds start from a guide price, which is shown here: . The final number is a fixed quote based on the countries, the specification you must follow and the software you already run, and you receive it before any work starts.
Are you accredited by the tax authorities?
No, and we do not claim to be. We build to each authority's published specification. Your business still needs to register and meet its own obligations with the authority in each country.
What happens if the internet goes down at the till?
A good integration stores each sale locally, marks it unsent, retries when the connection returns and never renumbers or duplicates a sale. In Uganda, URA allows offline issuing for up to five days through the app, desktop software or a system-to-system connection. In Kenya, KRA's VSCU route is for businesses not always online. For Tanzania and Rwanda, confirm the rule with the authority before you rely on it.