Expense Claims & Approvals: Stopping the Slow Leak
Nobody ever went bust on expense claims, which is exactly why they go unmanaged for years. The slow leak, why it is almost never dishonesty, and the approval structure that closes it without turning your finance team into police.
Expense claims are the least interesting line in most Kenyan businesses and one of the most reliably leaky. Individually every claim is small, plausible and urgent to somebody. Collectively they are a meaningful cost centre that nobody owns, coded to accounts that describe nothing, approved by whoever was available, and reimbursed because refusing feels petty.
The leak is almost never theft. It is four structural gaps that make ordinary behaviour expensive, and all four are closed by design rather than by suspicion.
The four gaps
| Gap | What it looks like | Why it persists |
|---|---|---|
| Coded to nothing | Everything lands in "general expenses" or "travel" | The claim form never asked which project, client or cost centre, so nobody supplied it |
| Approved by availability | Whoever was in the office signed, regardless of authority or budget | No threshold structure, so all claims are equally approvable by anyone senior-ish |
| No policy anyone can cite | Per diem and mileage amounts vary by who is claiming and who remembers what | The policy exists in an email from 2023 that three people have and nobody applies consistently |
| Advances never closed out | Field advances issued, partly spent, never reconciled against receipts | The advance is treated as a payment rather than as a debt to be retired |
The last one is the largest by value in most organizations with field operations, and the most invisible, because an unretired advance sits as a balance nobody reads. Somebody was given money for a trip, spent most of it, returned some, and the difference was never reconciled — repeated across a year and a team.
An advance is a debt, not a payment. Treated as a payment it disappears into expenses; treated as a debt it has to be retired by receipts or returned cash.
Coding at entry does most of the work
The single highest-return change is requiring the claimant to say what the cost was for, at the moment they claim it — project, client, cost centre or explicitly overhead. Not finance guessing three weeks later from a description that says "transport".
This matters beyond tidiness. Travel to a client site is a cost of serving that client, and if it lands in general expenses then that engagement looks more profitable than it is while overhead grows unexplainably. Across a year of field visits this is not a rounding difference — it is the reason a service line that appears to work does not. The wider allocation discipline is in project cost allocation.
What a usable claim captures
- What it was for, in language somebody who was not there can understand
- Which project, client or cost centre — or overhead, chosen deliberately rather than by leaving the field blank
- The date it was incurred, not the date it was claimed
- A receipt attached to the claim, not promised separately by email
- The claimant, and the approver, both recorded with timestamps
- Any advance it is being set against, so advances retire rather than accumulate
Thresholds beat scrutiny
The instinct when expenses feel out of control is to review everything more carefully. That fails predictably: it makes approval slow, pushes the burden onto the most senior people, and creates pressure to wave things through — which is worse than the original problem because now there is a control that is known not to work.
Thresholds invert it. Small claims approved by a line manager, larger ones escalating, and only genuinely significant amounts reaching senior authority. Attention concentrates where value is, and approval stays fast for the ninety per cent of claims that are routine. The design goal is that the rule about who can approve what lives in the system rather than depending on who happens to be in the office — see the box below for how far ours actually goes on that, because it is further from automatic than you might assume.
Scrutiny-based
- Every claim reviewed at the same depth regardless of value
- Approval bottlenecks on two or three senior people
- Pressure to approve quickly, so review becomes nominal
- Claimants feel policed; approvers feel burdened
- The control is known to be theatre, which corrodes the rest
Threshold-based
- Routine claims approved close to the work, quickly
- Escalation only where the value justifies attention
- Senior time spent on the claims that matter
- Claimants get paid faster; approvers approve less
- The system enforces authority, so the control is real
The approver must not be the claimant
This sounds obvious and is routinely broken in small teams, particularly for the most senior people whose claims are approved by nobody or by someone who reports to them. If a director's expenses cannot be approved by a peer, have them reviewed by the board or by the owner and say so in the policy — see segregation of duties. An acknowledged constraint with a compensating control is defensible; an unexamined exception for the largest claims is not.
Field advances need closing out, deliberately
Organizations with field teams — NGOs, contractors, distributors, service companies — issue cash advances because that is the only practical way to work. The failure is treating the disbursement as the end of the transaction.
-
Issue the advance as a balance owed by the person
Not as an expense. It is money the organization has given out and is owed accounting for, and it should appear as such against a named individual.
-
Retire it with receipts and returned cash
The claim set against the advance, plus whatever cash comes back, should equal the advance. Anything left over is still owed.
-
Refuse a second advance while the first is open
Enforced, not requested. This one rule ends advance accumulation almost immediately, and it is the rule most organizations are reluctant to apply.
-
Review open advances weekly
By person and by age. An advance open past a month is either an accounting failure or a conversation nobody is having.
-
Reconcile mobile money the same way
Funds sent to a field officer's phone are an advance with the same obligations — see per diems, field advances and mobile money.
Policy has to be short enough to follow
A long expenses policy is a policy nobody has read. What is needed is one page: standard per diem and mileage rates, what needs a receipt, what needs pre-approval, thresholds by value, and how quickly claims are reimbursed.
That last item is more important than it looks. Slow reimbursement is the main driver of inflated and duplicated claims, because a person waiting two months to be repaid for their own money starts treating claims defensively. Paying promptly is a control, not a courtesy. Tax treatment of per diems and benefits is a separate question — confirm it with your accountant rather than assuming, because getting it wrong creates a PAYE exposure.
What we do and do not do
What AWRA OpsHub does today
- Claims coded at entry to a project, a category and an expense account, with vendor, payment method, currency and tax amount on the record.
- Custom fields on expenses, so a cost centre, client or voucher reference can be captured and made required.
- Workflow rules on expenses, which is where a value threshold can raise an approval task, notify a manager or escalate.
- A full audit trail in the audit log — who created a claim, who changed its status, when, and from where.
- Expense reporting by category, project and period, with export.
- A dedicated approve-an-expense permission — shipped 2026-08-01. Granting it to any role switches approval on for the whole organisation: payables then start as pending, cannot be paid until approved, and cannot be approved by whoever raised them — a rule no permission grant can buy past. Grant it to nobody and nothing changes, so a one-person business is unaffected.
- The approver on the claim itself — who approved or rejected it, when, and the rejection reason, on the record rather than only in the audit log.
- Expenses post to the ledger automatically. Recognition on creation — Dr Expense / Cr Bank or Cash when paid outright, Dr Expense / Cr Accounts Payable when a payable — and Dr Accounts Payable / Cr Bank on settlement. Rejecting a pending expense reverses the accrual, so a refused claim leaves nothing behind on the books.
- Documents attach to the transaction itself — shipped 2026-08-01. Expenses, purchase orders, requisitions, quotations and assets all take Document Vault files directly: checksummed on upload, classified, every download logged, and archived rather than deleted when removed. The receipt now lives on the record it evidences instead of in a naming convention.
More we can add to your workspace
- A value threshold on expense approval. Approval is all-or-nothing once switched on: every payable needs sign-off, not just those above an amount. Stock adjustments do have a value threshold; expenses do not yet.
- An advances module: a float or advance issued to a person, a balance to retire a claim against, and a liquidation deadline. Advances are the one part of this page that needs building rather than configuring.
- A mandatory receipt. You can attach one to a claim today; refusing the claim without it is the build.
- Approval routing by role or amount. An "above X goes to a director" chain, instead of one permission that approves anything.
- An OCR — the claimant enters the detail; and no card-provider integration to import transactions.
- Fraud detection. Claims are visible, coded and attributable; judgement remains human.
Corrected twice. On 2026-08-01 four claims here were checked against the code and did not hold; later the same day three more were fixed in the other direction — the approval permission and the approver field shipped, and "expenses do not post to the ledger" was simply wrong and had been since before it was written. Expenses have always posted full double entry; the check that produced that claim looked in the wrong place. The honest summary now: we can control spend as well as code it, with two real limits — approval is all-or-nothing rather than threshold-based, and advances remain out of scope. The tax treatment of per diems, mileage and benefits in kind affects PAYE — confirm it with your accountant or KRA; nothing here is tax advice.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsNote on professional firms
Firms that incur costs on behalf of clients have a second problem layered on this one: a disbursement that is never recovered is a claim you paid twice — once to the staff member and once by not billing it. That specific mechanic is covered in overhead and disbursement control in professional firms, and it is worth reading alongside this guide rather than instead of it.
Our take
Require coding at entry, approve by exception instead of reviewing everything, treat advances as debts that must be retired before another is issued, and reimburse quickly. Four structural changes, none of which require distrusting anybody — and together they usually recover more than any expense-cutting exercise a management team is willing to run.
See expenses coded where they belong
Claims coded at entry with receipts attached, approval that switches on the moment you grant it and refuses self-approval, advances tracked as balances until retired, and everything posting to one ledger.
Explore expense managementFrequently asked questions
What is the biggest source of expense leakage?
In organizations with field teams, unretired advances — money issued for a trip, partly spent, never reconciled against receipts or returned cash, sitting as a balance nobody reads. Everywhere else it is costs coded to general accounts, which is less about money leaving and more about losing the ability to see which clients, projects and service lines are actually profitable. Both are structural rather than behavioural.
Should every expense claim be reviewed in detail?
No — that approach fails reliably. Reviewing everything at the same depth bottlenecks approval on a few senior people, creates pressure to wave claims through, and produces a control everybody knows is nominal. Thresholds work better: routine claims approved quickly close to the work, escalation where value justifies attention, and the authority rules enforced by the system rather than depending on who is in the office.
How should we handle cash advances to field staff?
Issue the advance as a balance owed by the named individual rather than as an expense, retire it with receipts plus returned cash, and refuse a second advance while the first is open. That last rule is the one organizations are most reluctant to enforce and the one that ends advance accumulation almost immediately. Review open advances weekly by person and by age — anything open past a month is a conversation somebody is avoiding.
Does the system read receipts automatically?
No. There is no OCR extraction and no card-provider integration importing transactions, so the claimant enters the detail and attaches the receipt. We would rather state that than imply automation we have not built. In practice the constraint on expense management is rarely data entry — it is whether claims are coded to something meaningful and approved by someone with the authority to approve them.
Why does slow reimbursement matter?
Because it is the main driver of inflated and duplicated claims. Someone waiting two months to be repaid for money they spent from their own pocket starts submitting defensively — rounding up, claiming marginal items, occasionally claiming twice because they lost track of what was paid. Fast reimbursement removes that pressure entirely, which makes it a control rather than a courtesy, and it costs nothing.
