Pre-decision invoice control: why validate supplier invoices before payment approval, not after

There is a moment in the supplier payment cycle when control is free. Before the payment is approved, the invoice can be corrected, disputed, or blocked at zero cost. The supplier hasn't been paid. The cash hasn't left the account. The error is still a discrepancy on paper.

The moment that payment is authorised, that changes completely. The cash has moved. Recovering it, through a credit note, a supplier dispute, a reconciliation adjustment, costs time, friction, and frequently results in partial recovery rather than full recovery. The same error that would have taken five minutes to block before approval takes five hours to recover after payment.

This asymmetry, the cost difference between pre-payment interception and post-payment recovery, is the entire argument for pre-decision invoice control. It is not about achieving higher accuracy. It is about achieving the same accuracy at dramatically lower cost by positioning the control at the moment when correction is still free.

This article explains what pre-decision invoice control is, why the timing of validation matters far more than the thoroughness of validation, and what the practical implementation looks like for a finance team that currently validates after the fact.

The cost asymmetry that makes pre-decision control essential

Most finance teams validate invoices. The question is not whether validation happens but when, and the timing difference produces radically different cost outcomes.

The pre-decision moment.

An invoice arrives. Before it is approved for payment, it is checked: price against contracted rate, delivery confirmation against purchase order, duplicate status against invoice history. A price deviation is identified, the supplier has charged 12% above the negotiated rate on three line items. The invoice is held. The AP team contacts the supplier with the specific line items. The supplier issues a corrected invoice. The corrected invoice is approved and paid. Total cost of the discrepancy resolution: one email, one conversation, fifteen minutes.

The post-payment moment.

The same invoice is approved and paid without pre-payment validation. Three weeks later, during the monthly AP review, the price deviation is identified. The supplier has already been paid the inflated amount. The AP team must: document the discrepancy, issue a formal dispute, request a credit note, track the credit note to ensure it arrives and is correctly applied, and repost the credit in the accounting system. Total cost of the discrepancy resolution: two to four hours, spread across multiple people, with the outcome uncertain, suppliers frequently reject credit note requests for invoices that have already cleared their systems.

The financial difference between these two outcomes is not just the time spent. In the first scenario, the company pays the contracted price. In the second scenario, the company has paid the incorrect price, initiated a dispute process that costs more in staff time than the recovered amount in many cases, and still may not recover the full difference.

Multiply this by the invoice error rate, typically 3-7% of invoices contain price deviations, duplicates, or missing delivery confirmation, across a supplier base of 50 active vendors processing 500 invoices per month, and the cumulative annual cost difference between pre-decision and post-decision control is significant. Vivason identified €180,000 in annual supplier overcharges that were passing through a monthly review process. La Nouvelle Garde intercepted €28,000 in fraudulent invoices within weeks of implementing pre-payment validation. In both cases, the errors were not new, they had been occurring for months, accumulating unchecked because the control was positioned after payment rather than before it.

Why "we review invoices before paying them" is not the same as pre-decision control

The most common objection to pre-decision invoice control is that it already exists: "We have an approval workflow. Every invoice is reviewed by someone before it's paid."

This conflates approval with validation. They are different activities with different objectives.

Approval confirms that the invoice has been seen by an authorised person who endorses the payment. It is an accountability mechanism, it documents who signed off on the payment and creates an audit record. It does not, by itself, verify that the invoice is accurate.

Validation checks the invoice against external reference data: the contracted price, the purchase order, the delivery confirmation, the invoice history. It requires access to data that is not on the invoice itself, the contract, the PO, the goods receipt record, the historical invoice population for duplicate comparison. Without this cross-reference, an approver is confirming that the invoice looks reasonable, not that it is correct.

Most invoice approval workflows in practice perform no automatic cross-referencing. The approver sees the invoice amount, the supplier name, and the cost-centre coding, and approves based on whether the transaction looks plausible. A price deviation of 5-12% is not visible to a human approver reviewing an invoice without the contracted rate in front of them. A duplicate with a modified invoice number is not visible without a comparison against the full invoice history.

This is the gap that pre-decision control addresses. It is not an approval workflow, it is a validation layer that provides the approver with confirmed reference data before they make the approval decision. The approver sees not just the invoice but the result of the automated cross-reference: price compliance confirmed (or: line item 3 is 12% above contract rate), duplicate check passed (or: this invoice number closely matches one paid on March 3rd), three-way match confirmed (or: delivery confirmation not found for PO #4721).

The decision validation layer transforms the approval from a plausibility check, does this look right?, into a genuine control, is this confirmed correct?

The 6 checks that pre-decision invoice control must cover

For pre-decision invoice control to serve its purpose, intercepting every financially material error before payment is authorised, it must cover six specific checks. Implementing any five of the six leaves a category of error that will pass through to post-payment recovery.

Check 1 - Price compliance against contracted rates

The most common source of invoice overcharging. Every line item is compared against the contracted rate for that product or service, as recorded in the reference system. The comparison is line-level, not invoice-total-level, a price deviation on line item 3 that is partially offset by a line item 4 discount will not appear in a total-invoice comparison.

Reference data matters here: the check is only as accurate as the contracted price reference. An organisation that maintains its contracted rates in a contract management system, a supplier master spreadsheet, or an ERP-linked price list has the reference data needed for automated line-level price checking. One that relies on the approver's memory of what was negotiated does not.

The supplier billing control agent performs this line-level check against the price reference, flagging deviations with the specific line items, the contracted rate, and the invoiced rate shown side by side for the approver's review. For more on supplier price compliance controls, see the supplier invoice validation software article and prevent supplier overpayment.

Check 2 - Duplicate detection across the full invoice population

An invoice is a duplicate if it requests payment for something that has already been invoiced, regardless of whether the document itself is identical. Near-duplicate detection must cover: the same invoice number from the same supplier, the same amount and supplier with a different invoice number, the same line items across a period boundary (month-end re-billing), and consolidated invoices that overlap with individual invoices already processed.

Each pattern requires a different comparison logic. Exact invoice number matching is handled by most ERP systems. Population-level near-duplicate detection requires comparing the current invoice against the full historical invoice population, a cross-reference that must be performed before the invoice enters the approval queue, not as part of the ERP's own posting logic.

The 3-way matching and stop-losing-money agent applies population-level duplicate detection as part of the pre-payment validation stack, identifying near-duplicates that would pass ERP-level validation. For a detailed treatment of the duplicate detection gap, see the article on three-way matching automation and why matching alone does not catch duplicates with modified identifiers.

Check 3 - Three-way match confirmation

The three-way match confirms that a purchase was authorised (PO exists), that goods or services were received (delivery confirmation exists), and that the invoice corresponds to both. An invoice that passes the three-way match before payment is confirmed to represent a legitimate, delivered, correctly-ordered obligation.

Most organisations that run three-way matching run it inside the ERP, as a posting-time check rather than an approval-time check. This means the match is confirmed after the payment decision has been made, not before it. An invoice that fails the ERP's three-way match generates a posting exception, but the approver who authorised the payment may not be aware of the mismatch before the payment runs.

Pre-decision three-way matching runs before the approval decision, ensuring that the approver confirms payment only for invoices where all three legs of the match are confirmed. The 3-way matching use case covers the end-to-end implementation logic.

Check 4 - Supplier master data integrity

A supplier invoice is legitimate only if the payment destination is correct. The IBAN and bank account details on the invoice must match the authorised payment details in the supplier master. A mismatch, the most common pattern in Business Email Compromise fraud, means that payment for a legitimate invoice would go to an unauthorised account.

Pre-decision supplier master validation checks every invoice's payment details against the supplier master before the invoice reaches the approval queue. Changes to supplier bank details that haven't been processed through the supplier master update workflow generate an exception and block the invoice from approval until the change is verified through the supplier onboarding protocol.

La Nouvelle Garde's €28,000 fraud interception was specifically this pattern: fraudulent invoices with modified payment details that would have passed a standard approval workflow without pre-decision supplier master validation. For a detailed treatment of pre-payment controls including supplier master integrity, see the pre-payment controls glossary entry.

Check 5 - Contract terms compliance beyond price

Many supplier contracts contain terms that go beyond unit pricing: payment term conditions (net 30 versus net 45), early payment discount triggers, volume rebate thresholds, penalty clauses for late delivery, and currency denomination conditions. An invoice that is price-correct but violates these terms, charging net 30 when the contract specifies net 45, applying a surcharge when a performance penalty should apply instead, is not compliant even though the line-item prices match.

Contract terms compliance requires the contract terms to be accessible in a structured, queryable form, not buried in a PDF that requires a human to read before every invoice. The agent for extracting key terms from contracts at scale transforms contract PDFs into structured data that the pre-decision control layer can query automatically: payment terms, penalty conditions, rebate triggers, all extracted and applied to each invoice before it reaches approval.

Check 6 - Invoice completeness and format compliance

An invoice that is missing required fields, no PO reference, no VAT number, incomplete delivery address, cannot be correctly posted or audited. Approving and paying a non-compliant invoice creates downstream problems: matching failures when the PO reference is absent, VAT reclaim complications when the VAT number is missing, audit documentation gaps when the required fields are absent.

Pre-decision completeness checking confirms that every required field is present and populated before the invoice reaches the approval queue. Incomplete invoices are returned to the supplier with specific field-level feedback rather than entering the approval workflow with missing data. The accounting inbox agent applies this completeness check at the point of document ingestion, the first step in the pre-decision validation chain.

What the pre-decision validation architecture looks like in practice

Implementing the six checks above requires a validation architecture that operates upstream of the approval workflow, not as a component of it. The sequence:

Step 1 — Ingestion and triage.

Every invoice arrives through the accounting inbox, email, supplier portal, scan, and is immediately extracted, classified, and assessed for completeness. Incomplete invoices are returned to the supplier at this stage. Complete invoices proceed to validation.

Step 2 — Automated validation.

The six checks are applied automatically, in parallel where possible: price compliance against the contracted rate reference, duplicate detection against the invoice history, three-way match against the PO and delivery records, supplier master validation against the payment details reference, contract terms compliance against the extracted contract data, and completeness verification. Each check produces a pass, fail, or exception result.

Step 3 — Exception routing.

Invoices that pass all six checks proceed to the approval queue with a validation confirmation attached. Invoices that fail one or more checks are routed to the exception workflow with the specific failure identified, the relevant reference data surfaced, and a recommended resolution action. The exception is held until resolved, the invoice does not enter the approval queue until the exception is cleared.

Step 4 — Approval with validation context.

The approver sees the invoice alongside its validation confirmation: all six checks passed, the specific values compared, and a clear indication that the invoice is validated and ready for payment. The approval decision is genuine, the approver is confirming a validated transaction rather than providing a plausibility endorsement of an unchecked document. The human-in-the-loop control principle applies: the agent validates, the human decides, accountability is maintained.

Step 5 — Documented decision record.

The approval decision, the validation results, and the exception resolution path (where applicable) are captured in the audit trail automatically. The documentation exists before the payment runs, not assembled retrospectively. Audit-ready finance processes are the natural output of this architecture.

The relationship between pre-decision control and approval workflow design

Pre-decision invoice control changes the nature of the approval workflow, not just the accuracy of the data the approver sees.

In a standard approval workflow without pre-decision validation, the approver's role is both evaluative and investigative. They review the invoice for plausibility, check whether it looks right, and escalate if something seems off. The escalation requires investigation, finding the contract, checking the delivery records, calling the supplier. This investigation is often not performed for invoices that look plausible but contain errors that are invisible to unaided human review.

In an approval workflow with pre-decision validation, the approver's role is confirmatory. The investigation has been completed by the validation layer. The approver reviews the validation results alongside the invoice, confirms that the results are consistent with their understanding of the supplier relationship, and approves. The escalation protocol is already defined, the validation layer has identified what is wrong, the exception workflow has structured the investigation, and the approver confirms the resolution rather than initiating an open-ended investigation.

This role change has two practical implications. The approval review is faster, the approver spends seconds on a validated invoice rather than minutes on an uninvestigated one. And the approval coverage is higher, the approver can review more invoices with more confidence, because the investigation work that would otherwise limit throughput has been automated.

Exception-based finance review applied to the approval workflow means that the approver's attention concentrates on the 3-7% of invoices that have failed a validation check, rather than being distributed across the full invoice population. This is not a reduction in scrutiny, it is a concentration of scrutiny on the invoices that actually require it.

The fraud prevention dimension of pre-decision control

Invoice fraud, fraudulent invoices submitted for genuine payment, or legitimate invoices intercepted and modified to redirect payment, is a risk category that pre-decision validation addresses directly.

The most common patterns of invoice fraud that pre-decision validation intercepts:

Business Email Compromise (BEC) with modified payment details.

A fraudster intercepts a legitimate supplier's email communication (or impersonates the supplier) and sends an invoice with modified bank details, requesting payment to a fraudulent account. The invoice amount, reference number, and description are identical to a legitimate invoice. Without supplier master validation at the pre-decision stage, the invoice passes a standard approval review. With supplier master validation, the IBAN mismatch between the invoice and the authorised payment details generates an immediate exception before the invoice reaches the approver.

Fictitious supplier invoices.

A fraudulent invoice is submitted from a supplier that exists in the system (because the supplier name is used from the master data) but is not associated with an actual purchase. Without three-way match validation, the invoice may pass approval if it falls within an approver's tolerance for unfamiliar transactions. With three-way match validation, the absence of an associated PO and delivery record generates an exception that blocks the invoice from approval.

Duplicate fraud.

A legitimate invoice is submitted twice, once via the standard channel, once via an alternate channel, in a pattern designed to pass ERP-level duplicate detection by using a modified invoice number or date. Without population-level near-duplicate detection, the second invoice may pass both the ERP check and the approver's review. With pre-decision near-duplicate detection, the second invoice is flagged before it reaches the approval queue.

The financial risk exposure that invoice fraud represents is significant and growing, industry data consistently shows invoice fraud as one of the fastest-growing categories of business financial crime. Pre-decision validation is not a fraud detection system in isolation; it is a control layer that eliminates the specific workflow gaps that make invoice fraud possible.

FAQ

What is pre-decision invoice control?

‍Pre-decision invoice control is the practice of validating supplier invoices against reference data, contracted prices, purchase orders, delivery records, supplier master data, and invoice history, before the payment approval decision is made. It positions the control at the point where intervention is free: before cash leaves the account, before the approver commits to a payment, before the error becomes a recovery problem. The six specific checks that pre-decision control covers are: price compliance, duplicate detection, three-way match, supplier master integrity, contract terms compliance, and completeness verification.

Why does the timing of invoice validation matter?

‍The cost of intercepting an invoice error before payment is trivial, the invoice is held, the supplier is contacted, the corrected version is approved. The cost of recovering from an invoice error after payment is significant, credit note process, supplier dispute, correction postings in the ERP, partial recovery risk. The financial difference between the two outcomes, multiplied across an organisation's invoice error rate, is what makes pre-decision control far more cost-effective than post-payment review, even when the total validation work performed is identical.

Is pre-decision control the same as an invoice approval workflow?

‍No. Invoice approval confirms that an authorised person has endorsed the payment. Pre-decision control validates that the invoice is accurate by cross-referencing it against external reference data that is not visible to the approver without the validation layer: contracted prices, PO and delivery records, invoice history for duplicate comparison, supplier master payment details. A typical approval workflow performs plausibility checks, does this look right? Pre-decision control performs accuracy checks, is this confirmed correct? The two are designed to work together: pre-decision validation provides the accuracy confirmation, the approval workflow provides the accountability endorsement.

What is the typical invoice error rate before pre-decision control is deployed?

‍Invoice error rates before systematic pre-decision control typically range from 3-7% of invoice lines, with higher rates in organisations with complex supplier pricing agreements, high supplier counts, or manual invoice ingestion processes. These errors are distributed across price deviations (most common), duplicates (second most common), and missing delivery confirmation or supplier master mismatches (less frequent but higher individual financial impact). After deploying pre-decision validation, the error rate in approved and paid invoices typically decreases to under 2%, the Astotel case (7% to 2%) is representative.

How does pre-decision invoice control interact with the existing ERP?

‍Pre-decision control operates upstream of the ERP, it validates invoices before they enter the ERP's approval workflow or posting queue. Validated invoices are passed to the ERP with validation confirmation attached. Invoices with unresolved exceptions are held outside the ERP until the exception is cleared. The ERP's own validation (structural checks, duplicate invoice number detection) continues to apply as a second layer after the pre-decision validation has confirmed economic accuracy. The two layers are complementary: pre-decision validation ensures the data is economically accurate; ERP validation ensures the posting is structurally correct.

How long does pre-decision invoice validation add to the invoice processing cycle?

‍For automated validation (the 93-97% of invoices that pass all six checks without exceptions), pre-decision validation adds zero time to the cycle, the checks run in parallel with the document ingestion process and are completed before the invoice would have entered the manual review queue under the previous workflow. For exception invoices (the 3-7% that fail one or more checks), the exception resolution adds time to that specific invoice's cycle, but this time would have been spent on post-payment recovery anyway, under worse conditions and with higher total cost.

What is the difference between pre-decision invoice control and continuous finance control?

‍Pre-decision invoice control is a specific application of the continuous finance control principle to the AP workflow. Continuous finance control is the broader posture of validating financial data continuously throughout the period rather than in periodic batches. Pre-decision invoice control implements this posture specifically for the decision point where control is most cost-effective: the moment before payment is authorised. The relationship is hierarchical: continuous finance control is the operating philosophy, pre-decision invoice control is its application to the AP-specific decision gate.

Control is most valuable the moment before it becomes necessary

The distinguishing characteristic of pre-decision invoice control is not that it catches more errors than post-payment review. An organisation with a rigorous monthly AP review may ultimately catch the same errors. What pre-decision control changes is the cost of catching them.

Every error intercepted before payment costs nothing to correct. Every error discovered after payment costs time, friction, and uncertain recovery. The finance team that validates before approval is not more thorough than the one that validates after, it is the same thoroughness applied at the only moment when the control produces a guaranteed outcome.

The approver who sees a validated invoice, price confirmed, delivery confirmed, no duplicate found, payment details verified, makes a different kind of decision than the approver who signs off on an unchecked document. The first is a decision backed by evidence. The second is a judgment call based on plausibility. Only one of those two decision types meets the standard of financial control.

Phacet's pre-decision validation architecture implements the full six-check stack, supplier billing control, three-way matching, accounting inbox management, contract terms extraction, and payment extraction and verification, as an integrated pre-approval layer. Every invoice is validated before it reaches the approver. Every validation result is documented. Every exception is routed with context. The approver confirms; the agent validates. That is what pre-decision control looks like in production. Book a demo to see it applied to your invoice population.