The best pre-payment controls for accounts payable teams

Most accounts payable teams have controls. They have an ERP with approval workflows. They have a two-way or three-way match requirement, at least in policy. They have a signoff chain for payments above a certain threshold. And most AP teams, if asked, would say their controls are working.

The evidence suggests otherwise. The Association of Certified Fraud Examiners reports that billing fraud represents the most common form of asset misappropriation, with a median loss of $100,000 per incident. PwC's Global Economic Crime Survey found that 46% of organisations experienced fraud in the two years prior to the survey, with invoice fraud consistently ranking among the most frequent vectors. And these figures measure only fraud, they don't capture the far more common category of billing errors, price deviations, and duplicate payments that pass through without being intentional.

The gap between "we have controls" and "our controls cover 100% of transactions" is where the losses occur. This article maps the specific controls that make AP pre-payment coverage systematic, what each control catches, where it sits in the workflow, why manual processes cannot sustain it at scale, and how AI agents have changed the economics of building complete coverage.

Why AP teams have control gaps despite having systems

The instinct when control failures are identified is to blame process. Someone didn't follow the procedure. A payment got pushed through outside the normal workflow. An exception was made that shouldn't have been. But the more accurate diagnosis in most organisations is structural: the systems AP teams use were not built to provide the control coverage that AP operations require.

An ERP approval workflow validates that a payment has been approved by someone with the right authorisation level. It does not validate whether the invoice being approved is correctly priced, whether it duplicates a payment made last month across a different entity, whether the IBAN on the payment instruction matches the account that has historically received payments from this supplier, or whether the delivery confirmed matches what was actually ordered.

Each of these validations requires information that the ERP does not holdn the negotiated rate from the supplier contract, the full transaction history across all entities, the bank account registered when the supplier relationship was established, the quantities on the original purchase order. The ERP approval workflow confirms authority. It does not confirm accuracy.

This structural gap is what pre-payment controls are designed to close. Not by replacing the ERP approval workflow, but by adding the accuracy validations that the approval workflow cannot perform, at the point in the process where an action can still be taken before funds move.

The pre-decision control principle captures this precisely: every validation that catches an error before financial commitment is worth orders of magnitude more than the same validation performed after the fact. Recovering a duplicate payment requires supplier negotiation and credit note processing. Catching the duplicate before payment requires nothing more than a comparison against a prior transaction record.

The 6 pre-payment controls every AP team should have

AP control coverage is not binary, it is a stack of distinct controls, each operating at a specific point in the workflow and catching a specific category of error or fraud. A complete AP control stack requires all six. Most organisations have two or three, partially implemented.

Control 1 — Invoice intake validation: is this document legitimate and complete?

The first control point is at document receipt, before any structured processing begins. Invoice intake validation checks that each incoming document is what it purports to be: a legitimate invoice from a recognised supplier, with the structural completeness required for processing.

Intake validation catches:

• Document integrity issues: invoices where the PDF has been modified after generation, where field values are inconsistent with the document's apparent source, or where the formatting deviates from the supplier's established template in ways that suggest manipulation
• Completeness failures: invoices missing mandatory fields (VAT number, invoice date, purchase order reference, delivery address) that would require manual follow-up if not caught at intake
• Classification errors: documents that are not invoices, statements, reminders, quotations, entering the AP queue and creating processing overhead

Intake validation is a prerequisite for every downstream control. A control that compares an invoice's line prices against a contracted rate cannot function correctly if the invoice data was incorrectly extracted at intake. An organisation that skips intake validation and relies on manual review is transferring the quality burden to the most expensive point in the workflow.

Phacet's accounting inbox agent handles intake validation automatically across all incoming channels, email, supplier portal, scanned mail, extracting structured data, checking document integrity, and routing each document with a quality confidence score before any human reviews it.

Control 2 — Duplicate detection: has this invoice been submitted before?

Duplicate invoice fraud and processing errors are among the most common and most recoverable AP failures, but only if they are caught before payment. Once a duplicate has been paid, recovery requires a credit note request, supplier negotiation, and an extended reconciliation process. In multi-entity organisations where the same supplier invoices multiple entities, duplicates may never be identified at all if detection only operates within a single entity's AP system.

Effective duplicate detection requires checking each incoming invoice against:

• The same entity's own AP history (same invoice number, same amount, same supplier, submitted twice)
• Cross-entity AP history (same invoice appearing in the AP queues of two different entities in the same group)
• Near-duplicate patterns (slightly modified invoice numbers, marginal amount differences, changed issue dates, hallmarks of deliberate duplicate submission rather than processing error)

Standard ERP duplicate detection checks for exact invoice number matches within a single entity. It misses near-duplicates and cross-entity duplicates entirely. The accounts payable automation layer that Phacet's control agents add to this baseline extends duplicate detection to all three categories, covering the full range of duplicate patterns that ERP-native checks leave exposed.

Control 3 — Price compliance: does this invoice match what was agreed?

Price compliance is the control with the highest sustained financial impact in AP operations. Every organisation that purchases goods or services under negotiated contracts or price lists is exposed to price deviations on incoming invoices, some accidental, some systematic, and some deliberate. Without a systematic check of each invoice line against the applicable contracted rate, these deviations accumulate undetected.

The scale of exposure is significant. For a food service group purchasing €2M in food supplies annually, a 3% systematic price deviation across supplier categories represents €60,000 per year in undetected overpayment. For a retail chain managing 5,000 SKUs across multiple supplier relationships, verifying that each invoice line matches the negotiated unit price is, as one Phacet prospect described it, "humanly impossible."

Price compliance control requires:

• A current reference database: the contracted rates, price lists, or mercuriale pricing that each supplier invoice should be compared against
• Line-level matching: comparison at the individual invoice line, not the invoice total (a total can be correct while individual line prices are wrong, netting to the same amount)
• Deviation scoring: ranking anomalies by financial impact (high-volume deviations on low-value lines can exceed the financial impact of a single high-value deviation)
• Pre-payment routing: exceptions flagged before the invoice enters the payment queue, not after it has been processed

Phacet's supplier billing control agent runs this comparison on every invoice line, every cyclen not a sample. The Jinchan Group achieved a 5x increase in anomaly detection rate when moving from periodic manual checks to systematic AI-powered price compliance validation. Vivason identified €180,000 in annual overcharges that had been passing undetected through their existing AP controls.

For a comprehensive treatment of how price compliance control works in practice, see our article on preventing supplier overpayment.

Control 4 — 3-way matching: does the invoice match the order and the delivery?

3-way matching is the most structurally rigorous AP control, and the one most frequently implemented partially or not at all. The concept is straightforward: an invoice should only be approved for payment if the goods or services it describes were actually ordered (the purchase order) and actually delivered (the goods receipt or delivery confirmation). Matching these three documents prevents payment for goods never ordered, goods never received, and quantities or specifications that differ between order and delivery.

In practice, 3-way matching breaks down in two ways. First, organisations implement 2-way matching (invoice against PO only) without validating against the delivery record, leaving the category of "delivered differently from what was invoiced" undetected. Second, the matching is performed manually on high-value invoices only, leaving the majority of the invoice population unchecked.

The financial exposure from incomplete 3-way matching is not limited to fraud. Suppliers that routinely invoice for slightly higher quantities than delivered, or slightly different specifications than ordered, generate systematic overcharges that accumulate over time without triggering any threshold-based alert.

Phacet's 3-way matching agent matches PO, delivery confirmation, and invoice at the line level, quantity, unit price, item reference, and routes invoices where any dimension of the match fails to an exception queue with the specific discrepancy identified. The use case page for 3-way matching covers the full scope of what systematic matching catches versus manual or partial implementations.

For the broader context of how 3-way matching fits into payment traceability, see AI 3-way matching automation and payment traceability.

Control 5 — Supplier master data integrity: is the payment going to the right place?

Supplier master data controls are the AP control category most frequently underestimated, and the one with the highest per-incident cost when they fail. Supplier bank account change requests are the primary vector for business email compromise (BEC) fraud, where attackers impersonate a supplier contact to redirect payment to a fraudulent account. The French national cybersecurity agency (ANSSI) identifies this as the leading fraud vector affecting French businesses, with average losses typically exceeding €50,000 per incident.

The control gap is structural. AP teams have processes for onboarding new suppliers, KYC checks, procurement approval, bank detail registration. Most organisations do not have equivalent systematic controls for supplier bank account changes. A request to update a supplier's IBAN that arrives by email, appears to come from a known contact, and references a legitimate invoice, passes through the standard AP workflow without any dedicated validation beyond a clerk's judgment call.

Effective supplier master data controls catch:

• IBAN change requests that precede a scheduled payment run for the affected supplier, the timing pattern characteristic of BEC fraud
• Bank account details that don't match the supplier's country of registration, a French supplier whose new IBAN has a foreign country code
• Changes submitted from email addresses or domains that deviate from the supplier's established communication pattern
• Multiple changes to the same supplier record in a short window, a pattern consistent with account takeover attempts

La Nouvelle Garde's experience illustrates the stakes directly: a €28,000 payment was intercepted after an IBAN change request passed through their normal workflow without triggering any alert. The fraud was caught at the pre-payment validation stage by Phacet's control layer, the point in the workflow where the payment instruction was being prepared, not after the funds had already moved. See the full La Nouvelle Garde case study for the detection mechanism detail.

Control 6 — Payment batch validation: final check before funds move

Payment batch validation is the last control checkpoint before payment instructions are executed, a final sweep of the payment batch to confirm that every item in it has cleared the upstream controls, that no anomalies have been introduced during batch assembly, and that the batch totals are consistent with the approved invoices it should contain.

This control is not a substitute for upstream validation. An AP team that relies on payment batch review as its primary control is reviewing hundreds of line items under time pressure, making the same systematic errors that make upstream validation necessary in the first place. Payment batch validation is effective as a final checkpoint precisely because upstream controls have already eliminated the bulk of anomalies, leaving a clean population where final-stage exceptions are meaningful rather than routine.

Batch validation specifically checks:

• Every invoice in the batch has a documented approval trail (the audit trail that connects invoice receipt to payment authorisation)
• No invoices in the batch were added after the approval cycle closed
• Batch totals reconcile to the sum of individually approved invoice amounts
• No payment destinations in the batch were changed after individual invoice approval

Combined with upstream controls, payment batch validation closes the window for post-approval manipulation, the category of fraud where an invoice is legitimately approved but the payment instruction is modified before execution.

Why manual AP controls cannot provide systematic coverage

Each of the six controls described above is, in principle, executable manually. AP teams know they should verify prices, check for duplicates, match delivery records. The structural problem is coverage: manual control processes can verify a sample of transactions, not all of them.

The sampling problem

A finance team that processes 400 invoices per month and dedicates four hours per week to AP control reviews can review approximately 30 to 40 invoices per cycle at adequate depth, roughly 8 to 10% of the invoice population. The 90% that goes unreviewed is not low-risk by definition; it is simply unreviewed. Price deviations, near-duplicates, and suspicious bank account changes in the unreviewed population accumulate undetected until a period-end reconciliation or an external audit surfaces them.

Our analysis of invoice sampling versus 100% validation covers this coverage gap in detail. The conclusion is consistent with what every AP team that has moved from sampling to systematic validation reports: the anomaly rate in the previously unsampled population is not lower than in the sampled population. It is the same. The only difference is whether those anomalies are caught before or after payment.

The consistency problem

Manual controls are person-dependent. The AP analyst who notices a 2% price deviation on a food supplier invoice might not be working the day a 1.8% deviation arrives from the same supplier. The colleague who covers that day applies a different threshold, tacitly or explicitly. Price tolerance, duplicate sensitivity, and the judgment calls about which anomalies warrant escalation vary between reviewers, between periods, and under time pressure.

Systematic pre-payment controls eliminate this inconsistency. The tolerance thresholds are configured once, applied uniformly, and documented for every transaction reviewed. The human-in-the-loop control model means human judgment is still applied to exceptions, but to the same exceptions, evaluated against the same criteria, every time.

The documentation problem

Manual AP controls generate informal documentation at best. An email chain confirming a price check. A note in the ERP that an invoice was reviewed. A spreadsheet tracking the payment batch approval. None of this constitutes the structured, searchable, timestamped audit trail that an auditor needs to verify that controls were operating systematically during a given period.

Audit-ready finance processes require documentation that demonstrates systematic coverage, not selective evidence of controls applied to the invoices that happened to be reviewed. Systematic pre-payment controls generate this documentation automatically: every invoice processed, every control applied, every exception raised, every human decision recorded, every resolution timestamped.

Building systematic AP control coverage with AI agents

The economics of manual AP control make systematic coverage unviable at any meaningful transaction volume. Hiring to achieve 100% manual review coverage of AP transactions is disproportionately expensive relative to the value at risk on most individual transactions. The alternative, accepting sampling as sufficient, is accepting that a predictable fraction of transactions will never be validated.

AI control agents change this equation. An AP control agent that runs continuously on 100% of in-scope transactions costs the same regardless of whether it processes 200 invoices per month or 2,000. The coverage is not degraded by volume, time pressure, or staff availability. The documentation is complete regardless of whether any individual transaction was unusual enough to attract human attention.

Phacet's AP control layer connects to the existing invoice intake channel, accounting inbox, supplier portal, or direct ERP integration, and applies the full control stack automatically. Invoices that pass all controls move to the payment queue without human intervention. Invoices where any control raises an exception enter the exception-based review workflow, typically 3 to 5% of total invoice volume, where a human reviewer receives the full context of the exception: which control triggered it, what the deviation is, and what action is recommended.

Astotel's experience illustrates the coverage shift. Moving from manual invoice review to systematic AI-powered validation reduced their invoice error rate from 7% to 2%, not by improving the quality of the reviews that were already happening, but by extending control coverage to the population of invoices that previously passed through without any validation at all. See the Astotel case study for the full deployment detail.

The purchase-to-pay automation framework that Phacet's agents implement covers the full AP workflow, from invoice intake through price and quantity validation, 3-way matching, supplier master data checks, and payment batch review, as a single, continuously operating control layer rather than a series of disconnected manual processes.

For the broader context of how AI is restructuring the P2P workflow, see AI purchase-to-pay automation and financial control.

From partial to systematic: an implementation path

AP teams moving from partial to systematic control coverage typically follow a sequenced path, deploying the highest-impact controls first and extending coverage as the initial deployment reaches steady state.

Step 1 — Connect the invoice intake channel (week 1–2).

The first connection is to the accounting inbox or AP intake point, the channel through which supplier invoices arrive. Phacet's no-code automation interface allows AP teams to configure this connection and the intake validation rules without IT project involvement. Intake validation and duplicate detection are active from day one of live operation.

Step 2 — Load supplier reference data (week 2–3).

Price compliance control requires the reference database against which invoice prices are compared, supplier contracts, price lists, mercuriale files, or the ERP's vendor master pricing data. This reference data is loaded into Phacet's control layer and mapped to the supplier identities in the invoice population. Price compliance checking is active once the reference data is loaded and validated.

Step 3 — Configure 3-way matching (week 3–4).

3-way matching requires connecting to the PO and goods receipt data in the ERP. Phacet's integration layer reads PO and GR records via API or structured export and applies the matching logic against incoming invoices. The matching tolerance thresholds, acceptable quantity variance, acceptable price rounding difference, are configured to reflect the organisation's commercial context.

Step 4 — Enable supplier master data monitoring (week 3–4).

Supplier IBAN change monitoring is configured from the supplier master records in the ERP. Any modification to a supplier's bank account details triggers an alert and is routed to a dedicated review workflow before the changed details can be used in a payment run.

Step 5 — Calibrate exception thresholds and review workflow (week 4–6).

The first weeks of live operation generate the data needed to calibrate exception thresholds, adjusting price tolerance levels, duplicate detection sensitivity, and matching variance parameters to reach the target exception rate. The review workflow is configured to route each exception category to the appropriate reviewer with the right level of detail and recommended action.

The full deployment from initial connection to stable systematic coverage typically takes four to six weeks, without ERP modification, without disruption to existing payment workflows, and without a dedicated IT project.

FAQ

What are pre-payment controls in accounts payable?

‍Pre-payment controls are the validation steps that AP teams apply to incoming invoices before approving them for payment. They include checks for invoice legitimacy and completeness (intake validation), comparison of billed prices against contracted rates (price compliance), cross-referencing of invoices against purchase orders and delivery records (3-way matching), verification of supplier bank account details (master data integrity), and final review of the payment batch before funds move. Pre-payment controls are distinct from post-payment reconciliation: their value is in catching errors and fraud before financial commitment, at the point where resolution costs a conversation rather than a recovery process.

Why are manual AP controls insufficient for most organisations?

‍Manual AP controls have three structural limitations: coverage (manual review can verify a sample of transactions, not all of them), consistency (different reviewers apply different thresholds and catch different anomalies), and documentation (manual controls generate informal records that do not constitute a systematic, auditable control trail). For organisations processing more than 100 to 200 invoices per month, manual controls operating at sample depth leave the majority of the invoice population unvalidated. The anomaly rate in the unreviewed population is not lower than in the reviewed population, it is simply unknown until something goes wrong.

What is 3-way matching in accounts payable?

‍3-way matching is an AP control that cross-references three documents, the purchase order, the goods receipt or delivery confirmation, and the supplier invoice, to verify that the quantities, prices, and item references are consistent across all three. An invoice is approved for payment only when all three documents match within configured tolerance thresholds. 3-way matching prevents payment for goods never ordered, goods never received, and quantities or specifications that differ between what was ordered and what was invoiced. It is the most comprehensive AP control for the purchase cycle and the one most frequently implemented partially or bypassed under time pressure.

How does AI improve AP controls versus traditional ERP automation?

‍ERP-native AP controls validate that a transaction meets the ERP's internal consistency rules, correct account codes, authorised approver, no exact duplicate invoice number within the same entity. They do not validate the transaction against external reference data: the contracted rate in the supplier agreement, the delivery record from the warehouse system, the bank account registered when the supplier was onboarded, or the invoice population across other entities in the group. AI AP control agents extend validation to these external reference sources, applying line-level price comparison, cross-entity duplicate detection, multi-dimensional 3-way matching, and supplier master data integrity checks that ERP-native controls cannot perform.

What is the ROI of systematic AP pre-payment controls?

‍The ROI of systematic AP pre-payment controls has two components. Direct recovery: the price deviations, duplicates, and billing errors that pre-payment controls identify and prevent paying, typically recoverable within the first 30 to 60 days of deployment as existing billing patterns are validated against contracted rates. Ongoing avoidance: the continuous prevention of billing deviations, duplicate payments, and fraud that would otherwise accumulate undetected. The time savings from shifting AP teams from manual review of all invoices to exception-based review of 3 to 5% of invoices is a third ROI component, hours freed for analysis and supplier management rather than transaction processing.

How long does it take to implement AI-powered AP controls?

A working AP control deployment covering invoice intake, duplicate detection, and price compliance is typically operational within two to three weeks. Adding 3-way matching and supplier master data monitoring requires a further one to two weeks for ERP data connection and configuration. Full deployment from initial connection to stable systematic coverage, including exception threshold calibration, takes four to six weeks. This timeline does not require ERP modification, IT project engagement, or changes to downstream payment and accounting workflows.

Control before cost: the AP standard that pays for itself

Every payment that goes through without validation is a bet that the invoice is correct. Most of the time, it is. But the fraction that isn't, the price deviations, the duplicates, the fraudulent bank account changes, the invoices for goods that weren't received, accumulates steadily, invisible until something surfaces it.

Systematic AP pre-payment controls are not an insurance policy against unlikely events. They are the operational standard that makes the AP function accurate by design rather than by luck. The finance teams that have deployed systematic coverage, complete intake validation, price compliance on every line, 3-way matching on every invoice, supplier master data monitoring, documented audit trails, report the same outcome: they spend less time processing transactions and more time managing the exceptions that matter, because the exceptions they see are the real ones.

Phacet's AP control agents deliver this coverage as a continuous operating layer, connected to your existing tools, applying your business rules, routing exceptions with full context, and maintaining the audit trail that makes every validation reviewable and every decision defensible. Book a demo to see how systematic AP pre-payment controls apply to your invoice population and what your current billing patterns reveal when every transaction is validated.