eTIMS

eTIMS JSON Format in Kenya: How Invoice Data Is Structured (2026)

K By Kev 23 June 2026 8 min read
Share
eTIMS guide

eTIMS JSON format is a question for any Kenyan business or developer connecting their own systems to KRA eTIMS. An eTIMS integration sends invoice data in a structured format, commonly JSON, containing the seller, buyer, item lines with tax, totals and the fields KRA needs. The exact JSON structure, field names and types are defined in KRA's official documentation, so build against that rather than a guessed schema. This guide explains the concepts and the practical approach, what to confirm in KRA's official documentation, and when you can skip the build entirely with compliant software. Technical specifics change, so treat KRA's official eTIMS documentation as the source of truth.

Key takeaways
  • eTIMS integrations send structured invoice data, commonly JSON, with seller, buyer, lines, tax and totals
  • The exact field names, types and required values live in KRA's documentation and change
  • Match the schema precisely; wrong types or missing required fields fail validation
  • Build against KRA's current structure and validate in the sandbox, not from old examples
On this page
  1. How eTIMS invoice data is structured
  2. How to approach it
  3. What to check before you build
  4. A developer matches the schema
  5. When you can skip the integration
  6. Frequently asked questions

How eTIMS invoice data is structured

When a system sends an invoice to eTIMS, it sends structured data, commonly as JSON, rather than a printed document. Conceptually that data carries the same things a compliant invoice shows: the seller details and PIN, the buyer PIN, the item lines with quantity, price and tax treatment, the totals and tax, and the fields KRA uses to register and sign the invoice.

The key discipline for a developer is that the exact JSON, the field names, nesting, data types and required values, is defined by KRA in its official documentation and changes over time. Guessing the structure or copying an old example leads to validation failures. So the useful knowledge here is the shape of the problem and the requirement to build against KRA's current schema, not a fixed example reproduced out of date.

The cheapest eTIMS integration is often the one you do not have to build, certify and maintain yourself.

How to approach it

A practical path. Confirm exact technical details against KRA's official documentation.

  1. 1

    Work from KRA's schema

    Get the current invoice data structure from KRA's official documentation. It defines the exact field names, types and required values.

  2. 2

    Map your invoice model to it

    Map your system's invoice fields to KRA's structure, ensuring tax treatment per line and buyer PIN are populated correctly.

  3. 3

    Validate types and required fields

    Check data types and required fields match exactly, since a wrong type or a missing required field triggers a validation error.

  4. 4

    Test against the sandbox

    Send test invoices to KRA's environment, read any validation responses, and correct the structure until it validates cleanly.

What to check before you build

Copying an old example payload

An old JSON example goes stale. Build against KRA's current documented structure to avoid validation failures.

Getting data types or required fields wrong

A wrong type or a missing required field fails validation. Match KRA's schema precisely.

Not reading validation responses

KRA's responses tell you what failed. Read them and correct the structure rather than guessing.

A developer matches the schema

Worked example

A developer building an eTIMS integration assembled an invoice payload from an example found online, and it kept failing validation on a field type.

They rebuilt the structure from KRA's current documented schema, matched every field name and type, populated the tax treatment per line and the buyer PIN, and read the validation responses to refine it.

Once the payload matched KRA's current schema exactly, invoices validated cleanly, where the stale example never would have.

Business impact

Trading without eTIMS-compliant tax invoices risks KRA penalties, blocked VAT input claims for your customers, and receipts a business buyer cannot expense.

Veira signs every sale to KRA eTIMS automatically, so each receipt is compliant the moment it prints, with no separate device to reconcile.

When you can skip the integration

The biggest decision here is whether you need to build an integration at all. Veira is already a compliant eTIMS system: it issues compliant KRA invoices automatically, applies the right tax treatment, captures the buyer PIN, transmits to KRA, and works offline. For many businesses that removes the need to build, certify and maintain a custom integration yourself.

If you do run an ERP or a custom stack, weigh the cost of building and maintaining an integration against running point of sale and invoicing on Veira and reconciling. Veira runs from KES 2,999 a month with a free terminal and a 30-day money-back guarantee. See how Veira works, or book a free demo to talk through your setup.

Frequently asked questions

What format does eTIMS use for invoice data?
An integration sends structured data, commonly JSON, carrying the seller, buyer PIN, item lines with tax, totals and the fields KRA needs. The exact structure is defined in KRA's official documentation and changes, so build against that.
What fields are in an eTIMS invoice payload?
Conceptually the same things a compliant invoice shows: seller and PIN, buyer PIN, item lines with quantity, price and tax treatment, totals and tax. The exact field names and types are in KRA's documentation.
Why not just copy an example JSON?
Example payloads go stale as KRA updates the schema, so copying one causes validation failures. Build against KRA's current documented structure and validate in the sandbox.
Do I need to handle the JSON myself?
Only with a custom integration. Compliant software like Veira builds and maintains the correct payloads against KRA's schema for you, so you never touch the JSON.
Do I have to build my own eTIMS integration?
No. Compliant software like Veira already issues and transmits compliant eTIMS invoices, so many businesses do not need to build, certify and maintain a custom integration. Build only if your stack genuinely requires it.
Where is the authoritative eTIMS technical spec?
KRA's official eTIMS API documentation is the source of truth for endpoints, payloads, control units and requirements. Specifics change, so build against the current official documentation, not third-party summaries.

eTIMS JSON format comes down to the concepts above plus KRA's official documentation for the exact details, and for many businesses the simplest path is compliant software that handles it for you. See how Veira works, or book a free demo. Always build against KRA's current official eTIMS documentation.

For more eTIMS guides and compliance resources, visit our free resource site.

Terms explained

Keep reading

See all eTIMS guides

Veira for your business

Browse Veira by business type