The Fraud Isn't in Your Policy. It's in the Vendor Master.

Procure-to-pay is the fastest-moving, highest-volume process most enterprises run. Thousands of purchase orders, goods receipts, and invoices clear every week, each one touching a vendor-master record that was set up, approved, and — critically — trusted, often years earlier and rarely re-verified since. It is also, for exactly those reasons, the process where a control gap turns into an actual cash loss the fastest. A misapplied policy costs you a finding. A vendor-master exception in P2P costs you a wire transfer that already left the building.

That exposure is no longer theoretical or rare. The Association for Financial Professionals' 2026 Payments Fraud and Control Survey Report found that 76% of organizations experienced attempted or actual payments fraud in 2025, with business email compromise — the technique most often used to redirect a legitimate vendor payment to a fraudulent account — affecting roughly 74% of organizations, making it the single most prevalent form of payments fraud today. Set against that, the same survey found only 17% of organizations currently use AI to help combat it. Most P2P defense still runs on periodic three-way matching, manual callback verification, and an annual audit sample — controls built for a threat that moves once a quarter, applied to a threat that now moves continuously.

Continuous controls monitoring closes that gap by testing procure-to-pay the way the fraud actually behaves: continuously, across the full transaction population and the vendor-master file behind it, not a sample drawn months after the payment cleared.

The Fraud Is Up. The Defense Isn't.

AFP's survey documents the pattern behind the headline number with a scenario worth sitting with: a fraudster infiltrates a vendor's email account, then sends legitimate-looking messages requesting updated banking details through the vendor's own domain. The documentation looks right. The request follows the organization's own process. The payment goes out on schedule — to an account the real vendor never controlled. Nothing about that chain trips a three-way match, because the purchase order, goods receipt, and invoice all agree with each other perfectly. The fraud sits one layer beneath the transaction, in the vendor-master record the transaction trusted without question.

The ACFE's Occupational Fraud 2026 report adds the operational-loss angle to the same picture. Organizations that use proactive data analytics as an anti-fraud control report fraud losses 53% lower than organizations that don't, against a median loss of $104,000 per case and an average exceeding $1.4 million where fraud does occur. Duplicate payments — a narrower, less headline-grabbing exposure than BEC but one that sits in the same vendor-master and invoice-matching blind spot — run an estimated 0.1% to 1.5% of total accounts-payable spend industry-wide, meaning a $100 million payables operation could plausibly be losing up to $1.5 million a year to an issue that, on the surface, looks like an administrative error rather than a control failure.

Both numbers point at the same structural problem: the controls most P2P functions rely on today were designed to catch format and calculation errors at the moment of transaction, not behavioral patterns that only become visible across time and across the vendor-master file as a whole.

Why Procure-to-Pay Is Where Governance Meets Cash

Every enterprise has a control environment on paper. P2P is where that paper meets an actual bank transfer, which is precisely why it deserves priority ahead of most other continuous-controls-monitoring domains. A policy gap in, say, vendor onboarding documentation is a finding an auditor writes up. A control gap in P2P is a payment that already left. The lag between when the gap exists and when it becomes irreversible is measured in days, not audit cycles.

Most ERP systems already run three-way matching — the standard check that a purchase order, the goods receipt confirming delivery, and the vendor's invoice agree on quantity and price before a payment is released. It is a genuinely useful, well-established control, and nothing here argues for removing it. But it is a point-in-time, single-transaction check. It has no memory of the last transaction, no visibility into whether this vendor's bank details changed last week, and no way to notice that three separate purchase orders were each kept just under an approval threshold that a single, larger order would have triggered. Those are cross-period, cross-record patterns — the exact category of risk a static match was never built to see, and the exact category continuous controls monitoring is built to test.

The Vendor Master File Is the Real Attack Surface

Ask most controllership teams where their P2P risk concentrates and they'll point to the invoice queue. The more accurate answer is the vendor-master file sitting behind it. Every payment eventually resolves to a bank account listed against a vendor ID, and that ID, once created, tends to go years without a serious re-verification — accumulating stale addresses, unreconciled duplicate entries, and, occasionally, a bank-account field a fraudster convinced someone to update. Crest.Digital's existing vendor-intelligence work has made a version of this argument for TPRM broadly: a questionnaire answered once tells you what was true at onboarding, not what's true today. The vendor-master record behind a P2P transaction has the identical problem, just with a live bank account attached to it instead of a compliance checkbox.

Continuous monitoring treats the vendor-master file as a living dataset that gets tested on the same cadence as the transactions running against it — watching for bank-account or payment-detail changes made close in time to an upcoming payment, changes submitted outside the vendor's verified contact channel, dormant vendors reactivated for a single payment, and vendor records whose address, tax ID, or bank details overlap with an employee record. None of these signals require reading the fraudulent email that triggered them. They surface from the pattern and timing of the vendor-master change itself measured against the payment calendar — which is exactly the layer a periodic review, arriving weeks or months after the fact, is structurally unable to reach in time.

8 Exceptions Continuous Monitoring Should Catch

A continuous P2P monitoring programme doesn't need to test everything on day one. These eight exception categories cover the bulk of where cash exposure and vendor-master risk concentrate, and most implementations start with two or three before expanding.

None of these eight categories require inventing a new control philosophy. Most audit programmes already test for versions of them, once a year, on a sample. What changes under continuous monitoring is coverage and timing — every transaction and every vendor-master record tested on an ongoing basis, with exceptions routed for review while the payment can still be held, not written up after it already cleared.

Standing Up Continuous P2P Monitoring: A Six-Step Delivery Model

Crest.Digital positions this as a configurable "Risk Automation Pod" rather than a bespoke software build — a shared underlying stack of integration connectors, a rules and risk-scoring engine, an evidence repository, and dashboards, customized around a specific organization's ERP, procurement setup, and vendor-master governance. The client-specific work is mainly data mapping, exception logic, and approval workflow — not the entire technology stack.

Starting narrow matters here more than almost anywhere else in a continuous-controls-monitoring rollout. A vendor bank-account-change alert that fires too often on legitimate changes gets ignored within weeks; one tuned against real historical data earns the trust that makes AP actually hold a payment when it fires. The validate step exists to build that trust before the programme expands into the remaining exception categories.

Continuous vs Periodic — and vs Broader CCM

It's worth being precise about how this fits alongside two things Crest.Digital has already written about. First, versus periodic review: an annual P2P audit tests a sample, usually 25 to 60 transactions, chosen to be statistically representative of a population that might run into the hundreds of thousands. A duplicate payment or a fraudulent bank-account change sitting outside that sample simply isn't found until the next cycle, if ever. Continuous monitoring tests the whole population on an ongoing basis, which is the entire point — it converts a coverage problem into a tuning problem, which is a much better problem to have.

Second, versus Crest.Digital's broader continuous controls monitoring overview, which introduces the full range of domains CCM can cover — ERP, payroll, CRM, banking, and operational systems generally. This piece deliberately narrows to one of those domains, procure-to-pay and its vendor-master file, because P2P combines the highest transaction volume with the most direct, fastest-moving cash exposure of any domain in that list. It's also the domain most enterprises are already primed to prioritize, given what AFP's and ACFE's 2026 data show about where payments fraud is actually landing.

The exception data this kind of monitoring generates also feeds naturally into internal audit's own work. Crest.Digital has covered how agentic internal audit extends AI across the full engagement lifecycle, and continuous P2P exception data is a direct input into that lifecycle — informing risk-based audit scoping and sampling with live control performance instead of a snapshot from the last review. And because an agent is now the one flagging the exception in the first place, the same accountability and audit-trail questions Crest.Digital has addressed elsewhere apply directly here: every alert needs a reconstructable record of what triggered it, and a named human remains accountable for the decision to hold, release, or escalate the payment it flagged.

Frequently Asked Questions