What controls should be in place before supplier invoice approval?

At Astotel, a group of 18 Parisian hotels, supplier price checks used to happen by sampling. Then a pre-approval control caught roughly 400€ of overbilling per month on a single supplier, close to 5,000€ per year. The approver never spotted the discrepancy because the approver was never the line of defense. The control was.

That's the shift this article is about. Supplier invoice approval is the last checkpoint in your workflow, not the first. The real protection happens before any human reviews the invoice: data validation, duplicate detection, vendor verification, banking change checks, PO matching, price catalog comparison, tolerance routing, threshold enforcement, and segregation of duties. Run those nine controls automatically, and your approver only sees clean, justified, exception-flagged invoices.

Below is the order they should fire, why most workflows miss them, and how AI agents now make them run on every invoice instead of audit samples.

Why approval is the last checkpoint, not the first

The AFP's 2025 Payments Fraud and Control Survey found that 79% of organizations experienced attempted or actual fraud in 2024. Yet most finance teams still run their invoice controls on samples: an auditor reviews 20 invoices a quarter, a controller spot-checks ten line items, a CFO eyeballs the high-value queue.

That isn't control. That's audit posture.

A real supplier invoice approval workflow treats the approver as the last gate, not the only gate. By the time an invoice reaches a human, it has already passed nine pre-approval controls. The human signs off because the data is already trusted, not to make the data trustworthy.

This reframes the question. The list of controls is not "approval steps." It is the gating stack that decides whether an invoice is even worth a human's attention.

The 9 pre-approval controls, in firing order

1. Required-field and data-integrity validation

The first control is brutally simple: does the invoice contain everything it needs? Vendor name, invoice number, invoice date, line-item descriptions, amounts, VAT, payment terms, PO reference where applicable. A missing field is a return-to-sender, not a routing decision. Most workflows skip this and accumulate exception backlogs that surface only at month-end.

2. Duplicate invoice detection

Duplicates are the highest-volume integrity risk in AP, and they hide beyond invoice number alone. A robust duplicate invoice detection check compares vendor name, amount, dates, line-item patterns, and bank account, not just the invoice ID. A single duplicate paid in error can wipe out a year of process improvement.

3. Vendor master verification

Before any invoice gets routed, the vendor itself must be verified. Is the vendor in the master file? Is the entity name exact, not a near-look-alike? Does the vendor's bank account match the master record? A "shell company" attack succeeds because the invoice looks plausible and no one verified the vendor master before processing. Independent vendor onboarding (with dual approval and out-of-band verification) is the structural defense.

4. Banking change verification

Vendor bank-detail changes are the single most exploited fraud vector in AP. The control is straightforward: every banking change on a supplier triggers a verification step (callback to a known phone number, second approver, hold on payment) executed out-of-band, never via the email channel that delivered the request. Phacet built the Detect fake IBAN fraud agent specifically around this attack pattern, because the cost of one missed change can run into hundreds of thousands of euros.

5. Two-way or three-way matching

For PO-backed spend, the foundational control is matching. Two-way match compares invoice to purchase order (price and quantity). Three-way match adds the goods receipt note, confirming what was actually delivered. Three-way matching is the difference between paying for what you ordered and paying for what a supplier said they delivered. For services or recurring spend without a PO, the match shifts to contract terms instead of the receiving report.

6. Price catalog (mercuriale) variance check

This is the control most workflows simply do not run. A price catalog comparison verifies each invoiced line against the negotiated supplier price. It catches the slow-bleed errors that PO matching misses: prices drifting up between deliveries, off-contract substitutions, conditioning changes, hidden surcharges. Astotel's 5,000€/year on one supplier came from this exact category. Without a supplier price catalog control, variance lives in the invoice and dies silently in the ledger.

7. Tolerance-based exception routing

A control that returns a binary "PASS or FAIL" produces exception fatigue. The right pattern is tolerance routing: a 0.5% line-level variance might auto-clear, a 5% variance routes to the cost-center owner, a 15% variance escalates to finance with mandatory documentation. Tolerance bands turn matching into a triage function instead of a binary block.

8. Approval matrix and delegation of authority

The approval matrix (sometimes called the delegation of authority schedule) defines who can approve what, by amount, by cost center, by category. This is the threshold control. Without a documented matrix, approvers apply their own standards and inconsistency itself becomes a fraud surface. The matrix should be written, version-controlled, and enforced inside the workflow rather than in human memory.

9. Segregation of duties (SoD)

The final pre-approval control is structural: different people must enter, approve, and pay an invoice. Segregation of duties is the principle that no single individual controls a transaction end to end. In small teams where pure SoD is impossible, compensating controls (second-pair-of-eyes review on payments above threshold, mandatory vacation, surprise sample audits) carry the same weight.

Why these controls fail in practice

Every finance leader nods at this list. Few teams actually run all nine on every invoice. Three structural reasons:

Manual checks scale linearly with volume. A controller running price checks on 200 invoices a month works through them. The same controller at 2,000 invoices a month runs samples instead. Sample-based control is not control: it's audit posture.

Email and spreadsheet workflows lose evidence. A duplicate invoice flagged in an email thread, a banking change verified by phone but never logged, a tolerance breach approved verbally: none of those become an audit trail. Auditors find what was documented, not what was done.

Exceptions consume the team that's supposed to prevent them. Once exception volume crosses a threshold, the AP team stops investigating and starts processing. Variance becomes noise. The controls exist on paper, not in the workflow.

This is why pre-payment invoice checks need to run at machine speed and at 100% coverage, not at human-controller speed on a 5% sample.

How AI agents change the pre-approval stack

Rule-based AP automation handled steps 1, 2, and 8 reasonably well: required-field validation, duplicate detection by invoice number, threshold routing. It struggled with anything semantic: matching when line descriptions don't align character-for-character, detecting a price catalog variance when units differ, distinguishing a legitimate vendor change from a fraud signal.

AI agents close that gap. At Phacet, the controls are decomposed into specialized agents that each own one step of the stack:

The accounting inbox agent handles intake: extraction, supplier identification, required-field validation, and duplicate flagging in one pass. It runs continuously, not on a controller's schedule.

The 3-way matching agent performs semantic matching between invoice, PO, and goods receipt with a justification at every step. When line descriptions don't align exactly, the agent reasons about it instead of throwing the invoice into the exception queue.

The supplier billing control agent runs the price catalog check on every line of every invoice, not on samples. Variance is surfaced before approval, with the negotiated price, the invoiced price, and the gap shown side by side.

The fake IBAN fraud detection agent intercepts banking-change requests and triggers the verification protocol before any payment moves.

The documentary completeness agent verifies that the supporting evidence (PO, contract, GRN) is attached and consistent.

Each agent follows the same pattern: it structures the input (extracts and standardizes the data), controls against a reference (PO, contract, mercuriale, vendor master), then exposes the result with full justification. Every match, every variance, every override is timestamped in the audit trail, which means the controls themselves are inspectable later, not just the outcomes. Pair that with a layer of automated financial controls and the approver receives a packaged decision, not a raw invoice.

What 100% coverage looks like in production

Three customer outcomes show what changes when pre-approval controls run on every invoice:

Astotel (18 hotels) recovered roughly 5,000€ per year on a single supplier through the price catalog control. Their head of purchasing put it directly: "I catch errors I would never have spotted on my own."

La Nouvelle Garde (10 brasseries) intercepted 28,000€ of attempted fraud and eliminated about 1,800 manual operations per year. Their CFO described Phacet as a teammate that operates around the clock.

Vivason (audiology, multi-site retail) identified 180,000€ per year of supplier overcharges through the same control stack.

The common pattern: variance was not larger after Phacet, it was visible. Pre-approval controls running at 100% coverage surface what sample-based audit was always going to miss. That's the structural difference pre-decision invoice control makes: the call is informed before any euro moves.

FAQ

What is the difference between pre-approval controls and the approval itself?

Pre-approval controls are the automated checks that run before an invoice reaches a human approver: data validation, duplicate detection, vendor and bank verification, matching, price variance, tolerance routing. The approval itself is the human sign-off after those controls have passed or flagged exceptions. The goal of a strong supplier invoice approval workflow is to make the human decision a small, justified step on top of a large, automated control stack.

What is a 3-way match?

A three-way match compares the supplier invoice against the purchase order and the goods receipt note. It confirms three things at once: the price agreed (PO), the quantity received (GRN), and the amount billed (invoice). When all three align within tolerance, the invoice clears. When they don't, the discrepancy is routed for investigation. See more in our guide on three-way matching automation.

What is segregation of duties in accounts payable?

Segregation of duties (SoD) is the principle that no single person controls an AP transaction from start to finish. Different individuals should enter invoices, approve them, manage the vendor master, and release payments. SoD reduces both fraud risk and unintentional errors. In small teams where full SoD is impossible, compensating controls (second-reviewer threshold, mandatory vacation, periodic spot audits) cover the gap.

How do AI agents differ from rule-based AP automation for these controls?

Rule-based automation is good at exact-match tasks: required-field validation, exact duplicate detection, threshold routing. It breaks on anything semantic: matching descriptions that vary in wording, comparing prices when units shift, distinguishing legitimate vendor changes from fraud signals. AI agents handle the semantic layer, run on every invoice instead of samples, and produce a justification trail that auditors can inspect. See more in our overview of AI agents for finance control.

Should small finance teams run all nine controls?

Yes, with priority. Required-field validation, duplicate detection, vendor master verification, and banking change verification (controls 1 to 4) are non-negotiable at any size: they prevent the highest-impact fraud and error categories. PO matching, price catalog variance, and tolerance routing (5 to 7) scale with spend complexity. Approval matrix and SoD (8 to 9) need to exist in some form even with one or two finance people, often through compensating controls.

Build the stack before you buy the approver

The question "what controls should be in place before supplier invoice approval?" is really a question about where your last line of defense sits. If the approver is the line, you've already lost the volume battle. If the line is a stack of automated controls running on every invoice, the approver becomes what the role was supposed to be: a finance professional reviewing exceptions, not a clerk validating data.

Phacet customers typically deploy the accounting inbox agent and the supplier billing control agent first, with the first agent in production in under two weeks. From there, the matching, fraud, and contract-control agents extend the stack as the workflow demands. The 40+ agents in the catalog were built across 100+ real deployments, which means the controls reflect what finance teams actually need in production, not what looks good on a feature page.

The approval is still the human moment. The control is what you put in front of it.