A procurement approval workflow routes a purchase decision to the people authorised to make it. A useful implementation accounts for category, business unit, value, supplier context and the exceptions that occur in the organisation.

The first design input should be how the enterprise buys.

An approval matrix is a starting point

An authority matrix can identify who approves a purchase at a given value. It may not explain who checks the supplier, whether a contract already exists or what happens when a request contains several categories.

These details often live with experienced team members. If they remain outside the implementation, people will keep using email to move a request through the gaps.

Map a few real purchases from request to receipt. Include an ordinary repeat order, an unfamiliar supplier and a request that needs escalation. Ask who made each decision and what information they needed.

Define the record that follows the request

A purchase request should carry enough context for the next actor. Depending on the agreed process, that can include the category, business unit, requester, supplier, estimated value and relevant contract reference.

A sourcing award should remain connected to the contract it leads to. The contract should remain visible when the team raises an order. Receiving and invoicing should retain their relationship to what was purchased.

This is why source-to-pay implementation involves more than configuring a request form.

Make the exceptions explicit

A request can be unusual for several reasons. Its supplier may be new. Its value may exceed a threshold. The category may require specialist review. An approver may be unavailable.

For each exception, define:

  • The condition that changes the approval path.
  • The person or role responsible for the next action.
  • The supporting information that must be available.
  • Whether the request can proceed while the issue is open.
  • The record of the final decision.

An escalation path should avoid leaving the requester to guess which inbox to contact.

Agree the finance boundary early

Procurement and finance need a shared understanding of which system owns each record and when information moves between them.

Confirm where supplier data is maintained, how orders reach the finance system and how receiving and invoice information are reconciled. Integration requirements should be assessed against the actual ERP environment before making promises about a connection.

Configuration needs adoption

The people who raise, review and approve requests need to understand the new process. Training should include the exceptions they encounter, alongside the ordinary purchase flow.

After go-live, examine where requests stall and whether reviewers have the context they need. Those observations are useful inputs for the next phase of configuration.

Serpro implements and tailors source-to-pay procurement software systems around approval structures, categories and existing finance systems. The scope brings planning, configuration, integration, training and support into the same delivery conversation.

Put numbers around the administrative work

Consider 350 purchase requests per month, each consuming an assumed 45 minutes of administrative handling across request preparation, chasing context and assembling an approval. That amounts to about 263 hours.

If a connected workflow reduced average handling to 20 minutes, the model would release about 146 hours. At an assumed $40 loaded hourly cost, the monthly capacity value is about $5,833. These are illustrative inputs, not a measured outcome or a promise of cash savings.

Time spent negotiating a difficult purchase is different from time spent finding the contract reference. Measure both, but do not assume software should eliminate every minute of buyer judgement. The strongest first use case often removes avoidable coordination around the decision.

Make bid comparisons honest

A cheaper headline price may refer to a different pack size, exclude freight or depend on a longer lead time. An item-matching assistant can propose comparable descriptions and normalise a unit price, but the buyer must confirm that the items are genuinely interchangeable.

Retain the original quote. Show the conversion used to calculate the comparison. Let the buyer record why a supplier was selected even when it is not the cheapest offer. Quality, availability, payment terms and contractual obligations may matter more than a single price column.

Treat supplier changes as a distinct control

Creating a purchase request and changing a supplier’s payment details should not be treated as the same authority. Establish who can create, edit and approve supplier information and how those changes reach the finance environment.

For onboarding, define which evidence is required for the category and who is qualified to review it. A checklist-completeness agent can identify a missing document. It cannot replace a specialist’s assessment of what the document establishes.

Connect the application without duplicating its masters

Agree where supplier, item, category and accounting data originate. Define the direction of each integration and what happens when a record is rejected or temporarily unavailable.

Single sign-on, contract storage and reporting also need operational ownership. A reusable application foundation can reduce repeated implementation work, while configuration and adapters reflect the customer’s actual systems.

Pilot a complete buying path

Start with one category, one authority structure and the people who actually use them. Include a new supplier, an unavailable approver and a request that exceeds the ordinary limit. The pilot should exercise the exception paths as deliberately as the ordinary purchase.