From 1 January 2026, KRA's Income and Expense Validation Engine automatically cross-checks every income and expense entry in a tax return against eTIMS invoice data. From the 2026 Year of Income, declared expenses — not just income — must be supported by valid eTIMS invoices. Your deduction now depends on whether your supplier invoiced you correctly.
That last sentence is the whole change. Until now, eTIMS was mostly a question about your own outgoing invoices: were you generating them, were they reaching KRA, did the numbers match what you filed. The validation engine keeps that question and adds a second one pointing the other way. Every cost you claim is checked against an invoice somebody else was supposed to generate.
A caveat before anything else: we are engineers, not tax agents. Nothing here is tax advice. Confirm the treatment of any specific expense with your accountant or a registered tax practitioner. What we can tell you is what your systems have to produce, so that whatever your accountant confirms is actually supportable when KRA's engine runs the comparison.
What the validation engine actually does
The mechanism is simple, which is why it is effective. KRA already holds the invoice data — every eTIMS invoice, from every registered taxpayer, with buyer PIN, date, line items and amounts. The return you file is a set of totals. The engine reconciles the second against the first.
If you declare an amount in a deductible expense category and the eTIMS records show invoices to your PIN totalling less than that, the difference is visible without anyone opening a file. It is the reconciliation your finance team does manually against supplier statements, run automatically across every taxpayer at once.
For engineering, that means a mismatch between your billing system and eTIMS has stopped being a filing inconvenience. It is now a rejected deduction. Different failure mode, different cost, different urgency.
The IFMIS integration raises the stakes for government suppliers
On 31 August 2026, KRA and the National Treasury announced the integration of eTIMS with IFMIS, the Integrated Financial Management Information System, as part of the government's Digital Transformation Agenda.
For anyone invoicing a government entity, this changes the order of operations. A supplier must now generate a valid eTIMS invoice before submitting for payment through IFMIS. And the invoice details submitted to the government entity must correspond precisely with what was generated and recorded in eTIMS.
"Precisely" is the operative word. If your system lets a user edit an invoice after eTIMS generation but before the IFMIS submission — a changed line description, a rounded amount, a corrected PO reference — you have built a mechanism that produces unpaid invoices.
Most billing systems allow exactly that, because until August 2026 it was harmless. Go and check whether yours does.
One source of truth, or a monthly reconciliation job forever
The architectural point is narrow, and it matters more than anything else here.
Generate the eTIMS invoice from the same record that feeds your internal reporting. Not from a copy. Not from an export. The same row, the same amounts, the same line items, with the eTIMS invoice number and control unit details written back onto that record when KRA acknowledges it.
If you maintain two sources of truth — an internal invoice and a separate eTIMS submission — they will diverge. Not because anyone is careless, but because every credit note, every rounding difference, every cancelled-and-reissued invoice and every retry after a timeout is a chance for the two to disagree. You then need a monthly reconciliation process to find the disagreements, forever. That job is overhead created by an architectural decision, and it is avoidable.
The practical shape of it: your invoice record holds an eTIMS status field (pending, submitted, acknowledged, failed), the returned invoice number and control unit details, and a timestamp. Nothing goes to a customer or a government entity until that status reads acknowledged. Retries are idempotent, so a resubmission cannot create a second eTIMS record. And corrections go through credit notes rather than edits, because eTIMS records are not a mutable table and your system should not pretend otherwise.
We covered the mechanics of getting data into eTIMS in our eTIMS integration guide for Kenyan businesses. This piece is about what the 2026 changes mean for how the system is built, not about the API calls themselves.
Choosing your integration method honestly
eTIMS comes in several forms, and the pressure is usually toward the most complex one. It is a volume and control decision, so here is the honest version.
The online portal — entering invoices one by one on KRA's web interface. Right if you issue a handful of invoices a month and your accounting lives in a spreadsheet. Manual, and it has no integration cost. For a consultancy issuing a dozen invoices a year, building anything else is waste.
eTIMS Lite — built for small and service businesses. Lower friction than the client modules, and no engineering project required. If you are a small service business without a custom billing system, start here and stop here. A lot of unnecessary software gets built by businesses that would have been fine on eTIMS Lite.
Client modules (OSCU / VSCU) — these sit closer to your own billing. Right when you have a real billing system and meaningful volume, but not enough to justify a full API programme. The online variant suits businesses with reliable connectivity; the virtual variant fits setups where invoicing happens across several points.
Full API integration through a KRA-approved integrator — right when you invoice in volume, when invoicing is an automated part of your product rather than a finance task, or when the IFMIS precision requirement makes a human retyping invoice details an unacceptable risk. It is the most expensive path and the one that needs ongoing maintenance. Choose it because your volume demands it, not because it sounds more serious.
The failure we see most often is a business with thirty invoices a month commissioning an API integration, and one with three thousand still typing them into the portal.
Your suppliers' compliance is now your problem
This is the part that catches finance teams off guard. If a supplier does not issue you a valid eTIMS invoice, the validation engine has nothing to match your claimed expense against. Their non-compliance shows up in your return.
So vendor onboarding has to change, and most of the work is not code:
- Capture and validate the KRA PIN at onboarding, before the first purchase order — not at the first payment run.
- Ask directly whether the supplier is eTIMS-compliant, and by which method. A supplier still on manual invoices is a supplier whose invoices may not support your deduction.
- Make an eTIMS-valid invoice a condition of payment in your procurement terms. Payment is the only pressure that reliably works.
- Put a gate in accounts payable: an invoice with no eTIMS details does not enter the approval queue. Doing this in software beats doing it in a policy document, because the software is the thing that actually runs.
- Report the gap monthly. "Expenses recorded with no matching eTIMS invoice reference" should be a query you can run, and the answer should be zero long before filing season.
What this changes
This quarter, if you invoice in Kenya: confirm your billing system writes the eTIMS acknowledgement back onto the same invoice record your reports read from. If it writes to a separate table or a separate system, that is the first thing to fix.
If you supply government entities: lock the edit path. No invoice mutation between eTIMS generation and IFMIS submission, enforced in code rather than in a process note.
If you are a small service business: check whether eTIMS Lite covers you before anyone quotes you for an integration.
In accounts payable: add the PIN and the eTIMS question to vendor onboarding now, and build the missing-invoice report before the year closes.
Across all of it: your accountant decides what is deductible. Your system's job is to make sure the evidence exists, is consistent, and can be produced without a spreadsheet exercise in March.
Kenyan teams are usually doing this alongside payment work — the same invoice record that carries the eTIMS acknowledgement is often the one reconciling an M-Pesa payment through Daraja, and getting both to agree on one record is most of the job. That combination is a large part of what we build for clients in Kenya.