One procurement process. One model. Three questions.
Purchase-to-pay for indirect materials at a mid-sized company. Below: how we would help you map it, what the model shows, where AI could help, what that would need in governance, and how the controls would be evidenced. Everything here is illustrative.
Illustrative. A fictional purchase-to-pay process assembled from typical patterns. Not a client, not a case study.
The process, mapped
| Element | In this process |
|---|---|
| Owner | Head of Procurement; the accounts-payable lead for the invoice and payment steps. |
| Objectives and KPIs | Requisition-to-PO cycle time · share of spend under contract · three-way-match rate first time · supplier on-time delivery · price variance against contract. |
| Applications | The ERP system (requisition, release strategy, PO, goods receipt, invoice matching, payment run) · the supplier master · the contract repository · email for exceptions. |
| Data | Requisitions, approval logs, POs and their change history, goods receipts, invoices and match results, payment runs, supplier master changes, user-role assignments. |
| Existing controls | Approval limits by amount band · segregation of duties (requester ≠ approver ≠ goods receipt ≠ payment release) · supplier qualification before first order · three-way match before payment · duplicate-invoice check · supplier master change approval. |
| Risks | Spend outside contracts · approval bypass through PO splitting · duplicate or fraudulent payment · orders placed before supplier qualification · data quality in the supplier master. |
| AI in use today | None, in this illustration. |
A part of the meta-model, populated for one process to show the principle; a real mapping carries more element types and more relationships.
This is the model: not a document about the process, but the elements and how they connect. The same table, kept current, serves all three questions below.
Value: where could AI create measurable improvement?
- Spend classification across requisitions and invoices, to find contract leakage
- Cycle-time analysis, to locate where approvals wait
- Pattern search for PO splitting just under the approval bands
- Duplicate-supplier and duplicate-invoice detection
- Match-failure clustering by supplier and by cause
| Opportunity | Value | Feasibility | Data readiness | Risk | Priority |
|---|---|---|---|---|---|
| Auto-classification and routing of requisitions to the right contract and buyer | Cycle time down; spend under contract up | High: structured data, clear rules | Good: requisition text and the contract catalogue exist | Low: a person confirms before the PO | 1 |
| Invoice data extraction and pre-matching | AP effort down; first-time match rate up | High: mature technology | Good: invoices and POs in the ERP | Low to medium: payment follows only after the match | 2 |
| Anomaly flags on payment runs (duplicates, unusual amounts, split POs) | Loss prevention; the control strengthened | High | Good | Low: flags go to a person | 2 |
| Supplier risk signals at qualification and renewal (financial, sanctions, delivery history) | Fewer disruptions; better qualification decisions | Medium: external data needed | Medium: supplier master quality uncertain | Medium: a decision about a supplier affects a third party | 3 |
| Demand forecasting for recurring indirect purchases | Fewer rush orders; better prices | Medium | Medium: history is thin for some categories | Low | 4 |
Scores are illustrative. In an engagement they come from the data and the process owners.
Governance: what would these need?
For each opportunity the model shows what has to be added, and where it sits.
Who owns each AI use (the process owner, not IT), who approves changes to the model or the rules, who handles flagged exceptions.
Proportionate to the use. Classification and matching: low impact, internal. Supplier risk signals: a decision that affects a third party, so an impact assessment, documented criteria, human review of adverse outcomes, and a way for a supplier to query a decision.
Where the person stays in the loop (every PO, every payment release, every supplier decision) and what they see from the AI.
Which data trains or feeds each use, where it comes from, how its quality is monitored. Vendor models treated as third-party AI.
Access to invoice and supplier data by the AI components, logged and reviewed; the AI-specific threats ISO/IEC 27090 describes (data poisoning, prompt injection, model extraction) treated as risks in the ISMS where one exists.
Acceptance criteria before go-live; monitoring of accuracy, drift and override rate; change control; retirement.
In the existing management system. The procurement procedure gains the AI steps; the risk register gains the AI risks; the internal audit programme gains the AI controls. ISO/IEC 42001 provides the AI-specific requirements; the QMS or ISMS already provides the rest. No second system.
Assurance: what evidence shows it works?
| Control | Application | Data | Evidence | Test |
|---|---|---|---|---|
| Approval limits by amount band | ERP release strategy | PO header, release log, user-role table | Every PO above the band carries a release by an authorised role before output | Full-population check over the period; list the exceptions; look for splitting just under the band |
| Segregation of duties | ERP roles and authorisations | User-role assignments; the actor on requisition, approval, goods receipt, payment | No user performs two conflicting steps on the same document | Full-population comparison of actors per PO; review of role assignments against the SoD matrix |
| Three-way match before payment | ERP invoice verification | Invoice, PO, goods receipt, block and release log | Payments only after a match, or a documented release of the block | Full-population check; analysis of block releases by user and reason |
| Supplier qualification before first order | Supplier master workflow | Supplier master change log, qualification records | No first PO to a supplier without a completed qualification | Compare first-PO dates with qualification completion; sample the records |
| AI requisition classification (once live) | The classification service and the ERP | Model output log, override log, monitoring report | Accuracy and override rate within the agreed thresholds; drift reviewed; changes approved | Review the monitoring records against the acceptance criteria; sample the overrides; check the change approvals |
What this gives an audit: findings written against full populations where the data allows, each traceable to the record it came from, next to interviews, documents and observation. Formal audits guided by ISO 19011:2026.
Where Valment designed the AI governance, someone else audits it.
What a client would take away
The populated register, the process models, the opportunity portfolio with its scores and reasons, the governance additions per opportunity, the evidence table for the controls, and a roadmap: opportunities 1 and 2 first, the anomaly flags alongside, the supplier risk signals after the supplier master is cleaned, the forecasting once the history allows. Under ISO 9001 this is what improvement looks like: the process delivers its outcomes more consistently, and the QMS records it.
In spreadsheets, diagrams and documents. Theirs to keep.
The next step would be to pick the process where this would tell you the most.
Map your first process
Pick the process where a model like this would tell you the most. We'll come back with a fixed scope.