Contingent Workforce and Services Procurement Software Problems: The 7 That Leak Money, and How to Avoid Them

Why does the programme scope creep into rebuilding requisition to invoice?

The common scope failure is treating this as a workflow project. Requisition, submission, shortlist, offer, timesheet, invoice: it is a legible chain, everybody can describe it, and it makes a satisfying diagram. So the budget goes into rebuilding that chain, and eighteen months later you own a competent commodity workflow while statement of work spend is still invisible and contractors still keep their badges after the assignment ends.

The reason is that the workflow is the part everyone touches daily, so it dominates requirements gathering. But requisition to invoice is a commodity. SAP Fieldglass, Beeline, Magnit and Utmost all do it, and doing it slightly differently wins you nothing. The parts worth owning are the three that depend on systems and policies unique to you: the enforcement point on rates, the statement of work controls, and the identity lifecycle that connects an assignment to a badge and a network account.

The fix is to write the scope around those three and treat the workflow as the minimum required to support them. Practically, that means the first release covers requisition through submission with enforced rate cards, assignment records, timesheet approval and self billed invoicing, in one country, with your five largest suppliers, staff augmentation only. Statement of work control and provisioning follow once the basic discipline exists. Attempting a global launch across every category at once is the most reliable way to stall a programme of this kind.

What goes wrong when you migrate worker, supplier and rate history?

You need history because tenure policy depends on it and because supplier scorecards without a baseline persuade nobody. The migration is harder than it looks, and it is harder for one structural reason: the person was never the record. The requisition was.

Three failures recur. The same human appears under two suppliers with two spellings of their name and no shared key, which is precisely the case tenure policy exists to catch, so importing without resolution means the policy is unenforceable exactly where it matters. Rate cards were negotiated as documents with amendments in email, so the version in force on a given date is genuinely uncertain, and importing today's card as historic truth makes every past variance disappear. And assignment end dates are wrong at scale because nobody closed requisitions, so imported tenure calculations count people who left two years ago as still engaged.

The approach that works is to resolve worker identity as a reviewed exercise before anything else, with candidate matches confirmed by a programme manager and every merge reversible. Import rate cards as versioned records with effective dates and accept that older periods will have gaps rather than papering over them. Reconcile open assignments against your identity provider and your badge system before go live, because that comparison is also the first genuinely useful output the programme produces and it usually surprises people.

Why do enterprise resource planning (ERP) and identity integrations break after launch?

They break at the joins where two systems disagree about what a person is. Your finance system knows cost centres and purchase orders. Your identity provider knows accounts. Your badge system knows people who may or may not correspond to accounts. The assignment record has to be the thing that ties them, and if it was designed as a procurement object rather than an identity object, that tie does not hold.

The specific break is early termination. A contractor leaves three weeks before the planned end date, the supplier tells the hiring manager, the hiring manager tells nobody, and the assignment record still shows an end date in the future. Provisioning ran off the assignment, so deprovisioning does not fire, and the account stays live. Extensions cause the mirror image: the assignment ends on paper while the person is still working, access is cut, and everybody learns to route around the system.

Two fixes worth insisting on. Make assignment end an event that requires positive confirmation from each system owner rather than a date that passes silently, and reconcile the assignment population against your directory and badge system on a schedule so orphans surface within days rather than at an audit. Then handle cost allocation at approval using the cost centre on the requisition, so the entry reaching finance is already correct and month end accruals are calculated rather than estimated. Your controller will care about that more than anything else in the build.

What happens when tenure, classification and offboarding are not covered?

You accumulate the two exposures that auditors and counsel actually ask about. The first is access. A contractor whose assignment ended in March still holding a badge and a network account in July is a finding waiting to be written, and it happens because nothing breaks when offboarding is skipped. Onboarding gets chased because the person cannot start without it. Offboarding has no natural pressure at all.

The second is the classification and tenure question, and it is important to be precise about what software can and cannot do here. Worker classification rules differ by country and by state and continue to change, and none of this is legal advice. What the system can do is capture the fact pattern: who directs the work, who supplies the tools, how the engagement is priced, how long it has run, and whether a statement of work engagement is being tracked by hours and managed day to day by your staff. Your counsel defines the test. The system captures the evidence.

Build tenure calculation on a persistent worker identity so it survives a person moving between suppliers, run policy checks at requisition, at submission and at extension with a documented decision each time, and let the assignment record drive identity lifecycle in both directions. That evidence pack is what you want to have before a review rather than during one, and assembling it retrospectively is exactly the scramble the programme was funded to prevent.

Should you build custom or configure what you already own?

Configure if you run fewer than about a hundred contingent workers with a handful of suppliers in one country. A mid market vendor management system, or a module in the procurement suite you already pay for, will do the job for a fraction of a build, and the discipline problem you have is a process problem rather than a software one.

Buy Fieldglass or Beeline if you need broad global coverage quickly, have a managed service provider who will run the programme, and your processes are close enough to standard that you can adopt rather than adapt. That last clause is the one that decides it. These are capable systems, and the expensive surprises come from configuration projects fighting a process the product did not anticipate, not from the products being weak.

Build when two or more hold. Statement of work spend is a large share of your programme and no system sees it. Configuration quotes keep coming back high for your approval hierarchy and tenure policy. You need assignment records to drive provisioning and deprovisioning in your own identity estate, which is where packaged tools consistently disappoint. You run a managed programme for clients and need it branded and shaped per client. Or you have already implemented a platform and your suppliers still email spreadsheets, which means adoption failed and buying a second platform will not fix it.

How do hidden costs get into the quote?

Five drivers, all foreseeable.

• Country count. Pay rules, tax treatment, working time regulation and data protection differ everywhere and nothing generalises, so each country is closer to a new implementation than a configuration.
• Integration count. A real programme touches finance, the identity provider, physical access control, background screening and possibly a payroll or employer of record partner. Name them before scoping.
• Supplier onboarding. Every supplier must be trained and connected, and some will move slowly because the system makes their markup visible. This is schedule risk more than cost.
• Self billing mechanics. Multi currency and tax handling on self billed invoices is exacting work with unforgiving edge cases.
• Policy archaeology. Most organisations discover their tenure, approval and rehire policies contain contradictions the moment somebody tries to encode them, and resolving those is calendar time with senior people.

The quiet one is change management with hiring managers. The system's value comes from stopping them doing something convenient, so adoption needs sponsorship and a plan, not a training email. Programmes that skip it produce an exception queue that becomes the new normal.

What separates a build that works from one that fails here?

The builds that work put the control at the point of decision. A submission outside the agreed band for its title and location is blocked or requires a named exception with a reason, and the implied markup is shown to the hiring manager rather than buried in an attachment. Supplier scorecards then publish compliance rates, submission quality and fill time, which changes behaviour faster than any contract clause because suppliers can see where they stand. The builds that fail collect the same data and report it monthly, by which time the rate is agreed, the person has started and nobody is reopening it.

The second differentiator is invoicing direction. Self billing generated from approved time and accepted milestones removes most disputes, because the invoice comes from data both sides already agreed. A developer planning to build an invoice inbox with matching logic has not understood where the disputes originate, and you will end up with a person reviewing four thousand lines instead of twelve exceptions.

When choosing a developer, ask how a worker identity survives moving between two suppliers, because a model that attaches the person to the requisition makes tenure policy unenforceable in exactly the cases it exists for. Ask what identity and access integration they have done and get the systems named. Ask how a statement of work is modelled, and listen for milestones with acceptance criteria, a named acceptor and invoice release gated on acceptance rather than a container for hours. Then settle ownership of code, cloud accounts and all supplier, rate and worker data in writing before kickoff, because you will want that intact the next time you retender the programme.