TL;DR
- Intake and eProcurement solve different problems. Intake replaces the front door, eProcurement replaces the transaction spine.
- Four questions decide the sequencing: where spend leaks, whether the problem is capture or execution, what the ERP already does, and what reverses cheaply.
- Intake is cheaper to reverse because it sits in front of existing systems. eProcurement becomes the system of record.
- If both are broken, start with intake. Clean input improves eProcurement outcomes. The reverse is not true.
- See how Merlin Intake handles procurement requests. Request a demo.
Four questions decide it, and none of them is about features. Where your spend leaks, whether your problem is the front door or the transaction spine, what your ERP already does, and what you can reverse cheaply if you get it wrong.
Structured intake and full eProcurement are often presented as competing purchases. They are not. They solve different problems and most organizations eventually run both. The real question is sequencing, and sequencing is where the money is won or lost.
This is written for procurement teams weighing a first significant platform investment, where the budget supports one decision now rather than both. If you are still establishing what intake is, start there instead.
What does structured intake actually replace?
The front door. Intake replaces the scattered ways requests currently arrive, which is usually email, chat, a form nobody likes, and a colleague who knows how to get things done.
It captures the request in structured form, applies policy before commitment, and routes to the right owner. What it does not do is process the transaction. Intake hands a clean, coded, policy-checked request to whatever system executes it, whether that is an eProcurement suite, an ERP, or a person.
The value is concentrated at the moment of capture, which is also the only moment where the commercial decision is still open. Once a requester has spoken to a supplier, the negotiation has happened whether or not procurement was in the room. Intake is the only control that operates before that point, which is why its value does not scale with transaction volume in the way eProcurement value does.
What does full eProcurement actually replace?
The transaction spine. Requisitions, purchase orders, catalogs, receipting, and the audit trail that connects them.
This is heavier machinery and it delivers a different kind of value: control and efficiency over the execution of spend that has already been decided. It assumes a request already exists in usable form. Most eProcurement implementations quietly depend on someone upstream having produced that request correctly, which is precisely the assumption intake removes. That dependency is invisible in a business case and expensive in production, because the manual work it implies never appears in the project plan.
Hackett studied the procurement agenda broadly rather than the intake versus eProcurement decision. The relevance here is that a widening gap between workload and capacity changes the sequencing calculus: whichever investment removes manual handling soonest is worth more than the one that is theoretically more complete.
Figure 1: Where each tool sits relative to the commercial decision.
Question one: where does your spend leak?
If spend leaks before procurement sees it, the leak is at the front door and eProcurement will not find it. Requests that never entered a system cannot be controlled by the system that processes requests.
If spend leaks after approval, through off-contract buying, price variance, or invoice exceptions, the leak is in the transaction spine and intake will not close it.
Most teams can answer this from existing data in an afternoon. Compare spend under management against total spend, then against the proportion of requests arriving through a controlled channel. If both are low, the front door is the constraint. If capture is high and spend under management is still low, the leak is downstream and a better front door will not find it. Figure 2 shows where each leak sits.
Figure 2: Two leaks, each pointing at a different first investment.
Question two: is your problem the front door or the transaction spine?
APQC measured procurement productivity in aggregate, not the intake decision. What the spread indicates is that throughput differences of this size are rarely explained by transaction processing alone, since the mechanics of issuing a purchase order vary little between organizations. The variance sits in how much work arrives ready to process.
If your team spends more time chasing information than executing transactions, the front door is the problem. A useful test is to sample twenty requests from the last month and count the return trips for missing information. Return trips are pure rework and they originate entirely at capture.
Question three: what does your ERP already do?
Most organizations underuse the requisition and approval capability they already own, because the experience is poor rather than because the function is missing.
If the ERP can already issue purchase orders and enforce approval limits competently, buying a full eProcurement suite duplicates capability while leaving the actual complaint, that nobody wants to use it, untouched. Intake in front of an existing ERP is frequently the cheaper and faster answer.
If the ERP genuinely cannot handle catalogs, receipting, or three-way match at your volume, that is a transaction spine problem and intake will not fix it. The distinction worth holding is between capability the ERP lacks and capability it has that nobody uses, because the two cost very different amounts to resolve. Ask whether anyone has tried the existing requisition path in the last year, and what stopped them.
Figure 3: Time to value, on the same axis.
Question four: what can you reverse cheaply?
Intake implementations are comparatively cheap to reverse. They sit in front of existing systems, integrate through defined interfaces, and can be switched off without stranding transactional history.
Full eProcurement implementations are not. They become the system of record, they absorb master data, and unwinding one is a migration project rather than a decision.
That research covered shared services rather than procurement specifically. It is included because it describes the same structural squeeze from a second angle, and because reversibility matters more when capacity is tightening: a wrong decision costs more when there is no slack to absorb it.
Figure 4: The four questions and where each answer points.
Which combination fits which organization?
If requests arrive chaotically and the ERP executes competently, start with intake. Merlin Intake operates as the front door for procurement requests, works inside Microsoft Teams and Slack, and passes structured requests to the systems already in place.
If requests arrive cleanly and execution is the bottleneck, start with eProcurement. If both are broken, start with intake anyway, because clean input improves eProcurement outcomes while the reverse is not true. Structured requests make a transaction system work better on day one. A better transaction system does nothing for a request that arrived incomplete.
Frequently Asked Questions
What is the difference between intake management and eProcurement?
Intake management captures, validates, and routes purchase requests before they enter the buying process. eProcurement executes the transaction: requisitions, purchase orders, catalogs, and receipting. Intake is the front door, eProcurement is the machinery behind it. They are complementary rather than alternative, and most mature organizations run both.
Do I need intake if I already have eProcurement?
Often yes. eProcurement assumes a well-formed request already exists. If requests still arrive by email and someone manually converts them into requisitions, the eProcurement investment is being fed by an uncontrolled process. Intake closes that gap without replacing the transactional system.
Can intake software replace eProcurement?
No. Intake does not issue purchase orders, manage catalogs, or perform receipting and matching. Organizations sometimes run intake in front of an ERP rather than a dedicated eProcurement suite, which works when the ERP handles transactions adequately, but intake is not a substitute for transaction processing.
Which should we implement first?
Implement intake first if spend leaks before procurement sees it, if your team spends more time chasing request information than executing transactions, or if your ERP already issues purchase orders competently. Implement eProcurement first if requests arrive in usable form and the bottleneck is transaction execution, catalog management, or matching.
Is intake cheaper than eProcurement?
Typically yes, in both license cost and implementation effort, because intake sits in front of existing systems rather than replacing them. The more significant difference is reversibility: intake can be withdrawn without stranding transactional history, while an eProcurement suite becomes the system of record and is expensive to unwind.
What is spend under management and how does it relate to this decision?
Spend under management is the proportion of total enterprise spend that procurement actively controls. Comparing it against the proportion of requests arriving through a controlled channel is the fastest diagnostic available. A large gap between the two indicates the front door is the problem rather than the transaction spine.
How long does an intake implementation take compared to eProcurement?
Intake implementations commonly run weeks to a few months, depending on integration scope and master data readiness. Full eProcurement implementations typically run several months to over a year because they touch catalogs, master data, approval hierarchies, and financial integration. The gap in timelines is itself a factor in the sequencing decision.
Can we run intake in front of our ERP instead of buying eProcurement?
Yes, and this is a common pattern. It works well when the ERP handles purchase orders, approvals, and receipting adequately and the actual complaint is user experience rather than missing capability. It works poorly when the ERP cannot support catalogs or matching at your transaction volume.
