System Integration Consultant, Kenya

The systems around a Kenyan ERP

Integration design starts with a complete picture. For a Kenyan trading, manufacturing or distribution business, the inventory usually includes:

• eTIMS: the route by which invoices and credit notes reach KRA, either directly from the ERP, through a third-party integrator's connector or through a separate tool. Which route suits you is confirmed with your tax advisor and the provider.
• M-Pesa: Paybill and Till collections, B2C payouts to agents or suppliers, and the statements behind them.
• Banks: statement imports, supplier payment files and sometimes direct connections offered by the bank.
• Payroll: a provider or payroll system handling statutory deductions and posting journals to the ERP.
• Branches and depots: POS terminals or branch systems recording cash, card and mobile money sales.
• Sales channels: a webshop, marketplace listings or a CRM sending orders.
• Logistics: clearing and forwarding agents, transporters and warehouse tools for imports and deliveries.
• Reporting: Power BI or another BI tool combining ERP and channel data.

Every entry records the content, frequency and transport of the flow, plus the person who would spot a stoppage. Sometimes the answers reveal a single staff member exporting statements every morning, or a connector built by a developer who is no longer reachable. Those become the first priorities. The ERP consultant page for Kenya places these integrations in the wider system picture.

eTIMS as an integration, not a checkbox

Most ERP and accounting vendors in Kenya will say their product works with eTIMS. That statement covers a wide range of designs, and the differences show up in daily operation. I treat eTIMS as an interface with its own specification rather than a feature to tick.

The questions the specification answers include:

1. Which documents must be transmitted, and at what point in the sales process, as confirmed with your tax advisor.
2. Which route carries them: the ERP's own module, a third-party connector or middleware, and who maintains it.
3. Which master data must be clean first, such as customer PINs, item classifications and tax codes, and which system owns each.
4. What the ERP does while transmission is pending or fails: whether the invoice can be printed, how it is flagged and who resends it.
5. How each credit note points back to its original invoice, so both records match on KRA's side.
6. How branches with weak connectivity queue documents and how the backlog clears.

Testing covers normal invoices, credit notes, zero-rated or exempt items where they apply, long outages and duplicate submissions. Finance compares ERP totals with eTIMS records for a test period before go-live. Requirements can change, so the specification names who monitors KRA guidance and who updates the connector. If your eTIMS setup has already caused mismatches, the ERP audit page for Kenya explains how I review it.

Mobile money and bank flows at field level

Receipt matching rules are a finance design question, covered in my business analysis work. The integration question is how the data physically reaches the ERP and how it stays correct when things go wrong. For M-Pesa and bank flows, I specify:

• Source: real-time payment notifications through the provider's APIs or an aggregator, scheduled statement downloads, or both, with the statement used to catch anything notifications missed.
• Identifiers: the M-Pesa transaction code or bank reference stored on every receipt and used to reject duplicates, since notifications can be sent twice.
• Mapping: which fields carry the payer's phone number, name, account reference and amount, and how each maps to customer, invoice or suspense.
• Settlement: how collections move from mobile money to the bank and how charges are recorded.
• Reversals: how a reversed transaction is recognized and what it undoes in the ERP.
• Payouts: how B2C payments to agents, suppliers or refunds are created, approved and confirmed.

Bank flows follow the same pattern: which bank channel is used, how often statements arrive, which fields identify the customer and how supplier payment files are approved and returned. Dollar accounts are specified separately, with the exchange rate source agreed with your accountant.

Each flow ends with a daily control: totals in the ERP compared with the provider or bank, with differences sent to a named person. The ERP business analyst page for Kenya covers the matching rules themselves.

Connectivity, queuing and branch systems

A Kenyan integration design has to assume that some links will drop. Branches outside major towns, depots on generator power and reps on mobile data all lose connection from time to time. An integration that fails quietly in those moments creates gaps that surface weeks later as missing sales or unbalanced stock.

I design for interruption from the start:

• Local queuing: POS terminals and branch systems keep recording sales offline and hold them in a queue until the connection returns.
• Ordered replay: queued records are sent in sequence, with identifiers that let the ERP reject anything it has already received.
• Status visibility: head office can see which branches have unsent records and how old they are.
• Hosting choices: middleware and integration services hosted where connectivity is reliable, so one branch outage does not stop other flows.
• Fallback procedures: what staff do when an outage lasts longer than expected, written in the runbook.

Stock is the hardest part. If two branches sell the same item while offline, the ERP must decide how to handle a temporary negative balance. I agree those rules with operations and finance before the build, because the answer is a business decision, not a technical one.

Testing includes deliberate disconnections: switching off a branch link mid-shift, resending a day's queue and checking that totals match. Retail and distribution businesses will find related context on the distribution industry page.

Builders, testers and long-term owners

My role is design and oversight. The build is done by your ERP implementer, in-house developers or an integration specialist, often a Kenyan firm that can support the system locally. I write the requirements and mappings they build from, review their approach, compare the delivered connector with the written design and join the test cycle.

Choosing the method is part of the design. For each interface I compare:

Ownership is a frequent weak point. A developer builds a working connector, hosts it on a personal account and later becomes unreachable. To avoid that, the design states that source code, hosting accounts, API credentials and documentation belong to your company, held in your own repositories and accounts from the first day.

After go-live, each interface has logs, alerts to named people and a runbook. A responsibility table names who handles eTIMS failures, unmatched receipts and branch backlogs. The CRM consultant page for Kenya and the Kenya page describe related remote services.