Skip to main content
This is where compliance pays off: you submit a sale, the platform pushes it to KRA over OSCU, and KRA returns a signed receipt (ETR number). You can then issue credit notes to reverse accepted sales.

Prerequisites (read this first)

A sale will fail unless these are true. They are the most common stumbling blocks:
  1. The item is synced to eTIMS. A registered-but-not-synced item is rejected with “Item has not been synced to eTIMS”. → Catalog
  2. For goods, there is enough stock. Selling a GOODS item deducts inventory, so it fails with “Insufficient stock” if there isn’t enough on hand — add stock first → Stock. SERVICE items are non-stock: skip this entirely; they can be sold right after syncing. See Goods vs Services.
So the working order is:

Create a sale

This is asynchronous — you get a syncBatchId immediately; the receipt arrives once KRA accepts. See Tracking Results.

Request body

For valid receiptTypeCode, paymentTypeCode, and invoiceStatusCode values, see Codes & Values. Line item:

The submit query flag

By default a sale is submitted to the OSCU pipeline. To persist a sale without submitting to KRA (e.g. staging a draft), pass ?submit=false:

Sale outcome

A sale is processed asynchronously and ends in one of two outcomes:
  • Accepted — KRA signed the invoice; the sale carries a KRA receipt number (e.g. ETR-…).
  • Rejected — the submission failed; a human-readable reason is available.
Confirm the outcome via List sales or dashboard sync monitoring.

Read sales

List sales (thin proxy to compliance):
Query params: before, after, startDate, endDate, pageSize (all optional). Get a single sale by its id:

Express credit notes

To reverse an accepted sale, raise an express credit note referencing the sale’s id:
“Express” means the platform derives the credit note lines from the original sale, so you don’t re-send line items. The result is a separate CREDIT_NOTE document. Like sales, it accepts ?submit=true|false.

Common errors