Skip to content
EMPOBase
en

How to set approval limits for NGO procurement

By the EMPOBase team · · 4 min read

Short answer

Set approval limits as a short table of amount bands. Each band names the role that can approve purchases up to that value. Keep the person who raises a request out of its approval, never let one person approve two steps of the same purchase, and record every decision with a name, a date and a note. Review the table once a year and whenever a donor's rules change.

Key points

  • Use three to five amount bands, each tied to a role, not to a named person.
  • The requester never approves their own request, and one person never approves two steps.
  • Check the strictest donor rule that applies; it sets your floor, not your ceiling.
  • A decision is only evidence if it records who approved, when and why.

Why approval limits matter

Procurement is where most donor money leaves an NGO. A clear rule for who can approve what protects three things: the budget, the staff who sign, and the trust of the donor. Without a written rule, approvals drift toward whoever is available. A busy finance officer approves a large order “just this once”, or a field manager approves a purchase they also requested. Each case may be honest, but an auditor cannot tell honest from dishonest when the record is thin.

Approval limits replace personal judgement about who should sign with a rule everyone can read before they buy.

What is an approval limit?

An approval limit is the highest purchase value that a role can approve on its own. Above that value, the request moves to the next role. Most NGOs express this as amount bands (sometimes called delegation of authority or approval levels).

A typical table looks like this. The amounts are examples only; set your own from your budget size and donor rules.

BandPurchase value (total cost)Approver role
L1Up to 500Project manager
L2501 to 5,000Field office manager
L35,001 to 25,000Head of finance or operations
L425,001 to 100,000Country director
L5Above 100,000Country director and a procurement committee

Tie each band to a role, not a person. People change jobs; roles stay. When a new country director arrives, the table still works.

How to set the amounts

  1. List your donor rules. Write down each active donor’s procurement thresholds. The strictest rule that applies to a grant is your minimum standard for purchases charged to that grant.
  2. Look at last year’s purchases. Sort them by value. Your bands should send most small, routine purchases to L1 and L2, so senior staff spend their time on the few large ones.
  3. Match bands to quotation rules. If your policy needs three quotations above a certain value, put a band edge at the same value. One number is easier to remember than two.
  4. Add a committee for the largest purchases. At the top band, one approver is not enough. A small committee, with minutes, spreads the decision and the responsibility.
  5. Write it down and publish it. Put the table in your procurement policy and in your shared document space, with a version number and an effective date.

Which rules should sit next to the limits?

Amounts alone do not stop the common failures. Add these rules:

  • The requester cannot approve. The person who raises a request never approves it, at any band.
  • One person, one step. The same person cannot approve more than one step of the same purchase, for example both the request and the payment.
  • No splitting. Breaking one need into several small orders to stay under a band is a breach, not a shortcut.
  • Budget check first. A request names the project and budget line it will charge, so the approver sees whether money is available before they sign.
  • Written delegation. A delegate acts only for a stated period, and the record shows the delegate’s name.

Our article on conflict of interest in procurement covers the next layer: what to do when an approver knows the supplier.

What should the approval record show?

An approval that lives only in an email thread is hard to find and easy to dispute. For each decision, keep:

  1. The request, with project, budget line and amount.
  2. The approver’s name and role.
  3. The date and time of the decision.
  4. The decision itself: approved or rejected.
  5. A note, especially for a rejection or an exception.

When an auditor asks “who approved this, and were they allowed to?”, you should be able to answer in one step, not by searching inboxes.

How often should you review the limits?

Review the table once a year, and also when:

  • a new donor with different thresholds signs an agreement,
  • your organization’s budget changes size,
  • an audit finding points to a weak control,
  • the organization structure changes.

Record each change with the date, the reason and who approved the change itself.

Where EMPOBase fits

In EMPOBase, Procurement routes approvals through authority levels L1 to L5, and your organization sets the approval limits. The person who raised a request cannot approve it, the same person cannot approve more than one step, and every decision records who acted, when and any note. Approved requests post to the project ledger exactly once. EMPOBase does not make bank transfers, so the payment itself stays with your bank process. You can see the whole chain on the procure-to-pay workflow page, or ask us for a walk-through with sample data.

Questions people ask

Should approval limits be the same in every country office?

Keep one structure for the whole organization, but allow lower bands for offices with small teams or higher risk. A smaller office can use the same roles with lower amounts.

What happens when the approver is on leave?

Name a delegate in writing before the leave starts, for a fixed period, and never delegate to the person who raised the request. The record should show that the delegate acted, not the absent manager.

Do approval limits include tax and transport?

Use the total cost of the purchase, including tax, transport and installation. Splitting one need into several smaller orders to stay under a limit should be treated as a control breach.