Learn Finance · Fund & Financial Accounting · Task B5. Process a supplier invoice the controlled way — so every payment is for something ordered, received, and correctly priced.

What it is

Procure-to-pay (P2P) is the controlled chain from "we need to buy something" to "we paid for it":

Purchase Request → Purchase Order → Goods Receipt → Invoice → Payment.

Two controls make it trustworthy: - Thresholds decide who must approve — a $200 purchase and a $20,000 one don't need the same sign-off. - The three-way match checks that the PO (what we ordered), the goods receipt / GRN (what we got), and the invoice (what we're billed) all agree before payment. No match, no pay.

Why it matters

It's the main defence against loss. Most fraud and error in an NGO lives in payments — paying a ghost vendor, paying twice, paying for goods never delivered. The three-way match blocks all three.
Donors require segregation of duties. The person who orders must not be the one who receives and the one who pays. The chain enforces that separation.
It protects the budget. The PO commits the money up front (an encumbrance), so you see committed-but-not-yet-spent before the invoice even arrives.

Where you do it in VanillaPM

Everything below is in Finance → Accounting (procure-to-pay). A step-by-step:

Know the thresholds. ProcurementThreshold sets the approval tiers — who signs off at what amount — so a $500 order and a $50,000 order don't take the same path.
Walk the P2P chain. Purchase Request → Purchase Order → GoodsReceipt: the PR is the ask, the PO commits the budget (A3), the GRN confirms the goods actually arrived.
Three-way match the invoice. Enter the APInvoice (and lines) and match it against the PO and the GoodsReceipt — the quantities and prices must agree across all three before it's cleared to pay. (VendorPrepayment handles advances.)
Post and pay. Posting the approved invoice: Dr 5xxx Expense (→ coding block) / Cr 2xxx Accounts payable; paying it: Dr Accounts payable / Cr 1101 Bank. The commitment from step 2 converts to actual as it's paid.

Honest boundary: VanillaPM holds the full PR→PO→GRN→invoice→payment chain and thresholds. Whether the three-way match is system-enforced (hard block) or documented-and-checked is a Phase-0 verification item for this track — this lesson teaches the control; confirm the enforcement mode in your instance before relying on it as a hard gate.

Walked example — Hilsa Health Initiative

The field office needs $5,000 of medical supplies for the grant.

Step	Document	What it records
1	Purchase Request	"We need supplies" — approved per the threshold for $5,000
2	Purchase Order → vendor	commits $5,000 (an encumbrance against the grant budget)
3	Goods Receipt (GRN)	the supplies physically arrived — qty checked
4	Invoice	vendor bills $5,000 → three-way match: PO = GRN = invoice ✓
5	Payment	`Dr Payables 5,000 / Cr Bank 5,000` — only after the match passes

If the invoice had been $5,400 against a $5,000 PO and GRN, the match fails — the $400 over-bill is caught before a cent leaves the bank.

The numbers

The match is three equalities: PO quantity & price = GRN quantity = invoice quantity & price. A tolerance may be allowed (say ±2% on price for freight), but anything outside it stops for investigation. The encumbrance from the PO also means your available grant budget already reflects the $5,000 commitment the moment the PO is raised — not when the invoice lands.

Controls & evidence

Segregation of duties — different people request, approve, receive, and pay.
Approval per threshold — the right level signed off for the amount.
Three-way match evidenced on every invoice before payment.
No duplicate payment — an invoice can only be paid once against its PO.

Best practices & pitfalls

Do raise the PO before the purchase, not after. A PO written to match an invoice you already received defeats the whole control.
Do check the GRN against what physically arrived, not against the paperwork.
Pitfall: "urgent" purchases that skip the request/PO step. Emergencies need a documented exception path, not a silent bypass.
Pitfall: paying an invoice that doesn't match "to keep the vendor happy." The mismatch is the control working — resolve it, don't override it.

Practise question

Q1. A vendor invoices you for 100 units at $12. The PO was for 100 units at $12, but the goods receipt shows only 80 units arrived. Do you pay the invoice? Why?

Answer: No — the three-way match fails on quantity (invoice/PO = 100, GRN = 80). You pay for what was received: 80 × $12 = $960, pending a corrected invoice or a credit note for the 20 undelivered units. Paying the full $1,200 would be paying for goods you never got.

Terms used here

Procure-to-pay (P2P) — the controlled chain from request to payment.
Three-way match — PO = goods receipt = invoice, checked before payment.
Goods receipt (GRN) — the record that ordered items physically arrived.
Encumbrance / commitment — budget reserved by a PO before the cash is spent.
Segregation of duties — no one person controls a whole transaction.
Related: Record a balanced journal entry — the postings behind the invoice and payment.

How an auditor / donor expects this

They sample payments and walk them backwards: payment → invoice → GRN → PO → request, checking the match, the thresholds, and that different people acted at each step. A payment that can't produce a matching PO and GRN is the classic finding. The P2P chain exists so every payment survives that walk.

Run a vendor invoice through P2P controls