What Is eTIMS and Why It Matters

Kenya Revenue Authority (KRA) operates the Electronic Tax Invoice Management System — eTIMS — as the country's mandatory tax compliance platform for all VAT-registered businesses. Every sale, purchase, and stock movement that carries a tax implication must be reported to KRA in real time through eTIMS. Businesses that fail to submit, submit late, or submit incorrect data face penalties and risk being flagged for audit.

Before iVendNext introduced native eTIMS integration, retail operators in Kenya had two options: manually export transaction data from their point-of-sale system and upload it to the KRA portal, or run a separate compliance tool alongside iVendNext. Both approaches created duplicate work, introduced the possibility of human error, and made it difficult to maintain a consistent audit trail. A busy cashier handling hundreds of invoices a day could not realistically be responsible for a parallel compliance workflow.

iVendNext solves this by embedding eTIMS compliance directly into the transaction lifecycle. When a POS Invoice is submitted in iVendNext, the compliance data flows to KRA automatically — without any additional steps for the cashier. The integration works through Slade360 Advantage, a KRA-approved middleware provider that sits between iVendNext and the eTIMS API. This means iVendNext does not connect to KRA directly; all submissions are routed through Slade360, which handles the protocol, authentication, and KRA-specific formatting requirements.

The Role of Slade360 Advantage

Slade360 is not a simple pass-through — it actively manages authentication tokens, translates iVendNext payloads into the format KRA expects, and returns confirmation responses including the QR code that appears on a compliant receipt. From the operator's perspective, it is invisible: the cashier submits an invoice, iVendNext sends it to Slade360, Slade360 forwards it to KRA, and the QR code returns to the invoice record within seconds.

If Slade360 is temporarily unreachable, iVendNext continues to operate normally. The eTIMS submission is queued and retried without blocking the transaction — compliance reporting is never allowed to interrupt retail operations.

Configuring iVendNext KRA eTIMS Settings

Before any transactions can be submitted to eTIMS, a System Admin must configure the integration through the iVendNext KRA eTIMS Settings document in iVendNext Desk. This is a per-company configuration, meaning retail businesses operating multiple entities in iVendNext will need a separate settings record for each company.

The settings document contains several groups of fields, each serving a distinct purpose.

Company and activation fields identify which company the settings apply to and whether the integration is currently live. The Is Active flag is the master switch: when set to inactive, all eTIMS hooks across the entire company are silently bypassed. This is useful during initial setup, testing, or when temporarily suspending submissions for a specific entity. The Sandbox Environment checkbox switches the integration to Slade360's test environment, allowing the team to validate the configuration without sending data to KRA's live system.

Connectivity fields define how iVendNext reaches Slade360. The Server URL is the Slade360 API endpoint; the Auth Server URL is the authentication endpoint used to obtain and refresh access tokens. These URLs differ between sandbox and live environments. The Client ID, Client Secret, Auth Username, and Auth Password are credentials issued by Slade360 when the business registers for the service. These are stored securely: the secret and password fields are encrypted at rest in iVendNext.

KRA identity fields identify the business to the revenue authority. The Tax Payer's PIN (TIN) is the KRA-issued tax identification number for the company. The Branch ID (bhfid) is the KRA branch identifier assigned to each physical trading location. Both must be correctly entered before any submission can succeed — KRA uses them to associate incoming data with the correct taxpayer record.

Auto-submission controls determine which transaction types are submitted automatically. Separate toggles exist for sales (POS Invoices), purchases (Purchase Invoices), and stock movements (Stock Ledger Entries). Disabling a toggle means that category of transaction will not be submitted automatically, though manual submission options may still be available. This granular control is useful when a business is rolling out the integration in phases — for example, going live with sales first and enabling stock submission once the warehouse team is trained.

Retry limits set the maximum number of background submission attempts for each transaction type before the system stops retrying. If an invoice reaches its retry limit without a successful submission, it will appear in the failed submissions view for manual intervention. Setting these limits too low in an unstable network environment can lead to unnecessary manual work; setting them too high can cause background queues to fill up.

Organisation Mapping is a child table that links the company's iVendNext entity to its corresponding Slade360 organisation, branch, and department identifiers. At least one row must be present and valid before any submission can succeed. These identifiers are provided by Slade360 when the business account is set up on their platform.

Token Management and Security

iVendNext manages Slade360 access tokens automatically via a scheduled background job that refreshes them regularly. Retail operators do not need to manage this manually. If a token becomes invalid — for example, because credentials were changed on the Slade360 side — the integration logs an authentication error and the System Admin updates the credentials to restore the connection.

No eTIMS credentials are stored in plain text. Client Secret and Auth Password fields are encrypted at rest, and access to the eTIMS Settings document is restricted to the System Manager role.

Sandbox vs. Live: Testing Before Going Live

Every retail business implementing Kenya eTIMS compliance should validate the integration thoroughly in sandbox mode before switching to live submissions. Slade360 provides a dedicated test environment that mirrors the live KRA API but does not transmit data to KRA's production system. Transactions submitted in sandbox mode do not create real tax records and carry no compliance obligations.

During sandbox testing, teams should verify that POS Invoices submit successfully and return a QR code, that return invoices generate correct credit notes, that items register without errors, and that customer and supplier records sync to the partner registry. The QR code returned in sandbox mode is a test QR code and will not scan as a valid KRA receipt — this is expected behaviour and not an error.

Once sandbox testing is complete and the team is confident the configuration is correct, the System Admin changes the Environment field to live, disables the Sandbox Environment checkbox, and updates the Server URL and Auth Server URL to the Slade360 production endpoints. From that point, all submissions flow to KRA's live eTIMS platform.