ProcurementOps

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.

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.^[1] 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.^[2]

• Not logistics or inventory. Moving, storing and planning physical goods belongs to 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. 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; this page runs the onboarding and review steps that feed it.
• Not cloud cost optimisation. Commitment purchases and rightsizing are taught in 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.

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.^[3] CIPS publishes a 13-step Procurement and Supply Cycle.^[4] An ISO guidance standard covers sustainable procurement (ISO 20400, 2017),^[5] and public buying is set by law in many jurisdictions (for example the UK’s Procurement Act 2023).^[6]

“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.^[7] Northeastern University’s Procurement Operations team “develops and implements processes and procedures related to buying goods and services for the university”.^[8]

“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.^[9] 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.^[7] This page uses the broad sense, the whole source-to-pay operating model, with most space on the controls and the data.

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.

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

Procurement also buys for every other function, so it touches ITOps (software and hardware), IdentityOps (supplier and contractor accounts), and GreenOps (supplier emissions data). Several pages hand their buying to this one: vehicles and fleet leases (FleetOps), merchandise and store supplies (RetailOps), lab consumables and instruments (LabOps), and contracts with AI model and API providers (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.

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”.^[11]
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.

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

The Green Book also recommends unique transaction identifiers, naming “unique invoice numbers and purchase order numbers”, so that duplicates can be detected.^[11] It also notes that segregation of duties mitigates the risk of management override but “cannot absolutely prevent it because of the risk of collusion”.^[11] 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.

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):

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.

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.^[4] Operationally, the same life is easier to run as five stages, each with an owner and an exit condition.

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

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

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.^[12]

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

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.^[12] 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.^[12]

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.

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

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).^[12] Bank-field changes follow SOP-VM-03.
• Matching runs in the system of record, so holds actually block payment; payment is released by a separate role.

Alternatives and trade-offs.

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.^[12]

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

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

Happy path details. Specialist reviews run in parallel (intake playbook); 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.

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.

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

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) 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^[12]).

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.

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^[12]). Owner: buyer or category manager.

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).

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.

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.^[13]
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).^[14] The scoring method belongs to 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”.^[15] In a survey of 465 US treasury practitioners released in April 2026, 74% said their organisation had been affected by BEC in 2025.^[16] The figure shows the workflow; SOP-VM-03 in the reference implementation 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.^[17] 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.^[17][18] 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).

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

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.

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.^[19] A university research foundation’s procedure states the consequence: “payment cannot be made until the hold is resolved or manually released”.^[20]

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

Choosing the match level.

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.

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^[12]); 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^[12]) 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.

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.^[21]
• 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”.^[22] It places categories on two dimensions, profit impact and supply risk, giving four quadrants: non-critical, leverage, bottleneck and strategic items.^[23]

Two recorded criticisms: it is designed for categories but often misapplied to suppliers, and it is a snapshot that ages as markets move.^[23] 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).^[12] One combined “savings” number is the commonest way procurement overstates its value.

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

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.^[11] Cite it for principles; use your own auditors’ framework for the controls you are tested against.

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

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

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 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.^[11] 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.^[16] Test any AI feature on exceptions you already resolved (precision and recall), and log its suggestions as evidence, not decisions.

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).

# 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.

Artefact 3: matching and tolerance policy.

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

# 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).

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).

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.

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).

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).

"""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):

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.

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).

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).

"""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):

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.

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).

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).

"""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):

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^[11]).

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

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).

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).

"""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):

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).

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.^[12] 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.

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.

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.^[37] 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.

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.^[1] These are cases investigated by certified fraud examiners, not a random sample.

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,^[1] 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”^[11]). 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).^[14]

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.

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.^[12] 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).^[28] 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,^[38] and the IASB amended IAS 7 and IFRS 7 for supplier finance arrangements in May 2023.^[39] 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”.^[25] Your spend cube feeds a spend-based estimate; the method belongs to GreenOps.

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.

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

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.^[15] 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, 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.

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).

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.

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

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.

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.

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

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

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

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.

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 as the checklist.

One-page procurement charter

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

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

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

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) ___

ProcurementOps compared with its nearest neighbours.

Centralised, decentralised and centre-led procurement.

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.^[4]

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.^[11]

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.^[5] 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.^[11] Do not let a model decide payments, bank changes or exceptions; those are exactly where attackers aim.

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;^[26] intra-EU e-invoicing becomes mandatory from 1 July 2030 under ViDA.^[27] 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.^[17]
• One supplier record for many purposes (emerging): sanctions screening, security due diligence, modern-slavery statements, EU due diligence (very large companies, from 2029^[31]) and Scope 3 estimates.^[25] 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.^[35]

Leaders: read the cheat sheet, when to use and the judgement call. Practitioners: do the four labs and the mastery check.

• 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.
• 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.

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%;^[1] 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.

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?

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

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?

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?

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

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?

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.

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.

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.

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.