Beyond the Invoice: What Else Must Be Reported to KRA

Most retail teams, when they first learn about eTIMS compliance, focus on invoices. Invoices are the most visible output of any POS system and the most direct way KRA tracks VAT. But Kenya Revenue Authority's data requirements extend further than sales transactions. KRA also requires businesses to maintain a registered item catalogue, report inventory movements, and keep the partner registry — customers, suppliers, and payment types — accurate and up to date.

iVendNext's eTIMS integration addresses all of these requirements. Items must be registered in Slade360 before they can appear on a compliant invoice. Stock movements must be reported whenever goods enter or leave the warehouse. Customer and supplier records must be reflected in KRA's partner registry, and payment modes must be mapped to eTIMS accounts. This article explains how iVendNext handles each of these areas.

Item Registration: Preparing Your Catalogue for KRA

KRA requires every product sold through eTIMS to be registered with specific tax classification data before it appears on an invoice. This registration happens in Slade360, and iVendNext triggers it automatically when an item is saved — but only if the item has all the required eTIMS fields populated.

There are six eTIMS fields that must be completed on every Item record before iVendNext will attempt registration:

• Item Classification — the HS (Harmonised System) code that categorises the product for trade and tax purposes

• Product Type — the eTIMS product type code

• Item Type — the eTIMS item type code

• Taxation Type — the tax category (KRA uses categories A through E, representing different VAT treatments)

• Packaging Unit — the eTIMS code for how the item is packaged (each, box, carton, etc.)

• Unit of Quantity — the eTIMS unit of measure code

• Country of Origin — the country where the item was manufactured or produced

If any of these fields are missing when the item is saved, iVendNext will throw a validation error listing the specific fields that need to be completed. The item cannot be saved until the data is provided. This validation exists to prevent a situation where an item is used on an invoice but fails to submit to eTIMS because it was never registered — an error that would only become visible at the point of sale.

When all required fields are present, iVendNext's background job calls Slade360's ItemsSearchReq endpoint. If the item already exists in Slade360 (for example, because it was registered through another channel), the system retrieves its Slade360 identifier. If it does not exist, Slade360 creates it and returns a UUID. iVendNext stores this UUID in the ivendnext_etims_slade360_id_mapping record, which links the iVendNext Item to its Slade360 counterpart.

Once an item is registered, the custom_item_registered flag on the Item record is set to 1. At this point, the item is locked against deletion — iVendNext will block any attempt to delete a registered item with an error message. This protection ensures that no item with a KRA registration record can be removed from iVendNext, which would create an orphaned record in Slade360 and a potential compliance gap.

For businesses with large product catalogues that predate the eTIMS integration, the Item list view includes a Bulk Register Items action. This allows a System Admin to select multiple unregistered items and trigger registration for all of them in a single operation, rather than opening and saving each item individually.

Customer and Supplier Sync

KRA maintains a partner registry — a database of the business entities that a taxpayer trades with. iVendNext keeps this registry current by syncing Customer and Supplier records to Slade360 automatically whenever they are created or updated.

When a new Customer is saved in iVendNext, a background job calls Slade360's BhfCustSaveReq endpoint, passing the customer's details including their Tax ID if one is recorded. On a successful response, a Slade360 ID mapping record is created for that customer, confirming the sync. The same process applies to Suppliers.

For B2B customers where a Tax ID is required, iVendNext enforces entry at the customer record level — saving a customer without a Tax ID when the require_tax_id flag is active will throw a validation error, preventing incomplete records from reaching the KRA registry.

For partners created before the integration was configured, the eTIMS Settings document provides Submit All Customers and Submit All Suppliers bulk actions. Finance Managers typically run these as part of the go-live checklist before the first live submission.

Mode of Payment Mapping

Every payment method configured in iVendNext — cash, card, M-Pesa, voucher, and so on — needs a corresponding mapping in Slade360's accounts registry. This mapping ensures that the payment type reported on each eTIMS invoice matches a recognised account type in KRA's system.

Unlike items and customers, Mode of Payment mapping is triggered manually using the Submit to eTIMS button on the Mode of Payment form. iVendNext calls Slade360 to locate the corresponding eTIMS account and create the payment method mapping; on success, custom_submitted_successfully is set to 1. This is a one-time setup task that must be completed for all active payment modes before the first live invoice submission, as payment type is a required field in the eTIMS payload.

Stock Movement Reporting

KRA requires businesses to report inventory movements — goods receipts, stock adjustments, and stock reconciliations — to eTIMS, not just sales. This gives KRA a complete picture of the business's inventory position, allowing them to cross-check that the goods sold are consistent with the goods received.

In iVendNext, every inventory transaction generates a Stock Ledger Entry (SLE) — an internal record that tracks what moved, in what quantity, and to or from which warehouse. When stock auto-submission is enabled in eTIMS Settings, iVendNext automatically attempts to submit each new SLE to Slade360.

The submission follows a three-step asynchronous flow. First, iVendNext submits the stock movement header (StockMasterSaveReq) and receives a Slade360 UUID stored on the SLE as custom_slade_id. Second, it submits the line-item details (StockMasterLineReq). Third, it calls the transition endpoint (StockAdjustmentTransitionReq) to move the record to PROCESSED status. Only when all three steps succeed is custom_submitted_successfully set to 1. Because each step is discrete, a failure at step two or three can be retried from that point without repeating earlier steps.

Not all stock movements are reported to KRA. Material Transfer entries — internal transfers between warehouses within the same business — are excluded, as they do not represent a tax event. iVendNext detects these by checking the Stock Entry type on the SLE and skips submission entirely for those records.