A requisition system that handles half your purchasing controls half your purchasing, and no feature compensates for the other half. That makes adoption the measure of success, and adoption is driven by two things that are rarely on a requirements list: how quickly a request is answered, and whether the requester can see what is happening to it.
Speed, because the alternative always exists
People can buy things another way and sort it out later. If a request takes three days and a card purchase takes an hour, urgent spend leaves the process, and urgent spend is a meaningful share of the total. Same-day answers for routine requests are achievable with named approvers, automatic cover and escalation.
Visibility, because silence teaches avoidance
A requester who cannot see where their request is will chase, and a requester whose request vanished will not use the system next time. Acknowledgement, a reference and a visible status remove most informal chasing and are the cheapest adoption improvement available. A declined request should say why, promptly.
How to measure adoption honestly
Not by requests raised, which the system can only count for itself, but by the share of invoices arriving with a purchase order behind them, month by month and by department. That figure is visible from payables data and it is the only real proof that the control is spreading rather than being routed around.
Questions people ask about requisition system
Should we enforce it?
Enforcement works once the process is fast enough to comply with. Enforcing a slow process produces resentment and inventive workarounds.
What threshold should require a requisition?
Low enough to cover what people would otherwise put on a card, high enough that trivial purchases do not clog the queue. Set it deliberately and review it.
How long should adoption take?
A quarter or two, because it is a habit change involving people outside finance.