Source-to-Pay

Source-to-pay software for complex manufacturers

One record runs from the request to the payment run, so nothing is re-typed between the stages inside it.

Source to pay software covers the whole chain: a need is raised, approved, sourced, awarded, ordered, received, invoiced and scheduled for payment. Most of the cost in that chain is not in any single stage. It is in the gaps between them, where work gets re-keyed, and that is what this is built to close.

Intake · a need in plain language Illustrative
Agent actionPlain language becomes a structured, classified request
Sourcing event SRC-2291 · opened from the request Illustrative
Human decisionSuppliers answer in their own portal — responses stay sealed until the award step
Award · what one decision creates Illustrative
Awarded
Split · 60 / 40, two suppliers
Purchase orders
PO-118322, PO-118323
Contract record
Supplier, price and dates carried over
Re-keyed by a person
Nothing
Scoring behind itTechnical and commercial criteria, weighted by the category teamOn the record
Human decisionThe award is a person’s decision. What it creates is not re-typed.
Receipt and match · PO-118322 Illustrative
Goods receipt
120 of 120 · quality-approved
Against the order
Quantity and price agree
Against the contract
Matches SA-4471
Service entry sheet
Not a service line — does not apply
Duplicate check
No prior invoice on this order
Eight conditions
All pass · no human click
Rule appliedOne failure sends it to a person with that condition named
Where the chain ends Illustrative
The supplierAn approved order becomes a PDF and is emailed straight out. On by default.Automatic
The payment runApproved invoices are scheduled. A person executes the run.Human
The recordEvery approval, award and status change is written to the audit trail with who did it and when.Logged
Human decisionThe two steps that commit money are the two that always wait for a person

Someone writes what they need. Category, entity and value band are structured out of it.

Same purchase. Seven systems, or one record.

Nothing here is about any one stage being slow. It is about what happens between them.

The problem
With Proconomy
The problemA need is agreed over email, then typed again into a sourcing spreadsheet
With ProconomyThe approved request opens the sourcing event with its lines already on it
The problemThe award is decided in a comparison sheet, then entered again as an order and again as a contract
With ProconomyThe award decision carries into the purchase order and the contract record together
The problemNobody can say where a request has got to without asking three people
With ProconomyEvery stage writes to the same record, so the status is the record rather than a report about it
The problemInvoices are checked in a system that never saw the price anyone agreed
With ProconomyThe invoice is matched against the order, the receipt and the agreed contract price
The problemEach stage keeps its own approval rules, and changing one means a ticket
With ProconomyRouting follows your policy — sequential or parallel, by value, category or entity
The problemCommitted spend only becomes visible when the invoice arrives
With ProconomyCommitments are tracked against the budget as commitments, not left to surface as actuals

Source-to-pay software, stage by stage.

From the first request to the payment run, every stage writes to the same record. Pick the stage that hurts most and see what actually runs there.

Intake and orchestration

One front door for every request, whatever is being bought.

  • Plain language becomes category, entity, value band and required date
  • Checked against your own catalogue, your punchout sources and your approved suppliers
  • Routing follows your policy — sequential or parallel, by value, category or entity
  • The requester can see which approver it is sitting with

Explore intake

Intake · a need becomes a request Illustrative
Agent actionPlain language in, a classified request out — before anyone is asked to approve anything

The chain

Eleven stages. One record underneath them.

This is the whole of source to pay. Five stages run without anyone. The two that commit money — the award and the payment run — always need a person.

  1. 01 Human

    Someone describes what they need

    A requester writes what they want in their own words, in one place, rather than choosing a form they have to understand first. Attachments, a quote or a specification can come with it.

  2. 02 Rule

    It is classified and checked against what you already buy

    Category, entity, value band and required date are structured out of that text, and the request is matched against your own catalogue, your punchout sources and your approved suppliers before anyone is asked to approve anything.

  3. 03 Human

    The right people approve it, in the order your policy sets

    Approval routing is configured to your organisation: sequential chains, parallel groups, or branching by value, category or cost centre. Delegation covers planned absence, and an approval left sitting escalates rather than stalling.

  4. 04 System

    Sourcing opens from the approved request

    An approved request that needs a competitive event opens one with its lines already on it. An RFI, RFQ or RFP is built from a template your category team maintains, so the questionnaire is not rewritten each time.

  5. 05 Human

    Suppliers respond in their own portal

    Invited suppliers submit pricing and answer the scored sections themselves rather than returning a spreadsheet for someone to re-key. They can ask clarifying questions inside the event, correct a submission before the close, or formally decline with a reason.

  6. 06 Rule

    Bids are evaluated and ranked

    Weighted scoring runs across the technical and commercial criteria your category team set, and every supplier lands in one side-by-side comparison. Bids that failed a mandatory requirement are set aside as non-responsive, and round-over-round comparison shows what actually moved between negotiation rounds.

  7. 07 Human

    The award is decided — and it carries forward

    A category manager awards the whole event to one supplier or splits it deliberately across several. The decision carries into the purchase order and into the contract record, so the supplier, the price and the dates are not entered a second time.

  8. 08 System

    The order reaches the supplier

    The moment an order is approved it is turned into a PDF and emailed to the supplier. This is on by default for every organisation, and a manual send is available for those that switch it off.

  9. 09 Human

    What arrives is recorded

    A receiving clerk records the goods receipt, or a service owner approves a service entry sheet. Receipts can be partial, and stock can be held for quality inspection before it is accepted.

  10. 10 Rule

    The invoice is checked, then scheduled

    The invoice is matched against the order, the receipt and the contract price. Eight disclosed conditions decide whether it clears on its own; a failure sends it to a person carrying the condition that stopped it. Approved invoices are scheduled into the next payment run that still beats the due date.

  11. 11 Human

    A person executes the payment run

    Marking a run paid, with its shared payment reference, is a deliberate click. Nothing in the system marks a payment run as paid on its own, and that is a design decision rather than a gap.

The handoffs

Six joins. Nothing re-typed at any of them.

Any vendor can draw this chain as a diagram with arrows. These are the six real joins and exactly what crosses each one.

Lines, quantities, dates Request → sourcing

An approved request that needs a competitive event opens one with its lines already on it, so the category, the quantities and the required date do not get re-typed into a sourcing document.

Supplier, price, dates Award → order

The award decision carries into the purchase order: supplier, line, price and dates come from what was actually awarded rather than from somebody reading the comparison sheet back out again.

The awarded terms Award → contract

The same decision carries into the contract record, so the agreement reflects the terms that were awarded. The contract then lives its own life — renewal dates, obligations and the rest sit in contract lifecycle management.

Item, unit, price Catalogue → order

A request filled from your own catalogue or from a supplier punchout arrives as a structured requisition with the item, the unit of measure and the negotiated price already attached.

The order itself Order → supplier

Once an order is approved it becomes a PDF and is emailed straight to the supplier. On by default for every organisation, with nobody re-keying or re-sending it by hand.

Quantity and price Order and receipt → invoice

The invoice is matched against the order it belongs to and the receipt that confirmed delivery, plus the contract price that was agreed. Three-way matching is the default; services match against an approved service entry sheet instead.

Core capabilities

What source-to-pay software has to cover.

One intake for every request

Every kind of purchase enters the same way, in plain language

A requester describes what they need in their own words rather than picking a form first. Category, entity, value band and required date are structured out of that text, and the request is checked against your catalogue, your punchout sources and your approved suppliers before an approver sees it. Direct materials, indirect goods, services and project spend all enter the same way, whatever is being bought, rather than through a separate form each.

Sourcing events from the approved request

RFI, RFQ and RFP built on the request rather than beside it

An approved request opens a competitive event carrying its own lines, built from templates your category team maintains with scored questionnaire sections. One event can run through several negotiation rounds, and an RFI can become an RFP without starting again.

Sealed bidding

Responses stay sealed until award

Supplier responses are held sealed until award, including from your own buyers. Suppliers submit in their own portal rather than returning a spreadsheet, can correct a submission before the close, and can decline formally with a reason you can read later.

Comparison and award

A ranked field, then a decision that carries into the order and the contract

Technical and commercial criteria are weighted the way your category team set them, then ranked with every supplier side by side. Bids that failed a mandatory compliance question are set aside. An award can go whole or be split deliberately, and carries into the order and the contract.

Supplier qualification before a supplier can be used

A supplier reaches a purchase order only through the stages you set

Suppliers register themselves and move through named qualification stages, each with its own review. An approved vendor list governs who can be selected against a part, and a supplier placed on hold cannot be invited to a new event or put on a new order.

Budget and commitment control

Committed spend is visible when the order is raised, not when the invoice lands

The budget is checked before a request is submitted and again before it becomes an order. Commitments are tracked as commitments rather than waiting to become actuals, and you choose whether an over-budget request is blocked outright or warned and routed to an extra approver.

Receipt and three-way match

What was ordered, what arrived and what was invoiced have to agree

Goods receipts can be partial, tolerances are yours to set, and stock can be held for quality inspection before it is accepted. A service invoice matches against an approved service entry sheet instead, and that gate is on by default rather than something you configure.

Invoice checks you can read

Eight disclosed conditions, and a named reason for every refusal

The invoice is matched against the order, the receipt and the contract price, then eight disclosed conditions decide whether it clears without anyone touching it. A single failure sends it to a person carrying the condition that failed — deterministic rule code, not a confidence score.

How the decisions are made

Agents draft. People decide.

  • An agent can draft a requisition from a conversation, or a sourcing event from a described need. What it produces is a draft for review. Nothing it drafts is published or submitted on its own.
  • The invoice approval step is deterministic rule code, not a model. It replaced an earlier model-based version, and we would rather tell you that than market it as AI.
  • Every refusal names the condition that failed, so an exception queue is a list of reasons rather than a list of low scores.
  • Approval routing is configured to your policy rather than ours — sequential chains, parallel groups, or branching by value, category or entity.
  • A service invoice cannot reach approval without a confirmed receipt. The only way past is a named role leaving a logged justification.
  • The payment run is always executed by a person. Nothing in the system marks a run as paid on its own, and that is a design decision rather than a gap.
  • Every approval, award and status change is written to an audit trail with who did it and when.

Where Proconomy fits

It runs the workflow. Your systems keep the record.

Three things stay where they are, on purpose. Knowing what a platform does not try to own is usually the fastest way to tell whether it will fit.

Your bank still moves the money

Proconomy schedules payment runs and records them as executed, and a person executes the run with a shared payment reference. The disbursement itself happens in your bank or your finance system, which is where treasury controls already live.

Your ERP stays the system of record

Proconomy owns the workflow between your ERP and your supplier: intake, approval, sourcing, award, ordering, receipt, matching and run scheduling. Your finance system keeps the books and holds the inventory, and it does not have to be replaced for any of this to run.

Your supplier relationships stay yours

Suppliers are invited to your events and onboarded to your organisation, not to a shared network that every other buyer also trades on. Who you buy from, what you pay and how they perform stay inside your tenant.

Three purchases. Three different routes.

1

A catalogue item that stops for nobody extra

A requester finds a drive unit in your own catalogue at its negotiated price. The request is classified and checked against the budget on its own. It stops exactly three times, and each stop is one your policy asked for: the approver on the routing you set, the clerk who records what arrived, and the person who executes the payment run. Nothing in between needs a chaser, and the invoice clears all eight conditions without anyone opening it.

2

A tooling package that has to be competed

A plant raises a need with no agreement behind it. The approved request opens an RFQ carrying its lines, built from the template the category team maintains. Suppliers bid in their own portal, responses stay sealed until the award step, scoring weights technical fit against price, and the award is split across two suppliers on purpose. That decision carries into two orders and into the contract record.

3

A service invoice that stops until the work is confirmed

A contractor invoices for a completed milestone before the service entry sheet is approved. The gate holds it. Once the service owner confirms the work and the quantity covers what was invoiced, the check clears and the invoice continues. If it has to move sooner, a procurement manager can override — and the override and its reason are both on the record.

Bring us one purchase you had to compete.

Not a category list and not a scripted scenario. One real purchase, from the request that started it to the invoice that ended it. We will run it through and show you every point where somebody currently re-types something.

Request a demonstration

Security, compliance and recognition

Checked by auditors. Judged by the industry.

Where each compliance programme stands, and what the procurement industry has given us so far.

Security and compliance

Awards

Five, presented on stage at three industry events.

  • Autonomous Procurement Platform of the Year
  • Procurement Technology Innovation Award
  • Unified Procurement and Supplier Management Platform
  • Procurement Startup of the Year
  • AI in Procurement or Supply Chain Award — Solution Provider

See the events and the trophies

Before you book anything. Answered honestly.

What is source-to-pay software?

Source-to-pay software covers the whole chain from the moment somebody needs something to the moment the supplier is paid: raising and approving the request, running the competitive event, awarding it, turning that award into an order and a contract, recording what arrived, matching the invoice against both, and scheduling the payment. It is broader than procure-to-pay, which starts at the approved order and ends at the payment run. The difference that matters is not the number of stages a vendor lists. It is whether the stages share one record, or whether somebody re-keys between them.

How is source-to-pay different from procure-to-pay?

Procure-to-pay is the downstream half: order, receipt, invoice, match, payment run. Source-to-pay adds the upstream half in front of it — intake, approval, sourcing, negotiation and award — and, critically, the joins between the two. A business that buys mostly from existing catalogues and agreements may only need procure-to-pay. A business where a meaningful share of spend has to be competed first, and where the result of that competition then has to become an order, a contract and eventually a matched invoice, needs the whole chain or it will rebuild the joins by hand.

Do we have to replace our ERP?

No, and we would not advise it. Proconomy runs the workflow between your ERP and your supplier: intake, approval, sourcing, award, ordering, receipt, matching and payment-run scheduling. Your ERP keeps the books, holds the inventory and stays the system of record. Order, receipt and supplier data flows in from connected systems to support matching, so the two stay aligned without your team maintaining a spreadsheet between them.

Can we start with one part of the chain rather than all of it?

Yes, and most implementations do. Intake and orchestration is the usual first step because it is where the chain is most often broken and where the result is visible soonest. Procure-to-pay is the other common starting point when the pain is in accounts payable rather than in requesting. The reason to think about the whole chain early is not that you have to buy it at once. It is that the joins are what make each stage worth more than it is alone, so it is worth knowing where the sequence is heading before the first module goes live.

What stops a wrong invoice from being paid?

Eight conditions, all of which have to pass. The invoice has to be under the value threshold you set. Invoicing against the order, including this invoice, has to stay inside the order total. A goods receipt has to exist, where three-way matching applies. Every goods receipt on the order has to have been quality-approved. No line can be flagged for a variance against the contract price. The invoice cannot have been flagged as a possible duplicate. There can be no unresolved tax mismatch sitting on it. And a foreign-currency invoice has to have an exchange rate. Any single failure sends it to a person with that condition named. There is no partial automatic approval and no confidence band in the middle.

Is this built for direct materials, or only for indirect spend?

Both come in through the same intake, and the chain runs for both. Four things exist specifically for direct materials: multi-tier supplier and BOM risk mapping, APQP and PPAP stage gates tied to sourcing, component lifecycle flags surfaced in the BOM view itself, and first-article gating on receipt. Beyond those four, direct materials is the part of the chain where you should ask the most specific questions about your own parts, because what is deep for one manufacturer is thin for another. Bring us a BOM rather than a category list, and we will tell you which of it we handle and which of it we do not.

How much of this runs without a person?

Less than you might expect, and deliberately so. Classification, matching, scoring, budget checks and the order going out to the supplier all run without anyone. The approvals, the award and the payment run are human decisions by design. Where an agent is involved, it drafts — a requisition from a conversation, a sourcing event from a described need, an email to a supplier whose performance is slipping — and a person reviews before anything is published, submitted or sent.

What should we ask for in a demonstration?

Ask for one of your own purchases, traced end to end, rather than a scripted scenario. Bring a request that had to be competed, and watch the award become an order and a contract without anyone typing. Bring a month of real invoices and see which ones would have cleared on their own and exactly which condition stopped the rest. And ask to see it in a live system rather than a slide deck, because the joins between the stages are the hardest part of this to stage convincingly.

One purchase. Traced end to end.

No slides. Bring one of your own and watch where the chain holds and where somebody currently re-types it.

Someone from client success replies, not a sales sequence. If we are not a fit we will say so on the first call.