eTIMS for software companies: what an invoice needs, and what your system must do

If your business issues invoices in Kenya, KRA’s electronic Tax Invoice Management System, eTIMS, decides whether those invoices count. If your business builds or runs the software that issues them, eTIMS also decides part of how that software has to work.

This post covers both: what the regime requires of a business, what “eTIMS-compliant invoice” means in fields and control numbers, what that means for any system that generates invoices, and how the integration options differ by volume. It describes the rules as KRA publishes them. It is not tax advice, and your own accountant should confirm how they apply to you.

What the regime requires

The legal basis is section 23A of the Tax Procedures Act, added by the Finance Act 2023. In KRA’s words, it “requires every person in business to record each sale, issue and transmit invoices through an electronic system as prescribed by the Commissioner” (KRA onboarding guidelines). eTIMS is that system.

Three consequences matter most, all from KRA’s eTIMS FAQ unless noted:

• Everyone in business is in scope. “All persons engaged in business are required to on-board eTIMS and issue electronic tax invoices.” This is not limited to VAT-registered businesses.
• Your invoice is your customer’s deduction. “Any business claiming deductions for business expenses must support them with valid electronic tax invoices.” An invoice that did not go through eTIMS can cost your client the deduction, which makes it a commercial problem for you as well as a tax one.
• Returns are checked against the data. From 1 January 2026, KRA validates the income and expenses declared in income tax returns against eTIMS invoices, withholding tax data and customs import records, with exceptions set out in section 23A and the Tax Procedures (Electronic Tax Invoice) Regulations, 2024 (EY, BDO East Africa).

One exception changes who does the invoicing. Where you buy from a small business whose annual turnover does not exceed five million shillings, KRA’s FAQ says “the purchaser shall issue a tax invoice on their behalf.” If your system buys from small suppliers, it may need to raise invoices for them, not only for itself.

What an eTIMS invoice actually contains

The clearest statement of the fields is KRA’s own technical specification for invoicing systems that connect to eTIMS (version 2.0, April 2023). It calls the invoicing software a Trader Invoicing System, and the eTIMS component it talks to a Sales Control Unit: online (OSCU) or virtual (VSCU).

Every receipt must show, as a minimum:

• the taxpayer’s name, PIN, and the address where the sale takes place
• the buyer’s PIN
• the receipt type and transaction type
• a serial number “from an uninterrupted ascending number series per receipt type”
• each item or service with description, quantity and price
• the total, the tax rates applied, and the VAT added
• the means of payment
• the date and time stamped by the invoicing system
• the control unit’s information, printed in a block of its own

That last block is what makes an invoice an eTIMS invoice. When your system sends the invoice data to the control unit, the control unit answers with its identity, its own timestamp, receipt counters and a signature, and the specification says how they must be printed:

Printed as	What it is
SCU Information	The heading of the block
Date and Time	The control unit’s timestamp, not your server’s
CU ID: KRACU04XXXXXXXX	The control unit’s identification
CU invoice number	The CU ID and a sequential receipt number, e.g. KRACU04XXXXXXXX/1
Receipt counter	In the form A/B followed by the receipt label
Internal data	Encrypted data about the receipt, printed with a dash after every fourth character
Receipt signature	Printed the same way
QR code	Invoice date, time, CU number, CU receipt number, internal data and receipt signature, joined by #

Anyone holding the invoice can check it. KRA’s FAQ gives two ways: scan the QR code, or enter the invoice number in the invoice number checker on iTax.

Receipt types, corrections and credit notes

The specification also fixes how invoices relate to each other, which is where most invoicing software needs changing:

• Every receipt is a combination of a receipt type (normal, copy, training, proforma) and a transaction type (sale, credit note, debit note), and carries a label for it: NS for a normal sale, NC for a normal credit note, CS for a copy, and so on.
• Only one original is printed. A reprint carries a “Copy” watermark.
• A transaction cannot be corrected without first cancelling the original, the cancellation must refer to the original receipt number, and an original can be cancelled only once.
• A credit note contains only negative amounts and refers to the original invoice it corrects.

What this means for any system that generates invoices

Read as engineering requirements, those rules come down to a handful of design decisions. They apply whether your system talks to eTIMS directly or a person registers each invoice by hand.

An issued invoice is immutable. Once it has a control unit number it is a fiscal document. Corrections are new documents that point at it, never edits to it. If your invoices table allows an update to the amount of an issued invoice, that path has to go.

Numbering has no gaps, per type. Invoices and credit notes each need their own uninterrupted sequence. A number drawn inside a transaction that rolls back must be released, not skipped, which means drawing it from a locked counter inside the same transaction as the invoice.

Credit notes are documents, not negative invoices. They need their own type, their own sequence, a reference to the original, and the reason for the correction recorded.

The control unit’s answer is stored with the invoice. CU ID, CU invoice number, timestamp, internal data, signature, QR payload. Stored atomically with the invoice and never regenerated, because the printed copy must be reproducible years later exactly as it was issued.

The buyer’s PIN is captured. Your customers’ PINs become required data on the customer record, so a missing or malformed PIN is caught when the customer is set up, not when the invoice is issued.

There are two timestamps. Your system’s and the control unit’s. Keep both.

Copies say they are copies. Re-downloading a PDF a week later must not produce a second original.

The integration options, by volume

KRA’s onboarding guidelines set out who each solution suits:

Solution	KRA’s eligibility, in short
eTIMS Lite (web on eCitizen, or USSD on *222#)	Non-VAT taxpayers with no other active eTIMS solution; small and micro businesses
eTIMS online portal	Services only, no goods, and no more than 10 invoices a month
eTIMS Client (Windows or Android)	Businesses without an invoicing system
OSCU or VSCU	Businesses with an existing invoicing system that needs integrating

Between the two integration options, KRA’s system-to-system page describes OSCU as “suitable for taxpayers whose invoicing is always online” and VSCU as suited to “bulk invoicing” from a system that “is not always online”. Either way the integration is done by self-integration, which goes through KRA’s development, testing, vetting and certification process using its sandbox at etims-sbx.kra.go.ke, or through one of the KRA-verified third-party integrators KRA publishes.

The practical reading for a software company is that the right option changes as you grow. A small services business issuing a few invoices a month is inside the online portal’s limits. A SaaS product invoicing hundreds of subscribers a month is not, and needs its billing system integrated through OSCU, or through VSCU if invoices are generated in batches.

How we handle it in our own invoicing

Kimcard invoices its clients from our own system, so we have made these choices for ourselves. We sell services only, at a volume inside the online portal’s limits, so the system is built to register invoices through KRA’s portal and record the result, not to talk to eTIMS directly.

Concretely, it generates invoices with the fields above and a gapless number, and tracks each invoice’s eTIMS status. Once an invoice is registered, it stores the CU invoice number and the QR payload, prints both on the PDF, and refuses to mark the invoice final for tax until that number exists. Until then the PDF says the registration is pending, plainly, and never claims compliance it does not have. The CU invoice number is unique across all invoices, enforced by the database, because two invoices carrying the same number means one was typed wrong. Credit notes are raised in KRA’s solution against the original and referenced here.

The registration step sits behind a single interface with one implementation today: a person records what KRA’s portal returned. When volume justifies a direct OSCU integration, it becomes a second implementation of that interface, and no invoice code has to change. That is the shape we would recommend to any business whose eTIMS route is likely to change as it grows: design the invoice for the strictest option from the start, and keep the transport replaceable.

Questions for your accountant

Because the rules have consequences for deductions and returns, a few questions are worth putting to your own accountant before you design anything:

• Which eTIMS solution fits our turnover, our VAT status and our invoice volume today, and in a year?
• Which of our purchases fall under the exceptions, and which suppliers will need us to invoice on their behalf?
• How should credit notes and cancellations be handled in our records, and by whom?
• What happens to invoices issued before we onboarded?

If your invoicing system needs eTIMS designed in, that is the kind of work our SaaS product development covers.