Invoice Validation & Exception Review

How it works

What the validation layer checks - and when

Validation is the step that sits between invoice intake and the approval queue. Its job is to answer the questions that an approver shouldn't need to answer: does this invoice have a GST calculation that reconciles to its line items, does the total match the sum of lines, has this invoice reference been processed before, has anything changed about this supplier's bank details since the last payment?

Running these checks before a human sees the invoice means approvers are reviewing validated invoices, not performing validation themselves. The distinction matters because validation is a structured, repeatable check - the kind that a system does reliably every time. Approval is a judgment call about whether the expenditure is authorised - the kind that requires a person. Mixing the two functions means approvers are doing some of both, inconsistently, under time pressure.

What a well-designed exception looks like

An exception that says "review required" is not useful. It tells the reviewer nothing about what triggered the hold, what information they need to resolve it, or who should be involved in the resolution. An exception that says "bank account number differs from last payment - previously 06-2341 123456789, now 06-2341 987654321 - verify by calling supplier's finance contact before approving" is actionable immediately.

The difference between these two designs is the difference between an exception queue that gets worked through and an exception queue that accumulates until someone approves everything in it to clear the backlog. If exceptions are vague, the path of least resistance is to approve and move on. If exceptions are specific, the reviewer knows exactly what to do and can do it in minutes.

Exception routing matters for the same reason. A changed bank detail exception should route to someone with authority to verify it - the CFO or financial controller - not sit in the standard AP officer's queue alongside 40 routine invoices. A PO mismatch exception should route to the person who raised the PO, because they're the one who can confirm whether the variance is legitimate. Getting the routing right requires mapping exception types to resolution owners before the system is configured, not after it's live.

Why month-end correction is the wrong metric

Errors caught at validation before approval cost nothing to fix - the invoice is held, the issue is resolved, the corrected version proceeds. Errors discovered at month-end, after the invoice has been approved and posted, require journal entries, credit notes, supplier queries, and explanations to whoever is reviewing the accounts. The work is the same but the cost is five to ten times higher. Businesses that measure their AP process by how smoothly approvals flow are measuring the wrong thing. The relevant measure is how many corrections happen downstream - and whether those corrections could have been eliminated with better upstream checks.

Frequently asked questions

Related glossary terms