Blog · Procurement and supply chain · Procurement
Specify a procurement analytics pilot with reviewed AP controls, match exceptions, evidence coverage and buyer tasks instead of an uncheckable dashboard promise.
A procurement demonstration can show an attractive category chart without proving that the amounts reconcile, the contract joins are correct or the category manager can use the exceptions. A pilot should make those claims testable before a wider project is agreed.
This is an acceptance specification, not another software-selection page. Use the existing procurement software guide for buying criteria and the procurement KPI guide for measure selection. Here the deliverable is a bounded test plan with a recorded result.
Start with a question such as which invoices in one category cannot yet be confirmed as managed under the agreed policy. Choose the intended user and the decision the output should support. Avoid a pilot described only as build a dashboard or analyze procurement.
Specify companies, categories, date basis, period, currencies and sample-selection method. Include ordinary invoices, credits, unmapped suppliers and difficult contract cases rather than only the cleanest rows. The sample should be authorized and stripped of unnecessary personal details.
Record the deliverables: a reconciled line table, status summary, match-exception list, selected category/unit view and a short limitations note. State whether recurring refresh, live integration or broader data remediation is outside the pilot.
Select the managed-spend rule and denominator before testing. The SUM guide remains its content owner, while unknown-status reporting handles incomplete evidence. The pilot should not assume every organization uses the same definition.
Obtain source row counts and signed totals from AP independently of the analysis output. Agree an acceptable rounding tolerance in advance; do not invent a tolerance after seeing a discrepancy. Ask the AP owner to confirm how credits, taxes and reporting currencies are represented.
Microsoft documents multi-column merge keys. Test those keys and match cardinality explicitly; a successful operation does not establish that a business rule or contract mapping is correct. Power Query merges.
The example contains 100 invoice lines totaling $100,000 on one approved net-spend basis.
| Reviewed outcome | Lines | Spend |
|---|---|---|
| Confirmed managed under selected policy | 60 | $60,000 |
| Confirmed unmanaged | 25 | $25,000 |
| Unknown: insufficient evidence | 15 | $15,000 |
| Total | 100 | $100,000 |
Evidence coverage by spend is 85%. The managed-share bound is 60%-75% if every unknown dollar could be unmanaged or managed respectively. Calling the result 60% with no unknown disclosure hides uncertainty; calling all unknowns unmanaged asserts more than the evidence supports.
The sample is illustrative. It does not set a recommended commercial performance target or prove that a pilot on another dataset will attain these results.
| Test | Passing evidence |
|---|---|
| Source perimeter | File identifiers, extract dates and selected rows match agreed scope |
| Line grain | Each source-company/document/line key appears once |
| Amount control | Signed line total agrees with approved AP control within agreed tolerance |
| Mapping control | Supplier/category/unit joins preserve count and amount |
| Contract selection | Dated, scoped matches reproduce reviewed examples |
| Unknown handling | Missing evidence is visible rather than forced into a confirmed status |
| Output usability | Category manager answers the agreed question and opens supporting lines |
| Repeatability | Same files and recorded rules reproduce the same output |
Include negative tests. Supply one duplicated line, an expired contract, an overlapping contract and a missing supplier mapping in a separate synthetic test set. The output should expose each expected exception. A failed test should remain failed until its cause and correction are reviewed.
Record pass, fail, not tested or blocked for each criterion, with reviewer and evidence reference. A buyer finding the table useful does not erase a failed reconciliation. Conversely, a small disclosed evidence gap may be acceptable for a limited discovery question if the owner explicitly agrees its effect.
Estimate further work from the exceptions found: supplier crosswalk review, category coding, missing contract scope or additional source history. Keep that estimate separate from a promise of savings. The contract exception method explains the difficult joins.
The pilot handover should include definitions, sample scope, control results, reviewed output, unresolved cases and a proposed next scope. A subsequent project agreement can reference these acceptance tests instead of relying on a vague promise of complete procurement visibility.
Bring an authorized AP sample, contract register and source controls to discuss a pilot. The conversation establishes feasibility and scope; it does not mean every method here is already automated, that an ERP connector is included or that the pilot guarantees financial savings.
No. Also test selected definitions, mappings, evidence states and whether the intended user can answer the agreed question from traceable output.
No. Those are separate commercial outcomes and service scopes. The pilot should establish fit, verified outputs and remaining work.