Procure to Pay

What actually creates the friction between asking for something and paying for it?

Requisition raisedThe need is declared
Payment clearedThe obligation is settled

Why this process resists visibility

Procure to Pay looks orderly in policy and behaves as an exception queue in practice.

  • A matched invoice says little about the route

    A successful three-way match does not tell you the purchase order was raised after the invoice arrived, or that the approval ran four times before it held.

  • Buying starts outside the system

    Needs are often agreed informally long before a requisition exists, and for some categories the first system record of the purchase is the invoice itself.

  • The exception queue is the real process

    Teams organise themselves around blocked invoices and failed matches, which is often the part of the process least likely to have been measured end to end.

  • Approval hierarchies drift quietly

    Delegations, thresholds, absences and reorganisations produce routing that no longer matches the policy document describing it.

  • Savings leak between contract and payment

    Rates are negotiated centrally and diverge in execution through off-contract buying, missed discounts and price variance that surfaces only in aggregate.

Where time and effort accumulate

The process is normally drawn as six clean stages. Execution data shows what actually collects at each one, and how much of the cycle is spent waiting rather than working.

  1. Stage 1

    Requisition

    • Needs raised without a requisition
    • Specifications incomplete at submission
    • Wrong category, cost centre or entity
    • Duplicate and superseded requests
  2. Stage 2

    Sourcing and approval

    • Approval chains longer than policy requires
    • Re-submission after every edit
    • Delegation and absence rerouting
    • Thresholds applied inconsistently
  3. Stage 3

    Purchase order

    • Orders raised after the invoice arrives
    • Purchase orders amended repeatedly
    • Missing or expired contract reference
    • Incomplete supplier master data
  4. Stage 4

    Goods and service receipt

    • Receipts entered late or not at all
    • Partial and over-receipts
    • Service confirmation chased by hand
    • Quantity and price mismatch surfacing here
  5. Stage 5

    Invoice processing

    • Invoices arriving without a purchase order
    • Match failures held in exception
    • Coding corrected manually after capture
    • Duplicate and re-submitted invoices
  6. Stage 6

    Payment

    • Invoices missing the payment run
    • Blocked and inactive supplier records
    • Early settlement discounts lost
    • Urgent payments made outside the run

What runs underneath all six

These four behaviours recur across the stages and often account for a large share of the cycle: work waiting in a queue without a clear owner, work looping back to a stage it already passed, work changing hands between teams with little record of the handoff, and the same purchase type running through materially different routes depending on who touched it.

How RE-ViVE observes it

No process remodeling. No new workflow instrumentation. Read-only source access.

You provide the relevant source records and limited subject-matter support. RE-ViVE does the reconstruction and the analysis.

  1. Step 1

    Read-only extracts

    Requisition, order, receipt, invoice and payment records from the systems that already hold them. Nothing is written back.

  2. Step 2

    Execution reconstructed

    RE-ViVE maps source records into its Execution Data Model, allowing each purchase to be reconstructed across the systems involved.

  3. Step 3

    Followed end to end

    Each purchase can then be followed from requisition raised to payment cleared, with dwell time, loops and handoffs measured rather than estimated.

  4. Step 4

    Kept current

    The view refreshes as new purchases are recorded, so the effect of any change is visible in the same measure.

What you are left holding

Evidence specific enough to act on, and traceable back to the individual purchase behind it.

  • The routes purchases actually take

    Every variant present in the data, ranked by volume and by the effort it consumes, against the route policy describes.

  • Where the days sit

    Cycle time broken down by stage and split between work in progress and work waiting, so the delay has an address.

  • Rework made countable

    Repeated approvals, amended orders, re-keyed coding and re-submitted invoices, counted and costed rather than assumed.

  • Cause attributed

    Delay and exception attributed by category, supplier, entity, cost centre, buyer and approver.

  • Leakage explained

    Off-contract buying, retrospective purchase orders and missed settlement discounts, separated and sized.

  • A monitored process

    Continuous visibility once the first view is built, giving a baseline that automation and touchless targets can be measured against.

Where the evidence lives

Procure to Pay leaves a record in systems you already run.

  • ERP purchasing
  • Sourcing and procurement suite
  • Contract management
  • Approval workflow
  • Supplier portal
  • Invoice capture
  • Accounts payable
  • Payment and banking

RE-ViVE works with the systems an enterprise already runs, including platforms such as SAP, Oracle, Coupa and Ariba, along with other procurement and ERP platforms, workflow engines, capture tools, portals and custom applications. Where execution moves outside the available system evidence, RE-ViVE makes the unexplained interval visible for investigation.

Processes next door

Procure to Pay shares its evidence with the processes around it.

See how your purchases actually execute

Give us read-only access to the purchasing data you already hold, and we will show you the routes, the exceptions and the rework inside it.

See all processes