Buyer-Initiated eTIMS API for Procurement Platforms | Risiti

Test buyer-initiated eTIMS workflows for agriculture, procurement, marketplaces and aggregators in the Risiti API sandbox.

Buyer-initiated invoicing lets a registered buyer prepare a tax invoice on behalf of a seller who is not positioned to issue it directly. KRA identifies small-scale farmers and informal traders supplying larger buyers as important use cases, and requires seller validation, notification and approval before an accepted invoice reaches eTIMS.

KRA's current guidance separates the eCitizen and USSD Buyer Initiated Invoicing flow from reverse invoicing for structured corporate supply chains. Reverse invoicing uses a buyer's existing billing system, system-to-system integration and KRA approval through a Know Your Customer process. Procurement platforms should establish which route KRA approves for their operating model before implementation.

Risiti's buyer-initiated API is available as a sandbox preview. It supports lifecycle testing but does not claim KRA approval, certification or production availability; live transmission remains locked until the buyer's approved KRA route is configured.

Designed for high-volume supplier networks

The opportunity is strongest where a platform already knows what was delivered, by whom, in what quantity and at what agreed price. Instead of re-keying that purchase into a separate invoicing tool, the platform can prepare the tax-invoice request from the procurement event and keep its state visible until the seller and eTIMS complete the process.

Agricultural aggregators collecting tea, coffee, dairy, grain, horticulture or livestock products.
Manufacturers buying raw materials from distributed small suppliers.
Commodity buyers, cooperatives and outgrower-management platforms.
Marketplaces that already control order, delivery and settlement records.
Logistics and collection platforms connecting verified suppliers to enterprise buyers.

One integration, two invoice directions

The Risiti sandbox keeps ordinary sales invoices and buyer-initiated invoices under the same merchant, authentication, idempotency, webhook and audit conventions. Buyer invoices use a dedicated resource because seller consent and procurement evidence require a distinct lifecycle, without creating a second authentication or operations stack.

An ordinary sales invoice can move from received to eTIMS processing immediately after validation. A buyer-initiated request must first establish seller eligibility and consent. It therefore needs additional states such as awaiting_seller_consent, seller_rejected and consent_expired before eTIMS submission can begin.

Shared merchant and environment model across ordinary and buyer-initiated workflows.
Stable external IDs and Idempotency-Key handling for procurement events and retries.
Explicit seller identity, eligibility evidence and consent references.
Signed webhooks for consent, rejection, expiry, submission and failure events.
Separate invoice sequences and correction rules where KRA requires them.

The sandbox buyer-initiated lifecycle

A platform creates a buyer-initiated invoice request from a completed procurement event. Risiti validates required buyer, seller, item, quantity, price and tax fields, then records the request without treating it as a submitted tax invoice.

The seller must be validated against the applicable KRA rules and notified through the approved consent channel. KRA's current BII guidance gives the seller 30 days to approve or reject a request; an unanswered request is automatically rejected after that period. Only an approved request proceeds to eTIMS, and every initiation, approval, change and submission must remain in the audit trail.

draft or received: the platform has supplied the procurement record.
awaiting_seller_consent: the seller has been notified and no tax invoice has been submitted yet.
seller_rejected or consent_expired: terminal consent outcomes that must not be submitted to eTIMS.
pending or retrying: an approved request is being processed by the integration.
submitted: eTIMS receipt and control-unit fields are available for reconciliation.

Controls enterprise buyers should expect

Buyer-initiated invoicing affects tax records for another party, so production access cannot be a client-side switch. Risiti keeps live capability disabled until the organization, KRA approval route, supplier population, consent mechanism, webhook receiver and operational ownership have been reviewed.

KRA approval and KYC evidence where the reverse-invoicing route applies.
Seller eligibility checks, including the treatment of VAT-registered sellers under current KRA guidance.
A versioned buyer-seller agreement and evidence of seller consent or rejection.
Role-based access, least-privilege API scopes and immutable operator audit events.
Idempotent corrections, credit-note ownership and retention of supporting records.
Monitoring for old consent requests, repeated failures and webhook dead letters.

What a design partner should prepare

Risiti is looking for procurement and supply-chain teams willing to map a real workflow before the API is finalized. The most useful input is not a feature list; it is a sample procurement event, supplier-onboarding process, approval model, expected volume and the operational team responsible when a seller disputes an invoice.

Buyer legal entity, KRA PIN, branches and current eTIMS solution.
Supplier categories, identifiers, VAT status and expected monthly volume.
The event that proves delivery, acceptance, quantity and agreed price.
Consent and notification channels already used with suppliers.
Rejection, correction, dispute, settlement and reconciliation procedures.
Named compliance and technical owners for sandbox and production review.

Availability and product boundary

The Risiti v1 sandbox now supports buyer-invoice creation, seller-consent simulation, signed events and audit inspection. It does not send live buyer invoices to KRA. Live access will be exposed only after the applicable KRA integration route, approval evidence, production gates and end-to-end pilot are complete.

KRA remains the authority for taxpayer eligibility, BII rules, reverse-invoicing approval, technical specifications and production certification. A Risiti design-partner conversation does not constitute approval by KRA.

Frequently asked questions

Does Risiti support buyer-initiated invoicing today?

Yes in sandbox preview for integration and lifecycle testing. It is not a generally available production feature, and sandbox acceptance is clearly marked as simulated rather than a live KRA submission.

Is Buyer Initiated Invoicing the same as reverse invoicing?

They both allow a buyer to prepare an invoice on behalf of a seller, but KRA documents different operating routes. Current BII guidance includes eCitizen or USSD initiation and seller consent, while reverse invoicing is positioned for approved structured buyers using an existing billing system and system-to-system integration.

Who is this API direction for?

It is intended for agricultural aggregators, manufacturers, commodity buyers, cooperatives, marketplaces, logistics and collection platforms that already hold reliable procurement and supplier records.

Can a seller reject a buyer-initiated invoice?

Yes. KRA's current BII guidance requires the seller to approve or reject the request. It states that sellers have 30 days to respond, after which the pending request is automatically rejected.

Can buyer-initiated requests use the ordinary invoice endpoint?

No. Use POST /v1/buyer-invoices in sandbox. It shares keys, merchants, idempotency, webhooks and logs with ordinary invoices while keeping seller consent and audit states explicit.

Does joining the design-partner programme provide KRA approval?

No. KRA's current eligibility, KYC, technical and production requirements remain authoritative and separate from Risiti's product design process.