---
title: "ProcurementOps"
slug: procurementops
category: industry
term_status: established
evidence_status: partially_verified
summary: "ProcurementOps (procurement operations) runs how an organisation buys, from a request to the supplier's payment, as a fast, measured operation whose controls (approvals, segregation of duties, matching) stop error and fraud."
audience: [Beginners, Procurement and P2P analysts, Accounts payable and finance, Budget holders and requesters, Engineers integrating ERP and procurement tools, Leaders]
last_verified: 2026-10-23
key_takeaways:
  - "Procurement is an established profession (CIPS holds a Royal Charter); \"procurement operations\" is a real team and job name, while the one-word \"ProcurementOps\" is informal."
  - "The core asset is a chain of controls from request to payment: approved need, purchase order, receipt, matched invoice, verified supplier master data, and a payment released by someone who did not create the payee."
  - "Segregation of duties and three-way matching target common, costly losses: billing schemes were 22% of the cases in the ACFE's 2024 study, and BEC losses reported to the FBI were about $2.77 billion in 2024."
  - "In this Atlas's judgement, given BEC losses, the riskiest single transaction is a change to a supplier's bank details: verify it through a channel the requester did not supply, and treat a bank's payee-name mismatch as a stop."
  - "Match the control to the spend: catalogues and cards for small, frequent buys, purchase orders with matching for goods, competitive sourcing for large or risky spend. One heavy process for everything drives people around it."
  - "Measure cycle time, PO compliance, first-pass match rate and duplicate payments together; savings figures alone reward the wrong behaviour."
related: [supplychainops, legalops, riskops, finops, complianceops, fincrimeops, fleetops, retailops]
---

## What ProcurementOps is

### In 30 seconds

**ProcurementOps (procurement operations) is the discipline of running everything an organisation does to buy goods and
services, from "I need this" to "the supplier has been paid", as a dependable, measured operation.** It owns the buying channels
people use, the approvals and contracts that commit money, the supplier records that say who may be paid and where, the matching
of invoices to orders and receipts, and the data that shows where the money went.

Two outcomes pull against each other: requesters want things quickly; finance and auditors want proof that every payment was
authorised and went to a real supplier, for something received, at the agreed price, once. A good operation makes the compliant
path the fastest, with hard controls only where money can be lost.

Written for beginners, procure-to-pay (P2P) and accounts payable staff, budget holders, engineers who integrate ERP and
procurement tools, and leaders. Sources were last verified on **2026-10-23**.

::: note Scope of this page
This page teaches the **request-to-payment control chain** (segregation of duties, approvals, three-way matching, supplier master
data) as its centre of gravity, an editorial emphasis this Atlas assigned (see [what it is not](#what-procurementops-is-not)).
Nothing here is legal or tax advice: every legal statement names its jurisdiction and a date.
:::

### At a glance

| Question | Short answer |
|---|---|
| Goals | Spend that is authorised, competitive and recorded; fast purchasing that stays compliant; clean supplier data; no duplicate or fraudulent payments |
| Users | Requesters, budget holders, buyers, procurement operations analysts, accounts payable (AP), treasury, reviewers, auditors |
| Scope | Intake, approvals, sourcing (RFI, RFP, RFQ), purchase orders (POs), receipt, invoice matching, supplier onboarding and master data, renewals, spend analysis, procurement systems |
| Prerequisites | Basic accounting vocabulary (accrual, payable, cost centre); no prior procurement knowledge needed |
| Key outputs | Buying channels and policy, approval matrix, supplier master, POs, matched invoices, spend cube, KPIs, audit evidence |
| Term status | **Established** practice; "procurement operations" is a common team and job name; "ProcurementOps" in one word is informal (see [term status](#term-status-and-where-the-label-comes-from)) |

### The problem it solves

Without an operating discipline, buying fails in recognisable ways:

- **Money is committed before anyone checks.** A manager signs a supplier's order form; finance learns about a three-year
  commitment from the first invoice, and budget, legal and data-protection review happen after the fact, if at all.
- **Invoices cannot be checked.** With no purchase order and no receipt, AP can only ask the requester "is this OK?" by email, so
  overbilling, duplicates and invoices for things never received get paid.
- **The supplier list is a liability.** Three records for one supplier, a bank account changed after an email, suppliers never
  screened against sanctions lists, a vendor sharing a bank account with an employee.
- **Nobody knows what the organisation buys,** so it cannot negotiate as one customer, see concentration risk, or report on
  suppliers when the law or a customer asks.
- **Or the opposite: controls so heavy that people avoid them.** A six-week process for a $300 tool teaches everyone to expense
  purchases on a personal card, which removes every control at once.

The cost of the first four is not hypothetical. In the Association of Certified Fraud Examiners' 2024 study of 1,921 occupational
fraud cases, billing schemes (invoices for fictitious goods or services, inflated invoices, or invoices for personal purchases)
appeared in 22% of cases with a median loss of $100,000, and a lack of internal controls was the main weakness in 32% of cases.[^acfe]
External fraud aimed at payables is larger still: the FBI's Internet Crime Complaint Center (IC3) recorded 21,442 business email
compromise (BEC) complaints with reported losses of about $2.77 billion in 2024, and defines BEC as a scam aimed at those working
with suppliers or regularly making wire transfers.[^ic3-2024]

### What ProcurementOps is not

- **Not logistics or inventory.** Moving, storing and planning physical goods belongs to [SupplyChainOps](../supplychainops/).
  **Editorial distinction:** in this Atlas, ProcurementOps is the *buying process* (who may commit money, to whom, on what terms,
  and how the invoice is proven); SupplyChainOps is the *physical flow* of goods. Many organisations put both under one chief
  procurement officer, and the industry does not draw this line consistently.
- **Not contract law.** Drafting, negotiating clauses and contract lifecycle management (CLM) belong to [LegalOps](../legalops/).
  Procurement decides commercial terms and routes contracts; legal owns the legal review.
- **Not the supplier risk method.** How to score, accept and aggregate third-party risk belongs to [RiskOps](../riskops/); this
  page runs the onboarding and review steps that feed it.
- **Not cloud cost optimisation.** Commitment purchases and rightsizing are taught in [FinOps](../finops/); the enterprise contract
  and the supplier relationship are procurement's.
- **Not just accounts payable or "the people who raise POs".** That view loses the upstream controls (need, budget,
  competition) that prevent most problems.
- **Not a software category.** Buying an "intake-to-procure" or "procure-to-pay" suite does not create the operating model, the
  data or the segregation of duties.

## Vocabulary, origins and neighbours

### Term status and where the label comes from

Procurement is an established profession. The Chartered Institute of Procurement & Supply (CIPS)
holds a Royal Charter, is a not-for-profit awarding body, and reports over 60,000 members in over 150 countries.[^cips-about]
CIPS publishes a 13-step Procurement and Supply Cycle.[^cips-cycle] An ISO guidance standard covers sustainable procurement
(ISO 20400, 2017),[^iso20400] and public buying is set by law in many jurisdictions (for example the UK's Procurement Act 2023).[^uk-pa-esx]

**"Procurement operations"** is a common name for a team and job family. GitLab's public handbook describes a Procurement
Operations job family that "supports procurement and spend management activities", with analysts who maintain the procurement
process, run spend analytics and procurement metrics, and own supplier onboarding with accounts payable.[^gitlab-jobs] Northeastern
University's Procurement Operations team "develops and implements processes and procedures related to buying goods and services
for the university".[^neu]

**"ProcurementOps"** in one word is informal: a web search on 2026-10-23 for the exact string found only pages about procurement
operations, and no body, standard or product of that name. Vendors promote neighbouring labels: Zip defines "intake-to-procure" as
"a centralized, structured process that guides purchase and supplier requests" up to approval, with POs, invoicing and payment in
the downstream procure-to-pay process.[^zip-i2p] That is a product category, not a definition of the discipline.

In the **narrow** usage, procurement operations is the transactional sub-team (requisitions, POs, supplier set-up, systems,
reporting), separate from strategic sourcing, as in GitLab's separate operations and category-manager roles.[^gitlab-jobs] This
page uses the **broad** sense, the whole source-to-pay operating model, with most space on the controls and the data.

### Glossary and mental model

| Term | Meaning |
|---|---|
| Source-to-pay (S2P) | The whole chain: need, sourcing, contract, order, receipt, invoice, payment |
| Procure-to-pay (P2P) | The transactional part of S2P: requisition, PO, receipt, invoice, payment |
| Requisition | An internal request to buy, approved before a PO exists |
| Purchase order (PO) | The buyer's numbered commitment to buy stated quantities at stated prices and terms |
| Goods receipt / service entry | A record, by someone other than the buyer, that goods arrived or a service was done |
| Two-, three-, four-way match | Comparing the invoice with the PO (2), plus the receipt (3), plus inspection results (4), before payment |
| Tolerance and hold | The permitted difference (for example 2% and 0.50 per unit) before a mismatch blocks payment as a hold |
| GR/IR | Goods receipt / invoice receipt clearing account: SAP posts the receipt value there until the invoice clears it[^sap-grir] |
| Supplier (vendor) master | The record of who may be paid: legal name, tax ID, address, bank account, terms, status |
| Segregation of duties (SoD) | Splitting authorise, record, custody and review so no one person controls a transaction end to end |
| RFx | Requests for information (RFI), proposals (RFP) or quotations (RFQ) |
| Category management | One strategy for a group of similar spend (for example laptops and peripherals) |
| Tail spend | The many small suppliers that together make up a small share of spend |
| Maverick spend | Buying outside the agreed channels or contracts (off-contract, no PO); the target of PO-compliance metrics |
| Evaluated receipt settlement (ERS) | Paying from the receipt and the contract price without a supplier invoice; it moves the whole control onto the receipt |
| Verification of Payee (VoP), Confirmation of Payee (CoP) | A bank service that checks the payee name against the account before a transfer (EU and UK names) |
| SOX, COSO | The US Sarbanes-Oxley Act's internal-control rules; COSO's Internal Control – Integrated Framework, widely used by auditors |

**Mental model: a chain of evidence.** Think of every payment as needing five pieces of evidence that were created by
*different* people or systems: an **approved need** (requisition), a **commitment** (PO or contract), **proof of delivery**
(receipt), a **claim** (invoice) that matches the first three, and a **payee** (supplier master record) that was verified
independently. When any piece is missing, or two pieces were created by the same person, the chain is weaker exactly there. The
rest of this page is about building that chain without making it slow.

### How ProcurementOps relates to other Ops

::: figure ProcurementOps and its neighbours: who owns which part of buying
```mermaid
flowchart LR
  PF["`PortfolioOps, BizOps:
    budgets, priorities`"] -->|"budget"| PO
  FO["`FinOps:
    cloud demand`"] -->|"forecast"| PO
  PO["`ProcurementOps:
    request-to-payment
    control chain`"]
  PO <-->|"contracts"| LO["`LegalOps:
    contract terms`"]
  PO -->|"supplier facts"| RO["`RiskOps:
    risk method`"]
  PO -->|"evidence"| CO["`ComplianceOps:
    audits`"]
  PO -->|"orders"| SC["`SupplyChainOps:
    logistics`"]
  PO -->|"anomalies"| FC["`FinCrimeOps:
    fraud monitoring`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class PO core
  class PF,FO,LO,RO,CO,SC,FC neutral
```
Text equivalent: PortfolioOps and BizOps send budgets, and FinOps cloud demand forecasts, into ProcurementOps (the
request-to-payment control chain). It exchanges contracts with LegalOps, and sends supplier facts to RiskOps, evidence to
ComplianceOps, orders to SupplyChainOps and payment anomalies to FinCrimeOps.
:::

| Neighbour | Shared scope | ProcurementOps owns | The neighbour owns |
|---|---|---|---|
| [SupplyChainOps](../supplychainops/) | Sourcing of direct materials, supplier performance | Buying process, PO, matching, supplier master | Demand planning, inventory, logistics, SCOR metrics |
| [LegalOps](../legalops/) | Contracts, NDAs, data-processing agreements | Commercial terms, routing, the renewal or re-tender decision | Legal review, clause libraries, the CLM record (dates, notice periods) |
| [RiskOps](../riskops/) | Third-party risk | Running due diligence at onboarding and renewal | Risk appetite, scoring method, acceptance |
| [FinOps](../finops/) | Cloud and SaaS commitments | Enterprise agreements, supplier relationship | Usage data, commitment sizing, cost allocation |
| [ComplianceOps](../complianceops/) | Audit evidence | Producing evidence that controls ran | Control framework mapping, audits |
| [FinCrimeOps](../fincrimeops/) | Payment fraud | Preventive controls in P2P | Transaction monitoring and investigations in financial services |
| [PeopleOps](../peopleops/) | Contractors and agencies | Contracting the supplier | Worker records, background checks |
| [GovOps](../govops/) | Public procurement rules | The process inside a public body | Public-value constraints on services |

Procurement also buys for every other function, so it touches [ITOps](../itops/) (software and hardware), [IdentityOps](../identityops/)
(supplier and contractor accounts), and [GreenOps](../greenops/) (supplier emissions data). Several pages hand their buying to this
one: vehicles and fleet leases ([FleetOps](../fleetops/)), merchandise and store supplies ([RetailOps](../retailops/)), lab
consumables and instruments ([LabOps](../labops/)), and contracts with AI model and API providers ([FinOps for AI](../finops-for-ai/)).
Those pages own *what* to buy and how to run it; this page owns how the purchase is approved, contracted and paid.

## Principles and operating model

### Charter and principles

No body publishes a "ProcurementOps manifesto"; this charter is **this Atlas's proposal**, distilled from the sources cited here.

**Mission.** Let the organisation buy what it needs quickly, from suppliers it can trust, on terms it has agreed, and pay each
supplier correctly and once, with evidence that a sceptical auditor would accept.

**Principles (proposed):**

1. **Commit before you buy.** Money is committed by an approved request and a PO or contract *before* work starts, never
   reconstructed from an invoice afterwards. Exceptions are listed, not improvised.
2. **No one person controls a transaction end to end.** Authorising, recording, receiving and paying are split; where a team is
   too small to split them, a compensating review is designed and evidenced. This follows the US Government Accountability
   Office's Green Book, which asks management to separate "authorizing transactions, processing and recording them, reviewing the
   transactions, and handling any related assets".[^gao-gb]
3. **The payee is verified independently of the request.** Supplier identity and bank details are confirmed through a channel
   the requester or the email sender did not provide.
4. **Proportionate control.** Control follows value and risk; small, repetitive buys use low-friction channels.
5. **One front door, visible queues.** Every request has an owner, a service level and a visible status.
6. **Data is a product.** Supplier master, categories and contract metadata are kept clean.
7. **Measure flow and leakage together,** so neither speed nor control wins at the other's expense.

**Non-goals.** Deciding *what* budget holders need; legal advice; physical logistics; winning negotiations at the cost of
supplier relationships.

### Fundamentals: the documents and the control points

The chain has eight records, each with the control that applies to it.

| Record | Created by | Control that applies | What it proves |
|---|---|---|---|
| Requisition / intake request | Requester | Budget-owner approval within delegated authority | The need exists and is funded |
| Sourcing record (quotes, RFx, award) | Buyer | Competition thresholds; conflict-of-interest declaration | The price and supplier were chosen fairly |
| Contract | Legal and procurement | Signature authority matrix | Terms are agreed and enforceable |
| Purchase order | Buyer or system | PO cannot exceed the approved requisition; numbered and unique | The commitment and its price |
| Receipt / service entry | Receiver (not the buyer) | Independent confirmation | Goods or services were delivered |
| Supplier master record | Supplier (self-service) plus vendor data team | Screening, tax and bank verification; changes approved by a second person | The payee is who they claim to be |
| Invoice | Supplier | Matching to PO and receipt within tolerances; duplicate check | The claim is due |
| Payment | Treasury / AP | Release by someone who cannot create suppliers or post invoices | Money left once, to the verified account |

The Green Book also recommends unique transaction identifiers, naming "unique invoice numbers and purchase order numbers", so that
duplicates can be detected.[^gao-gb] It also notes that segregation of duties mitigates the risk of management override but
"cannot absolutely prevent it because of the risk of collusion".[^gao-gb] Collusion between two or more people defeats any split of
duties, which is why the chain also needs detective controls (analytics, reviews, tips), not only preventive ones.

### Roles, ownership and RACI

Besides requesters, budget holders, AP, treasury and the legal, security and privacy reviewers, three procurement roles matter:
**buyers and category managers** (sourcing, negotiation, supplier relationships), **procurement operations analysts** (intake,
workflow, tooling, policy, KPIs) and a **vendor data team** (onboarding, bank-detail verification). **Internal audit** tests the
controls independently.

**RACI for the main activities** (R responsible, A accountable, C consulted, I informed):

| Activity | Requester | Budget holder | Procurement | AP | Treasury | Legal / Security |
|---|---|---|---|---|---|---|
| Raise and justify request | R | A | C | – | – | – |
| Choose sourcing route and run RFx | C | C | A/R | – | – | C |
| Approve commercial terms | C | A | R | – | – | C |
| Contract review and signature | I | A | R | – | – | R |
| Onboard supplier and verify bank details | I | – | A/R | C | C | C |
| Issue PO | I | I | A/R | I | – | – |
| Confirm receipt | R | A | I | I | – | – |
| Match invoice and clear holds | C | C | C | A/R | – | – |
| Release payment | – | – | – | C | A/R | – |
| Spend reporting and KPIs | I | I | A/R | C | I | – |

**Segregation-of-duties matrix.** The pairs in the table should never be held by one person without a documented compensating
control. Lab 3 below turns this table into a script.

| Duty A | Duty B | Why the pair is dangerous |
|---|---|---|
| Create or change supplier | Release payment | Can create a payee and pay it |
| Create PO | Confirm receipt | Can order and confirm receipt of goods that never arrived |
| Post invoice | Release payment | Can enter an invoice and pay it |
| Raise requisition | Approve the same requisition | Approves own spending |
| Change supplier bank details | Approve that change | No second check on the riskiest field |

### Lifecycle: from need to renewal

CIPS describes a 13-step Procurement and Supply Cycle: Specification, Analysis, Strategy, Market, Documentation, Criteria, Tender,
Evaluation, Contract, Delivery, Performance, Management and Asset, with a "Gateway review: Stop, Think, Check" between
steps.[^cips-cycle] Operationally, the same life is easier to run as five stages, each with an owner and an exit condition.

::: figure The procurement lifecycle in five operating stages
```mermaid
flowchart TB
  A["`1 Need and intake
    request, budget check, routing`"] --> B["`2 Source and contract
    RFx, negotiation, legal, security`"]
  B --> C["`3 Onboard and order
    supplier master, PO issued`"]
  C --> D["`4 Receive, match, pay
    receipt, 3-way match, payment`"]
  D --> E["`5 Manage and renew
    performance, renewal or exit`"]
  E -->|"renewal or re-tender"| B
  E -->|"new need"| A
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,B,C,D,E core
```
Text equivalent: five stages in sequence. 1, need and intake (request, budget check, routing). 2, source and contract (RFx,
negotiation, legal and security review). 3, onboard and order (supplier master record, PO issued). 4, receive, match and pay
(receipt, three-way match, payment). 5, manage and renew (supplier performance, renewal or exit). From stage 5 a renewal or
re-tender loops back to stage 2, and a new need loops back to stage 1.
:::

| Stage | CIPS steps covered | Exit condition |
|---|---|---|
| 1 Need and intake | Specification | Approved request with category, value, data classification and owner |
| 2 Source and contract | Analysis, Strategy, Market, Documentation, Criteria, Tender, Evaluation, Contract | Award decision recorded; contract signed by someone with authority |
| 3 Onboard and order | (contract implementation) | Supplier active in master data; PO released |
| 4 Receive, match, pay | Delivery | Invoice matched or exception resolved; payment released |
| 5 Manage and renew | Performance, Management, Asset | Review held; renewal, re-tender or exit decided before the notice date |

A catalogue order skips stage 2 (sourcing was done once for the catalogue); a renewal skips onboarding but never the stage 5
review.

### Operating model and governance

**Delegation of authority.** A written approval matrix states who may approve spend, sign contracts and release payments, by
amount and type; every approval workflow is configured from it. GitLab, for example, points requesters to an "Authorization
Matrix" and allows only "a small number of team members" to sign agreements.[^gitlab-proc]

**Buying channels by spend type.** Mature operations route each kind of purchase to the lightest channel that controls its risk:

| Channel | Use for | Main control | Typical friction |
|---|---|---|---|
| Catalogue / punch-out | Repeat items from contracted suppliers | Prices fixed in advance; approval by amount | Minutes |
| Purchasing card | Small, low-risk, one-off buys | Card limits, blocked merchant categories, monthly review | Minutes |
| Purchase order | Goods and defined services above the card limit | Approved requisition, PO, receipt, matching | Days |
| Contract with call-offs | Recurring services under a framework | Contract rates; call-off orders against it | Days |
| Competitive sourcing | High value, high risk or new categories | RFx thresholds, evaluation panel, award record | Weeks |
| No-PO list | Utilities, taxes, statutory fees, refunds | Named exceptions with their own approval | Varies |

GitLab's tiers illustrate this (US dollars, handbook modified 2026-09-13): a procurement-led RFP with typically five or more
bids above $250K, a business-led RFP with two to three bids from $100K, a two-bid quick-bid from $25K, no bid below, and a PO
exception for one-time purchases under $5K.[^gitlab-proc] Set yours from your own risk and volume data.

**Cadence.** Daily triage of intake and invoice exceptions; weekly review of ageing requests and holds; monthly KPIs with
finance; quarterly category and renewal reviews with budget holders; an annual policy and threshold review.

**Escalation.** Make urgency criteria explicit. In GitLab's rule, "Supplier wants it signed today" does not qualify; a specific,
quantified business impact does.[^gitlab-proc]

## Architecture and workflow

### Reference architecture: process, systems and data

For a non-technical discipline, the reference architecture is a process-and-systems map: which system is the record for which
document, and where the controls run. Most organisations have four layers, whether they buy one suite or assemble several tools.

::: figure Reference architecture of a procurement operation
```mermaid
flowchart TB
  IN["`Engage: intake
  front door`"]
  CAT["`Engage: catalogues,
  supplier portal`"]
  WF["`Workflow: approvals
  from authority matrix`"]
  SRC["`Workflow:
  sourcing, RFx`"]
  CLM["`Workflow: contract
  repository (LegalOps)`"]
  VM["`Record:
  supplier master`"]
  POS["`Record:
  requisitions, POs`"]
  REC["`Record:
  receipts`"]
  AP["`Record: invoices,
  matching, holds`"]
  PAY["`Money:
  payment run, bank`"]
  DW["`Evidence:
  spend data, KPIs`"]
  IN --> WF
  CAT --> POS
  WF --> SRC
  SRC --> CLM
  WF --> POS
  VM --> POS
  POS --> REC
  REC --> AP
  AP --> PAY
  AP --> DW
  POS --> DW
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class WF,POS,REC,AP core
  class VM,PAY risk
  class IN,CAT,SRC,CLM,DW neutral
```
Text equivalent: four layers, named at the start of each label. Engage: intake front door, and catalogues with a supplier portal.
Workflow (decisions): approvals built from the authority matrix, sourcing and RFx, contract repository (with LegalOps). Record (the
ERP or P2P suite): supplier master, requisitions and POs, receipts, invoices with matching and holds. Money and evidence: payment
run with the bank, and spend data with KPIs. Intake feeds the approval workflow, which feeds sourcing (then contracts) and POs; catalogues create POs directly;
the supplier master feeds POs; POs lead to receipts, receipts to matching, matching to payment; invoices and POs feed spend data.
The supplier master and payment run are marked highest-risk.
:::

**Component responsibilities and trust boundaries.**

- **Intake** captures facts once and routes them; the requisition or PO in the ERP stays authoritative.
- **Approval workflow rules** are controlled changes: whoever edits routing can bypass every approval.
- **Supplier master** is the trust boundary between the outside world and your money. Suppliers enter their own banking and tax
  data through a portal; GitLab's handbook says its procurement team cannot enter suppliers' banking and tax information on their
  behalf: it does not know that information, and "it would be a violation of SOX Compliance guidelines" (SOX: the internal-control
  rules of the US Sarbanes-Oxley Act).[^gitlab-proc] Bank-field changes follow
  [SOP-VM-03](#reference-implementation-operating-artefacts).
- **Matching** runs in the system of record, so holds actually block payment; **payment** is released by a separate role.

**Alternatives and trade-offs.**

| Option | Strengths | Limits | Fits |
|---|---|---|---|
| ERP purchasing module only | One record, matching built in, fewer integrations | Poor requester experience; intake lives in email | Organisations with simple, mostly direct spend |
| ERP plus intake/orchestration tool | Good front door; routes legal, security, privacy reviews in parallel | Two systems to keep consistent; licence cost | Knowledge-work companies with many SaaS and services purchases |
| Full source-to-pay suite | Catalogues, sourcing, contracts, invoicing and supplier portal in one product | Implementation effort; lock-in; still needs ERP integration for the ledger | Large organisations with high invoice volumes |

GitLab's documented set-up is an example of the second and third rows combined: requests start in Zip, where sanctions,
procurement, financial planning and analysis (FP&A), IT and legal reviews take place (negotiation, security, privacy and PeopleOps reviews, when required, run in
parallel with legal review), and the requisition then moves to Coupa for final approvals and PO release.[^gitlab-proc]

### End-to-end workflow: happy path and exception paths

The flow below follows one purchase of goods; each label starts with the actor, and every change of actor is a control point.

::: figure One purchase from request to payment, by actor
```mermaid
flowchart TB
  R1["`Requester:
  submit request`"] --> R2{"`Budget holder: within
  budget and authority?`"}
  R2 -->|"no"| R1
  R2 -->|"yes"| P1["`Procurement: choose
  channel and source`"]
  P1 --> P2["`Procurement: onboard
  supplier if new`"]
  P2 --> P3["`Procurement:
  issue PO`"]
  P3 --> G1["`Receiver:
  record receipt`"]
  G1 --> A1["`AP: capture
  invoice`"]
  A1 --> A2{"`AP: matches PO
  and receipt?`"}
  A2 -->|"yes"| A3["`Treasury:
  release payment`"]
  A2 -->|"no"| A4["`AP and owner:
  hold and resolve`"]
  A4 --> A2
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class R1,P1,P2,P3,G1,A1,A3 core
  class R2,A2 decision
  class A4 risk
```
Text equivalent: one chain, each step labelled with its actor. The requester submits a request; the budget holder checks whether
it is within budget and authority; if not, it goes back to the requester. If yes, procurement chooses the channel and sources,
onboards the supplier if new, and issues the PO. The receiver records the receipt. Accounts payable (AP) captures the invoice and
checks whether it matches the PO and receipt; if yes, treasury releases payment; if not, AP and the hold's owner resolve the hold,
and the invoice is re-checked.
:::

**Happy path details.** Specialist reviews run in parallel ([intake playbook](#playbook-intake-and-triage)); the PO tells the
supplier to quote its number on every invoice; for services the requester confirms the milestone as the receipt; payment is
released on the due date; cycle time, holds and supplier performance feed the KPI review.

**Exception paths that need a documented owner.**

| Exception | Owner | Default action |
|---|---|---|
| Invoice without PO | AP, then requester | Return it, or route a counted retrospective approval (an "after-the-fact" PO) |
| Price above tolerance | Buyer | Accept with a PO change (documented reason) or dispute with the supplier |
| Quantity billed above received | Receiver, then AP | Confirm missing receipt or short-pay; never "receive" just to clear the hold |
| Duplicate suspected | AP | Hold both; confirm with supplier statement |
| Bank detail change request | Vendor data team | Out-of-band verification before any payment ([workflow](#playbook-supplier-onboarding-and-bank-detail-changes)) |
| Urgent request | Procurement lead | Apply the written urgency criteria; record the bypass and review it monthly |
| Supplier fails due diligence | Procurement with RiskOps | Reject, or accept with recorded risk owner and conditions |

The quietest failure is the third row: receipts booked to unblock invoices turn three-way matching into two-way matching.
Monitor receipts entered *after* the invoice and in bulk.

## Practices and playbooks

Each playbook names its trigger, owner, steps, acceptance criteria and the usual variant. Together they cover the recurring work.

### Playbook: intake and triage

**Trigger:** any new request. **Owner:** procurement operations. **Goal:** route every request correctly on first contact.

1. Publish one front door (a form in the procurement tool or chat) and retire side doors such as personal email.
2. Ask only the questions that change routing (Artefact 2 in the [reference implementation](#reference-implementation-operating-artefacts))
   and derive the route automatically: value sets approvers and sourcing, data shared sets security and privacy review, a new
   supplier triggers onboarding, anticorruption answers trigger compliance review.
3. Run reviews in parallel, not in series, and show each review's status to the requester.
4. Publish and measure service levels per review (GitLab's range from two days for buyer review to four to fourteen days for
   security and privacy[^gitlab-proc]).

**Acceptance criteria:** fewer than one in ten requests rerouted after submission; median time to first action within one
working day; requesters can see status without asking.

### Playbook: choosing the sourcing route and running an RFx

**Trigger:** new spend above the bid threshold, a change of supplier, or a periodic market test (GitLab requires a market review
every three years for existing contracts[^gitlab-proc]). **Owner:** buyer or category manager.

| Instrument | Use when | Output |
|---|---|---|
| RFI (information) | You do not yet know the market or the right specification | Long list, market facts, refined requirements |
| RFQ (quotation) | Requirement is fully specified; price is the main differentiator | Comparable prices; award to lowest compliant quote |
| RFP (proposal) | Solutions differ; quality, risk and price must be weighed | Scored proposals; award on weighted criteria |

Steps for an RFP: separate must-haves from scored criteria; fix criteria and weights **before** opening responses; sign
confidentiality agreements before sharing sensitive needs; collect evaluators' declarations of interest; score independently, then
moderate; record the award rationale; notify unsuccessful bidders. Public bodies follow statutory procedures instead (see [the regulatory map](#regulatory-map-as-of-october-2026)).

**Pitfalls:** writing the specification around a preferred supplier; changing weights after seeing prices; letting the incumbent
see competitors' prices; running an RFP for a purchase too small to justify the suppliers' bid cost.

### Playbook: supplier onboarding and bank-detail changes

**Trigger:** award to a supplier not yet in the master, or any change request to a supplier's legal, tax or bank data.
**Owner:** vendor data team (procurement operations), with AP and treasury consulted.

Onboarding steps:

1. Search the master by tax ID, normalised legal name and bank account to avoid duplicates.
2. Screen the legal entity and its owners against applicable sanctions lists by full legal name. The US Office of Foreign Assets
   Control (OFAC) lists screening software not updated for list changes, and missed alternative spellings, among
   failures.[^ofac]
3. Run the due diligence the category needs (security, privacy, financial viability, anticorruption). NIST CSF 2.0 asks that
   "Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party
   relationships" (GV.SC-06).[^nist-csf] The scoring method belongs to [RiskOps](../riskops/).
4. The supplier enters legal, tax and bank data through a self-service portal; tax IDs and account formats are validated.
5. A second person approves the record before it is activated.

**In this Atlas's judgement, the bank-detail change is the riskiest single transaction in procurement.** Payment-diversion fraud usually arrives as a
plausible email, sometimes from the supplier's real but compromised mailbox. The FBI's advice for BEC is to "use secondary
channels and/or two-factor authentication to verify requests for changes in account information".[^ic3-psa] In a survey of 465
US treasury practitioners released in April 2026, 74% said their organisation had been affected by BEC in 2025.[^afp-2026] The
figure shows the workflow; SOP-VM-03 in the [reference implementation](#reference-implementation-operating-artefacts) is the
one-page procedure.

**Keep the bank's payee-name check switched on.** The EU Instant Payments Regulation requires banks to offer Verification of
Payee (VoP), a check of the payee's name against the IBAN, before every SEPA credit transfer, instant or not, from 9 October 2025
in the euro area. The answer is match, close match or no match, and the payer can still pay after a warning.[^vop-pwc] Business
payers may opt out for orders sent as a bundle, which is how many AP payment files go, and banks are to tell payers how ignoring a
warning affects the bank's liability and the payer's refund rights.[^vop-pwc][^vop-ecb] So do not waive the check without a documented compensating
control, keep the supplier's legal name equal to the account holder's name, and treat a close match or no match on a recently
changed account as a stop. The UK equivalent is Confirmation of Payee (see the [regulatory map](#regulatory-map-as-of-october-2026)).

::: figure Verifying a supplier bank-detail change before any payment
```mermaid
flowchart TB
  A["`Change request
    arrives`"] --> B{"`Submitted through
    supplier portal?`"}
  B -->|"no: email, phone, letter"| C["`Do not edit the record
    ask supplier to use portal`"]
  B -->|"yes"| D["`Hold payments
    to this supplier`"]
  C --> D
  D --> E["`Call back on a number
    already on file, not
    one in the request`"]
  E --> F{"`Supplier confirms
    new account?`"}
  F -->|"no"| G["`Reject, alert security
    and AP, check mailbox`"]
  F -->|"yes"| H["`Second person approves
    change in the master`"]
  H --> I["`Release held payments;
    first payment monitored,
    bank name check must match`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class D,E,H,I core
  class B,F decision
  class C,G risk
```
Text equivalent: a change request that did not come through the supplier portal (email, phone, letter) is not entered; the
supplier is asked to use the portal. Either way, payments to the supplier are held and the supplier is called back on a number
already on file. If it does not confirm, the change is rejected, security and AP are alerted and the mailbox checked. If it
confirms, a second person approves the change, held payments are released, and the first payment is monitored; the bank's
payee-name check must return a match.
:::

**Acceptance criteria:** 100% of bank changes have a recorded call-back to a pre-existing number and a second approver; no
payment is made to a changed account within the verification window; duplicate-supplier rate trends down.

### Playbook: invoice matching and exceptions

**Trigger:** invoice received. **Owner:** accounts payable.

Oracle's Payables documentation describes two-, three- and four-way matching with percentage and amount tolerances for quantity
and price, and named holds such as "QTY REC" when more is billed than received.[^oracle-ap] A university research foundation's
procedure states the consequence: "payment cannot be made until the hold is resolved or manually released".[^rfsuny]

::: figure Three-way match: the decision an invoice line goes through
```mermaid
flowchart TB
  S["Invoice line"] --> D1{"`Duplicate of an
    earlier invoice?`"}
  D1 -->|"yes"| H1["Hold: DUPLICATE"]
  D1 -->|"no"| D2{"`Valid PO line
    for this supplier?`"}
  D2 -->|"no"| H2["Hold: NO PO"]
  D2 -->|"yes"| D3{"`Price within
    tolerance?`"}
  D3 -->|"no"| H3["Hold: PRICE"]
  D3 -->|"yes"| D4{"`Billed qty within
    ordered and received?`"}
  D4 -->|"no"| H4["Hold: QTY"]
  D4 -->|"yes"| OK["Pass to payment run"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class S,OK core
  class D1,D2,D3,D4 decision
  class H1,H2,H3,H4 risk
```
Text equivalent: each invoice line is checked in order. If it duplicates an earlier invoice, it is held as DUPLICATE. Otherwise,
if there is no valid PO line for this supplier, it is held as NO PO. Otherwise, if the price is outside tolerance, it is held as
PRICE. Otherwise, if the billed quantity exceeds what was ordered or received, it is held as QTY. If all checks pass, the line
goes to the payment run.
:::

**Choosing the match level.**

| Spend type | Match | Why |
|---|---|---|
| Physical goods | Three-way | Receipt proves delivery |
| Goods with quality acceptance (medical, aerospace, regulated parts) | Four-way | Delivery is not acceptance |
| Services with milestones | Three-way with a service entry by the requester | Requester confirms the milestone |
| Subscriptions and fixed fees under contract | Two-way, with periodic usage review | Receipt adds little; review prevents paying for unused seats |
| Utilities, taxes | No-PO, with their own approval | No order exists |

**Tolerances** are policy, not a technical default: too tight and AP drowns in rounding holds, too loose and systematic
overbilling passes. Use *two-sided* limits (percentage **and** absolute amount) so a small percentage on a large line cannot hide
a large overcharge, and never allow quantity over-billing on goods.

**Resolving holds.** Price holds go to the buyer, quantity holds to the receiver, no-PO invoices to the requester for a counted
retrospective approval. AP must not "fix" a hold by editing the PO: whoever approves an exception must not own the clogged queue.

### Playbook: renewals, supplier reviews and offboarding

**Trigger:** a contract enters its notice window, or a supplier is no longer needed. **Owner:** category manager with the
business owner.

1. Keep a renewal calendar, procurement's working view of the term, notice and auto-renewal dates held in LegalOps' CLM record,
   and review it quarterly with budget holders (GitLab reviews a rolling 12-month list each quarter[^gitlab-proc]); start at
   least 90 days before notice deadlines for anything material. Procurement owns the renewal or re-tender decision.
2. Before renewing, check usage (seats, consumption), the last market test, and changes in risk (new data shared, sanctions hits,
   security incidents).
3. Segment suppliers so effort matches importance (GitLab uses four tiers: Strategic, Niche, Commodity, Transactional[^gitlab-proc])
   and hold business reviews on success criteria, issues and utilisation.
4. On exit: send notice as the contract requires, remove access and integrations, recover or delete data, deactivate the
   supplier after the last invoice, and keep the record for the retention period.

### Spend analysis and category management

Build a **spend cube**: every payment or invoice line classified by *supplier* (one parent per legal entity), *category* and
*business unit*, over time.

- **Classify** with a taxonomy: an internal one, or the United Nations Standard Products and Services Code (UNSPSC), four levels
  (segment, family, class, commodity) of two digits each; according to Wikipedia, the UN Development Programme has maintained it
  since 1 January 2025.[^wiki-unspsc]
- **Analyse** concentration, fragmentation (many suppliers per category), the share of spend on PO or contract, and the tail.
- **Act** through category strategies. A widely taught tool is Peter Kraljic's matrix from his 1983 *Harvard Business Review*
  article "Purchasing Must Become Supply Management".[^hbr-kraljic] It places categories on two dimensions, profit impact and supply
  risk, giving four quadrants: non-critical, leverage, bottleneck and strategic items.[^wiki-kraljic]

| Quadrant | Typical strategy | Example (illustrative) |
|---|---|---|
| Non-critical (low impact, low risk) | Simplify: catalogue, card, consolidate suppliers | Office supplies |
| Leverage (high impact, low risk) | Compete: tender, volume consolidation, price benchmarking | Laptops, cloud capacity under contract |
| Bottleneck (low impact, high risk) | Secure supply: buffers, alternatives, longer contracts | A niche spare part with one maker |
| Strategic (high impact, high risk) | Partner: joint planning, executive relationship, exit plan | A core payroll or ERP platform |

Two recorded criticisms: it is designed for categories but often misapplied to suppliers, and it is a snapshot that ages as
markets move.[^wiki-kraljic] Re-plot categories at least yearly.

**Savings: define them before you report them.** GitLab separates *soft savings* (cost avoidance, such as resisting a proposed
price increase) from *hard savings* (a cost decrease from last year, valid only for renewals).[^gitlab-proc] One combined
"savings" number is the commonest way procurement overstates its value.

## Frameworks, regulation and tools

### Methods, standards and frameworks

Separate what is **mandatory** for you (law, your auditors' framework, contract terms) from what is **guidance** you may adopt.

| Framework | Type | What it gives a procurement operation |
|---|---|---|
| GAO Green Book, 2025 revision (GAO-25-107721)[^gao-gb-page] | Mandatory for US federal entities; GAO says non-federal entities may adopt it; it adapts the principles of the Internal Control – Integrated Framework of the Committee of Sponsoring Organizations of the Treadway Commission (COSO)[^gao-gb] | Plain-language control principles: segregation of duties, management override, IT general controls, preventive and detective control examples |
| CIPS Procurement and Supply Cycle[^cips-cycle] | Professional guidance | The 13-step sourcing life cycle with gateway reviews |
| Kraljic matrix[^hbr-kraljic] | Management model | Category segmentation by profit impact and supply risk |
| ISO 20400:2017 Sustainable procurement | Guidance standard | Integrating sustainability into procurement; **not certifiable** ("neither intended nor appropriate for certification purposes", per its steering group)[^iso20400] |
| NIST CSF 2.0, GV.SC outcomes[^nist-csf] | Voluntary framework | Supplier criticality, due diligence and contract requirements for cybersecurity |
| UNSPSC[^wiki-unspsc] | Classification standard | A shared category taxonomy for spend analysis and catalogues |
| GHG Protocol Scope 3, category 1[^ghg-s3] | Accounting standard | Emissions of purchased goods and services from supplier or spend data |
| Peppol[^peppol] | Interoperability framework | Standard e-orders and e-invoices exchanged through accredited providers |

The Green Book was written for US federal agencies (the 2025 revision applies from fiscal year 2026), but it is one of the clearest
free statements of internal-control principles, and GAO describes the update as continuing "harmonization" with COSO's
framework.[^gao-gb] Cite it for principles; use your own auditors' framework for the controls you are tested against.

### Regulatory map (as of October 2026)

Procurement touches many laws. The table is orientation for the jurisdictions named, not legal advice; confirm with counsel.

| Topic | Jurisdiction | What applies | Operational consequence |
|---|---|---|---|
| E-invoicing | EU | The Council adopted the VAT in the Digital Age (ViDA) package on 11 March 2025; mandatory e-invoicing and near real-time reporting for intra-EU transactions apply from 1 July 2030[^vida] | Plan structured e-invoices (for example via Peppol); check earlier national mandates |
| Payment terms | EU | Late Payment Directive 2011/7/EU: public authorities pay within 30 days (60 in very exceptional cases); businesses within 60 days unless expressly agreed and not grossly unfair (Commission FAQ).[^latepay] A 2023 proposal to replace it with a regulation (2023/0323(COD)) still awaited the Council's first-reading position[^latepay-oeil] | Payment-term policy and on-time payment KPI; invoice cycle time matters legally |
| Modern slavery | UK | Organisations doing business in the UK with turnover of £36 million or more publish an annual statement on modern slavery risks in their supply chains[^uk-msa] | Supplier questionnaires, risk-based audits, evidence |
| Supply-chain due diligence | EU | Omnibus I amended the CSDDD; per a law-firm summary, in-scope companies (EU: over 5,000 employees and €1.5 billion turnover) comply from 26 July 2029[^omnibus] | Large companies map suppliers' human-rights and environmental risks; others get questionnaires |
| Sanctions | US (and others) | OFAC regulations do not require a formal sanctions compliance programme, but OFAC strongly encourages organisations subject to US jurisdiction to adopt a risk-based one; its framework lists screening failures such as software not updated for list changes and missed alternative spellings[^ofac] | Screen at onboarding and on list updates; handle alternative spellings |
| Payee verification | EU | Instant Payments Regulation (EU) 2024/886: banks must offer Verification of Payee before SEPA credit transfers, instant or not; euro area from 9 October 2025, other member states by 9 July 2027; business payers may opt out for bundled orders[^vop-pwc][^vop-ecb] | Keep the check on for payment files or record the compensating control; a close match or no match on a changed account stops payment |
| Payee verification | UK | Confirmation of Payee checks a payee's account details against those held by the payee's provider; over 320 organisations offer it. The direction requiring it was due to expire on 1 November 2026; the regulator consulted in July 2026 on removing the expiry (no decision found on 2026-10-23)[^psr-cop] | As in the EU: a mismatch on a changed account stops payment |
| Public procurement | UK | The Procurement Act 2023 and its regulations came into force on 24 February 2025, replacing the Public Contracts Regulations 2015;[^uk-pa-esx] procurements begun under the old rules, and contracts awarded under them, continue under those rules[^uk-pa-trans]; notices go through an enhanced Find a Tender service[^uk-pa-guid] | Statutory procedures and transparency notices; see [GovOps](../govops/) |
| Third-party risk in banking | US | Banking agencies proposed new third-party risk guidance on 15 September 2026 to rescind and replace the 2023 guidance; comments close 16 November 2026[^fr-tprm] | Banks: keep the current guidance until final; risk-tiered due diligence |

### Tooling landscape

Vendor-neutral first: these are the jobs tools do, then examples verified for this page.

| Tool category | Job | Examples (as of October 2026) | Selection criteria | Risks |
|---|---|---|---|---|
| Intake and orchestration | One front door; parallel reviews; status | Zip[^zip-i2p] | Form logic, ERP integration | A second source of truth if not integrated |
| Procure-to-pay suite | Catalogues, requisitions, POs, receipts, invoices, supplier portal | Coupa (a "cloud-based purchasing and payment platform" in GitLab's handbook[^gitlab-proc]); SAP Ariba; Oracle procurement | Matching controls, supplier adoption, ERP integration | Long implementations; lock-in |
| ERP purchasing and payables | Ledger, GR/IR, matching, payments | SAP, Oracle, Microsoft Dynamics; open-source Odoo (a "3-way matching" setting and a "Should Be Paid" status[^odoo]) | Accounting fit, matching levels | Poor requester experience alone |
| Sourcing and RFx | Events, scoring, awards | Modules in the suites above; standalone tools | Scoring audit trail, supplier experience | Overkill for small teams |
| Supplier risk and screening | Sanctions, financial, security, ESG data | Screening services, questionnaires | List coverage and updates, false positives | Alert fatigue |
| E-invoicing network | Structured invoices | Peppol access points; suite networks | Your suppliers' countries | Mandates differ by country |
| Spend analytics | Classification, cube, dashboards | Suite analytics; BI on a warehouse | Classification accuracy, supplier hierarchy | Polished dashboards on dirty data |

SAP Ariba and Oracle are named as examples only (their product pages could not be opened for this page). Re-check any
capability against current documentation before you buy.

### Automation and AI

Automation helps most where the work is high-volume and rule-based: invoice capture, matching, duplicate detection, routing,
and supplier self-service. The Green Book describes automated approvals that "authorize transactions without human intervention"
for lower-risk items, paired with rule maintenance and manual review of flagged issues.[^gao-gb] That is a good template: automate
the decision, keep a human owner for the rules and the exceptions.

Language models help (as of October 2026, with human review) to structure free-text requests, suggest category codes, summarise
security questionnaires, extract fields from non-standard invoices and draft RFx documents. They are risky for deciding to pay,
approving bank-detail changes or accepting supplier risk: a model that reads "our bank has changed" is exactly the target of
payment-diversion fraud.

In the AFP survey released in April 2026, 17% of organisations said they use AI to combat payments fraud.[^afp-2026] Test any AI
feature on exceptions you already resolved (precision and recall), and log its suggestions as evidence, not decisions.

## ProcurementOps in practice

### Reference implementation: operating artefacts

For an **illustrative organisation** of 1,200 employees, 2,500 active suppliers and 40,000 invoices a year, with one ERP and an
intake tool. Adjust thresholds to your own volumes and risk.

**Artefact 1: the authority matrix as configuration,** kept in a reviewed file so changes are visible and approvable.

_Example status: syntax-checked as YAML by the Atlas validator; not executed against any product (illustrative values)._

```yaml
# approval-matrix.yaml: who may approve spend, sign and pay (illustrative values, USD)
version: 2026-10
currency: USD
# mode: all = every listed person must approve; mode: any = one of them is enough
spend_approval:            # total contract value, including renewals and options
  - max: 5000
    mode: all
    approvers: [budget_holder]
  - max: 50000
    mode: all
    approvers: [budget_holder, department_head]
  - max: 250000
    mode: all
    approvers: [budget_holder, department_head, finance_director]
  - max: null              # no upper limit
    mode: all
    approvers: [budget_holder, department_head, cfo]
sourcing:
  - max: 25000
    route: single_quote
  - max: 100000
    route: two_quotes
  - max: 250000
    route: rfp_business_led
  - max: null
    route: rfp_procurement_led
signature_authority:
  - max: 100000
    mode: any
    signers: [procurement_director]
  - max: null
    mode: any               # either one signs
    signers: [cfo, general_counsel]
mandatory_reviews:
  personal_data_shared: [privacy, security]
  system_access: [security, it]
  new_supplier: [sanctions_screening, vendor_data]
  government_interaction: [ethics_compliance]
segregation:
  - [maintain_vendor, release_payment]
  - [create_po, receive_goods]
  - [post_invoice, release_payment]
  - [create_requisition, approve_requisition]
```

**Artefact 2: intake form fields and the routing they drive.**

| Field | Values | Drives |
|---|---|---|
| What are you buying? | Category picker (taxonomy) | Category owner, catalogue suggestion |
| Total contract value | Amount and currency, incl. renewals | Approvers and sourcing route |
| Term and renewal | Start, end, auto-renewal, notice period | Renewal calendar |
| Supplier | Existing (search) or new (legal name, website) | Onboarding and sanctions screening |
| Data the supplier will receive | None, internal, confidential, personal | Security and privacy review |
| Access to our systems or premises | Yes or no | Security and IT review |
| Government interaction or recommendation | Yes or no | Ethics and compliance review |
| Needed by | Date, plus business impact if missed | Urgency rule |
| Quotes and documents | Upload | Buyer review |

**Artefact 3: matching and tolerance policy.**

_Example status: syntax-checked as YAML; illustrative policy values._

```yaml
# matching-policy.yaml
default_match: three_way
by_category:
  subscriptions_under_contract: two_way      # plus quarterly usage review
  regulated_components: four_way             # inspection acceptance required
  utilities_taxes_statutory: no_po           # named exceptions only
tolerances:
  price:
    over_percent: 2.0       # both limits must hold
    over_amount: 0.50       # per unit, document currency
  quantity:
    over_percent: 0.0       # never pay for more than received
  freight_and_charges:
    unplanned_max: 100.00   # above this, buyer approval
duplicate_check:
  keys: [supplier, normalised_invoice_number]
  fuzzy_keys: [supplier, amount, invoice_date_within_days: 7]
hold_owners:
  PRICE: buyer
  QTY_REC: receiver
  NO_PO: requester
  DUPLICATE: accounts_payable
```

**Artefact 4: standard operating procedure for supplier bank-detail changes** (one page).

```text
SOP-VM-03  Supplier bank-detail change            Owner: Vendor data lead
Purpose    Prevent payment diversion; every change verified out of band.
Scope      Any change to bank account, beneficiary name or payment address.
Steps
 1. Accept changes only through the supplier portal; reply to email or
    phone requests with portal instructions. Do not edit the record.
 2. Place a payment block on the supplier at once.
 3. Call the supplier on a phone number already in the master record or
    the contract, never one given in the request. Speak to a known contact.
 4. Record date, time, number called, person confirming, account last 4.
 5. A second vendor-data analyst approves; the requester cannot approve.
 6. Remove the block. Flag the first payment to the new account for
    treasury review before release. Keep the bank's payee-name check
    (VoP or CoP) on: a close match or no match stops the payment.
 7. If the supplier denies the request: reject, inform security and AP,
    check recent payments, and treat it as a suspected BEC incident.
Evidence   Call log, approvals and before/after values kept for 7 years
           (or your retention rule).
Metric     % of changes with call-back evidence (target 100%).
```

**Artefact 5: monthly operations scorecard** (the full KPI definitions are in [Metrics and KPIs](#metrics-and-kpis)).

| KPI | Target | This month | Trend | Owner | Action if off target |
|---|---|---|---|---|---|
| Median request-to-PO cycle time (days) | ≤ 5 | 7.5 | Worse | Proc. ops | Find slowest review step |
| PO compliance (% of addressable spend on PO before invoice) | ≥ 90% | 86% | Better | Proc. ops | Target top 10 no-PO suppliers |
| First-pass match rate | ≥ 80% | 74% | Flat | AP | Analyse hold reasons |
| Bank changes with call-back evidence | 100% | 100% | Flat | Vendor data | — |
| Duplicate payments made (count, value), from the quarterly review | 0 paid; review run | 2 / 3,400; review run | — | AP | Recover; root-cause both |
| Requests breaching SLA | ≤ 10% | 18% | Worse | Proc. ops | Staff legal review queue |

### Hands-on labs

Four labs on **synthetic data only** (Python 3.8+ standard library and bash; no accounts, no cost). Each was run on 2026-10-23 as
printed (Python 3.8.10, Ubuntu Linux); expected outputs are copied from those runs.

::: warning Never practise on real supplier or payment data
Real vendor master data contains bank details and personal data of sole traders. Use synthetic files like these; do not copy
production exports to a laptop.
:::

#### Lab 1 (beginner): build a three-way match

**Objective.** Implement two- and three-way matching with price and quantity tolerances and a duplicate check, and see why each
hold fires. **Prerequisites.** Python 3.8+, bash. **Time.** 30 minutes. **Risk.** None (synthetic data).

1. Create the folder and three files: PO lines, receipts and invoices.

_Example status: verified by execution on 2026-10-23 (bash, Linux)._

```bash
mkdir -p ~/procurement-labs/lab1 && cd ~/procurement-labs/lab1
cat > po_lines.csv <<'CSV'
po,line,vendor,item,qty,unit_price,match
PO-1001,1,V-ACME,Laptop 14in,10,1200.00,3-way
PO-1001,2,V-ACME,Docking station,10,180.00,3-way
PO-1002,1,V-NORTH,Safety gloves (box),200,6.50,3-way
PO-1003,1,V-CLOUDX,SaaS licence (annual),50,240.00,2-way
PO-1004,1,V-BOLT,M8 bolts (box),40,12.00,3-way
CSV
cat > receipts.csv <<'CSV'
po,line,qty_received,received_on
PO-1001,1,10,2026-10-02
PO-1001,2,8,2026-10-02
PO-1002,1,200,2026-10-05
PO-1004,1,40,2026-10-07
CSV
cat > invoices.csv <<'CSV'
invoice,vendor,po,line,qty,unit_price
INV-881,V-ACME,PO-1001,1,10,1200.00
INV-882,V-ACME,PO-1001,2,10,180.00
INV-0457,V-NORTH,PO-1002,1,200,6.60
INV-0458,V-NORTH,PO-1002,1,200,6.50
CX-3301,V-CLOUDX,PO-1003,1,50,240.00
B-77,V-BOLT,PO-1004,1,40,12.95
INV881,V-ACME,PO-1001,1,10,1200.00
Z-1,V-ZED,,,1,4999.00
CSV
```

2. Save the matcher as `match.py`.

_Example status: verified by execution on 2026-10-23 (Python 3.8.10, standard library)._

```python
"""Two- and three-way invoice matching with tolerances (standard library only)."""
import csv
import re
from collections import defaultdict

PRICE_TOL_PCT = 2.0      # unit price may exceed the PO price by at most 2 %
PRICE_TOL_ABS = 0.50     # ... and by at most 0.50 per unit (both must hold)
QTY_TOL_PCT = 0.0        # no over-billing of quantity


def load(name):
    with open(name, newline="") as f:
        return list(csv.DictReader(f))


po = {(r["po"], r["line"]): r for r in load("po_lines.csv")}
received = defaultdict(float)
for r in load("receipts.csv"):
    received[(r["po"], r["line"])] += float(r["qty_received"])

billed = defaultdict(float)   # quantity already passed for payment, per PO line
seen = set()                  # (vendor, normalised invoice number)


def norm(number):
    """INV-0881, inv 881 and INV881 are the same document."""
    digits = re.sub(r"[^0-9A-Z]", "", number.upper())
    return re.sub(r"^([A-Z]*)0+", r"\1", digits)


for inv in load("invoices.csv"):
    key = (inv["po"], inv["line"])
    qty, price = float(inv["qty"]), float(inv["unit_price"])
    holds = []
    dup_key = (inv["vendor"], norm(inv["invoice"]))
    if dup_key in seen:
        holds.append("DUPLICATE")
    seen.add(dup_key)
    line = po.get(key)
    if line is None:
        holds.append("NO_PO")
    else:
        if line["vendor"] != inv["vendor"]:
            holds.append("VENDOR_MISMATCH")
        po_price = float(line["unit_price"])
        over = price - po_price
        if over > 0 and (over > PRICE_TOL_ABS or 100 * over / po_price > PRICE_TOL_PCT):
            holds.append("PRICE")
        limit = float(line["qty"]) * (1 + QTY_TOL_PCT / 100)
        if billed[key] + qty > limit:
            holds.append("QTY_ORD")
        if line["match"] == "3-way" and billed[key] + qty > received[key]:
            holds.append("QTY_REC")
    if not holds:
        billed[key] += qty
    status = "PASS" if not holds else "HOLD " + ",".join(holds)
    print(f"{inv['invoice']:<9} {inv['vendor']:<9} {inv['po'] or '-':<8} "
          f"{qty * price:>10.2f}  {status}")
```

3. Run it: `python3 match.py`.

**Expected output** (copied from the 2026-10-23 run):

```text
INV-881   V-ACME    PO-1001    12000.00  PASS
INV-882   V-ACME    PO-1001     1800.00  HOLD QTY_REC
INV-0457  V-NORTH   PO-1002     1320.00  PASS
INV-0458  V-NORTH   PO-1002     1300.00  HOLD QTY_ORD,QTY_REC
CX-3301   V-CLOUDX  PO-1003    12000.00  PASS
B-77      V-BOLT    PO-1004      518.00  HOLD PRICE
INV881    V-ACME    PO-1001    12000.00  HOLD DUPLICATE,QTY_ORD,QTY_REC
Z-1       V-ZED     -           4999.00  HOLD NO_PO
```

**Validation.** INV-882 bills 10 docking stations but 8 were received. INV-0457 is 0.10 (1.5%) over the PO price, inside both
tolerances. INV-0458 re-bills the gloves under a *different invoice number*: the duplicate check misses it, quantity matching
catches it. CX-3301 is two-way matched. B-77 is 0.95 (7.9%) over price. INV881 is INV-881 retyped. Z-1 has no PO.

**Troubleshooting.** `KeyError: 'po'`: a mistyped CSV header. `ValueError: could not convert string to float`: a blank quantity
or price. Every line on `QTY_REC`: receipts use different PO or line identifiers.

**Teardown.** `rm -r ~/procurement-labs/lab1`.

#### Lab 2 (beginner): a spend cube and the tail

**Objective.** Classify payments into categories, compute the share of spend on PO, and find the suppliers that make up the head
and tail of spend. **Prerequisites.** Python 3.8+. **Time.** 20 minutes. **Risk.** None.

1. Create the payment extract.

_Example status: verified by execution on 2026-10-23 (bash, Linux)._

```bash
mkdir -p ~/procurement-labs/lab2 && cd ~/procurement-labs/lab2
cat > spend.csv <<'CSV'
paid_on,supplier,description,amount,po
2026-07-03,CloudCo Inc,Cloud hosting July,48000,PO-2001
2026-07-09,Northwind Office,Paper and toner,1200,
2026-07-15,Acme Laptops Ltd,Laptops x20,26000,PO-2002
2026-07-21,Brightlearn,Training workshop,4500,
2026-07-28,Fieldwise Consulting,Security assessment,22000,PO-2003
2026-08-02,CloudCo Inc,Cloud hosting August,51000,PO-2001
2026-08-06,Northwind Office,Chairs x6,2100,
2026-08-12,Acme Laptops Ltd,Docking stations,3600,PO-2002
2026-08-19,Pixel Print,Event banners,900,
2026-08-23,Fieldwise Consulting,Pen test retest,6000,PO-2003
2026-08-30,QuickCater,Team lunch,650,
2026-09-04,CloudCo Inc,Cloud hosting September,53000,PO-2001
2026-09-10,Northwind Office,Paper,800,
2026-09-14,Brightlearn,E-learning seats,3000,
2026-09-18,Saasly,Survey tool annual,7800,
2026-09-22,Dataport,Data enrichment,9500,
2026-09-26,QuickCater,Offsite catering,2400,
2026-09-29,Pixel Print,Brochures,1300,
CSV
```

2. Save the analysis as `cube.py`.

_Example status: verified by execution on 2026-10-23 (Python 3.8.10, standard library)._

```python
"""A small spend cube: classify, aggregate, find tail spend and off-PO spend."""
import csv
from collections import defaultdict

RULES = [  # first matching keyword wins; order matters
    ("hosting", "IT / Cloud"), ("laptop", "IT / Hardware"),
    ("docking", "IT / Hardware"), ("tool", "IT / Software"),
    ("data", "IT / Software"), ("security", "Professional services"),
    ("pen test", "Professional services"), ("training", "People / Learning"),
    ("e-learning", "People / Learning"), ("paper", "Facilities / Office"),
    ("chairs", "Facilities / Office"), ("banner", "Marketing / Print"),
    ("brochure", "Marketing / Print"), ("lunch", "Travel & events"),
    ("catering", "Travel & events"),
]


def classify(description):
    d = description.lower()
    for keyword, category in RULES:
        if keyword in d:
            return category
    return "UNCLASSIFIED"


with open("spend.csv", newline="") as f:
    rows = list(csv.DictReader(f))

total = sum(float(r["amount"]) for r in rows)
by_cat, by_sup = defaultdict(float), defaultdict(float)
sups_in_cat = defaultdict(set)
on_po = 0.0
for r in rows:
    amount, cat = float(r["amount"]), classify(r["description"])
    by_cat[cat] += amount
    by_sup[r["supplier"]] += amount
    sups_in_cat[cat].add(r["supplier"])
    on_po += amount if r["po"] else 0.0

print(f"Total spend {total:,.0f} | on PO {100 * on_po / total:.1f}% | "
      f"suppliers {len(by_sup)}")
print("\nCategory                 Spend   Share  Suppliers")
for cat, amount in sorted(by_cat.items(), key=lambda x: -x[1]):
    share = 100 * amount / total
    print(f"{cat:<22} {amount:>8,.0f} {share:>6.1f}%  {len(sups_in_cat[cat])}")

print("\nPareto: suppliers that make up the first 80% of spend")
running, head = 0.0, []
for sup, amount in sorted(by_sup.items(), key=lambda x: -x[1]):
    if running < 0.8 * total:
        head.append(sup)
    running += amount
tail = [s for s in by_sup if s not in head]
tail_spend = sum(by_sup[s] for s in tail)
print(f"head {len(head)} suppliers: {', '.join(head)}")
print(f"tail {len(tail)} suppliers = {100 * tail_spend / total:.1f}% of spend")
```

3. Run `python3 cube.py`.

**Expected output** (copied from the 2026-10-23 run):

```text
Total spend 243,750 | on PO 86.0% | suppliers 9

Category                 Spend   Share  Suppliers
IT / Cloud              152,000   62.4%  1
IT / Hardware            29,600   12.1%  1
Professional services    28,000   11.5%  1
IT / Software            17,300    7.1%  2
People / Learning         7,500    3.1%  1
Facilities / Office       4,100    1.7%  1
Travel & events           3,050    1.3%  1
Marketing / Print         2,200    0.9%  1

Pareto: suppliers that make up the first 80% of spend
head 3 suppliers: CloudCo Inc, Acme Laptops Ltd, Fieldwise Consulting
tail 6 suppliers = 14.0% of spend
```

**Validation.** Check by hand that 152,000 / 243,750 = 62.4%. The loop adds suppliers until 80% is reached, so the head ends at
86%. Here the off-PO spend (14%) happens to equal the tail; in real data they differ, and both lists are worth reviewing.

**Questions to answer.** Which category should be a catalogue? Which supplier is a concentration risk? Is "Data enrichment"
software? Keyword rules drift, so classification needs an owner.

**Troubleshooting.** `UNCLASSIFIED` means no keyword matched: add a rule. Wrong totals usually mean thousands separators.

**Teardown.** `rm -r ~/procurement-labs/lab2`.

#### Lab 3 (intermediate): find segregation-of-duties conflicts

**Objective.** Detect conflicting permissions (a preventive gap) and transactions where one person did two incompatible steps (a
detective finding). **Prerequisites.** Python 3.8+. **Time.** 25 minutes. **Risk.** None.

1. Create a role export and an event log.

_Example status: verified by execution on 2026-10-23 (bash, Linux)._

```bash
mkdir -p ~/procurement-labs/lab3 && cd ~/procurement-labs/lab3
cat > roles.csv <<'CSV'
user,permission
asha,create_requisition
asha,approve_requisition
ben,create_po
ben,receive_goods
chen,maintain_vendor
chen,release_payment
dana,maintain_vendor
eli,post_invoice
eli,release_payment
fay,create_po
CSV
cat > events.csv <<'CSV'
doc,step,user
PO-3001,requested,asha
PO-3001,approved,asha
PO-3002,requested,gus
PO-3002,approved,asha
PO-3002,po_created,ben
PO-3002,received,ben
PO-3003,requested,gus
PO-3003,approved,hal
PO-3003,po_created,fay
PO-3003,received,gus
CSV
```

2. Save `sod.py`.

_Example status: verified by execution on 2026-10-23 (Python 3.8.10, standard library)._

```python
"""Find segregation-of-duties conflicts in role assignments and in actual transactions."""
import csv
from collections import defaultdict

# Pairs one person should not hold together (adapt to your own risk assessment).
CONFLICTS = {
    ("maintain_vendor", "release_payment"): "can create a payee and pay it",
    ("create_po", "receive_goods"): "can order and confirm receipt of the same goods",
    ("post_invoice", "release_payment"): "can enter an invoice and pay it",
    ("create_requisition", "approve_requisition"): "may approve own requests",
}
# Steps of one document that must be done by different people.
STEP_RULES = [("requested", "approved"), ("po_created", "received")]

perms = defaultdict(set)
with open("roles.csv", newline="") as f:
    for r in csv.DictReader(f):
        perms[r["user"]].add(r["permission"])

print("Role conflicts (preventive control gaps):")
for user in sorted(perms):
    for (a, b), why in CONFLICTS.items():
        if a in perms[user] and b in perms[user]:
            print(f"  {user:<5} {a} + {b}: {why}")

steps = defaultdict(dict)
with open("events.csv", newline="") as f:
    for r in csv.DictReader(f):
        steps[r["doc"]][r["step"]] = r["user"]

print("Transaction conflicts (detective review):")
for doc in sorted(steps):
    for a, b in STEP_RULES:
        who = steps[doc]
        if a in who and b in who and who[a] == who[b]:
            print(f"  {doc}: '{a}' and '{b}' both by {who[a]}")
```

3. Run `python3 sod.py`.

**Expected output** (copied from the 2026-10-23 run):

```text
Role conflicts (preventive control gaps):
  asha  create_requisition + approve_requisition: may approve own requests
  ben   create_po + receive_goods: can order and confirm receipt of the same goods
  chen  maintain_vendor + release_payment: can create a payee and pay it
  eli   post_invoice + release_payment: can enter an invoice and pay it
Transaction conflicts (detective review):
  PO-3001: 'requested' and 'approved' both by asha
  PO-3002: 'po_created' and 'received' both by ben
```

**Validation.** Four users hold conflicting pairs; two conflicts were actually used. In PO-3003 gus requested *and* received,
which is normal for services and not a conflict under these rules: the rule list is a risk decision.

**Troubleshooting.** No output under a heading means no conflicts. In real ERPs, map conflicts to transaction codes or API
scopes, not role names.

**Extend it.** Add a "mitigated" list with the compensating control and reviewer for accepted conflicts (common in teams too small
to split duties, as the Green Book allows[^gao-gb]).

**Teardown.** `rm -r ~/procurement-labs/lab3`.

#### Lab 4 (advanced): vendor master red flags

**Objective.** Find near-duplicate suppliers, a supplier sharing a bank account with an employee, and recent bank changes not
made through the portal, with the amount paid since. **Prerequisites.** Python 3.8+. **Time.** 30 minutes. **Risk.** None; the
bank account values are fake test strings, not valid IBANs.

1. Create the extracts.

_Example status: verified by execution on 2026-10-23 (bash, Linux)._

```bash
mkdir -p ~/procurement-labs/lab4 && cd ~/procurement-labs/lab4
cat > vendors.csv <<'CSV'
vendor_id,name,tax_id,iban,bank_changed_on,changed_via
V-100,Acme Laptops Ltd,GB111,GB00TEST0001,2024-02-01,portal
V-101,ACME Laptops Limited,GB111,GB00TEST0009,2026-10-01,email
V-102,Northwind Office,GB222,GB00TEST0002,2023-06-12,portal
V-103,Fieldwise Consulting,GB333,GB00TEST0003,2026-09-30,email
V-104,Bright Learn Ltd,GB444,GB00TEST0042,2025-01-15,portal
CSV
cat > employees.csv <<'CSV'
employee_id,iban
E-7,GB00TEST0042
E-8,GB00TEST0777
CSV
cat > payments.csv <<'CSV'
paid_on,vendor_id,amount
2026-10-03,V-101,18400
2026-10-04,V-103,22000
2026-10-05,V-102,800
CSV
```

2. Save `vendor_flags.py`.

_Example status: verified by execution on 2026-10-23 (Python 3.8.10, standard library)._

```python
"""Vendor master red flags: duplicates, shared bank accounts, risky bank changes."""
import csv
import re
from collections import defaultdict
from datetime import date

TODAY = date(2026, 10, 6)
RECENT_DAYS = 30
STOP = {"ltd", "limited", "inc", "llc", "gmbh", "plc", "the", "co"}


def load(name):
    with open(name, newline="") as f:
        return list(csv.DictReader(f))


def key(name):
    words = re.sub(r"[^a-z0-9 ]", " ", name.lower()).split()
    return " ".join(w for w in words if w not in STOP)


vendors = load("vendors.csv")
staff_ibans = {e["iban"]: e["employee_id"] for e in load("employees.csv")}
payments = load("payments.csv")

groups = defaultdict(list)
for v in vendors:
    groups[("name", key(v["name"]))].append(v["vendor_id"])
    groups[("tax_id", v["tax_id"])].append(v["vendor_id"])
    groups[("iban", v["iban"])].append(v["vendor_id"])
for (kind, value), ids in sorted(groups.items()):
    if len(ids) > 1:
        print(f"DUPLICATE {kind}={value}: {', '.join(ids)}")

for v in vendors:
    if v["iban"] in staff_ibans:
        print(f"EMPLOYEE BANK {v['vendor_id']} shares an account with "
              f"{staff_ibans[v['iban']]}")
    changed = date.fromisoformat(v["bank_changed_on"])
    age = (TODAY - changed).days
    if age <= RECENT_DAYS and v["changed_via"] != "portal":
        since = sum(float(p["amount"]) for p in payments
                    if p["vendor_id"] == v["vendor_id"]
                    and date.fromisoformat(p["paid_on"]) >= changed)
        print(f"RISKY CHANGE {v['vendor_id']} bank changed {age} days ago via "
              f"{v['changed_via']}; paid since: {since:,.0f}")
```

3. Run `python3 vendor_flags.py`.

**Expected output** (copied from the 2026-10-23 run):

```text
DUPLICATE name=acme laptops: V-100, V-101
DUPLICATE tax_id=GB111: V-100, V-101
RISKY CHANGE V-101 bank changed 5 days ago via email; paid since: 18,400
RISKY CHANGE V-103 bank changed 6 days ago via email; paid since: 22,000
EMPLOYEE BANK V-104 shares an account with E-7
```

**Validation.** V-101 is the classic pattern: a second record for a real supplier, with a new bank account from an email, paid
within days. V-103's bank was changed by email. V-104 may be a conflict of interest, a shell company or a declared family
business; the flag starts an inquiry, not an accusation.

**Troubleshooting.** Matching employee bank data requires a lawful basis and a privacy review in many jurisdictions; run it inside
the finance or audit function with access controls, never as an ad hoc export. Name normalisation is crude: extend the stop-word
list for your countries' legal forms.

**Teardown.** `rm -r ~/procurement-labs` (removes all four labs).

### Use cases and scenarios

The first case is a sourced description of documented practice; the others are clearly labelled illustrative scenarios.

**1. Sourced: a remote-first software company buying mostly SaaS and services (GitLab).** *Problem:* many requesters and SaaS
tools, each purchase needing security, privacy, legal and finance input. *Method (GitLab's public handbook, modified
2026-09-13):* one intake system (Zip) whose first page asks anticorruption gating questions; specialist reviews in parallel with
legal review, each with a published target time; suppliers register their own bank and tax data in Coupa; the PO is released only
after signature; quarterly renewal reviews and a three-year market test.[^gitlab-proc] *Trade-offs:* requests take "5 days to 3+
weeks" by GitLab's own estimate, trading speed for assurance; no outcome metrics are published, so effectiveness cannot be judged
from outside.
*Success criteria to adopt:* SLA attainment per review, no work before contract, renewals decided before notice dates.

::: example Illustrative scenario 2: a manufacturer moving direct materials to four-way matching
A medical-device maker inspects every batch of machined parts, but AP pays on three-way match, so suppliers are paid for parts
that later fail inspection. **Method:** set inspection-required on PO lines for regulated part families (four-way match), so the
QUALITY hold blocks payment for rejected quantities; give quality engineers a daily list of held invoices; agree a contractual
right to short-pay rejects. **Trade-offs:** more holds and disputes at first; inspection backlog becomes a payment bottleneck.
**Success metrics:** value paid for later-rejected parts (near zero), days to resolve QUALITY holds. **Pitfall:** four-way
matching for consumables too, which floods the queue.
:::

::: example Illustrative scenario 3: a university fixing tail spend with cards and catalogues
A university sends thousands of low-value invoices for lab consumables through the same PO-and-match route as large purchases;
researchers wait weeks. **Method:** find the tail with a spend cube (Lab 2); move frequent categories to punch-out catalogues with
contracted prices; issue purchasing cards with merchant-category blocks and a second-person monthly review; keep POs for equipment
and services. **Trade-offs:** cards move control after the purchase, so the monthly review must happen and be sampled. **Success
metrics:** time to order, invoices per AP analyst, card exceptions per 1,000 transactions.
:::

## Measurement, risk and cost

### Metrics and KPIs

Measure **flow** (is buying fast?), **control** (is money protected?), **coverage** (how much spend is managed?) and **data**
(can we trust the records?). Review them together; each family can be gamed if it is reviewed alone.

| KPI | Definition and formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| Request-to-PO cycle time | Median and 90th percentile of (PO release − request submission), by route | Intake and ERP timestamps | Averages hide the tail; show paused clocks | Weekly |
| PO compliance | Spend on invoices whose PO was created **before** the invoice date ÷ addressable spend (excluding the no-PO list); the rest is maverick spend | ERP invoices and POs | Counting after-the-fact POs as compliant | Monthly |
| After-the-fact PO rate | POs created on or after the invoice date ÷ all POs | ERP | Teams create POs just to clear holds | Monthly |
| First-pass match rate | Invoice lines matched with no hold on first attempt ÷ PO-backed invoice lines | AP system | Loose tolerances inflate it | Weekly |
| Touchless invoice rate | Invoices posted and approved with no human action ÷ all invoices | AP system | Touchless is not the same as correct; sample them | Monthly |
| On-time payment | Invoices paid by the due date ÷ invoices paid | AP | Paying early to hit the metric costs cash | Monthly |
| Duplicate payments | Count and value of duplicates paid, found by a post-payment review, and value recovered | Recovery reviews, Lab 1 style checks | Zero found may mean nobody looked: also report that the review ran | Quarterly |
| GR/IR ageing | Value and count of GR/IR items older than 60 or 90 days, split into receipts without invoice and invoices without receipt | ERP GR/IR clearing account | Old items written off instead of investigated | Monthly |
| Spend under management | Spend through contracts, catalogues or competitive awards ÷ addressable spend | Spend cube | Definitions vary; publish yours | Quarterly |
| Supplier master health | Duplicate records, records missing tax ID, inactive > 18 months, as % of active records | Vendor master | Deactivation backlog | Monthly |
| Bank changes verified | Changes with call-back evidence and second approver ÷ all bank changes | Change log | Must be 100%; anything less is an incident | Monthly |
| Open SoD conflicts | Users with unmitigated conflicting permissions | Access review (Lab 3 style) | Mitigations that nobody performs | Quarterly |
| Savings | Hard savings and cost avoidance, reported separately | Award records | Mixing them; claiming list-price discounts | Quarterly |

**Spend under management** has a defined, tiered meaning in some settings, for example US federal category management, where
OMB memorandum M-19-13 (2019) sets agencies goals for it and points to GSA's tracking dashboard.[^omb-m1913] Elsewhere, write
your formula down before you report it.

**Worked calculation (illustrative month).** An organisation records this month:

- Addressable spend 8,400,000; of that, 6,900,000 on invoices with a PO created before the invoice date, and 600,000 on
  after-the-fact POs; the rest has no PO.
- 5,200 PO-backed invoice lines, of which 3,900 passed matching first time.
- 6,000 invoices in total, of which 2,700 were posted and approved with no human touch.
- Request-to-PO times for 400 requests: median 4.0 days, 90th percentile 19.0 days.
- 38 bank-detail changes, 36 with call-back evidence.

Then:

- PO compliance = 6,900,000 ÷ 8,400,000 = **82.1%** (the after-the-fact 600,000 is *not* compliant; counting it would show 89.3%).
- First-pass match rate = 3,900 ÷ 5,200 = **75.0%**.
- Touchless rate = 2,700 ÷ 6,000 = **45.0%**.
- Cycle time: the 4-day median looks healthy; the 19-day 90th percentile is where the complaints come from.
- Bank changes verified = 36 ÷ 38 = **94.7%**: two incidents to investigate today, not a trend to improve next quarter.

**Setting targets.** Baseline for a quarter first. Improve flow by removing waiting time (parallel reviews, catalogues), not by
loosening controls; control metrics such as bank-change verification are 100% by definition. The classic vanity metric is
"savings" against a supplier's opening quote.

### Fraud, security and compliance

**Where fraud happens in buying.** In the ACFE's 2024 study, 109 cases (7%) were committed by purchasing staff, median loss
$143,000; corruption appeared in 79% of them and billing schemes in 33% (schemes overlap). Frauds by three or more perpetrators
had a median loss of $329,000 against $75,000 for one, and the median fraud lasted 12 months.[^acfe] These are cases investigated
by certified fraud examiners, not a random sample.

| Risk | Signal | Preventive control | Detective control | Owner |
|---|---|---|---|---|
| Fictitious supplier (shell company) | No web presence, PO box address, bank shared with an employee | Tax-ID validation; second approver | Lab 4 checks (with privacy approval) | Vendor data |
| Inflated or duplicate invoices | Price creep, same amount repeated, invoice numbers retyped | Three-way match with tight tolerances; duplicate check | Post-payment recovery review | AP |
| Kickbacks and conflicts of interest | One buyer always awards one supplier; specs written around a product | Evaluation panels; declarations of interest; rotation | Award-pattern analytics; tips | Procurement lead |
| Payment diversion (BEC) | Bank change by email; urgency; account in a new country | Portal-only changes; call-back; payee-name check | First-payment review | Vendor data, treasury |
| Purchase splitting | Several invoices just below an approval or bid threshold | Thresholds on total contract value, not per invoice | Split-purchase analytics | Proc. ops |
| Management override | Senior person instructs an urgent exception | Written urgency rule; exceptions logged | Monthly review of all bypasses by finance | CFO, audit |
| Sanctions breach | Supplier or owner on a list; alternative spellings | Screening at onboarding | Re-screening on list updates[^ofac] | Compliance |

Tips are the main way fraud is found in the ACFE data (43% of cases), and external sources such as customers, vendors and
competitors gave about one-third of tips,[^acfe] so tell suppliers in your terms how to report concerns, and protect the channel.

**Security and privacy.** The procurement system holds bank details and sole traders' personal data: apply least privilege,
log every master-data change, and review access and SoD on actual permissions quarterly (GAO: no one individual should control
"all critical stages of a process"[^gao-gb]). Put supplier security and privacy review before signature; NIST CSF 2.0 asks that
requirements be "integrated into contracts and other types of agreements" (GV.SC-05).[^nist-csf]

**Compliance and evidence.** Auditors of financial-reporting controls typically test approvals against the authority matrix,
matching holds and supplier-change approvals. Keep that evidence in the system, not in inboxes, for the retention period your tax
and company law sets.

### Cost, capacity and sustainability

**Process cost.** Mostly people time. Calculate your own cost per PO and per invoice (team cost ÷ volume) and track it with
quality, because cost per invoice falls fastest when nobody checks anything. Published benchmarks are mostly paywalled and
definition-dependent, so none is quoted here.

**Capacity planning.** Model the queues: requests per week by route, review time per specialist, invoices per AP analyst per day
including exception handling. The bottleneck is usually a specialist review (legal or security) rather than procurement itself;
GitLab's published targets show legal review alone ranging from three to five days for renewals with existing vendors to one to
three weeks or more for new ones.[^gitlab-proc] Staff the bottleneck, or cut its load with standard terms.

**Working capital.** Payment terms are a cash lever, within legal limits (in the EU, 60 days business-to-business unless
expressly agreed and not grossly unfair; see the [regulatory map](#regulatory-map-as-of-october-2026)).[^latepay] Two more
levers need a fast, clean P2P process. An *early-payment discount* such as 2/10 net 30 (2% off if paid in 10 days, else due in 30) is worth taking when
your cost of cash is below its annualised value: forgoing 2% to keep cash 20 more days costs about 2/98 × 365/20 ≈ 37% a year
(illustrative arithmetic), and only invoices matched inside the window can earn it. *Supply-chain finance* (reverse factoring)
lets a bank pay suppliers early against invoices the buyer has approved, while the buyer pays the bank on the original due date.
Accounting standards now ask buyers to disclose it: under US GAAP, ASU 2022-04 requires the programme's key terms,
confirmed amounts outstanding at period end and a yearly rollforward,[^asu-2022-04] and the IASB amended IAS 7 and IFRS 7 for supplier finance arrangements in May
2023.[^ifrs-sfa] Run such programmes with treasury and the auditors, not as a procurement initiative alone.

**Sustainability.** GHG Protocol scope 3 category 1 ("Purchased goods and services") offers four methods, from supplier-specific
data to spend × industry-average emission factors, and notes that splitting production from non-production purchases "may be
aligned with procurement practices".[^ghg-s3] Your spend cube feeds a spend-based estimate; the method belongs to
[GreenOps](../greenops/).

### Assurance of the operating model

A procurement operation needs its own monitoring, the business equivalent of observability:

- **Continuous control checks** (daily or weekly scripts like Labs 1, 3 and 4): duplicates, split purchases, bank changes without
  evidence, receipts entered after invoices, SoD conflicts, payments to inactive suppliers.
- **GR/IR ageing review** each month: old receipts without invoices reveal unbilled or mis-booked deliveries (and accrual errors);
  old invoices without receipts reveal goods paid or held without proof of delivery. Each old item needs an owner and a reason.
- **Exception logs** for every bypass (urgent requests, after-the-fact POs, released holds), reviewed monthly outside procurement.
- **Sampling.** Each quarter, trace 25 random paid invoices through the full chain and check each step was done by a different
  person; record failures as findings. Internal audit reviews supplier master and payments at least yearly.
- **Leading indicators** of control erosion: rising after-the-fact POs, manual hold releases, new suppliers per month and
  specialist-review SLA breaches.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Requesters expense purchases instead | Too slow for small buys; no card or catalogue | Expense claims by category; cycle-time p90 | Card or catalogue; fast lane under a threshold | Proportionate channels; SLAs |
| Hold queue grows every week | Tolerances too tight, receipts not recorded, or POs priced wrongly | Hold reasons by type, supplier and buyer | Fix the top cause (often missing receipts) | Receipt reminders; PO price from contract |
| Receipts entered in bulk after invoices | Receivers clearing holds, not confirming delivery | Receipt timestamp vs invoice date | Retrain; require evidence for late receipts | Monitor the pattern; receipts by a third party for goods |
| Same supplier appears three times | No duplicate search at onboarding; mergers and renames | Lab 4 name, tax-ID and bank checks | Merge records; block old ones | Mandatory search; tax-ID uniqueness |
| Contract auto-renewed unnoticed | Notice periods not captured | Auto-renewing contracts past notice dates | Negotiate now | Metadata at signature; 90-day alerts |
| Savings reported, budgets unchanged | Cost avoidance counted as savings; volume grew | Reported savings vs actual spend | Separate hard and soft savings | Finance validates definitions |
| Supplier paid twice | Invoice retyped, sent twice, or a statement paid as an invoice | Lab 1 normalised numbers; amount and date window | Recover; credit note | Duplicate check before payment |

### Worked runbook: a supplier payment diverted to a fraudulent account

::: example Illustrative incident, used to teach the runbook
On a Tuesday, a supplier's credit controller calls to ask why a 64,000 invoice is overdue. AP sees it was paid on Friday, to an
account that was changed eleven days earlier after an email that appeared to come from the supplier. The change was entered by one
analyst and approved by the same analyst under a temporary access exception.
:::

::: figure Responding to a diverted supplier payment
```mermaid
flowchart TB
  A["`Supplier reports
    unpaid invoice`"] --> B["`Confirm payment went
    to a changed account`"]
  B --> C["`Hour 0-1: ask bank
    to recall the funds`"]
  C --> D["`Hour 0-1: block all
    payments to that account`"]
  D --> E["`Day 0: report to police
    or national fraud centre`"]
  E --> F["`Day 0-2: preserve
    emails and change logs`"]
  F --> G{"`Was our mailbox or
    the supplier's compromised?`"}
  G -->|"ours"| H["`Security incident
    process (ResponseOps)`"]
  G -->|"theirs"| I["`Tell supplier; review
    their other changes`"]
  H --> J["`Week 1-4: fix control
    gap; pay supplier per
    legal advice; review`"]
  I --> J
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,B risk
  class C,D,E,F,H,I,J core
  class G decision
```
Text equivalent: the supplier reports an unpaid invoice; AP confirms the payment went to a changed account. Within the first
hour, ask the bank to recall the funds and block all payments to that account. On day 0, report to the police or national fraud
reporting centre. Over days 0 to 2, preserve emails and change logs. Then decide whether your own mailbox or the supplier's was
compromised: if yours, run the security incident process (ResponseOps); if theirs, tell the supplier and review their other
changes. In weeks 1 to 4, fix the control gap, pay the supplier according to legal advice, and hold a review.
:::

**Notes on the steps.**

1. **Recall first.** The FBI's advice is that "time is of the essence": ask the financial institution to recall the transfer at
   once, and in the US file a complaint with IC3.[^ic3-psa] Elsewhere, use the national reporting route.
2. **Contain widely.** Block the account for every supplier (fraudsters reuse accounts), list all payments to accounts changed in
   the last 90 days, and keep the phishing email with full headers.
3. **Find the entry point:** a look-alike domain or a compromised mailbox? If yours shows forwarding rules or odd sign-ins, run
   the security incident process ([ResponseOps](../responseops/), [IncidentOps](../incidentops/)).
4. **Name the control failures.** Here two combined: a bank change accepted by email without call-back, and a temporary access
   exception that let one analyst enter and approve the change (a segregation-of-duties breach). For a SEPA transfer, also check
   the bank's payee-name result: was a close match or no match overridden, or was the check waived for the payment file?
5. **Fix and verify.** Whether to pay the supplier again depends on contract and law (involve legal). Remove the exception,
   re-verify the last 12 months of bank changes by call-back, and test the fixes at the next quarterly sample.

**Signals that should have fired:** bank change via email (Lab 4 "RISKY CHANGE"), approver equals entrant (Lab 3 transaction
rule), a payee-name mismatch from the bank, a large first payment to a new account.

**The near miss.** Where the rule is followed, the same attack (a reply from the supplier's compromised mailbox inside a genuine
invoice thread) fails: the portal-only rule and a call-back on the contract's number show the supplier asked for nothing. The
rule works because it does not depend on anyone spotting a fake email.

### Anti-patterns and myths

| Anti-pattern or myth | Why it seems right | What happens | Do instead |
|---|---|---|---|
| "One process for everything" | Consistent and easy to audit | Small purchases wait weeks; people bypass via expenses | Channels by value and risk |
| "No PO, no pay" announced overnight | Strong compliance message | Suppliers unpaid, exceptions explode | Phase in by supplier group, with an exception route |
| "Three-way match makes us fraud-proof" | Matching blocks mismatches | Fake receipts defeat it, and collusion between two or more people defeats segregation (GAO 10.22)[^gao-gb] | Add analytics, rotation, tips channel, sampling |
| "Savings is our headline KPI" | Easy to explain | Cost avoidance inflates results; quality drops | Hard and soft savings separately, with service metrics |
| "The suite will fix it" | Vendors demo clean workflows | Dirty supplier data and unclear authority are automated, not fixed | Clean master data and authority matrix first |
| "Procurement approves everything" | Central control | A bottleneck that owns others' decisions | Budget holders approve the need; procurement owns route and terms |
| "Loosen tolerances to cut the backlog" | Faster AP | Systematic overbilling passes | Fix root causes of holds |
| "Urgent means skip" | Business pressure | Unvetted suppliers and terms; precedent | Written urgency criteria; logged, reviewed bypasses |

## Deciding and adopting

### When to use and when not to use

Every organisation that pays suppliers has a procurement process; the question is how much dedicated operation to build.

**Invest in a dedicated procurement operation when** several of these hold: supplier spend is a large share of costs; there are
more requesters than one person can know; purchases often involve personal data, system access or regulated goods; auditors test
your financial controls; a fraud or duplicate payment has already happened; or a law requires documented procedures.

**Do not build one yet** if you are a small company with a handful of suppliers and one finance person who knows every invoice.
You need a written authority matrix, two people for bank changes and payments, POs for large commitments and a good accounting
system, not a team, an intake tool or a sourcing suite. The cost of process must stay below the risk it removes.

**Hidden responsibilities:** supplier master data needs an owner forever, every threshold creates an exception process, and a
central team gets blamed for every delayed purchase. **Scale down** a low-risk control that catches nothing for a year (verify by
sampling).

### Decision framework

Most adoption decisions are really "which channel and how much control for this kind of spend". The tree below is a starting
point; set the thresholds from your own data.

::: figure Choosing the buying channel and control level for a purchase
```mermaid
flowchart TB
  Q0{"`Need approved
    and funded?`"} -->|"no"| X0["`Stop:
    do not buy`"]
  Q0 -->|"yes"| QN{"`On the
    no-PO list?`"}
  QN -->|"yes"| CN["`Pay under its
    own approval`"]
  QN -->|"no"| Q1{"`Recurring item with
    contract prices?`"}
  Q1 -->|"yes"| C1["`Catalogue or call-off
    approval by amount`"]
  Q1 -->|"no"| Q2{"`Supplier gets data,
    access or regulated role?`"}
  Q2 -->|"yes"| C2["`Add security, privacy,
    legal review; no card`"]
  Q2 -->|"no"| Q3{"`Value under the
    card limit?`"}
  Q3 -->|"yes"| C3["`Purchasing card
    monthly review`"]
  Q3 -->|"no"| Q4{"`Value above the
    bid threshold?`"}
  C2 --> Q4
  Q4 -->|"yes"| C4["`Competitive sourcing
    then contract and PO`"]
  Q4 -->|"no"| C5["`Requisition and PO,
    match level by spend type`"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q0,QN,Q1,Q2,Q3,Q4 decision
  class CN,C1,C2,C3,C4,C5 core
  class X0 risk
```
Text equivalent: first ask whether the need is approved and funded; if not, stop and do not buy. Then ask whether the item is on
the no-PO list (utilities, taxes, statutory fees); if yes, pay it under its own approval. Otherwise ask whether the item is
recurring with contract prices; if yes, use a catalogue or call-off with approval by amount. If not, ask whether the supplier will
get data, system access or a regulated role; if yes, add security, privacy and legal review, never use a card, and continue to the
bid-threshold question. If not, ask whether the value is under the card limit; if yes, use a purchasing card with monthly review.
Otherwise ask whether the value is above the bid threshold; if yes, run competitive sourcing, then contract and PO; if not, use a
requisition and PO, with the match level from the [match table](#playbook-invoice-matching-and-exceptions) (three-way for goods, two-way plus
usage review for subscriptions under contract).
:::

**Weighted comparison for a tooling decision (illustrative).** Score options 1–5 on criteria weighted by what matters to you.
The weights below suit a 1,200-person organisation with many SaaS purchases; a manufacturer would weight matching and supplier
portal higher.

| Criterion | Weight | ERP only | ERP + intake tool | Full S2P suite |
|---|---|---|---|---|
| Requester experience and visibility | 25% | 2 | 5 | 4 |
| Enforced controls (matching, SoD, audit trail) | 25% | 4 | 4 | 5 |
| Fit with existing ERP and ledger | 20% | 5 | 4 | 3 |
| Implementation effort and time | 15% | 5 | 4 | 2 |
| Licence and running cost | 15% | 5 | 3 | 2 |
| **Weighted score** | 100% | **4.00** | **4.10** | **3.45** |

Arithmetic for the middle column: 0.25 × 5 + 0.25 × 4 + 0.20 × 4 + 0.15 × 4 + 0.15 × 3 = 1.25 + 1.00 + 0.80 + 0.60 + 0.45 = 4.10.
The near-tie is the real finding: the choice turns on how much you value requester experience, a judgement to record in a
decision record.

### Maturity model

This is **this Atlas's model**, not an industry standard. Levels describe observable behaviour; move up only when the exit
criteria are met.

| Level | Observable behaviour | Evidence | Exit criteria to the next level |
|---|---|---|---|
| 1 Ad hoc | Anyone signs; invoices approved by email | Suppliers created on request; no PO numbers on invoices | Written authority matrix; supplier changes need a second person |
| 2 Controlled | POs for goods and services above a threshold; matching blocks payment; SoD in roles | Hold reports; access reviews | PO compliance ≥ 80% measured; zero unmitigated SoD conflicts in payments |
| 3 Channelled | One intake; catalogues and cards for small buys; parallel reviews; SLAs published | Cycle-time reports by route | Median request-to-PO within target; after-the-fact PO rate falling for two quarters |
| 4 Managed | Category strategies for top categories; spend cube refreshed monthly; renewal calendar | Category plans; master health report | Duplicate suppliers < 1%; renewals decided before notice dates; savings definitions agreed with finance |
| 5 Optimised | Continuous control checks; supplier risk, ESG and finance share one supplier record; automation with monitored exception rates | Control check logs; quarterly sampling with few findings | Sustained; review the model yearly |

Aim for level 3 quickly and level 4 for the largest categories; level 5 pays off at high volume.

### Adoption roadmap: 30/60/90 days

Assumes an organisation at level 1–2 with a sponsor in finance and one procurement operations lead.

| Period | Actions | Quick wins | Milestone / metric |
|---|---|---|---|
| Days 1–30: see and stop the bleeding | Map the process; extract 12 months of payments; run duplicate, bank-change and SoD checks (Labs 1, 3, 4); write the bank-change SOP; draft the authority matrix with finance | Portal-only bank changes with call-back; remove payment-release rights from people who create suppliers | Baseline: PO compliance, duplicates, SoD conflicts; SOP live |
| Days 31–60: build the front door | Publish one intake with routing rules; channels by spend type; POs required for the top 50 suppliers; matching tolerances | Catalogue or card for the two largest tail categories (Lab 2) | Intake used for ≥ 80% of new requests; first-pass match rate weekly |
| Days 61–90: measure and govern | Monthly scorecard; renewal calendar for the top 100 contracts; quarterly sample of 25 invoices; plans for the top three categories | Renegotiate one auto-renewing contract caught by the calendar | Scorecard reviewed by finance; first sample results |

**Dependencies:** ERP data access, finance agreement on authority levels, legal capacity for templates, IT for integrations.
**Skills:** process design, data analysis (spreadsheet or Python), stakeholder management, basic ERP configuration.

## Toolkit

### Checklists

**Supplier onboarding (per supplier)**

- [ ] Searched for an existing record by tax ID, normalised name and bank account
- [ ] Legal entity and owners screened against applicable sanctions lists, full legal name used
- [ ] Due diligence matches the risk: security, privacy, financial viability, anticorruption as required
- [ ] Supplier entered its own legal, tax and bank data; formats validated
- [ ] Second person approved activation; contract or PO exists before work starts

**Payment run (each run)**

- [ ] All lines matched or holds released with a recorded reason by an authorised person
- [ ] No payments to accounts changed within the verification window without call-back evidence
- [ ] Bank payee-name check (VoP or CoP) on for this file, or the waiver and its compensating control recorded
- [ ] Duplicate check (normalised invoice number, amount and date window) run on the proposal
- [ ] Release by a person with no supplier-maintenance or invoice-posting rights
- [ ] First payments to new or changed accounts reviewed by treasury

**Quarterly governance review**

- [ ] KPI scorecard reviewed with finance; flow and control metrics side by side
- [ ] All bypasses (urgent requests, after-the-fact POs, manual hold releases) reviewed by someone outside procurement
- [ ] Access review and SoD analysis on actual permissions; mitigations evidenced
- [ ] Random sample of 25 paid invoices traced end to end; findings logged
- [ ] Renewal calendar for the next 12 months reviewed with budget holders
- [ ] Inactive suppliers deactivated; duplicate suppliers merged

For a suspected payment fraud, use the [runbook](#worked-runbook-a-supplier-payment-diverted-to-a-fraudulent-account) as the
checklist.

### Templates

**One-page procurement charter**

```text
PROCUREMENT OPERATIONS CHARTER                       Version / date: ______
Purpose     Buy what the organisation needs quickly, from trusted suppliers,
            on agreed terms; pay each supplier correctly and once.
Scope       All third-party spend except: ____________ (no-PO list ref ____)
Owns        Intake, channels, sourcing route, POs, supplier master,
            procurement KPIs, renewal calendar
Does not    Budget decisions (budget holders); legal review (Legal);
own         payment release (Treasury); supplier risk method (Risk)
Authority   Approval matrix ref ____  Signature matrix ref ____
Service     Request acknowledged in 1 working day; route-specific SLAs ____
levels
Controls    SoD matrix ref ____; matching policy ref ____; SOP-VM-03
Measures    Cycle time, PO compliance, first-pass match, bank changes
            verified, duplicates, savings (hard / avoidance separately)
Review      Monthly with finance; annual policy and threshold review
Sponsor ____________   Owner ____________   Next review ____________
```

**Purchase request (intake) form**

```text
PURCHASE REQUEST                                    Request ID: _________
Requester / team / cost centre: ________________________________________
What do you need and why? (business outcome) ____________________________
Category (pick list): __________   Supplier: [ ] existing ____ [ ] new ____
Total contract value incl. renewals: ________ Currency: ___ Term: ________
Auto-renewal? [ ] yes [ ] no   Notice period: ________
Data the supplier will receive: [ ] none [ ] internal [ ] confidential
                                [ ] personal data (describe) ____________
Access to our systems or premises? [ ] no [ ] yes (describe) ____________
Government official involved or recommended supplier? [ ] no [ ] yes
Quotes attached: ___   Needed by: ________
Impact if late (specific, quantified): __________________________________
Budget holder approval: __________________  Date: ________
```

**Supplier performance review form**

```text
SUPPLIER REVIEW        Supplier: ____________  Tier: strategic/other ____
Period: ______   Contract ref: ______   Business owner: ______________
1. Success criteria in the contract and how they were met: _____________
2. Service levels: target ____ actual ____ credits claimed ____
3. Invoices: count ____ first-pass match ____ % disputes ____
4. Utilisation: seats or volume paid ____ used ____
5. Risk changes: security incidents / sanctions hits / financial ____
6. Issues and agreed remediation (owner, date): ________________________
7. Decision: [ ] continue [ ] improvement plan [ ] re-tender [ ] exit
Next review date: ________   Signed: business owner / category manager
```

**Decision record for a procurement process change**

```text
DECISION RECORD PR-____    Title: ____________________   Date: ________
Context      What problem, with which data (volumes, holds, cycle times)?
Options      A ______  B ______  C (do nothing) ______
Decision     ______________________________________________________
Controls     Which control changes? Who checked SoD and audit impact?
Metrics      What will show it worked, and by when?
Reversal     How do we roll back, and what would make us do it?
Approved by  Finance ________  Procurement ________  Audit (informed) ___
```

### Deep comparisons

**ProcurementOps compared with its nearest neighbours.**

| Dimension | ProcurementOps | [SupplyChainOps](../supplychainops/) | [LegalOps](../legalops/) | [FinOps](../finops/) |
|---|---|---|---|---|
| Unit of work | A purchase, from request to payment | A flow of goods through plan, source, make, deliver | A legal matter or contract | A cloud or technology cost line |
| Core control | SoD, approvals, matching, supplier master | Inventory accuracy, service levels | Legal review and contract obligations | Allocation, accountability, commitments |
| Headline metrics | Cycle time, PO compliance, first-pass match | Service level, inventory turns, forecast error | Matter cycle time, outside counsel spend | Unit cost, coverage, waste |
| Typical systems | Intake, P2P suite, ERP | Planning, warehouse, transport systems | CLM, matter management | Cost tools, cloud billing data |
| Choose this page when | You need to control *how money is committed and paid* | You manage *physical flow and stock* | You run *legal work* | You manage *variable technology spend* |

**Centralised, decentralised and centre-led procurement.**

| Model | How it works | Strength | Weakness | Fits |
|---|---|---|---|---|
| Centralised | One team buys for everyone | Leverage, clean data | Bottleneck, far from users | Uniform organisations |
| Decentralised | Each unit buys for itself | Speed, local knowledge | Duplicate contracts, weak data | Very autonomous units |
| Centre-led (hybrid) | Central policy, systems and category strategies; local buying | Leverage with speed | Needs clear decision rights | Most multi-unit organisations |

### FAQ

**What is the difference between procurement and purchasing?** Usage varies; commonly *purchasing* is ordering and paying, while
*procurement* covers the whole cycle from need to supplier management, as in CIPS's 13-step cycle.[^cips-cycle]

**Do we need a PO for everything?** No. Use POs where they add control (goods, defined services, anything you must match). Keep a
written no-PO list for utilities, taxes, statutory fees and similar items, and use cards or catalogues for small, frequent buys.

**Our team is too small to segregate duties. What now?** Evidence compensating controls: the finance lead reviews every supplier
change and the bank's payment report weekly, and an external accountant samples quarterly. The Green Book allows "alternative
control activities" when segregation is not practical.[^gao-gb]

**Does three-way matching work for services and subscriptions?** For milestone services, yes, with the requester recording a
service entry as the "receipt". For fixed subscriptions under contract, two-way matching plus a periodic usage review is usually
more sensible; the risk there is paying for unused seats, not undelivered goods.

**Who should own the supplier master, procurement or AP?** Either, as long as its maintainers cannot also post invoices or release
payments.

**Is ISO 20400 certification worth asking suppliers for?** No: ISO 20400 is guidance, and its steering group calls any claim of
certification a misrepresentation.[^iso20400] Ask for the practices instead.

**Can AI approve invoices?** Rules can auto-approve matched, low-risk invoices, as GAO describes for automated approvals with
manual review of flagged items.[^gao-gb] Do not let a model decide payments, bank changes or exceptions; those are exactly where
attackers aim.

## Going further

### Advanced topics and emerging direction

Separate what is established, what is emerging, and what is mostly marketing (as of October 2026).

- **Structured e-invoicing (established, now mandated by law in places).** Peppol uses a four-corner model in which buyers and
  suppliers connect through accredited providers;[^peppol] intra-EU e-invoicing becomes mandatory from 1 July 2030 under
  ViDA.[^vida] Plan supplier onboarding to e-invoicing country by country.
- **Continuous control monitoring (established idea, uneven practice):** worthless unless someone owns the alerts.
- **Payee-name checks at the bank (new, mandatory for EU banks since October 2025):** they move part of the verification to the
  payment itself, for payers who keep them on.[^vop-pwc]
- **One supplier record for many purposes (emerging):** sanctions screening, security due diligence, modern-slavery statements,
  EU due diligence (very large companies, from 2029[^omnibus]) and Scope 3 estimates.[^ghg-s3] The hard part is governance: who
  may update which field, and how often it is re-verified.
- **Language models in intake and review (emerging):** treat "autonomous procurement" as marketing until you see exception rates
  on your own data.
- **Regulatory change in third-party risk (watch).** The US banking agencies' September 2026 proposal to replace their 2023
  third-party guidance with a more explicitly risk-tiered approach was still a proposal when this page was checked.[^fr-tprm]

### Learning path

| Stage | Goal | Activities |
|---|---|---|
| Prerequisites | Accounting basics | Learn accrual, payables, cost centres and the purpose of a GR/IR account[^sap-grir] |
| 1-day primer | Understand the chain | Read [What ProcurementOps is](#what-procurementops-is), [Fundamentals](#fundamentals-the-documents-and-the-control-points) and [the workflow](#end-to-end-workflow-happy-path-and-exception-paths); run Lab 1 |
| 1-week practice | Analyse your process | Map it against the five stages; run Labs 2–4 on synthetic data shaped like yours; draft an authority matrix and bank-change SOP |
| 30-day progression | Change something | Follow the first 30 days of the [roadmap](#adoption-roadmap-306090-days); present a baseline scorecard |
| Advanced specialisation | Pick a track | Sourcing and category management (CIPS, Kraljic); P2P systems; controls and audit (COSO, Green Book); sustainable procurement (ISO 20400, GHG Protocol) |
| Portfolio project | Show competence | A redesign of one category (cube, strategy, channel, metrics) or continuous-control scripts with alert owners |

Leaders: read the [cheat sheet](#executive-recap-and-cheat-sheet), [when to use](#when-to-use-and-when-not-to-use) and
[the judgement call](#a-judgement-call-auto-receipts-to-clear-the-hold-backlog). Practitioners: do the four labs and the
[mastery check](#learning-objectives-and-mastery-check).

## Wrap-up

### Executive recap and cheat sheet

- **Decide:** the authority matrix, the channel for each kind of spend, the match level per category, and tolerances.
- **Essential practices:** one intake; channels by value and risk; self-service supplier onboarding with screening; three-way
  match for goods; renewal calendar; spend cube; quarterly sampling.
- **Non-negotiable controls:** no one person creates a supplier and pays it; no one person orders and receives; no bank change
  outside [SOP-VM-03](#reference-implementation-operating-artefacts).
- **Metrics:** request-to-PO cycle time (median and p90), PO compliance (before-invoice POs only), first-pass match rate, bank
  changes verified (100%), duplicate payments, GR/IR ageing, open SoD conflicts, hard savings and cost avoidance separately.
- **Watch-outs:** one heavy process for everything; receipts booked to clear holds; savings inflation; urgency used as a bypass;
  waived payee-name checks; models deciding payments, bank changes or exceptions (rule-based auto-approval only for matched,
  low-risk lines with an owned rule set).
- **Next actions:** run the duplicate and bank-change checks (Labs 1 and 4) this week; publish SOP-VM-03; agree the authority matrix.

### A judgement call: auto-receipts to clear the hold backlog?

**The situation.** AP has 2,300 invoice lines on QTY REC hold because receivers do not record receipts; two suppliers threaten to
stop supply. Option A (the AP manager's): for suppliers with a good history, create receipts automatically when the invoice
arrives. Option B: keep three-way matching, clear the backlog in a two-week blitz in which receivers confirm deliveries with
evidence, and fix the root cause (reminders; the warehouse, not the requester, receives goods).

**Assumptions.** About 70% of held lines are from 40 regular goods suppliers; the warehouse can take over receiving for goods
within a month; the organisation's auditors test three-way matching as a key control.

**Why the attractive option A is likely wrong here.**

1. **It removes the control silently.** A receipt created from the invoice proves nothing; the match becomes two-way while
   reports still say three-way, misleading auditors and management.
2. **"Good history" is the profile fraud exploits.** In the ACFE's purchasing-department cases, corruption appeared in
   79%;[^acfe] a trusted-supplier exception is where overbilling would go unnoticed.
3. **It treats the symptom.** The backlog exists because receiving is not owned; option A makes that permanent.

**What option A gets right:** suppliers should not suffer for internal failures, and some categories do not need receipts. So
option B pays confirmed lines quickly and moves genuinely low-risk categories to two-way matching *by an approved policy change*.

**Decision under these assumptions:** option B, plus a documented policy change for categories where receipt adds little. If the
warehouse cannot take over receiving, do not reach for evaluated receipt settlement (ERS, paying from the receipt without an
invoice): it moves the whole control onto the receipt, so it helps only once receiving is owned and accurate. Instead, approve a
time-limited two-way match for named suppliers with a compensating control (for example monthly delivery confirmation by an
independent person) and auditor agreement. This is a reasoned recommendation, not a proven result.

### Learning objectives and mastery check

You should now be able to **explain** the request-to-payment chain; **design** an authority matrix, channels and a matching
policy; **operate** onboarding, bank-change verification and invoice exceptions; **measure** flow and control KPIs; and
**evaluate** process changes for their control impact.

1. An invoice is 1.8% above the PO unit price, which is 400.00, and your policy allows 2% and 5.00 per unit. Does it pass?

::: answer Answer and explanation
No. 1.8% of 400.00 is 7.20 per unit: inside the percentage limit but above the 5.00 absolute limit, and both must hold. A small
percentage on an expensive line can still be a large overcharge.
:::

2. Name the two duties whose combination is most dangerous in the supplier master, and a compensating control for a two-person
   finance team.

::: answer Answer and explanation
Creating or changing a supplier (including bank details) and releasing payments: one person could create a payee and pay it.
Give one person each duty; if impossible, the second person reviews every master-data change and the bank's payment report
weekly, with evidence, plus an external sample.
:::

3. Your PO compliance shows 92%, but 9 percentage points of it are POs raised after the invoice. What is the real figure, and why
   does it matter?

::: answer Answer and explanation
83%. After-the-fact POs record commitments made without approval, budget check or sourcing; counting them hides the behaviour
the metric exists to reduce. Report them as a separate after-the-fact PO rate.
:::

4. A supplier emails new bank details from its usual address, in an existing invoice thread, with a signed letter attached. What
   do you do?

::: answer Answer and explanation
Do not change the record from the email: a real mailbox can be compromised. Follow
[SOP-VM-03](#reference-implementation-operating-artefacts): hold payments, require the portal, call back on a number already on
file (never one in the email or letter), get a second approver, and let a payee-name mismatch stop the first payment.
:::

5. Which match level would you use for (a) laptops, (b) an annual SaaS subscription under contract, (c) implant components that
   must pass inspection?

::: answer Answer and explanation
(a) Three-way: receipt proves delivery. (b) Two-way with a periodic usage review: receipt adds little and the risk is unused
seats. (c) Four-way: delivery is not acceptance, so inspection results must block payment for rejected quantities.
:::

6. Your three-way match is perfect, yet a buyer and a supplier's salesperson split a kickback on inflated prices. Which controls
   would have helped?

::: answer Answer and explanation
Matching checks the invoice against the PO, and here the PO carried the inflated price. Helpful: bid thresholds on total contract
value, independent evaluation panels, declarations of interest, price benchmarking, award-pattern analytics, buyer rotation and a
protected tips channel. Segregation of duties is defeated by collusion, which is why these detective controls matter.
:::

**Scenario challenge.** Using the reference implementation's authority matrix, route a 180,000 two-year contract for an HR
analytics tool that will receive employee personal data. List every approver, review and the sourcing route.

::: answer Model answer
Spend approval (`mode: all`): budget holder, department head and finance director (up to 250,000). Sourcing: business-led RFP
(100,000 to 250,000). Reviews: privacy and security (personal data); IT if it integrates with HR systems; sanctions screening and
vendor data if the supplier is new. Signature (`mode: any`): the CFO or the general counsel. Add a data-processing agreement and
put the notice date in the renewal calendar.
:::

### Conclusion

ProcurementOps is not glamorous, and its best work is invisible: the supplier paid correctly, the fake invoice stopped at
matching, the bank change confirmed by phone before a large payment. It asks for two things most organisations treat as
opposites, speed for the people who need things and proof for the people who answer for the money. The way through is not more
approvals; it is putting each control where money can actually be lost, making the compliant path the easy one, and measuring both
sides honestly. Get the chain of evidence right (approved need, commitment, receipt, matched
invoice, independently verified payee, independent payment) and the tools, the categories and the savings follow. Get it wrong,
and no suite, dashboard or AI assistant will notice until a supplier calls to ask where their money went.

## Sources and further reading

All sources were opened on 2026-10-23 unless noted in the evidence ledger (`research/procurementops-ledger.md`). Legal sources
are for orientation; check the official text before relying on them.

[^acfe]: [Occupational Fraud 2024: A Report to the Nations](https://www.acfe.com/-/media/files/acfe/pdfs/rttn/2024/2024-report-to-the-nations.pdf) — Association of Certified Fraud Examiners, 2024. Checked 2026-10-23.
[^ic3-2024]: [2024 IC3 Annual Report](https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf) — FBI Internet Crime Complaint Center, April 2025. Checked 2026-10-23.
[^ic3-psa]: [Business Email Compromise: The $55 Billion Scam (PSA I-091124-PSA)](https://www.ic3.gov/PSA/2024/PSA240911) — FBI IC3, 2024-09-11. Checked 2026-10-23.
[^afp-2026]: [Over 75 percent of U.S. firms experienced payments fraud in 2025 while AI adoption for fraud mitigation lags](https://www.financialprofessionals.org/about/learn-more/press-releases/Details/over-75-percent-of-us-firms-experienced-payments-fraud-in-2025-while-ai-adoption-for-fraud-mitigation-lags) — Association for Financial Professionals, press release, 2026-04-14 (survey of 465 US treasury practitioners). Checked 2026-10-23.
[^cips-about]: [About CIPS](https://www.cips.org/about-us) — Chartered Institute of Procurement & Supply, undated. Checked 2026-10-23.
[^cips-cycle]: [CIPS Procurement and Supply Cycle](https://www.cips.org/intelligence-hub/procurement/procurement-supply-cycle) — Chartered Institute of Procurement & Supply, undated. Checked 2026-10-23.
[^gitlab-proc]: [The GitLab Procurement Team](https://handbook.gitlab.com/handbook/finance/procurement/) — GitLab Handbook, last modified 2026-09-13. Checked 2026-10-23.
[^gitlab-jobs]: [Procurement Operations job family](https://handbook.gitlab.com/job-description-library/finance/accounting-operations/procurement-operations/) — GitLab Handbook, modified 2026-03-12. Checked 2026-10-23.
[^neu]: [Procurement Services](https://finance.northeastern.edu/departments/procurement-services/) — Northeastern University Finance, undated. Checked 2026-10-23.
[^zip-i2p]: [What is intake-to-procure?](https://zip.com/blog/what-is-intake-to-procure) — Zip (vendor blog, Brooks Rocco), 2025-04-01. Checked 2026-10-23.
[^gao-gb-page]: [Standards for Internal Control in the Federal Government (GAO-25-107721)](https://www.gao.gov/products/gao-25-107721) — US Government Accountability Office, 2025-05-15. Checked 2026-10-23.
[^gao-gb]: [Standards for Internal Control in the Federal Government, 2025 revision (full report, PDF)](https://www.gao.gov/assets/gao-25-107721.pdf) — US GAO, May 2025: Table 1 and paras. 10.21–10.23, 11.16, Appendix II. Checked 2026-10-23.
[^oracle-ap]: [Using Approval (Oracle Payables Help)](https://docs.oracle.com/cd/A60725_05/html/comnls/us/ap/pomatc04.htm) — Oracle, legacy E-Business Suite help (release not shown). Checked 2026-10-23.
[^rfsuny]: [Two, Three, and Four Way Matching](https://www.rfsuny.org/media/rfsuny/procedures/ap_2-3-4-way-matching_pro.pdf) — The Research Foundation for SUNY, procedure, 2011. Checked 2026-10-23.
[^odoo]: [Bill control policies](https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/purchase/manage_deals/control_bills.html) — Odoo 18.0 documentation. Checked 2026-10-23.
[^sap-grir]: [Postings at Goods Receipt and Invoice Receipt](https://help.sap.com/saphelp_46C/helpdata/EN/47/60ff6f49f011d1894c0000e829fbbd/content.htm) — SAP Help, legacy R/3 4.6C documentation. Checked 2026-10-23.
[^vop-pwc]: [Verification of Payee requirements (VoP) under the EU's Instant Payments Regulation (IPR)](https://legal.pwc.de/en/news/articles/verification-of-payee-requirements-vop-under-the-eus-instant-payments-regulation-ipr) — PwC Legal (law-firm client alert), 2025-08-21. Checked 2026-10-23.
[^vop-ecb]: [Verification of Payee (VoP) Service](https://www.ecb.europa.eu/paym/target/target-professional-use-documents-links/tips/shared/pdf/tipsmeetdoc/ecb.tipsmeetdoc240419_TIPS-CG_Verification_of_Payee_Service.en.pdf) — European Central Bank, TIPS Contact Group presentation summarising the Instant Payments Regulation, 2024-04-19. Checked 2026-10-23.
[^psr-cop]: [CP26/2: Extending Specific Direction 17 (Confirmation of Payee)](https://www.psr.org.uk/publications/consultations/cp262-extending-specific-direction-17/) — Payment Systems Regulator, 2026-07-30. Checked 2026-10-23.
[^ofac]: [A Framework for OFAC Compliance Commitments](https://ofac.treasury.gov/media/16331/download?inline) — US Treasury, Office of Foreign Assets Control, undated PDF. Checked 2026-10-23.
[^nist-csf]: [The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf) — NIST, 2024-02-26. Checked 2026-10-23.
[^fr-tprm]: [Proposed Third-Party Risk Management Guidance (FR Doc. 2026-18859)](https://www.federalregister.gov/documents/2026/09/15/2026-18859/proposed-third-party-risk-management-guidance) — OCC, Federal Reserve, FDIC, NCUA, Federal Register, 2026-09-15 (status checked via the Federal Register API). Checked 2026-10-23.
[^hbr-kraljic]: [Purchasing Must Become Supply Management (P. Kraljic)](https://hbr.org/1983/09/purchasing-must-become-supply-management) — Harvard Business Review, September 1983 (page shows the introduction only). Checked 2026-10-23.
[^wiki-kraljic]: [Kraljic matrix](https://en.wikipedia.org/wiki/Kraljic_matrix) — Wikipedia (tertiary source). Checked 2026-10-23.
[^wiki-unspsc]: [UNSPSC](https://en.wikipedia.org/wiki/UNSPSC) — Wikipedia (tertiary source; unspsc.org could not be fetched automatically). Checked 2026-10-23.
[^peppol]: [About Peppol](https://peppol.org/about/) — OpenPeppol AISBL, undated. Checked 2026-10-23.
[^vida]: [VAT in the Digital Age (ViDA) formally adopted](https://ec.europa.eu/newsroom/digital/items/877702) — European Commission newsroom, 2025-04-04. Checked 2026-10-23.
[^latepay]: [Late Payment Directive: frequently asked questions](https://ec.europa.eu/docsroom/documents/16222/attachments/1/translations/en/renditions/native) — European Commission, DG GROW, undated PDF. Checked 2026-10-23.
[^latepay-oeil]: [Commercial transactions: combating late payment, procedure 2023/0323(COD)](https://oeil.europarl.europa.eu/oeil/en/procedure-file?reference=2023%2F0323%28COD%29) — European Parliament Legislative Observatory, procedure file (stage: awaiting Council's first-reading position). Checked 2026-10-23.
[^asu-2022-04]: [FASB Enhances Disclosure Requirements Related to Supplier Finance Programs](https://dart.deloitte.com/USDART/home/news/all-news/2022/sep/fasb-asu-supplier-finance-programs) — Deloitte DART (summary of FASB ASU 2022-04), 2022-09-30. Checked 2026-10-23.
[^ifrs-sfa]: [Supplier Finance Arrangements](https://www.ifrs.org/projects/completed-projects/2023/supplier-finance-arrangements/) — IFRS Foundation, IASB completed project, May 2023. Checked 2026-10-23.
[^uk-msa]: [Publish an annual modern slavery statement](https://www.gov.uk/guidance/publish-an-annual-modern-slavery-statement) — GOV.UK, Home Office, updated 2024-04-25. Checked 2026-10-23.
[^omnibus]: [EU Sustainability Omnibus Published in the Official Journal](https://www.lw.com/en/insights/EU-Sustainability-Omnibus-Published-in-the-Official-Journal) — Latham & Watkins (law-firm summary), 2026. Checked 2026-10-23.
[^uk-pa-esx]: [Procurement Act 2023](https://www.eastsussex.gov.uk/business/doing-business/procurement-act-2023) — East Sussex County Council, undated. Checked 2026-10-23.
[^uk-pa-trans]: [Guidance on transitional and saving arrangements](https://assets.publishing.service.gov.uk/media/68c92f0b5e09a4a59af0bf1c/Guidance_-_Transitional_and_Saving_Arrangements_FINAL_v4_pdf_links__.docx.pdf) — GOV.UK (Cabinet Office), Procurement Act 2023 guidance, undated PDF (paras 4–6). Checked 2026-10-23.
[^uk-pa-guid]: [Procurement Act 2023 guidance documents](https://www.gov.uk/government/collections/procurement-act-2023-guidance-documents) — GOV.UK, Cabinet Office, updated 2026-02-04. Checked 2026-10-23.
[^iso20400]: [Buyer beware: ISO 20400 is not certifiable](https://www.iso20400.org/wp-content/uploads/2023/06/ISO-20400-certification-v.2.docx-Final.pdf) — ISO20400.org Steering Group (independent experts), May 2023. Checked 2026-10-23.
[^omb-m1913]: [M-19-13, Category Management: Making Smarter Use of Common Contract Solutions and Practices](https://trumpwhitehouse.archives.gov/wp-content/uploads/2019/03/M-19-13.pdf) — US Office of Management and Budget, 2019-03-20 (archived; current status not verified). Checked 2026-10-23.
[^ghg-s3]: [Technical Guidance for Calculating Scope 3 Emissions, version 1.0](https://ghgprotocol.org/sites/default/files/standards/Scope3_Calculation_Guidance_0.pdf) — GHG Protocol (WRI and WBCSD), 2013, category 1. Checked 2026-10-23.

**Further reading**

- CIPS Intelligence Hub pages linked from the Procurement and Supply Cycle (specification, Kraljic, supplier management).
- The full GAO Green Book, especially Appendix II on preventive and detective control activities.
- Your auditors' control framework and your ERP vendor's current matching and approval documentation.

**Changelog**

- 2026-10-23, first version: researched and drafted; four labs executed on synthetic data; nine diagrams.
- 2026-10-23, r1 revision after independent review: added EU Verification of Payee and UK Confirmation of Payee (playbook, SOP,
  regulatory map, runbook, checklist); corrected the OFAC and GAO wording; dated the Late Payment proposal and the UK transitional
  rules; added supply-chain finance, early-payment discounts and GR/IR ageing; acknowledged FleetOps, RetailOps, LabOps and FinOps
  for AI handoffs; redrew figures 3, 4 and 8 and removed HTML from diagram labels; dropped the maturity diagram, which restated
  its table (eight diagrams); merged scenario 4 into the runbook; trimmed repetition.
- 2026-10-23, post-score polish: figure 8 match level follows the match table; OMB M-19-13 wording; "riskiest transaction"
  labelled as judgement; UK CoP row dated; bank-change restatements now link to SOP-VM-03.