Procurement Intake and Orchestration: Why a Simple Purchase Takes Seven Weeks

Why intake is the most expensive unmanaged process in a large company

An engineering manager wants a monitoring tool. Forty two thousand dollars a year. She fills in a form she found on the intranet, which turns out to be the old form. Procurement asks whether security has reviewed it. Security asks for a completed vendor questionnaire and a SOC 2 report. The vendor sends a SOC 2 that expired in March. Legal will not review the order form until the data processing terms are attached. Privacy wants to know whether personal data leaves the region, which nobody has asked the vendor. Tax raises a withholding question because the entity signing is in a different country from the entity paying. Seven weeks later the purchase order issues, the renewal date the vendor quoted has moved, and the manager has quietly started using her corporate card for a smaller plan in the meantime.

Nobody in that story did anything wrong. Each function asked a reasonable question at the moment they encountered the request. The failure is that the sequence and the criteria were never encoded anywhere, so the requester served as the router, and the requester has no idea what the rules are.

The category exists because this is expensive. Zip, ORO Labs and Levelpath built businesses on exactly this problem and they are competent products. Coupa and Workday Strategic Sourcing have intake capabilities attached to their suites. If your policy is simple and your systems are standard, one of those will serve you. The reason companies build instead is that intake is not really a form. It is the executable version of your company's approval policy, which is a document written by your legal and finance teams containing thresholds, exceptions and entity specific rules that no vendor's configuration screen anticipated.

Problem one: routing rules are policy, and policy is specific

Real routing rules look like this. Anything above a threshold needs finance business partner approval, but the threshold differs by entity and by cost centre type. Anything touching customer data needs privacy review, unless the vendor is on the pre approved list and the use case is unchanged. Anything with a signature obligation over a certain term needs legal, and over a higher term needs the general counsel. Anything in a sanctioned or high risk jurisdiction needs export control review. Anything that is a renewal of an existing agreement with no scope change skips two of those steps entirely. Anything a specific business unit buys under a master agreement follows a shortened path.

Configuration engines in packaged tools handle a good portion of that with conditional logic. Where they break is dependency and re evaluation. A request that starts as software becomes a professional services engagement halfway through review, which changes the required reviewers retroactively. A privacy answer changes after security's review completes, invalidating an approval that was already given. Most tools treat approvals as a linear chain and struggle to reopen a completed step without restarting the whole thing, which is why in practice buyers work around the tool with email.

What a custom build does: model the request as a state machine with a requirement set that is recomputed whenever a material attribute changes. Each requirement names its policy clause, its owner group, its service level and its evidence. When an answer changes, requirements are recalculated and only the affected reviews reopen, with everyone notified about what changed and why. That single behaviour is the difference between a tool people use and a tool people route around.

Problem two: the requester does not know what they are buying

Ask a requester to categorise their purchase and they will get it wrong, not from carelessness but because the categories are procurement's categories. They do not know whether a tool that stores meeting transcripts counts as processing personal data. They do not know that a two year commitment crosses a threshold. They do not know your company already has three contracts with the same vendor.

What a custom build does: ask questions in the requester's language and derive the classification. Instead of asking for a spend category, ask what the tool does and who will use it. Instead of asking for the data classification, ask what information goes into it. Then map to policy behind the scenes. This is one of the few places a language model earns its place: parse the uploaded order form or quote and pre fill the request, extract term length, auto renewal clauses, total contract value and the contracting entity, and flag the auto renewal notice period, which is the clause that quietly costs companies the most money. Extraction with human confirmation, never silent acceptance.

Problem three: nobody knows the request already exists

Three teams buy three overlapping observability tools in the same year. A renewal auto renews because the notice window passed while the request sat in review. A supplier is onboarded twice under two spellings. These are all the same failure: intake has no memory of the estate.

What a custom build does: check every incoming request against existing suppliers, existing contracts and overlapping categories at submission time, and show the requester what already exists before a reviewer ever sees it. Fuzzy matching on supplier names catches the duplicate onboarding. Renewals get created automatically from contract end dates, working backwards from the notice period so the request opens with enough runway to actually negotiate or exit. In our experience renewal intake generated from contract data is the feature that pays for the build fastest, because it converts silent auto renewals into decisions.

Problem four: orchestration means writing back, not just collecting

An intake tool that ends with an approved request and a person retyping it into ERP has moved the bottleneck, not removed it. Real orchestration means the approved request creates the requisition in your ERP with the right cost centre, general ledger code, entity and supplier, opens the contract record in your contract system with the extracted metadata, creates the security review ticket in the reviewer's own tool rather than making them log into yours, and closes the loop when the purchase order issues.

This is where builds actually earn their money and where they get hard. Reviewers will not adopt a new inbox. Security lives in Jira or ServiceNow. Legal lives in their contract system and email. Finance lives in the ERP. The orchestration layer has to push work into the tools people already open every morning and pull status back, which means real integration work rather than notification emails with links.

Problem five: you cannot manage cycle time you cannot see

Ask most procurement operations leads where requests spend time and you get an anecdote. The truth is usually uncomfortable and specific: a large share of elapsed time is waiting on the requester to answer a question, and a smaller share is a single reviewer group with no backup during holidays.

What a custom build does: instrument every state transition, then report cycle time by stage, by reviewer group, by request type and by business unit, with waiting on requester separated from waiting on reviewer. Publish it. The reporting changes behaviour more than the workflow does, because it converts an argument between procurement and legal about who is slow into a chart both can check.

What this costs and how long it takes

Across the enterprise internal tools work Digital Heroes has delivered, this is the honest shape. A focused first release, meaning one intake experience, the policy rules engine with recomputation, reviewer assignment and service levels, requester status visibility, and ERP requisition writeback, runs $70,000 to $150,000 and ships in 10 to 16 weeks.

A full platform adding contract system handoff, automated renewal intake from contract dates, supplier and duplicate detection, integrations into reviewer tools such as Jira and ServiceNow, document extraction, reviewer workload management and cycle time analytics runs $180,000 to $400,000 phased over 6 to 11 months.

What pushes cost up here specifically: the number of ERP instances, because a group with SAP in one region and NetSuite in another has two requisition models and two chart of accounts mappings. Single sign on and entitlement complexity in a large enterprise. The number of reviewer tools you must push into rather than pull people out of. Multi entity tax and legal rules, which are the most detailed part of the policy and the part most likely to change mid build. And the policy itself, which frequently turns out not to exist in writing, so the project's first four weeks are a facilitation exercise getting legal, tax, security, privacy and finance to state their actual thresholds.

What keeps cost down: launch with software and services purchases only, which is where the pain concentrates, and leave direct materials and capital expenditure on the existing path for now.

Build versus buy, and when buying is the right call

Buy, and do not call us, if your approval policy is genuinely simple, you run one ERP, and your volume is modest. Zip and Levelpath are good products with fast time to value and they will beat a custom build at that profile on every axis. Same answer if you have just implemented Coupa or Workday and intake is included: use it for a year before concluding it does not fit.

Build when two or more of these are true. Your routing depends on attributes that change during review and your current tool cannot reopen a step without restarting. You operate across multiple entities and ERPs with genuinely different thresholds. Your reviewers refuse to work in a procurement tool and you need work pushed into their systems. You have policy rules that are commercially sensitive or unusual enough that describing them to a vendor's configuration team feels like a translation exercise. Or the tell we see most often: you bought an intake product, and buyers still keep a shadow tracker because the product cannot express the exceptions.

How to choose a developer for intake and orchestration

Ask them what happens when a request's data classification changes after security has already approved. If the answer is that the workflow restarts, they will build the thing your buyers work around. The correct answer involves recomputing requirements and reopening only what is affected.

Ask how they will get reviewers to adopt it. A developer who has done this will immediately propose pushing tasks into Jira, ServiceNow, Slack or email with actions available in place. A developer who proposes a beautiful reviewer dashboard has not watched a security engineer's day.

Ask which ERP requisition APIs they have written against by name. SAP, NetSuite, Oracle Fusion, Workday and Coupa are five different problems and experience does not transfer cleanly between them.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. This system encodes your approval policy, which means it will need editing every time policy changes, and you should never need a vendor's permission to do that.