Business Automation Consultant, Kenya

Receipts that allocate themselves, mostly

Allocating customer payments is often the largest daily manual task in a Kenyan finance team. A distributor pays through Paybill with an account reference that may or may not match an invoice, a retailer pays from a personal phone, a corporate customer pays several invoices in one bank transfer. Someone reads every line and decides.

Once the allocation rules are agreed, automation can do most of the reading. The design I specify works in layers:

1. Exact match: a valid account reference or invoice number on the payment closes the invoice automatically.
2. Known payer: a phone number or bank account already linked to a customer assigns the payment to that customer, oldest invoice first or as your rules state.
3. Suggested match: amount and date patterns produce a suggestion that a person confirms.
4. Unknown: anything else goes to a short list with the payer details, and stays there visibly until someone resolves it.

Duplicate checks on the M-Pesa transaction code prevent the same payment being applied twice. The automation never writes off differences or issues credit notes; those remain decisions for finance. How payment data physically reaches the ERP, through provider APIs or statement files, is integration work described on my system integration page for Kenya. This page is about removing the human matching once the data is there.

Following up eTIMS failures and withholding certificates

Two tax-related follow-ups consume a lot of time in Kenyan companies, and both are ideal for automation because the rules are clear once your tax advisor has confirmed them.

Invoices that did not complete their eTIMS step. Whatever route your system uses, some documents will fail: a missing customer detail, a connection drop, an item without the right classification. Automation can collect these into a daily exception list, group them by cause and send them to the person who can fix each one. A document that stays unresolved escalates to a supervisor. The automation does not change tax data on its own; it makes sure a person sees the problem quickly.

Withholding certificates owed by customers. When a customer deducts withholding and pays short, the difference needs a certificate to support your credit claim. Automation can:

• flag short payments that match an expected withholding amount;
• open an entry in the certificate register against the invoice;
• send scheduled, polite reminders to the customer's finance contact;
• alert the account manager when reminders go unanswered;
• close the entry when the certificate is received and filed.

The register then shows finance and management, at any time, which certificates are outstanding and from whom. The underlying routine, including who owns each step, comes from process work for Kenya.

Approvals and advances for people on the road

Many Kenyan managers spend much of their time away from a desk: visiting branches, depots, sites or customers. Approvals wait for them, and the business waits with them. Automation can shorten that wait without weakening control.

The approach I design has a few principles:

• Light notifications: approval requests reach the manager as a short message or email with the key facts and a link, readable on a phone with a weak connection.
• Clear limits: the approval matrix decides who receives each request, and amounts above a limit require a second approver.
• Escalation and stand-ins: if a request waits beyond an agreed time, it moves to a named deputy rather than sitting idle.
• Audit trail: every approval records who approved, when and from which channel.

The same pattern works for petty cash and imprest. Advances requested by drivers, field staff or site supervisors are approved through the same route, paid as your finance team decides, and tracked. Reminders go out automatically when receipts for an advance are overdue, and a new advance can be held until the previous one is cleared.

For simple request and approval apps that the ERP does not handle well, a low-code tool such as Zoho Creator can hold the form and workflow. The approval workflow page shows how this looks inside an ERP.

AI document capture and data protection

Branches and depots in Kenya generate a lot of paper: supplier invoices, delivery notes, fuel receipts, signed proof of delivery. Typing them in at head office is slow, and losing them creates audit problems. AI reading can help, provided it is used carefully.

The flow I specify is straightforward. Staff photograph the document on their phone, the image is stored with the transaction, AI or OCR extracts the key fields and business rules check them: supplier, amount, date, PIN where relevant, order reference. A person confirms the result before anything is posted. Documents the AI cannot read with confidence go straight to a person rather than being guessed. Images can be queued on the phone and uploaded when the connection returns.

AI can also draft responses to routine customer questions about balances or deliveries, and summarize a customer's payment history before a credit decision. It does not approve credit, release payments or change prices.

Kenya has its own data protection law, and documents can contain personal data about customers, suppliers and staff. The choice of AI or cloud provider, where it processes data and on what contract terms is for whoever owns data protection in the company, with legal input; I assemble the information they need. Originals must remain available as your tax advisor and auditor require. My wider approach appears under AI business automation.

What stays manual, who builds and how results are judged

Some steps should stay with people, and I write them down as part of the plan. In Kenyan companies these usually include changes to supplier bank or M-Pesa payout details, release of payment batches, write-offs and settlement of disputed balances, credit limit decisions and the treatment of unusual tax situations. These decisions carry accountability, and several of them are common targets for fraud.

Responsibilities for building are agreed up front. The rule book, exception paths and test list are mine to write, and I configure the flows your platform can run without code. Custom code, new payment or tax connectors and changes to accounting logic go to a developer, your implementer or an integration firm, working from my specification. I review their work and join testing, including tests with a connection deliberately cut.

After launch, every flow carries two owners, one from the business and one technical, plus a one-page runbook, alerts that reach an actual person and a pause switch. Automations built on someone's personal account or a forgotten script are moved into a supported setup.

Results are judged in plain terms with the teams affected. Is the unallocated list shorter at the end of each day? Are eTIMS failures fixed the same day? Do managers approve without being phoned? Are certificates arriving without repeated chasing? Automations that stop helping are adjusted or retired. The Kenya overview and my ERP consultant page for Kenya describe the rest of my remote support.