Buyer-Initiated eTIMS API for Procurement Platforms

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 models ordinary sales invoices and buyer-initiated invoices under the same merchant and authentication conventions, with replay protection for their creation operations. Buyer invoices use a dedicated resource because seller consent and procurement evidence require a distinct lifecycle. The detail and consent HTTP routes still need namespace parser repair; internal lifecycle events do not establish public webhook subscription availability.

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.
• Buyer-invoice event subscriptions are not currently accepted by the public webhook registration API.
• Separate invoice sequences and correction rules where KRA requires them.

The intended 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 lifecycle below is a design and compliance model, not an executable public API walkthrough. The namespaced detail and consent handlers are unavailable pending namespace parser repair; neither consent simulation nor audit-detail inspection is established by a successful creation response.

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 offers a partial buyer-invoice preview. Creation and listing are outside the identified parser defect, but detail and consent are unavailable pending namespace parser repair. Listing is not a substitute for immutable audit-detail inspection. Public buyer-invoice webhook subscriptions are not accepted. These statements reflect source review, not an exercised end-to-end HTTP workflow. Risiti does not send live buyer invoices to KRA; live access still requires the applicable KRA route, approval evidence, production gates and end-to-end pilot.

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.