Skip to content
EMPOBase
en

How to design a payment request approval process

By the EMPOBase team · · 4 min read

Short answer

A payment request approval process has four parts: a standard request that names the payee, amount, project and budget line; approval steps set by amount; separation of duties so no one approves their own request or two steps of the same request; and a record of each decision. Write it down, test it with a real request, and review it yearly.

Key points

  • Make the request form capture everything an approver needs: payee, amount, project, budget line and support.
  • Set approval steps by amount band and role, not by named person.
  • The requester never approves, and one person never approves two steps.
  • Approval is not payment. Keep a separate record that the money left the bank.

What is a payment request?

A payment request asks finance to pay a supplier, a partner, a staff member or another payee. It is the internal document that starts the payment. It is not the payment itself.

A good process answers one question the same way every time: who agreed to this payment, were they allowed to, and was the money available?

What should every request contain?

If the form is vague, approvers guess. Ask for the same details on every request:

  1. Payee name and what is owed.
  2. Amount and currency.
  3. Project, grant and budget line to charge.
  4. The reason, in one or two sentences.
  5. Support: invoice, purchase order, goods receipt or contract.
  6. The requester’s name and the date.

If a field is optional, people skip it. Make the ones above required.

How do you set the approval steps?

Tie the steps to amount bands and roles. A short example, with amounts for illustration only:

AmountSteps
Up to 1,000Budget holder
1,001 to 10,000Budget holder, then finance manager
Above 10,000Budget holder, finance manager, then country director

Pick the roles that match who truly knows the facts. The budget holder knows whether the work was done. Finance knows whether the money and documents are in order. A senior role signs for risk.

Set bands from your own volume and your donors’ rules. Our guide to procurement approval limits shows one way to choose them.

Which separation-of-duties rules apply?

Amounts do not protect you alone. These rules do:

  • The requester cannot approve their own request. No exceptions at any band.
  • One person cannot approve two steps of the same request. A finance manager who is also the budget holder must hand one step to someone else.
  • The person who approves does not release the payment without a second check, where your team size allows it.
  • Delegates are named and dated. If an approver is away, a named delegate acts for a fixed period, never the requester.

Small teams find this hard. Our article on segregation of duties in small teams covers what to do when you have few people.

What should the record show?

For each step, store the approver’s name, role, date and time, the decision and a note. A rejection needs a reason. An exception needs a reason and a second signature.

Then ask: can a new colleague, or an auditor, reconstruct the whole story from the record alone? If it lives in email threads and chat messages, the answer is no.

What happens after approval?

Approval says “this payment may be made”. Three things still need to happen:

  1. The payment is made through your bank process.
  2. The entry is recorded in the ledger against the right project, grant and budget line.
  3. Someone confirms the bank movement matches, usually in the monthly bank reconciliation.

Do not treat an approved request as proof of payment. A request can be approved and never paid, or paid with a different amount. Reconciliation closes that gap. See our article on monthly bank reconciliation.

How do you test and improve the process?

Run three real requests through it before you roll it out: a small one, a large one and a rejected one. Watch where people get stuck. Common problems are missing support documents, unclear roles and approvers who are never available.

Review the process once a year, and after any audit finding. Track two simple figures, even by hand: how long a request takes from submission to final approval, and how many are sent back for missing information. Long waits and many returns both point to a form or a step that needs work.

Where EMPOBase fits

In EMPOBase, Payment Requests follow approval chains with limits that your organization sets. The requester cannot approve their own request, one person cannot approve two steps, and each decision records who acted, when and any note. An approved request posts to the ledger once, charged to the project, grant and budget line it names. EMPOBase does not make bank transfers and has no settlement or proof-of-payment record, so the payment and the bank check stay in your bank process and your reconciliation. See the procure-to-pay workflow for the full chain.

Questions people ask

How many approval steps are enough?

Use one step for small amounts and add steps as the amount grows. Two or three steps cover most NGOs. More steps slow payment without adding much control.

What should we do with urgent payments?

Define an urgent route in advance, with a named delegate and a short written reason. Do not let urgency skip the separation of duties.

Should the approver see the budget balance?

Yes. An approver who cannot see what is left in the budget line is signing blind. Show the balance on the request or beside it.