The AP cycle, end-to-end

The £4,000 that left without anyone noticing

A series-A startup we worked with paid the same hosting bill twice in the same quarter. Same supplier, same amount, same reference. The first one came in on the 12th of the month as a recurring direct debit. The second one came in on the 28th as a one-off invoice from the supplier's accounts team, who hadn't realised the DD existed. Both got matched to "hosting" by the bookkeeper. Both got paid. Nobody noticed for fourteen months.

When they finally caught it during a year-end review, they got the £4,000 back — but only because the supplier was decent. There was nothing in their books that would have flagged it. No commitment record saying "we already agreed to pay this once". No purchase order pinning down the price. No goods-receipt note saying "we got one month of hosting, not two". Just two bills and two payments, both perfectly logged, neither of them telling the truth.

Accounts payable is the process that stops this. Not because anyone in the team was careless — they weren't — but because without structure, the books only record what happened. They can't tell you what was meant to happen, and they can't catch the gap between the two.

This series walks through the six stages of a working AP cycle inside Blankitt Finance Business. Before we get into how each stage works, here's why the process exists at all.

Why AP exists as a process (not just "pay bills")

There are four risks every AP function is built to control. Each stage of the cycle exists to control at least one of them.

Unauthorised spend. Someone in the team commits the company to a cost without sign-off. Often well-intentioned ("we needed the licence renewal urgently") but cumulatively expensive — and impossible to budget against when half the spend is invisible until the bill arrives.

Overpayment. You pay more than you owe. Could be a duplicate (the hosting story above), could be the supplier billing the original quote when you'd negotiated a discount, could be a tax error. Without a price you committed to in writing, you have no anchor to check the invoice against.

Paying for goods you didn't get. The classic one. You ordered 100 units; the supplier shipped 80 and invoiced for 100. Or they shipped 100 of the wrong thing. Or they invoiced for a service month they never delivered. If you only check the bill, not what arrived, you'll pay for the gap.

Paying late and damaging supplier relations. The reverse risk. Invoices land in a generic inbox, get sat on for three weeks, and your best supplier puts you on stop. Or worse, charges late fees. A working AP cycle makes the path from bill-received to payment-sent fast and predictable.

A bookkeeper-only AP function — "post bills, pay bills" — can't address any of these. You need the gates before the bill arrives, and you need the records that prove what was promised.

The six stages

  PR  →  PO  →  GRN  →  Bill  →  Payment  →  Reconciliation

PR — Purchase Request. The pre-spend gate. Someone in the team raises "I'd like to buy X for £Y". The approval engine routes it to the right approver based on the amount, the requester, and the document type. Nothing has been committed to a supplier yet. Triggered by: a need to spend money. Produces: an approved request, a justification on file, and an audit-log entry of who approved what.

PO — Purchase Order. The commitment. Once a PR is approved, you convert it to a PO and send it to the supplier. The PO is a contract: this is what we're buying, at this price, on these terms. Triggered by: an approved PR. Produces: a PDF, an email send-record, and a row in your commitments register so finance can see "we're on the hook for £X even though the bill hasn't arrived yet".

GRN — Goods Receipt Note. The "did we get it" check. When the goods or service arrive, someone on the receiving end raises a GRN against the PO. They tick off line items: "received 100 units of A, 80 of B, none of C". Triggered by: physical (or contractual) delivery. Produces: a receipt record per line, which is the second leg of the three-way match.

Bill. The supplier's invoice. Uploaded into the system (or pulled in by OCR), matched against the PO and the GRN. Discrepancies surface immediately: bill quantity differs from GRN quantity, bill price differs from PO price, bill is for a PO that doesn't exist. Triggered by: a supplier invoice arriving. Produces: a posted bill ready for payment, with the audit trail of which PO + GRN it relates to.

Payment. The transfer. Approved bills get scheduled, batched into a BACS file (or paid individually), and the payment record links back to the bill, the PO, and the GRN. Triggered by: a bill being due. Produces: a payment record + a BACS file ID + reconciliation candidates for when the bank confirms the debit.

Reconciliation. The bank match. The bank feed lands the actual debit. The reconciliation engine matches it to the payment record. Triggered by: a bank transaction arriving in the feed. Produces: a closed loop — every pound you paid is traceable back through Payment → Bill → GRN → PO → PR.

That's the cycle. Each stage produces evidence the next stage consumes. Each stage answers a different question.

Key point: The six stages aren't six pieces of paperwork. They're six different questions: was this authorised? what did we commit to? did we get it? does the bill match? has it been paid? did the money actually move? Skipping a stage means losing the answer to one of those questions.

The audit trail each stage writes

By the time a payment is reconciled, the system holds a complete evidence chain:

• PR.justification — the reason the spend was approved, in the words of whoever asked for it.
• PR.approved_by + approval_log — who said yes, when, and what policy matched.
• PO.pdf + PO.sent_to + fin_po_email_log — the document the supplier received, who it went to, and the message-id of the email send.
• GRN.received_at + GRN.lines — what arrived, how much, when, and who recorded it.
• Bill.uploaded_file + bill.ocr_fields — the supplier's invoice as a PDF plus the structured data extracted from it.
• Bill.match_status — whether the three-way match passed or which lines flagged.
• Payment.bacs_file_id + payment.sent_at — when you instructed the bank, the file the bank received.
• Bank match record — the actual statement line that confirmed the money moved.

Any one of those records can be pulled up in an audit, a supplier dispute, or an internal review. The chain links them. You're never asked "why did we pay this?" and stuck with "I think Steve agreed it on a call?". The PR justification answers it; the approval log proves it; the PO records what we agreed; the GRN proves we got it; the bill matches the PO; the payment matches the bill; the bank confirms the cash left.

Where teams typically skip stages — and what it costs them

"We just upload bills and pay them." The default for most early-stage finance teams. Bills land in the inbox, get coded, get paid. It's fast. It's also blind. There's no PR so spend isn't reviewed before it's committed; no PO so there's no agreed price to validate the bill against; no GRN so you can't catch short-shipments. Every supplier dispute becomes a "well, what did we agree?" conversation with no paper to back you up.

"We raise POs but no GRNs." Slightly better — you have agreed prices to check against — but you've still got no record of what arrived. A supplier can invoice for the full PO when they only delivered 80% and you'll pay it. Common in service businesses where the "delivery" is fuzzy (consulting hours, monthly retainers); also costly in companies that buy physical stock.

"We raise PRs but skip the PO." The PR sits in the system as the agreed spend, but nothing goes to the supplier. The supplier has no document confirming the price; if their internal records say a different number, you'll get billed the different number. PRs are internal; they don't anchor anything externally.

"We do all five but reconcile quarterly." Reconciliation is the loop-closer. Reconcile monthly at the latest. Quarterly reconciliation means duplicate payments live undetected for up to three months, and bank-feed errors compound.

What you'll learn in the next five chapters

#	Chapter	What it covers
2	Raise a clean purchase request	Anatomy of a PR, what makes a justification approvers will say yes to, templates for repeating spend
3	Convert PR to PO and send to the supplier	Conversion mechanics, the PO PDF, sending and re-sending, handling changes after sending
4	Goods receipt and the three-way match	Raising a GRN, partial deliveries, how the bill matcher uses PO + GRN to flag discrepancies
5	Bills, OCR and the payment run	Uploading bills, OCR field extraction, approval-then-pay, BACS batches
6	Reconciliation and the closed loop	Bank feed matching, exceptions, month-end commitment reporting

Read them in order if you're setting AP up from scratch. Dip into a single chapter if you're tightening one part of an existing process.

If you haven't yet configured an approval policy, do that first — Settings → Approval policies. The next five chapters assume you have.