Payment Approval Workflows in Kenyan Banks: Maker-Checker and Delegated Authority

Short answer: A sound payment approval workflow in a Kenyan bank puts every internal expense and supplier payment through maker-checker: one person raises it, at least one other person with the right delegated authority approves it, and neither can do both. Approvers are chosen from a delegated authority matrix by department, payment type and amount; overdue approvals escalate on a deadline; and the system keeps evidence of each step that internal audit and examiners can rely on.

This article is for CFOs, heads of finance and operations, internal auditors and IT teams at Kenyan banks and microfinance banks. It deals with the bank's own payments: supplier invoices, internal expenses, petty cash and staff reimbursements. It does not cover customer transactions such as transfers or cheque clearing, which run through core banking and payment systems with their own controls. Creodata builds payment approval software for Kenyan organisations, so we say where we fit near the end. This is practical guidance, not regulatory advice; confirm requirements with your compliance function and auditors.

Why banks need a formal payment approval workflow

The Central Bank of Kenya's prudential guidelines expect banks to maintain sound internal controls, including segregation of duties, defined approval authorities and audit trails. Internal audit, external auditors and CBK examiners will test whether the bank's own spending follows those principles as closely as its lending.

In practice, the bank's own payments are often the weakest link. Credit approvals run through a governed system while supplier invoices are approved by email, a signed paper voucher or a message. The risks are familiar:

• Approvals that cannot be evidenced. An email saying "approved" is hard to link to a specific payment and easy to lose.
• Authority exceeded. Nobody checks that the approver's limit covered the amount.
• Split payments. A large invoice broken into several smaller ones to stay under a limit.
• Self-approval. The person who raised the payment also approved it, often while covering for a colleague.
• Bottlenecks. A payment waits on one executive for weeks, and suppliers chase the wrong people.

What maker-checker means for payments

Maker-checker (also called four-eyes) is a simple rule: the person who creates a transaction cannot be the person who authorises it. For payments, that usually expands into three roles:

1. Maker (requester): raises the payment request and attaches the invoice, quotation or receipt.
2. Checker (reviewer): confirms the request is valid, correctly coded and supported. Often finance.
3. Authoriser (approver): holds delegated authority for the amount and releases the payment.

Larger payments add more checkers, for example a head of department, a finance reviewer and the CFO. The system, not the people, should enforce that the maker cannot appear later in the same chain.

How to build a delegated authority matrix

A delegated authority matrix (sometimes called a delegation of authority or DoA schedule) sets out who can approve what, up to what amount. It normally comes from a board-approved policy. A simplified example for a bank's own payments:

The figures are illustrative; use your own policy. Whatever the numbers, a matrix works in a system only if:

• It is resolved automatically from the department, payment type and amount on the request, not chosen by the requester.
• Thresholds are data, not code. Finance should be able to change a limit when the board changes the policy, without a software release.
• Changes are recorded. Who changed a limit, and when, is itself audit evidence.
• Delegation during leave is explicit. When an approver is away, their authority passes to a named deputy for a defined period, and the record shows the deputy acted.

Segregation of duties beyond maker-checker

Maker-checker is the starting point. Examiners and auditors also look at:

• Who can change the matrix versus who approves payments. These should be different people.
• Who can change supplier bank or M-Pesa details versus who approves payments to them. Changed payment details are a common fraud route.
• Who releases the payment once approved. Ideally, payment follows automatically from final approval, so nobody can change the amount or beneficiary in between.
• Who can edit the audit trail. Nobody should, including administrators.

SLA escalation: keeping approvals moving

A strict workflow can create its own problem: payments stuck waiting for a busy executive. Late supplier payments damage relationships and, where contracts carry penalties, cost money.

SLA escalation solves this without weakening control. Each approval stage has a deadline. When it passes, the request moves to the next approver in the chain or to a designated alternate, and the escalation itself is recorded. Good practice:

• Set deadlines per stage and payment type (a petty cash approval can reasonably be faster than a large capital invoice).
• Notify the original approver when their item is escalated.
• Report escalations by approver and department. Repeated escalations are a management signal, not only a system event.
• Never let escalation skip the control: an escalated request still needs someone with the right authority.

What audit evidence should the system produce?

For any payment internal audit or an examiner selects, you should be able to produce, from one record:

If assembling that pack takes an afternoon, the evidence exists but is not controlled. Our article on audit-ready expense workflows goes deeper on this.

What to look for in payment approval workflow software

• Approval chains resolved from department, request type and amount, configurable by finance.
• Maker-checker enforcement, including blocking self-approval. Test it in the demo.
• SLA escalation with an audit entry for each escalation.
• Payment on final approval, so nobody re-enters the amount or beneficiary.
• Ledger posting with documents linked.
• Single sign-on with your directory, so leavers lose access immediately.
• Role dashboards for requesters, approvers, finance and the CFO, and exports for audit.

The expense management buyer's guide for Kenya includes a scripted demo you can adapt.

Where Creodata fits

Our payment approval software is part of Creodata's expense management system, built in Nairobi on the Microsoft stack. For a bank's own payments, it provides:

• Three request types: supplier invoices, petty cash and cashbook payments, each submitted with attachments.
• Sign-in through Microsoft Entra ID single sign-on.
• Multi-stage approval chains, for example Head of Department, Finance Reviewer, CFO, resolved per department and request type, with an amount threshold (KES 10,000 on the reference configuration) deciding the route. Chains and thresholds are configurable.
• Automatic SLA escalation: a durable orchestration watches pending approvals and escalates overdue ones to the next approver, with an audit entry.
• Payment on final approval over M-Pesa B2C (petty cash and reimbursements) or M-Pesa B2B (suppliers), with callback reconciliation and the payment reference written back to the request.
• Posting to Microsoft Dynamics 365 Business Central over OData, with SharePoint document links attached.
• Role dashboards for submitters, approvers, finance reviewers, the CFO and administrators, with CSV exports.

What we do not do: we do not make bank or PesaLink payments, which many banks use for larger supplier payments; we post only to Business Central; we run on Microsoft Azure rather than on-premises; and we do not process customer transactions. If on-premises hosting or another ERP is a requirement, we are not the right fit. For document management across the bank, see our EDMS solutions.

To test your own delegated authority matrix in a live workflow, book a demo.

Frequently asked questions

What is maker-checker in payment approval?

Maker-checker means the person who creates a payment request cannot also approve it. At least one other person with the right authority must check and authorise it before payment. In a system, this should be enforced automatically, not left to good behaviour.

What is a delegated authority matrix?

It is a schedule, usually approved by the board, that sets out who may approve which types of payment and up to what amount. A payment approval system should read the matrix to route each request, so the requester cannot choose their own approver.

Does CBK require maker-checker for bank payments?

CBK's prudential guidelines expect banks to maintain internal controls including segregation of duties and audit trails. They do not prescribe a specific tool. Confirm how your bank's policies apply these expectations with your compliance function.

How does SLA escalation work in a payment approval workflow?

Each approval stage has a deadline. If an approver does not act in time, the request moves to the next approver or an alternate, and the escalation is recorded. This keeps payments moving without removing the control.

Can payment approval software handle supplier payments and staff expenses together?

Yes. A system with separate request types, such as supplier invoices, petty cash and cashbook payments, can apply a different approval chain and threshold to each while keeping one audit trail and one set of reports.