---
title: "Why your invoices never match your POs (and sane tolerance rules)"
description: "Service POs, penny mismatches and part-billing: why 3-way matching breaks on services, and the tolerance rules that stop blocking honest invoices."
url: "/blog/invoices-never-match-pos/"
date: "2026-07-20"
author: "Valeria Vahorovska"
tags: ["Guides","Accounting"]
---

# Why your invoices never match your POs (and sane tolerance rules)

Invoices don't match POs — especially service POs — because [matching rules built for goods](/features/reconciliation/) are applied to work that doesn't arrive on a pallet. Hours run over estimates, projects bill in slices, currencies move, systems round differently. The fix isn't stricter matching; it's **sane tolerance rules** plus an acceptance step that fits services — so honest invoices flow and real discrepancies stand out.

The practitioner pain here is vivid and specific: invoices *"off by a literal penny"* that *"don't get paid"*, service POs that never match anything, and the workaround economy — *"a custom spreadsheet for every single vendor"* — that grows around a matching process everyone has quietly stopped trusting. The cost runs both directions: honest suppliers blocked for pennies [become suppliers who pre-charge for the hassle](/blog/net-30-but-paid-in-90/), while the process cried wolf so often that real overbilling sails through on exception fatigue.

## Why service POs break goods-style matching

**Estimated quantity, actual billing.** A PO for "~120 consulting hours" meets an invoice for 126.5. Neither party did anything wrong — the PO was a forecast, the invoice is history. A goods-matcher sees a 5% quantity breach and blocks.

**Part-billing against a whole.** The £60k project bills monthly by progress; every invoice is a partial match against one PO. Unless the system tracks *cumulative* billed-vs-ordered, each slice looks like a mismatch — or worse, the total quietly overshoots across ten invoices no one summed. (The duplicate's favourite hiding place, [as we've covered](/blog/duplicate-po-problem/).)

**The penny class.** Two systems round a VAT line differently; FX moved between order and invoice; a unit price with four decimals got truncated. This is the *"off by a literal penny"* blocker — variance with zero information content, blocking payment and burning supplier goodwill.

**The missing middle leg.** Goods matching has a receiving dock: PO, goods-received note, invoice. Services often have… an email thread. With no acceptance artifact, "did we get what we're paying for?" has no evidence either way — so AP either blocks (and becomes the bottleneck) or approves (and becomes decorative).

## The tolerance rules that work

Write them down; the numbers matter less than their existence:

1. **An absolute floor.** Auto-approve any variance below £5–£25 (pick per your volumes). This deletes the penny class on day one and costs, by construction, almost nothing.
2. **A percentage band on estimated lines.** 1–2% on hours, usage and anything the PO admitted was a forecast. The 126.5-hours invoice flows; the 160-hours one stops.
3. **Cumulative tracking on part-billed POs.** Each slice matches if the *running total* stays inside the PO plus band. The overshoot gets caught on the invoice that crosses the line, not in a year-end audit.
4. **Escalation by size, with context.** Small breaches go to the budget owner as a one-click approve with the delta shown; large ones to procurement with the PO, the history and the variance attached. An exception that arrives with its evidence takes a minute; one that requires archaeology takes a week — [which is how invoices age](/blog/reconcile-payments-to-xero/).
5. **An acceptance artifact for services.** Timesheet, milestone sign-off, usage export — agreed at PO time, attached at invoice time. The middle leg of the triangle, sized for services.

## Where the agent earns its keep

All of the above is judgment encoded as rules — exactly what should run automatically. Fynex's [AI invoice analysis](/features/invoicing/) reads each incoming invoice, finds its PO even through a mangled reference, checks lines against contracted rates and [that vendor's history](/blog/hidden-fees-vendor-invoices/), applies your tolerance bands (including the cumulative math on part-billed POs), and books the clean majority straight through to [scheduled payment](/features/working-capital/). What reaches a human is the honest exception list: the genuine overbilling, the rate that drifted, the running total about to breach — each with the reference it violates attached.

The penny-blocked invoice and the unexamined overcharge are the same failure wearing opposite costumes: matching effort spent where the variance is meaningless and absent where it isn't. Tolerance rules are how you point the attention at the right one — and once they're written down, they're software.