Kenya’s transition toward digital tax administration has made electronic invoicing an important part of everyday business operations. For teams handling many transactions, the practical challenge is connecting an invoice with the sale, accounting entry, payment and supporting records that explain it.
Prefer a printable version? Download the eTIMS integration checklist (PDF) to use in your project meetings.
For the VAT, PAYE and withholding tax records that sit alongside your invoices, see KRA tax reporting and automation.
This guide focuses on the operating questions to resolve before connecting an ERP invoicing workflow to KRA eTIMS. It complements the introductory guide with a preparation, testing and reconciliation checklist.
What ERP and eTIMS integration needs to connect
KRA describes system-to-system integration as an API connection between a taxpayer’s invoicing or ERP system and eTIMS. Its guidance distinguishes the Virtual Sales Control Unit (VSCU) for bulk invoicing that is not always online, and the Online Sales Control Unit (OSCU) for invoicing that is always online. KRA also describes testing, vetting and certification as part of the integration process. Confirm the suitable route and current requirements with KRA and your implementation team.
An integration project therefore needs more than a connection test. Agree where the commercial invoice is created, how its submission status is recorded and how the finance team will identify transactions that need attention. Keep the ERP invoice reference and the relevant submission response connected so a person can follow the transaction without comparing unrelated spreadsheets.
Prepare the invoice data before testing
Start with a small, representative set of customers, products and services. Review customer details, item descriptions, units of measure, agreed tax treatment and the way discounts appear on an invoice. Resolve duplicate or incomplete records before importing a large dataset. Your tax adviser or responsible finance lead should validate the applicable treatment; software configuration should follow that decision.
Write down who can create, approve, amend and review invoices. Separate a draft commercial document from an issued transaction in the operating procedure. Agree what supporting information a reviewer needs, how exceptions are assigned and who can approve a correction. These decisions help the team evaluate an integration against its actual work.
Create a small data dictionary for the fields the integration will use. Identify the business owner, source and validation rule for each important value, and distinguish required information from optional detail. Review item and customer examples with the finance team before using them in a larger test set. When a field is corrected, keep the reason and the affected scenario in the test record so the relevant checks can be repeated. The dictionary should describe the proposed configuration and the current official specification; it should not become a separate list of assumed tax rules. Confirm any uncertain classification with the person responsible for the organisation’s tax treatment.
Test complete business scenarios, including exceptions
Ask for a demonstration using a straightforward sale, a discount, an invoice correction or credit, and the transaction types your organisation actually uses. Compare the source invoice with the returned status and the accounting record. Where branches, multiple users or high volumes matter, include those conditions in the test plan rather than assuming a single successful invoice represents the whole operation.
Also test an interrupted connection, a rejected request and a user pressing submit again. Ask how the proposed solution identifies a pending transaction, prevents an accidental duplicate and gives an authorised person a safe recovery route. These are evaluation questions: obtain evidence of the proposed setup rather than assuming every ERP handles them in the same way.
Keep a test log with the scenario, expected result, actual result and unresolved issue. Assign an owner to each issue and repeat the relevant test after a correction. Agree the acceptance criteria before the team switches its live invoicing process.
For each exception test, record the source transaction, the action taken, the response observed and the state presented to the user. Ask how the proposed integration distinguishes a request that failed before submission from one whose outcome is not yet known. The recovery procedure should be demonstrated and agreed for that setup; repeated submission should not be the default response to uncertainty. Use only the test environment and records authorised for the project. Keep the provider’s explanation, the result and any remaining limitation together, so a successful recovery in one scenario is not taken as evidence that every interruption has been covered.
Reconcile invoicing with finance records
Set a review routine that compares issued invoices, submission statuses, credits and the sales ledger for the same period. Investigate missing references, unexpected amounts and transactions still awaiting attention. A successful submission is one check; the finance team still needs to explain how the transaction appears in its accounts.
Decide who reviews exceptions each day and who signs off period-end differences. Keep the explanation and supporting documents with the transaction wherever your agreed records process permits. Connecting finance and accounts with invoicing can make these relationships easier to review, but an integration does not replace the team’s accounting controls or tax responsibilities.
Treat invoice acceptance, the accounting entry and the customer payment as separate reconciliation questions. An accepted invoice does not establish that a customer has paid, and a payment reference does not establish that the invoice submission was accepted. Choose a reporting period and follow each source reference through the records that answer those questions. Review credits, corrections and unallocated receipts with the responsible finance user. Where a total differs, document the reason and the proposed action before changing the underlying record. This approach gives the team a consistent way to investigate a difference while keeping the commercial, submission and collection status of the transaction distinct.
Questions to ask before choosing an integration
Scope: Which invoice types, business entities and branches are included? What is excluded, and what requires a separate configuration or service?
Responsibilities: Who supplies credentials, validates tax setup, cleans the source data and approves the tested workflow? Ask the provider to explain the applicable integration and onboarding responsibilities without assuming a certification or approval that has not been verified.
Support: How are rejected or pending transactions investigated? Who monitors service changes, communicates incidents and maintains the connection? Agree the handover documents and escalation route before go-live.
Commercial terms: What is included in implementation, training, ongoing support and any integration-related charges? Request a written scope so that software, configuration and support can be evaluated together.
Plan a controlled handover
Choose a cutover plan that identifies the last transactions in the old process and the first in the new one. Train the staff who issue invoices and the finance users who reconcile them. Define a fallback procedure, an escalation contact and a short review period for the first live transactions. Keep unresolved test issues visible until the responsible team accepts their resolution.
Prepare a handover pack that the operating team can use without relying on the project team being present. Include the agreed invoice flow, the information needed to investigate an exception and the people responsible for decisions. Identify who monitors pending work, who can authorise a correction and when an issue is escalated. Keep credentials and personal information out of ordinary issue notes; use the access arrangements approved for the project. Agree how changes to the integration will be reviewed and tested before they affect live invoicing. The first operating review should check actual exceptions and unresolved actions against this pack, rather than simply confirming that the connection remains available.
For a product discussion, explore VisionONE eTIMS integration and bring a representative invoice workflow to a demonstration. Confirm the scope and evidence for your own operation before selecting a solution.
Official source and related reading
Source checked on 2 November 2026: KRA: eTIMS system-to-system integration. KRA is the source for the integration-route and onboarding requirements described above. The preparation and testing steps are operational guidance, not a statement that a particular business or product has been certified.
For the broader software decision, use the ERP selection checklist and review how the proposed setup will connect invoicing, controls and daily financial work.
