Every filing season, the same thing happens. In the final hours before the deadline, millions of taxpayers hit iTax at once, and the portal buckles under its own weight: congestion, dropped sessions, the occasional 504 timeout at the exact moment it matters most.
KRA has spent years telling people to file early. It hasn't worked, because early filing was never really the problem. Filing is still a manual, high-pressure task, and most businesses, reasonably, put it off until they have no choice but to sit down and do it. When the portal falls over in that final window, the cost isn't just annoyance. It's penalties, interest, and explaining a missed deadline to KRA despite a genuine, timely attempt to file.
The bottleneck is architectural, not behavioural
For most of its history, iTax has been a walled garden: one portal, manual entry, a small set of authorized intermediaries. When every taxpayer in the country treats that single door as the only way in, the infrastructure hits a ceiling every peak season. That's not a bug. It's the predictable output of the design.
There's already a working alternative model in Kenya, and it didn't come from government.
What "Daraja for tax" could look like
Safaricom's Daraja API is probably the most successful piece of digital infrastructure Kenya has shipped in over a decade. Instead of one consumer app, it exposed a secure, developer-facing bridge; and let thousands of businesses embed payments directly into their own ERPs, websites, and point-of-sale systems. No manual portal logins. No single moment where the whole country hits the same server.
Apply that same logic to tax, and a few things follow:
- Compliance becomes invisible. Accounting software syncs transaction data with KRA continuously, instead of someone manually uploading a spreadsheet once a quarter.
- Load gets decentralized. If ERPs and POS systems handle tax functions directly, there's no single moment where the entire country hits the same server at once.
- Errors drop by design. A system fed automatically from a business's actual ledger has far less room for the manual mistakes that trigger disputes and audits later.
- Local fintech gets a new market. Treat KRA as an API provider instead of just a gatekeeper, and Kenyan developers get room to build tax-ready tools that make compliance a selling point instead of a chore.
This isn't hypothetical, it's already starting
Gava Connect is the first real move in this direction: official APIs for verification, nil filing, and status checks. It's an early step toward what some are calling "Tax Administration 3.0" - tax functions embedded directly into the tools people already use, instead of a separate destination they have to visit under deadline pressure.
The direction is right. As that infrastructure matures, the last-minute rush stops being an annual national event and becomes a non-issue, because compliance happens continuously in the background instead of in a once-a-year sprint against a portal everyone's hitting at once.
We've already built smaller versions of this for our own clients, through two different paths. For some, it's a system-to-system integration via the DigiTax API. For others, we've gone direct: setting up KRA's own Virtual Sales Control Unit software on the client's infrastructure ourselves, working straight from KRA's API documentation, with no intermediary between us and the tax authority. Either way, sales data flows through automatically as transactions happen, and compliant invoices get generated without a spreadsheet or a portal login anywhere in the process.
Remittance stops being something someone has to remember to do under deadline pressure. The system just does it, continuously. The same underlying idea as a Daraja payment settling in the background without anyone reconciling it by hand. It's a preview, at client scale, of exactly the pattern Gava Connect is trying to build nationally.