Kenya eTIMS E-Invoicing Bridge

The problem

The Kenya Revenue Authority's eTIMS programme requires that a tax invoice be transmitted to KRA and receive back a control unit code before it is a valid deduction for your customer. That is a per-document, near-real-time obligation. Zoho Books is a complete accounting system — it issues invoices, credit notes, tracks VAT at 16%, exempt and zero-rated rates, and produces the VAT3 figures you need — but it has no native channel to KRA's eTIMS endpoints. There is no field to hold a control unit serial number, no place for the KRA invoice number, and no way to print the QR code that a compliant invoice must carry.

So Kenyan businesses on Zoho Books end up running two systems. An invoice is raised in Zoho Books, then re-keyed into an eTIMS client or a spreadsheet, then transmitted, then the returned codes are copied back into a PDF that is edited by hand. Every re-key is a chance to transpose a figure. Every month-end, somebody reconciles what Zoho says was sold against what KRA says was transmitted, and the two never agree on the first pass.

What ECOSIRE builds

ECOSIRE builds a middleware bridge that lives inside your Zoho organization and treats Zoho Books as the single source of truth. Nothing is re-keyed.

Transmission engine

The core is a set of Deluge custom functions in Zoho Books, triggered by workflow rules on the Invoices, Credit Notes and Customer Payments modules. When an invoice moves to Sent — or to whatever status your policy dictates — the function assembles the eTIMS payload from the Zoho Books record: customer PIN, item lines with their tax classification codes, unit of measure, quantity, unit price, taxable amount and tax amount per line, and the document totals. It signs and posts that payload to the eTIMS endpoint over the credentials held for your branch, then parses the response.

The returned control unit invoice number, receipt signature, internal data and transmission timestamp are written back to custom fields on the Zoho Books invoice. A Deluge-generated QR payload is stored so your invoice template can render it. From that moment, the Zoho Books record carries its own proof of transmission.

Item and tax mapping

Most of the real work in an eTIMS project is mapping, not transport. ECOSIRE builds a mapping layer — held either in a Zoho Creator application or in a dedicated Zoho Books custom module, depending on your item count — that maps each Zoho Books item to its KRA classification code, packaging unit and quantity unit, and maps each Zoho Books tax rate to the corresponding eTIMS tax type. Items missing a mapping are surfaced in an exception list before they ever block an invoice.

Failure handling and retry

Network calls fail. A Zoho Flow scheduled flow, backed by a queue record for each pending document, retries failed transmissions on a defined interval with capped attempts. Documents that exhaust their retries raise a Zoho Cliq or email notification to a named finance owner. Nothing fails silently, and no document is transmitted twice — the bridge checks for an existing control code before posting.

Credit notes and reversals

Credit notes are transmitted as the corresponding eTIMS document type, linked to the control code of the original invoice so KRA sees the relationship. Zoho Books credit notes applied against an invoice pass the original document reference through automatically.

Reconciliation console

A Sigma widget, embedded in Zoho Books, gives finance a single view: documents transmitted this period, documents pending, documents failed with their error text, and the variance between Zoho Books output VAT and transmitted output VAT for the period. That variance figure is what you check before filing.

Purchases

Where your scope requires it, the bridge pulls purchase records available to your PIN from eTIMS and stages them for matching against Zoho Books bills, so input VAT claims are supported by what KRA already holds.

Who this is for

Businesses running Zoho Books as their books of account in Kenya and registered for VAT — distributors, wholesalers, professional services firms, retailers with a back-office Books organization, and multi-branch operations that need branch-level transmission credentials. It suits organizations with a real item catalogue, because that is where mapping effort concentrates. It also suits accounting firms managing several client organizations, since the bridge is deployed per Books organization.

How delivery works

Scoping call. We walk your Zoho Books organization: item count, tax rates in use, branch structure, document types issued, current invoice template, and who owns the KRA credentials. We confirm which eTIMS onboarding route applies to you and what you already have registered.

Fixed quote. You receive a written scope with the exact custom fields, functions, flows and widgets to be built, the mapping approach, and a fixed price. No hourly billing.

Build. ECOSIRE develops the Deluge functions, custom fields, workflow rules, Zoho Flow flows, the mapping store and the Sigma widget. Typical build is two to four weeks from confirmed scope, driven mostly by mapping volume and by how quickly credentials are made available.

Install in test. We deploy into a sandbox or test Books organization and transmit against the eTIMS test environment. You issue real-shaped documents and inspect the returned codes and the printed invoice.

Install in production. After your sign-off we deploy to the live organization, switch to production credentials, and run a supervised first batch with your finance team on the call.

Support. A defined support window follows go-live for defect fixes and configuration adjustments, with a written handover of every function, field and flow so your own team or another developer can maintain it.

ECOSIRE is an independent development firm. This is bespoke software written for your organization; it is not a certified or endorsed product of any tax authority or software vendor.