The Person Who Keys the Bill Cannot Approve It
Most supplier fraud does not start at the bank. It starts with a bill that should not exist, keyed by someone who could also approve it. Since 14 October the person who enters or last edits a supplier bill cannot approve it — the rule the payment run already had, moved to the document where the money is first promised.
The short version
Give the approve-supplier-bills permission to people who do not key bills, and check that at least two active people hold it. From then on, every bill in your workspace has passed two pairs of eyes before it can be paid, and every payment run has passed two more. A one-person finance team is not locked out: when nobody else can approve, the person who keyed it still can.
When an auditor in Nairobi walks through accounts payable, the first question is rarely about the bank. It is about who can create a liability. A bill is a promise to pay, and once it is approved it is payable: it sits in the ageing, it is picked up by the next payment run, and from that moment the money is spoken for. If the same person can key that promise and approve it, every control after it is checking the wrong thing.
The rule
A supplier bill records who created it and who last edited it. When someone tries to approve it, AWRA compares them with both. If they are either one, and anyone else active in your workspace holds the permission to approve supplier bills, the approval is refused with a plain message: someone other than whoever entered this bill has to approve it.
Last edited is the part that matters most in practice. A rule that looked only at the creator would let a clerk take a correctly keyed bill, change the amount or the supplier, and approve their own change. Editing a bill makes you one of its makers, whoever started it.
- On the web, in the app and through the API the same rule applies, because it sits in the one place a bill is approved rather than on a screen.
- Approval is still what posts the bill. An expense bill journals on approval; a bill against a purchase order is checked against the order total and its tolerance, and the three-way match is recorded on the order.
- The approver is recorded on the bill with the time, beside the person who created it, so the separation is visible on the document rather than asserted.
A one-person team is not locked out
Plenty of organizations that run AWRA have one person doing the books: a school bursar, the administrator of a small NGO office in Kisumu, the owner of a hardware shop who is also its accountant. A rule that demanded a second approver who does not exist would not create segregation of duties. It would stop suppliers being paid, and the first thing anyone would do is create a second login to get round it — which is worse than no rule at all.
So the check asks a precise question: is there anyone else, active in this workspace, who holds the approve permission? If not, the person who keyed the bill can approve it. The moment a second approver is added, the rule starts applying on its own. Nobody has to remember to switch it on.
The check counts people, not roles
A deactivated user does not count as another approver, and neither does someone whose role lacks the permission. If your second approver leaves and is deactivated, the remaining person can approve their own bills again until someone replaces them — worth knowing when you offboard a finance lead.
Why the bill, when the payment run already had this
The payment run — the batch that actually sends money to suppliers by M-Pesa or Paystack — already carried the same rule: whoever prepared or submitted a run cannot approve it, unless nobody else can. Approving a run also fixes each supplier’s payout details at that moment, so what was approved is paying those details.
That control is real, and it is at the wrong end of the story for one kind of fraud. A payment run pays bills that are already approved. If a fictitious bill from a supplier that exists only on paper was keyed and approved by the same clerk, the person approving the run sees a legitimate-looking approved bill among forty others. They are checking that the run pays what was approved. They are not re-approving every bill.
A control at the bank checks that the money goes where the books say. A control at the bill checks that the books say something true.
With both rules, the shortest path from keying a bill to money leaving needs at least two people, and usually three: one keys the bill, another approves it, and the run that pays it is approved by someone other than whoever prepared it.
| Step | Who may not do it | Unless |
|---|---|---|
| Approve a supplier bill | Whoever created or last edited the bill | Nobody else active holds the approve-bills permission |
| Approve a payment run | Whoever prepared or submitted the run | Nobody else active can approve payment runs |
| Sign a step of an approval rule, where your workspace uses them | Whoever raised the bill, or signed an earlier step | The rule’s own settings allow it |
The last row only applies if your workspace has switched on approval rules by amount. Most have not, and the first two rows hold either way. How bills, matching and approval fit together is on supplier bills and payables, and the run itself on vendor payments.
Five minutes with your own permissions
How many active people hold the approve-supplier-bills permission?
What you want to see
Two or more.
If you do not
With one, the rule steps aside by design, and every bill that person keys approves itself.
Do the people who key bills also hold the approve permission?
What you want to see
Some overlap is fine; the rule handles it bill by bill.
If you do not
If everyone holds both, any two clerks can approve each other’s bills — a pair, not a control.
Who approves payment runs, and are they the same people who approve bills?
What you want to see
Ideally a different, more senior person.
If you do not
Two layers held by the same two people are one layer twice.
Around the rule
Maker-checker on bills and payment runs is in place on the web, the app and the API. These are the next requests from finance teams that run it.
An audit note on a sole-approver bill
The payment run already writes into its audit trail when its preparer approved it because nobody else could. The same note on a bill would let an auditor list those approvals in one search.
A monthly self-approval report
Every bill and run approved by its own maker in the period, for the owner or the board to see at month end.
Tell us how your payables approvals work today and we will return a written scope and cost.
Scope your approvalsWhat AWRA OpsHub does today
- Maker-checker on supplier bills: whoever created or last edited a bill cannot approve it while anyone else active holds the approve-supplier-bills permission.
- The same rule on payment runs: whoever prepared or submitted a run cannot approve it while anyone else can, and approval fixes each supplier’s payout details.
- One rule everywhere a bill is approved: the web, the mobile app and the API all pass through the same check.
- A one-person finance team keeps working: with no other approver, the person who keyed the bill can approve it.
- Approval rules by amount, where your workspace switches them on, add steps that the bill’s author cannot sign and that one person cannot sign twice.
More we can add to your workspace
- An audit-trail note when a bill is approved by its own maker because nobody else could, matching the note a payment run already writes.
- A period report of self-approved bills and runs, for review at month end.
Where we point you to a specialist
- We will not lock a one-person team out of paying its suppliers. A rule that forces a second login to be invented destroys the record it was meant to protect.
- We do not decide who in your organization should hold the approve permission. That is a judgement about your people, and the rule enforces whatever you decide.
The audit note and the self-approval report read data AWRA already records on every bill and run — each is a short written specification and a price.
See bills, matching and approval together
Supplier bills keyed against orders or expenses, matched to what was received, approved by someone other than whoever keyed them, and paid in runs that carry the same rule.
Explore supplier billsFrequently asked questions
Can the person who entered a supplier bill approve it?
Not while anyone else active in your workspace holds the permission to approve supplier bills. The person who created the bill and the person who last edited it are both refused. If nobody else can approve, the person who keyed it still can, so a one-person team is not locked out.
Does editing a bill count as entering it?
Yes. Whoever last edited a bill is treated as one of its makers, so changing the amount or the supplier on someone else’s bill and then approving it is refused in the same way.
Does this apply in the mobile app?
Yes. The rule sits in the one place a bill is approved, so the web, the app and the API all apply it.
How is this different from payment run approval?
A payment run pays bills that are already approved, and its preparer cannot approve it either. The bill rule acts earlier, on the document that creates the debt, so a fictitious bill cannot be keyed and approved by the same person before it ever reaches a run.
What happens if our only other approver leaves?
Once they are deactivated they no longer count, so the remaining approver can approve bills they keyed until someone else is given the permission. Add a second approver when you offboard a finance lead.
