.svg)
The procure-to-pay cycle is one of the most studied processes in finance operations. Organisations have spent years investing in ERPs, procurement tools, and AP software. And yet the same problems keep appearing: invoices that do not match purchase orders, approvals that stall for days, payments that arrive late, and a finance team spending time on manual reconciliation that modern technology is supposed to have eliminated.
The reason these purchase-to-pay challenges persist is not that the technology does not work. It is that most P2P problems are connected, not isolated. A gap in supplier data quality at the onboarding stage creates invoice exceptions three weeks later. Disconnected systems that do not share data in real time create visibility gaps that make approval bottlenecks invisible until they become overdue payments. Fixing one symptom without addressing the structural cause means the same problem returns.
This guide covers the eight P2P challenges that finance teams consistently report, where each one actually originates, and what a structural fix looks like rather than a workaround.
P2P challenges are connected, not isolated. A data quality failure at supplier onboarding creates invoice exceptions, payment errors, and fraud exposure downstream. Fixing symptoms without addressing root causes means the same problems return.
This connection is the reason that partial fixes rarely hold. A company that addresses invoice exceptions without fixing the purchase order quality that generates them will continue to see exceptions. A company that improves approval workflow speed without connecting that workflow to real-time ERP data will continue to close months late.
The eight challenges below follow a consistent pattern across organisations, regardless of industry or size. Each one has a root cause that is usually upstream of where the symptom appears.
Maverick spending happens when employees purchase from unapproved suppliers or outside contracted agreements, usually because the approved process is slower or more complicated than just buying directly.
The most common P2P challenges include maverick spending, where employees bypass approved channels and purchase outside contracted vendors. The consequence is not just a compliance gap. It means negotiated contract prices are not being captured, spend is not visible to the finance team until it appears as an invoice, and budget controls that were supposed to apply at the purchase stage are not applied at all.
The fix is not stricter enforcement. It is making the approved process easier and faster than the workaround. When the purchase requisition workflow takes three clicks instead of three emails, when the approved supplier catalogue is visible at the point of purchase, and when pre-purchase approval is genuinely lightweight for low-value routine purchases, the behavioural incentive to bypass the process disappears.
Invoice exceptions, where the invoice does not match the purchase order or delivery note closely enough to auto-approve, are the single largest driver of AP team workload in most organisations. The Ardent Partners 2025 benchmarking found an industry average exception rate of 22.6%. Best-in-class organisations have reduced this to 5.4%.
The gap between those two numbers is mostly determined upstream. Exceptions originate when purchase orders are created with inaccurate descriptions, when partial deliveries are not recorded before the invoice arrives, when suppliers submit invoices without referencing the PO number, and when POs are created after the invoice rather than before.
Standard ERP three-way match catches exact duplicates but misses near-duplicates with slightly different invoice numbers, amounts, or dates. Improving the exception rate requires both better matching logic on the processing side and better discipline on the PO creation side. Neither alone is sufficient.
Most finance teams do not know what their organisation is committed to spending until the invoice arrives. Purchase orders are raised in one system, invoices are processed in another, payments are executed through a third, and the finance team constructs the actual picture of committed spend at month-end from data exported out of all three.
Poor spend visibility, where fragmented systems make it difficult to see what's being spent across the organisation in real time, is one of the most common P2P challenges.
The consequence is that budget overruns are discovered at month-end rather than at the point where they could have been prevented. Cash flow forecasts are based on what was invoiced rather than what was committed. And the finance team's role becomes reactive: explaining variances after the fact rather than controlling spend before it happens.
Real-time spend visibility requires that the P2P workflow operates within connected systems rather than across disconnected ones. When a purchase order is approved, that commitment should be visible to the finance team immediately. When an invoice is received against that PO, the outstanding liability should update in real time.
Approval cycles that run by email are structurally slow. An invoice arrives in the AP inbox, someone forwards it to the relevant approver, the approver has other priorities, the AP team sends a reminder, and eventually the approval happens. By which point the payment terms have often expired, early payment discounts have been missed, and the supplier relationship has absorbed a friction point that compounds over time.
Approval bottlenecks, where manual routing delays low-risk purchases, are among the most consistent P2P challenges finance teams report.
The fix is to automate approval routing based on invoice value, category, and urgency, create a separate fast track for discount-eligible invoices, remove email from the approval process, and replace it with structured workflows that escalate automatically when approvals are overdue.
The escalation piece matters as much as the routing. A workflow that routes correctly but does not escalate automatically when an approver does not respond within the defined window still creates the same bottleneck through inaction.
Duplicate invoices enter the payment queue in several consistent ways: a supplier resubmits an invoice because payment has not arrived, the same invoice is emailed to two different AP team members and processed independently, or a digitised version and a paper version of the same invoice both enter the system on different channels.
Standard ERP duplicate detection catches exact matches: the same invoice number, the same amount, the same supplier. It misses the near-duplicates: the same invoice with a slightly different reference number, a minor amount variation, or a different submission channel that creates a different internal reference.
Internal financial fraud risks fall by about 25% when automated and secured document workflows are used, with complete audit trails reinforcing that control environment.
Effective duplicate detection requires fuzzy matching that compares invoices across multiple normalised fields simultaneously, not just exact-match logic against invoice reference numbers.
Late payment is often framed as a payment timing problem. In practice, it is usually an approval timing problem. Invoices that arrive and are processed promptly but then sit in an approval queue for ten days do not create a payment problem until the approved invoice reaches a payment run that has already passed.
According to the Atradius 2025 Payment Practices Barometer, 43% of credit-based B2B sales were overdue in 2025, primarily driven by customer cash flow pressures. Late payments damage supplier relationships, trigger penalty clauses, and eliminate early payment discount opportunities.
In the UK, the Commercial Payments Bill introduces formal obligations around payment timing and transparency that make this a regulatory risk as well as a commercial one. Finance teams that cannot demonstrate that their P2P cycle reliably meets the 60-day payment cap will face reporting and compliance obligations they are not currently equipped to meet.
When procurement happens in one tool, invoices arrive in another, and payments are processed in yet another, organisations often face reconciliation challenges and zero real-time visibility into company spending. Manual handoffs between disconnected platforms create the perfect conditions for errors and duplicate payments that take up additional time to resolve.
Every manual handoff, exporting data from a procurement tool and re-entering it in the ERP, wastes time and introduces errors that accumulate through the P2P cycle.
This is the root cause of many of the challenges above. Maverick spending is harder to prevent when the purchasing tool and the approval workflow are in different systems. Invoice exceptions are harder to resolve when the invoice, the PO, and the delivery note are in separate systems. Spend visibility is impossible when committed spend and actual invoiced spend live in tools that do not share data.
The fix is not necessarily replacing every system. It is connecting them deeply enough that data flows in real time between them rather than being manually transferred.
According to the 2026 AFP Payments Fraud and Control Survey, 76% of organisations experienced attempted or actual payment fraud in 2025. The P2P cycle is a consistent fraud target because it involves many suppliers, many approval points, and significant outgoing cash flows.
The most common attack vectors are invoice fraud, where fraudulent invoices from fake or impersonated suppliers enter the payment queue; business email compromise, where payment details are changed through a convincing email appearing to come from a known supplier; and internal fraud, where someone with both supplier creation and invoice approval access creates payments to controlled accounts.
The controls that prevent fraud in the P2P cycle are the same controls that improve operational efficiency: a clean vendor master with verified bank details, automated duplicate detection, segregation of duties that prevents a single person from creating a supplier and approving their invoices, and a complete audit trail for every action on every document.
Dost's AP automation platform is designed around the structural causes of P2P challenges rather than their symptoms.
Invoice exceptions are reduced through AI-native data extraction that reads any invoice format at line-item level from the first document, with no templates required, and three-way matching that compares each invoice line against the corresponding purchase order and delivery note with configurable tolerance thresholds.
Approval bottlenecks are addressed through configurable approval workflows with mobile approval, automatic escalation, and priority routing for invoices with early payment discounts or approaching due dates.
Spend visibility is maintained in real time through native bidirectional integration with SAP, SAP Business One, Microsoft Dynamics 365 Business Central, Sage 200, Sage Intacct, Sage X3, and Oracle. Approved invoices post to the ERP immediately. Outstanding commitments are visible continuously rather than at month-end only.
Fraud controls include AI-powered duplicate detection using fuzzy matching across multiple normalised fields, vendor bank detail change alerts, and enforced segregation of duties across the supplier creation and invoice approval functions.
Calculate what fixing your P2P challenges would save your team.
Most P2P problems recur because the new software addresses one stage of the cycle without connecting to the stages upstream and downstream. A new AP automation tool that does not integrate with the procurement tool that creates POs, and does not post in real time to the ERP that holds the ledger, sits in the same disconnected position as the tool it replaced. The automation works within its scope, but the manual handoffs between systems remain. The root cause of most P2P challenges is disconnection between systems, not the capability of any individual system.
The evidence consistently points to purchase order discipline: ensuring that every purchase goes through an approved PO before the supplier delivers or invoices. This single change reduces invoice exceptions because matching has something to match against, reduces maverick spending because the commitment is recorded, improves spend visibility because committed spend is captured at the purchase stage, and reduces fraud exposure because every invoice should correspond to a known PO. It is an upstream change that improves every downstream metric.
The Commercial Payments Bill, currently moving through Parliament, introduces a 60-day maximum payment term cap for large businesses and mandatory payment performance reporting. For finance teams, this means the P2P cycle needs to be reliable enough to process invoices and make payment decisions within defined windows, not best-effort. Organisations with manual approval processes, batch ERP updates, and poor spend visibility are at higher risk of breaching the new requirements not because they intend to pay late, but because the process cannot reliably complete within the required timeframe. A well-automated P2P cycle is the structural answer to compliance with the new legislation.
The purchase-to-pay challenges that finance teams face in 2026 are not new problems. They are the same structural issues that have persisted through multiple technology investments because the technology addressed symptoms rather than causes.
Maverick spending, invoice exceptions, approval bottlenecks, duplicate payments, poor spend visibility, late payments, disconnected systems, and fraud exposure all trace back to the same underlying conditions: purchasing decisions made outside of connected workflows, invoice data that cannot be matched against reliable purchase records, and approval processes that depend on email rather than structured automation.
The organisations that have resolved these challenges consistently share one characteristic: they have connected the stages of the P2P cycle into a single workflow where data flows in real time and exceptions are visible at the point they occur, not weeks later during month-end close.
Use Dost's savings calculator to estimate what fixing your P2P process would save.
.png)