Three Generations of Procurement Technology, and the Problem None of Them Solved
Every decade brings a new wave of procurement software promising to finally eliminate manual work. First came the ERPs. SAP R/3 and Oracle digitized purchase orders and centralized spend data for the first time. Then the cloud-native source-to-pay suites arrived. Ariba, Commerce One, and Mangistics moved sourcing and supplier management online. When that generation consolidated and aged, Coupa and its peers showed up in the 2010s with modern UX, spend intelligence, and the promise of a unified procure-to-pay platform.
Each wave improved something real. Visibility got better. Approvals got faster. Catalogs replaced fax machines. But here's what three generations of technology have not changed: a significant share of procurement transactions still require a human being to open multiple systems, compare data, apply judgment, and manually push the process forward.
Ardent Partners' 2025 AP benchmarks put the industry-average invoice exception rate at 22%, with even top-performing teams still dealing with a 9% rate after years of investment. The Hackett Group's research on top-performing P2P implementations shows 73% touchless requisition-to-PO automation, meaning more than one in four transactions still drops into someone's queue. For most organizations, the numbers are far worse. McKinsey estimates that procurement functions today use less than 20% of available data to support decision-making, even as spend managed per employee has grown 50% over the last five years.
The gap between what procurement technology promises and what it actually automates is where billions of dollars in operational cost quietly live.
Legacy Tech Automated Basic Processes, but Left Humans to Handle Everything That Goes Wrong
If you run a GBS, shared services, or procurement operations function, none of this is abstract. You've sat through the vendor demos. You've signed off on the implementations. You've watched your team spend six months migrating to a new platform, only to find the same invoices piling up in the same exception queues, handled by the same people, at the same cost. Every few years there's a new promise – better analytics, smarter workflows, tighter integration – and every few years you end up back in the same place: explaining to leadership why headcount can't come down even though you just spent millions on automation.
The uncomfortable truth is that this isn't a vendor selection problem or a change management problem. It's three structural problems that every generation of procurement technology has inherited from the last, and that the latest wave of AI startups raising large rounds will inherit too – unless something fundamental changes about how the technology works.
Exceptions aren't edge cases, they're the job
The industry talks about exceptions like they're anomalies. They're not. They're the daily operating reality of procurement at scale.
A three-way match fails because a supplier shipped 480 units against a PO for 500 and the invoice reflects the shipped quantity, not the ordered quantity. A contract price doesn't match what's in the ERP because someone renegotiated terms last quarter and the system was never updated. A goods receipt sits in one system, the invoice in another, and the approval routing in a third, and none of them agree.
These aren't rare breakdowns. They represent more than one in five invoices across the industry, according to Ardent Partners. And The Hackett Group's research shows that even after implementing best-in-class P2P solutions, over a quarter of requisition-to-PO transactions still require human intervention. Every one of those transactions means someone stops what they're doing, opens three tabs, cross-references data across systems, applies judgment, and manually pushes the process forward.
When your exception rate holds steady above 20% year after year despite millions in technology investment, that's not a process problem. That's a structural failure in how procurement technology was designed.
Siloed systems can't reason across your operation
This structural failure comes from how every prior generation of procurement technology was built. ERPs, S2P suites, RPA tools. All of them operate within a single platform's walls. But exceptions are inherently cross-system problems. They span your ERP, your supplier portal, your email, your contracts, and sometimes a shared drive or a spreadsheet that your most experienced analyst just knows about.
RPA was supposed to help. It didn't. Bots follow scripts. They can move data between fields, but they can't reason about why a quantity mismatch exists and whether it should be accepted, escalated, or rejected. The 80% of transactions that are clean and structured? Automation handles those fine. The remaining 20% – the exceptions – are where the real cost concentrates. They require contextual judgment across data that lives in different systems.
This is also why the "AI features" now shipping inside every major S2P suite haven't changed the math. Bolting a copilot onto Coupa or SAP doesn't give it the ability to see your supplier's email, cross-reference your contract PDF, and check the spreadsheet your operations lead maintains on the side. No single platform can see across all of that. And wrapping an LLM around a single system's data doesn't create cross-system intelligence. It creates a faster way to search one silo.
The next-gen startups announcing large funding rounds face the same constraint if they're building on top of conventional architectures. More capital doesn't solve a design problem.
Everyone profits when your process stays broken
Here's the part nobody talks about. The companies you pay to manage the exception problem have no incentive to make it go away.
The global BPO market exceeded $325 billion in 2025, with procurement outsourcing alone valued at over $6 billion and growing at nearly 12% annually. BPOs and shared services teams are the human middleware that absorbs the cross-system rework that software can't handle. That spend isn't discretionary. It's structural. It's the cost of the automation gap.
Your BPO charges per head. Your consultants bill by the hour. Your software vendor sells more seats when more people are touching exceptions. Your implementation partner bills for a 12-month deployment. Every player in your procurement ecosystem profits when the process stays broken, and every player's commercial model is designed to scale with your pain, not eliminate it.
When the next procurement AI startup raises a big round, ask what's underneath it. Can the technology reason across every system in your operation without a data migration? Can it learn the tribal knowledge your best analysts carry in their heads? Can it go live in hours and charge you for outcomes instead of seats? If not, it's the same model in a new wrapper.
The Era of Paying for Your Own Pain Is Over
McKinsey's recent research on agentic AI in procurement describes this moment as a shift from automating steps to orchestrating outcomes. Previous generations of automation digitized individual tasks within a single system. AI agents can reason across systems, interpret context, and resolve problems end to end – the same way an experienced procurement analyst does, but at unlimited scale.
This isn't theoretical. McKinsey's research highlights enterprises already using AI agent systems to hit 20–30% efficiency gains in procurement operations, with one company boosting procurement staff efficiency by 20–30% while increasing value capture by 1–3%. Their analysis suggests that agentic AI could make procurement functions 25–40% more efficient overall.
But here's what matters if you're evaluating this wave: the technology is only as good as the architecture underneath it. An AI agent that can only see one system's data is just a faster version of the same silo. The question isn't whether AI can help. It's whether the underlying technology can actually reason across your full operation.
The era of vendors automating the easy 80% and leaving you to staff up for the hard 20% is ending. The question is which vendors are architecturally built to end it, and which ones are just repackaging the old model with a new label.
Introducing Fragment – and the End of Manual Processing for Source-to-Pay
Fragment was built to automate procurement workflows, end to end. Not to make the easy transactions 10% faster. Not to give your team a chatbot that searches one system. To resolve the exceptions that every previous generation of technology left for humans to handle, across every system in your operation.
Here's how it maps directly to the three problems above.
Your entire operation's knowledge, available on every transaction. The biggest bottleneck in exception resolution isn't processing speed. It's knowledge. Your most experienced people know which supplier abbreviations map to which contracts. They know that "FOB destination" in one system means something different from how another system codes it. They know the workarounds, the naming conventions, the business logic that lives in their heads rather than in any system of record. When those people leave, that knowledge walks out the door with them.
Fragment's technology builds a semantic understanding of how data relates across every system you run: ERP, supplier portals, contracts, email, spreadsheets, legacy tools. It learns your policies, your abbreviations, your institutional shortcuts. It ingests structured and unstructured data from every source without requiring you to move data into a new platform. Every transaction gets resolved with the full context of your operation behind it, not just the data in one system's view.
Instead of building another silo, Fragment sits on top of everything you already run and builds the cross-system intelligence that no prior architecture could.
Exceptions that used to take hours get resolved automatically. Take the three-way match failure described earlier. Fragment's agents identify the mismatch, cross-reference the supplier's shipment confirmation, check the contract terms, determine whether partial shipment acceptance is consistent with policy, and either resolve the exception or route it to the right person with full context attached. No one opened three tabs. No one manually reconciled data across systems.
The same logic applies across invoice discrepancies, receipt mismatches, approval bottlenecks, and the long tail of exception types that pile up in any enterprise procurement operation. Fragment deploys agents to manage each step in the process with unlimited scale, independently reconciling exceptions without human assistance.
Exceptions don't get managed. They get eliminated.
Fragment is the only vendor in your procurement ecosystem that profits when your exceptions go to zero. Your BPO's revenue grows when your exception volume grows. Your consultant's engagement extends when problems persist. Your platform vendor sells more licenses when more people need to touch transactions.
Fragment's commercial model is the opposite. There is no per-seat pricing. There are no implementation fees. There is no long-term contract required to start. You pay for outcomes, and Fragment only succeeds when your exception volume drops. Deployment connects to your existing systems without replacing anything. No data migration, no IT integration project, no 12-month implementation timeline. Your team validates outputs at every step until you're comfortable expanding the scope of automation.
Fragment's incentives are structurally aligned with yours.
What This Means for Your Operations
If you run procurement operations, GBS, or shared services, you know the math. Exception volume grows. Headcount budgets stay flat or shrink. BPO contracts cost more every year, and the work quality is inconsistent. Leadership keeps asking about AI strategy, but nothing you've been shown works on your actual problems. Nothing you've been shown can see across all of your systems and reason about the messy, cross-functional reality of how procurement actually works.
Fragment changes that math. No new systems. No IT project. No 12-month wait to see whether it works.
Want to see what this looks like on your actual workflows? That's exactly what we cover in a first conversation. [Get in touch →]