Why Government Spend Management Software Adoption Stalls
Most government procurement teams that invest in spend management software expect adoption to take care of itself once the system goes live. It rarely does. Across local councils, central agencies, and public sector bodies of all sizes, the pattern is remarkably consistent: the platform is licensed, configured, and technically available, but a significant share of organisational spend never touches it. The causes are structural, not just technical, and understanding them is the first step toward fixing them.
What does "stalled adoption" actually look like?
It looks like a system that is technically live but operationally optional. Procurement might be running requisitions through the platform, but across the wider organisation, a large portion of spend still arrives as no-PO invoices processed directly by accounts payable, email approvals that bypass workflow entirely, or purchasing card transactions with no connection to the procurement system. The platform captures enough activity to produce reports, but not enough to make those reports trustworthy. In practice, the organisation ends up running two procurement processes in parallel: the official one inside the system and the informal one that actually gets things bought.
Why is decentralisation the root cause?
Decentralised organisations lack a single point of authority that can mandate how buying happens. In most public sector bodies, individual departments or business units control their own budgets, maintain their own supplier relationships, and operate with significant autonomy over day-to-day purchasing. There is no shared incentive to route buying through a central system, particularly when that system was selected and configured by a central procurement team the department may not report to. Without someone who has both the authority and the organisational mandate to require system use across all spending units, adoption depends entirely on voluntary compliance. And voluntary compliance, in a decentralised structure, tends to settle at whatever level of effort each department finds convenient.
What governance barriers keep departments off the system?
Unclear or contested procurement policy is the most common governance barrier, and it is more widespread than most organisations realise. Many public sector bodies have procurement policies that were written before the system was implemented and never updated to reflect how the platform's workflows actually operate. Delegation of authority rules, the ones that define who can approve what value of purchase, often don't match the approval chains configured in the system. When staff encounter a mismatch between what the policy says and what the system requires, they default to the familiar process.
Meanwhile, the central procurement team typically carries responsibility for system adoption but holds no enforcement lever. They can encourage, train, and report on usage, but they cannot compel a department head to stop emailing purchase approvals to their finance officer.
What operational friction drives people around the system?
The fastest way to kill adoption is to make the system slower than the workaround. Requisition forms that ask for more information than the old paper form did, approval chains that route through five people when two would suffice, and incomplete supplier or catalogue coverage that means buyers genuinely cannot find what they need: all of these create rational reasons to go around the platform.
In many implementations, the approval workflow was built as a literal translation of the paper-based process rather than a rethinking of it. The result is a digital process that takes longer than the manual one it replaced. When a department manager can get something ordered in ten minutes via email or a purchasing card but the system requires thirty minutes of form-filling and a three-day approval chain, the system will lose every time. That is not a user training problem. It is a design problem.
Why does the compliance dimension matter more for public bodies?
Public bodies operate under procurement rules that commercial organisations do not face: value thresholds that trigger competitive quoting or open tender, transparency obligations that require public reporting of contract awards, and audit expectations that demand a clear chain of evidence from need identification through to payment. These rules exist for good reason, but they also mean the stakes of non-compliance are higher.
If the spend management platform does not make the compliant path the easiest path, users will find workarounds, and those workarounds will create compliance gaps that surface during audits. A system that adds friction to compliant purchasing while leaving non-compliant channels frictionless is a system that actively undermines its own purpose. The most effective implementations build compliance into the transaction flow so that doing the right thing requires less effort than doing the wrong thing.
What happens to spend visibility when adoption stalls?
Spend data becomes incomplete, and incomplete spend data is worse than no spend data at all. When only a fraction of organisational spend flows through the platform, the analytics it produces give a distorted picture. Category analysis is skewed toward the departments that use the system and misses the ones that don't. Contract consolidation opportunities are invisible because the data doesn't capture the full volume going to each supplier. Savings claims based on system data cannot be trusted because the denominator is wrong.
This creates a vicious cycle: the system cannot demonstrate its value because it doesn't capture enough data, and stakeholders don't adopt the system because they don't see its value. Breaking this cycle requires addressing the adoption barriers first and treating accurate spend data as a result of high adoption, not a reason for it.
What actually improves system uptake?
Fix catalogue and supplier coverage before anything else. If buyers cannot find what they need in the system, no amount of policy enforcement will drive adoption. Onboard the suppliers that departments actually buy from, not just the ones with the largest contracts, and make sure the catalogue reflects the products and services people order most frequently.
Simplify approval routing. Review every approval chain against the question: does this step add a decision, or just a delay? Align the system's workflows to actual delegation of authority rules, and update those rules if they no longer reflect how the organisation operates.
Give departments visibility of their own spend. When a department head can see their team's spend by category, supplier, and budget line in real time, the platform shifts from an obligation to a tool they actually want. This is the return on adoption that most implementations fail to deliver early enough.
Measure what matters. Track adoption as a percentage of addressable spend captured through the platform, not as a count of user logins or requisitions raised. Login metrics tell you who opened the system. Spend capture tells you whether the organisation is actually buying through it.
How do you diagnose where your own organisation is stuck?
Start with your data and work outward. These questions will tell you more than any maturity assessment:
What percentage of your total invoice value is matched to a purchase order raised in the system? If that number is below 70 or 80 percent, you have a meaningful adoption gap regardless of how many users are registered.
Which departments or cost centres have the highest rate of no-PO invoices? This tells you exactly where adoption has stalled and gives you a target list for investigation.
How many of your active suppliers are set up in the system with current catalogues or punchout connections? If buyers can't find their suppliers, they can't use the platform.
What is the average elapsed time from requisition to purchase order approval? If it's more than a day or two for routine purchases, your approval routing is likely a barrier.
When was your procurement policy last updated, and does it reference the system's workflow? If the policy predates the implementation or doesn't mention the platform, governance and system are operating in parallel rather than together.
The answers to these questions won't just tell you where adoption has stalled. They'll tell you why, and they'll give you a sequence for fixing it: coverage and speed first, governance alignment second, and visibility as the proof that it's working.