One call from your POS or ERP; a KRA-signed receipt comes back — offline-capable, tax math included. We run the VSCU, cmcKey, and Z-reports so you never learn eTIMS. Neutral infrastructure: we power your product, we never sell to your customers.
from kra_etims import KRAeTIMSClient, SaleInvoice, calculate_item, build_invoice_totals client = KRAeTIMSClient("", "", api_key="txd_sb_••••••••") items = [calculate_item("MacBook Pro M3", "HS847130", 5800, "B")] # Band B = 16% VAT receipt = client.submit_sale( SaleInvoice(tin="A000123456B", bhfId="00", invcNo="INV-2026-001", custNm="Acacia Enterprises Ltd", confirmDt="20260311120000", itemList=items, **build_invoice_totals(items)), idempotency_key="INV-2026-001", ) print(receipt["cuInvoiceNumber"]) # KRACU0100000001/152 NS
curl -X POST https://api.taxid.co.ke/v2/etims/sale \ -H "X-API-Key: txd_sb_••••••••" \ -H "X-TIaaS-Idempotency-Key: INV-2026-001" \ -H "Content-Type: application/json" \ -d '{ "supplierPin": "A000123456B", "amount": 5800.00, "invoiceDate": "2026-03-11", "taxBand": "B", "taxAmount": 800.00, "buyerPin": "P051234567X", "buyerName": "Acacia Enterprises Ltd", "itemDescription": "MacBook Pro M3" }'
{ "purchaseId": 152, "status": "SIGNED", "type": "SALE", "cuInvoiceNumber": "KRACU0100000001/152 NS", "sdcId": "KRACU0100000001", "receiptSignature":"A1B2C3D4E5F6...", "kraQrPayload": "11032026#143022#KRACU...", "vscuTimestamp": "20260311143022" }
KRA eTIMS is law, not a recommendation. In force since 1 January 2026, every VAT-registered business in Kenya must transmit invoices in real-time via eTIMS. Non-compliant invoices are ineligible for expense deduction under Section 16(1)(c) of the Income Tax Act — and iTax is now actively cross-referencing 2025 expense claims against PIN numbers on transmitted invoices.
Before your first signed receipt, you own all of this. Every item is a production incident waiting to happen.
The JAR is not publicly downloadable. It requires formal device registration and KRA approval. Approval timelines are not published and not guaranteed.
One JAR instance per branch — no horizontal scaling. Kubernetes StatefulSet with a dedicated PVC. One misconfigured volume mount overwrites your device state and resets your KRA activation.
The cryptographic machine code key must be AES-256-GCM encrypted at rest. It cannot appear in logs, stack traces, environment variable dumps, or Kubernetes secret output. Key rotation must be hot, zero-downtime, and auditable.
Per VSCU Spec v2.0 §2.2 Policy 4: after 24 hours without KRA connectivity, the VSCU JAR stops issuing receipt numbers. No workaround exists. You must monitor connectivity continuously and auto-generate KRA Downtime Notification Letters at the 15-minute mark.
Z-reports reset the VSCU day counter — irreversible per KRA TIS v2.0 §21.6.1. Your retry logic must be bounded to 3 attempts maximum to prevent a duplicate day-reset if the original command was processed but the HTTP response was lost.
Gaps in the rcptNo sequence trigger KRA audit flags. Duplicates on the same sdcId are a compliance violation. You need gap detection, duplicate detection, and a physical UNIQUE(sdc_id, rcpt_sequence_number) DB constraint.
Three-phase outbox protocol to prevent double-signing. SHA-256 payload validation before every replay. Exponential backoff with jitter. Survives pod restarts. Replay in chronological order. Back-fill all signed receipt fields into the original purchase record.
Row-level security on every table. Distinct AES-256-GCM keys per branch. Branch 001 must never be able to read the Electronic Journal or cmcKey of Branch 002. KDPA 2019 §4.7 compliance is a legal obligation, not optional hardening.
We've built and operate all of the above. It took us months.
Set a price and a tax band, then sign. The exact VAT split the SDK sends to KRA — and the fiscal receipt — build in front of you.
The tax math is real — the exact split the SDK sends to KRA. The signature and QR are sample-format; live ones come from KRA's control unit against your registration.
Most teams are signing receipts in their sandbox environment within a few hours of receiving credentials.
Fill in the form below. We provision your sandbox environment and send you an X-API-Key pointed at KRA's sandbox — the same VSCU device, isolated from production.
Install the Python SDK or call the REST API directly. One function call per transaction — sign a sale, issue a credit note, adjust stock. The offline queue and Z-reports require zero code on your end.
When you're ready, swap your sandbox credentials for production credentials. We handle KRA VSP certification, VSCU deployment, and cmcKey provisioning on our side. Your integration code doesn't change.
Every feature below is live and validated against KRA's sandbox environment.
PostgreSQL-backed queue survives pod restarts. Three-phase outbox ensures the VSCU is never called twice for the same transaction — no duplicate receipt numbers. Replay in chronological order on KRA restore.
Daily Z-reports auto-submit at 23:59 EAT. Bounded to 3 retry attempts — the VSCU day-reset is irreversible per KRA TIS v2.0 §21.6.1. After 3 failures, a CRITICAL alert fires and automatic retrying permanently stops.
Row-level security enforced at the PostgreSQL layer. Distinct AES-256-GCM keys per branch. Branch 001 cannot read Branch 002's Electronic Journal or cmcKey — guaranteed at the database constraint level, not just application logic.
Send unregistered suppliers a confirmation request via SMS or WhatsApp. On YES reply, TaxID generates a Category 5 reverse invoice on their behalf. For suppliers below KShs 5M turnover who can't issue eTIMS receipts independently.
Monotonic sequence counter on every rcptNo. Continuous gap and duplicate detection. Physical database constraint on (sdc_id, rcpt_sequence_number). You know before KRA does.
AES-256-GCM encrypted at rest. Zero-downtime hot rotation without a pod restart. Version-tracked per device — every rotation increments an audit column. The raw key never appears in logs, stack traces, or API responses.
We're onboarding early partners now. Waitlist members get sandbox access immediately, input on pricing before it's published, and guaranteed early access to production.
Join the waitlistDevelopers ask how fast they can integrate. Finance asks what the risk is. Three answers:
Every receipt is KRA-signed and transmitted in real time. Non-compliant invoices lose expense deductibility under Section 16(1)(c) of the Income Tax Act — TaxID keeps every sale on the right side of that line.
Self-hosting the VSCU can run past KES 1M in the first year once you count the build, the always-on infrastructure, and ongoing maintenance — before any fiscal risk. TaxID is a subscription and an afternoon's integration.
Signing keeps working through KRA outages, and the platform is maintained continuously. Your electronic journal is yours — exportable on demand — and the integration is standards-based, so you're never trapped in a proprietary format.
KRA VSP certification is in progress — you can build and go live on the sandbox today. Certification & security details →
resultCd values, including production-only codes
absent from the official KRA spec document.
pip install taxid-etims) built for high-throughput workloads.
If your stack is Odoo, ERPNext, Sage, or a custom Java/PHP backend, the REST API integrates cleanly.
Node.js and PHP SDKs are planned. Reach out if you need help scoping an integration for a specific ERP.
Sandbox is live and free. We provision credentials manually during early access — usually within one business day.
Production access opens after KRA VSP certification. Everyone on this list gets notified first, ahead of any public launch.
We've received your request and will be in touch. In the meantime, browse the eTIMS reference docs — all 30 KRA error codes, including production codes absent from the official spec.