TaxID connects your Kenyan invoicing, accounting or POS software to invoice submission, receipt lookup and reconciliation through one API.
Server-side API-key authentication. Use your assigned API URL and branch PIN. No client ID or client secret is required.
With your client configured and invoice mapped:
# invoice: your mapped SaleInvoice receipt = client.submit_sale( invoice, idempotency_key="INV-2026-001", ) print(receipt["cuInvoiceNumber"])
import os from kra_etims import KRAeTIMSClient, SaleInvoice, calculate_item, build_invoice_totals client = KRAeTIMSClient( api_key=os.environ["TAXID_API_KEY"], base_url=os.environ["TAXID_API_URL"]) items = [calculate_item("Synthetic service invoice", "SRV-001", 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"]) # SIMULATED-CU/152 NS
With your mapped invoice saved as invoice.json:
curl "$TAXID_API_URL/v2/etims/sale" \ -H "Authorization: Bearer $TAXID_API_KEY" \ -H "Idempotency-Key: INV-2026-001" \ -H "Content-Type: application/json" \ --data @invoice.json
curl -X POST "$TAXID_API_URL/v2/etims/sale" \ -H "Authorization: Bearer $TAXID_API_KEY" \ -H "Idempotency-Key: INV-2026-001" \ -H "Content-Type: application/json" \ -d '{ "supplierPin": "A000123456B", "amount": 5800.00, "invoiceDate": "2026-10-07", "clientReference": "INV-2026-001", "taxBand": "B", "taxAmount": 800.00, "buyerPin": "P051234567X", "buyerName": "Acacia Enterprises Ltd", "itemDescription": "Synthetic service invoice" }'
{ "purchaseId": 152, "status": "SIGNED", "cuInvoiceNumber": "SIMULATED-CU/152 NS" }
TaxID brings submission, receipt tracking and exception handling into your existing product.
Submit invoices, retrieve receipt fields and look up each sale by its original reference.
Resume an original invoice after evidenced registration recovery. Itemised returns retain original prices and taxes; uncertain corrections and stock operations stay available for investigation. These flows are tested in the simulator; production registration, retail corrections and stock remain gated.
Connect merchant branches with scoped application permissions and expiring, revocable credentials.
Keep branch device configuration and control-unit credentials behind your application’s API integration.
Sandbox withholding accounting keeps estimates, recorded deductions and supplied remittance evidence distinct. Operator approval and refund review preserve the liability; production withholding, automatic remittance and dedicated reverse invoicing remain gated.
Keep your invoice workflow. Connect the fiscal operations through REST or the Python SDK.
Authenticate server-side requests with a branch API key. No client ID or client secret is required.
Send invoice data from your application. Keep the original reference and idempotency key with each request.
Retrieve receipt fields and status by the original reference. Investigate uncertain outcomes before submitting another sale.
Your application maps invoice data; TaxID routes requests to the configured merchant branch. Production requires merchant authorisation and completed branch/control-unit setup.
INV-2026-001
Keep the original reference. The response alone cannot tell you whether signing happened.
In this example, lookup finds the stored SIGNED receipt for the same sale.
Retrieve its fields without submitting another sale. If the outcome is still uncertain, investigate before resubmitting.
Illustrative outcome, not a live submission. SIGNED records control-unit signing, not central KRA acceptance.
Explore a creator sale or retail basket with a local simulation in your browser. No fiscal invoice is issued or submitted to KRA.
Local simulation · synthetic data only. Runs entirely in your browser, with no API connection, fiscal signing, KRA submission, payment or remittance. Refreshing clears the examples.
This local illustration shows an uncertain predecessor holding the sale. Lookup then illustrates recovery after that predecessor resolves.
Creator sale: KES 1,160 including sample VAT. Separately invoice a platform fee of KES 134.56 (KES 116 + 18.56 sample VAT). These demonstrate two invoice obligations. These local examples do not verify separate creator and platform taxpayer authorisation; that requires invited integration testing. Buyer-issued reverse invoicing is unavailable.
Gross-receipts basis; fixture fee is 10% before fee VAT. Category, payer responsibility, residency, exemptions and fee treatment require transaction-specific assessment. Gifts remain unresolved: no gift invoice, withholding or payout is calculated.
Basket: two synthetic notebooks at KES 116 each, and one synthetic tote at KES 58. Sample standard VAT is included. Return one notebook using its original line, price and tax.
Fixture classifications are for the simulator. Production item registration and partial returns remain gated.
Ready to run a local simulation. No API connection is needed.
All statuses and receipt numbers here are browser-generated illustrations. SIGNED does not establish control-unit signing or central KRA acceptance. Lookup demonstrates recovery using the original reference. Financial figures are estimates, not deductions, verified receipts of money or paid payouts.
Current developer access is free and invitation-based. Try your integration in the simulator; no fiscal invoices are issued or submitted to KRA.
TaxID is not yet KRA-approved. Production requires KRA approval, real KRA testing, merchant authorisation and operational acceptance. Production pricing is being finalized.
We’ll email a private invitation when access is available. Open it to create your branch API key and test your integration in the simulator. This request does not grant production access. In the meantime, browse the eTIMS reference docs.