Source-to-Pay Process: Controls, Systems and Handoffs

What a controlled source-to-pay process must achieve

A source-to-pay operating model should control four things at every stage: who has authority, which record is authoritative, what evidence proves completion and who owns an exception. A workflow status alone is not enough. “Approved” must identify the approver, authority basis, time, object approved and version of the underlying record.

The GAO’s 2025 Green Book treats internal control as part of day-to-day operations and links control activities with quality information, communication and monitoring. It also says incompatible duties should be separated or alternative controls designed when separation is impractical. Although the Green Book is written for the US federal environment, these principles provide a useful control-design reference when adapted to a company’s own policy, risk and legal context.

For source-to-pay, that means the process should answer five questions without relying on personal knowledge:

• Authority: Who may request, evaluate, select, contract, commit, receive and accept?
• Record: Where is the approved need, supplier, evaluation, contract, purchase order and receipt held?
• Evidence: What proves that each control was performed on the correct version?
• Handoff: What must the next team receive, and how does it accept or reject the package?
• Exception: Who owns a deviation, how long is it valid and how is closure verified?

The design should be proportionate. A low-value catalogue purchase will not need the same sourcing record as a complex service contract. Proportionality changes the depth of evidence, not the need for a named owner, a permitted route and a traceable commitment.

Source-to-pay process map: nine controlled stage gates

The map below starts with an accepted business need. Spend analysis and category strategy may inform that need, but their methodology is outside this article. It ends when AP accepts a complete upstream package into its own invoice-to-payment process.

Where procurement must first establish which transactions and suppliers are in scope, the spend analytics data-readiness framework defines the source, coverage and classification checks needed for that decision.

The UK Government Source to Contract Functional Reference Model is a useful reference for this gate-based view. It links business need, sourcing, evaluation, award and mobilisation, and explicitly identifies a handover from commercial transaction processes to purchase-to-pay processes in finance. Its public-sector requirements are not universal corporate rules, so the controls and thresholds must be adapted rather than copied.

Make every process object authoritative in one system

“One source of truth” should not be interpreted as “one application for everything.” A source-to-pay estate may include intake, e-sourcing, supplier-risk, contract-lifecycle-management, enterprise resource planning (ERP), purchasing and AP tools. The control requirement is that each business object has one authoritative record, one owner and a controlled way to pass stable identifiers downstream. A coordination tool placed above that estate raises the same requirement in sharper form, and procurement orchestration scope and boundaries sets out what such a layer may write and what it must leave with the owning system.

The system map should also identify interfaces, timing, required fields, control totals, retry ownership and reconciliation. The Open Contracting Data Standard mapping guidance recommends identifying the systems that capture contracting data and how data held across systems connects to form a complete process view. That guidance concerns public contracting data, but the mapping discipline transfers well to internal source-to-pay architecture.

Three interface rules prevent many handoff defects:

1. Reject incomplete records at the boundary. Do not let a missing contract ID, supplier ID or acceptance owner become an AP research task.
2. Preserve version and lineage. A purchase order should reference the contract or catalogue version that authorised its terms, not merely the supplier name.
3. Reconcile accepted and rejected transfers. The sending system, receiving system and control owner should agree on counts, values and unresolved failures.

Responsibility, control and handoff matrix

The matrix assigns one accountable role for the stage outcome and distinguishes it from the people performing work. Titles will vary. The important design test is whether the accountability survives reorganisations, absences and system changes.

The responsibility model should be explicit rather than implied by system permissions. The Sourcing Playbook’s OKUA model separates ownership, knowledge, understanding and awareness. A company can use a RACI or another method, but it should still identify who owns the outcome, who supplies expertise, who must understand the control and who only needs visibility.

Set an acceptance contract for the AP handoff

The AP handoff should be treated as an acceptance contract between processes. Procurement sends a defined package. AP checks whether the package meets entry criteria. An accepted package enters invoice processing; a rejected package returns to the upstream role that can correct the source record.

The downstream invoice automation control model defines how AP captures, validates, matches, approves, routes exceptions and posts an accepted package.

The intended contract manager should be involved before award, not introduced after the first invoice. The Project Delivery Teal Book’s procurement and contract-management guidance recommends early involvement so the future manager understands the scope, payment regime, performance measures, change provisions, risks and exit terms. That is directly relevant to defining who may confirm delivery and what evidence AP will later rely on.

Minimum handoff package

• Payable supplier: active approved supplier ID for the correct legal entity, with master-data controls completed outside the invoice case.
• Commitment reference: purchase order, contract, catalogue or explicitly approved non-PO route, including the authorising record.
• Commercial terms: entity, currency, payment terms, price or rate basis, order limits and policy-required accounting or tax fields.
• Delivery evidence: receipt, service entry or milestone acceptance, including the person authorised to confirm it.
• Current contract state: effective dates and approved amendments reflected in the contract and order records.
• Exception status: exception type, approver, scope, limit, expiry and owner for any unresolved condition.
• Routing data: invoice channel, supplier contact, internal dispute owner and the identifiers AP needs to link the invoice to upstream evidence.
• Traceability: stable links among intake, sourcing, supplier, contract, requisition, order and receipt records.

Acceptance and rejection states

Use a small controlled status set. For example: submitted, accepted by AP, rejected upstream, resubmitted and closed. A rejection should carry a reason code and a responsible upstream owner. AP can identify the defect, but it should not create a missing contract approval, change a supplier record or invent evidence of receipt.

The Government Functional Standard GovS 008 requires documented offers, due diligence, authorised contract signatures and understood mobilisation obligations in its UK public-sector scope. The broader operating lesson is that award, contract and mobilisation evidence must be complete before transaction execution is treated as routine.

Treat exceptions as controlled routes

An exception is not a free-text explanation attached after the event. It is an alternative route with its own authority, evidence and expiry. Common routes include emergency procurement, a policy-approved non-PO category, a retrospective commitment, a supplier-master change, a contract amendment and a disputed or partial receipt.

The Vistry supplier-credit monitoring test shows when a reported insurance-limit change should remain a watch item and when evidence supports a controlled term, order or sourcing exception.

Every exception type should define:

• the condition that permits its use;
• the role that may request and approve it;
• the value, duration, supplier or category limits;
• the evidence that must exist before the next stage;
• the system code used to identify it;
• the owner and due date for corrective action;
• the monitoring threshold that triggers escalation or policy review.

Do not hide retrospective purchase orders inside normal cycle-time statistics. Tag them as exceptions and attribute the defect to the stage where the authorised commitment was missed. The same principle applies when AP discovers a contract, supplier or receipt problem: measure the defect where it originated, not only where it became visible.

Exception controls also need closure evidence. The Green Book’s timely-remediation principle calls for identified control deficiencies to be addressed through established reporting lines. In a source-to-pay model, an ageing exception queue should therefore show the accountable owner, original stage, current action, due date and closure approval.

Test whether the operating model works

Test the design on a bounded flow before extending it across every category and entity. Select one category or business unit, follow transactions from intake to AP handoff for 30 days, and record both successful transfers and rejected packages. The test should distinguish whether a control was designed, implemented in the workflow and performed in operation.

Process and control measures

• intake requests accepted on first submission;
• sourcing events released only after the route, criteria and approvals were recorded;
• award files with complete evaluation, due-diligence and approval evidence;
• contracts with a named owner, purchase rules and acceptance method before activation;
• purchase orders linked to the current contract or approved catalogue record;
• receipts or service entries recorded before the related invoice reaches AP;
• AP handoff packages accepted on first submission;
• exceptions by originating stage, reason, owner and age;
• open segregation-of-duties conflicts and alternative controls awaiting review.

Cycle time is useful only when paired with first-pass acceptance and exception data. A fast process that transfers incomplete records to AP has shifted work rather than improved control. Review the defect pattern with procurement operations, the contract-management owner, master-data governance and AP. Change the stage gate, data rule or responsibility where the defect begins, then repeat the test.

The deliverable from this review is not another process diagram. It is a governed operating standard: stage definitions, owners, system authority, required evidence, permitted exception routes, AP acceptance criteria and a change owner for keeping the model current.