A practical guide to source-to-pay reporting
Procurement Reporting in Power BI: S2P KPIs, Data Sources and Dashboard Requirements
Connect procurement measures to the records, owners and decisions behind them—from sourcing and contracts to invoices and payment.
At a glance
Make every KPI usable
- Define the calculationPopulation, dates, exclusions and what counts as success.
- Check the source recordsDocument IDs, line detail, history and reconciled totals.
- Design for actionA named owner, a useful work queue and a route to the source.
On this page
Procurement reporting in Power BI should help people decide what to do next. A sourcing lead needs to see which opportunities need attention. A buyer needs to find requests waiting for approval. Accounts payable needs to know why invoices are blocked and who can resolve them.
Source-to-pay (S2P) spans sourcing, contracting, purchasing, receipt, invoicing and payment. Those stages often sit in different systems. A useful report connects them without treating every date, status or amount as interchangeable.
Start with the decision, the person responsible and the frequency of review. Then agree the KPI and the records needed to calculate it. A monthly category review and a daily invoice-exception queue need different levels of detail and different refresh expectations.
01 · Define the measures
Practical S2P KPI definitions
The definitions below are starting points for agreement with procurement and finance, not universal benchmarks. For every KPI, record its owner, unit, numerator and denominator or timing rule, date basis, exclusions, target and refresh frequency.
Use an explicit “unknown” category where required evidence is missing. A zero denominator should return “not applicable” or blank with an explanation, rather than a misleading 0%.
Spend under management
Managed eligible spend ÷ total eligible spend × 100. Agree what evidence makes spend “managed”—for example, an approved sourcing process or documented procurement oversight. Use a consistent spend basis, such as posted invoice-line value excluding recoverable tax, with an agreed treatment of credits and currency.
Use invoice lines, supplier/category mappings and dated management evidence. Being paid through an ERP or appearing on a PO does not by itself prove management. Keep unknown classifications visible in the eligible population. Action: category owners prioritise unmanaged spend and classification gaps.
Contract coverage
Eligible spend linked to an applicable contract valid at the transaction date ÷ total eligible spend × 100. Specify the date used, the relevant contract scope and any approved exclusions. A supplier having a contract is not proof that every purchase is covered.
Use invoice/PO-line links, contract ID, effective dates and scope. Report unmapped spend separately; do not quietly drop it. Action: buyers route suitable purchases to agreed contracts and category owners investigate coverage gaps.
Requisition-to-PO cycle time
Measure elapsed time from requisition submission to PO issue to the supplier. For each eligible requisition line, use the point when its required quantity/value has been ordered; define how split orders and amendments are handled. Show median and a tail measure such as the 90th percentile for lines completed in the period.
Use submitted and issued timestamps plus requisition-to-PO-line links. Exclude cancelled lines under a stated rule and show open-line age separately. Do not relabel PO creation-to-approval time as requisition-to-PO time. Action: the buying team finds approval and hand-off delays.
Supplier lead time and on-time delivery
Keep two measures. Lead time: PO issue to final accepted receipt for eligible fully received lines. On-time delivery: eligible schedule lines with the required quantity received by their agreed due date ÷ eligible schedule lines due in the period × 100. State tolerances and whether original or revised promises are used.
Use order/schedule IDs, issue and promised dates, receipt timestamps, accepted quantity, units and reversals. Open past-due lines cannot disappear from the delivery denominator. Service purchases need an agreed acceptance milestone. Action: buyers expedite overdue supply and supplier managers investigate repeat delays.
First-pass invoice match rate
Distinct eligible PO invoices passing their first match check without an exception ÷ distinct eligible PO invoices with a known first-check outcome × 100. An invoice passes only if all required line checks pass. Specify the cohort—for example, invoices first checked in the period—and show unassessed records separately.
Use invoice IDs, PO/receipt links and dated match-result history. A current “matched” status cannot show whether an invoice failed earlier. Action: AP, buyers and requesters tackle the reasons for rework: price, quantity, missing receipt or reference errors.
Invoice processing cost
Agreed invoice-processing costs for the period ÷ distinct invoices completed in that period. Document included labour, technology and allocated overheads, plus the completion event. Segment PO and non-PO flows; disclose the treatment of credit notes and outsourced work.
Use finance-approved cost allocations and invoice completion records. Costs and volumes must cover the same scope and period; explain backlog effects. Action: AP leaders compare comparable processes and test whether changes reduce effort without weakening controls.
On-time payment rate
Eligible invoices fully settled by their contractual due date ÷ eligible invoices due in the period × 100. Agree the settlement event and treatment of disputes, credits and cancelled invoices. A partial payment is not a full settlement. Show overdue unpaid items at the reporting cut-off.
Use contractual due dates and payment allocations against invoice IDs, including reversals. Missing settlement evidence is unknown, not success. Action: AP and treasury separate approval holds from payment-execution issues and assign the next step.
Avoid one unexplained “supplier compliance” score. Contract coverage, on-time delivery, invoice accuracy and completed due-diligence checks measure different obligations. Report each against a defined rule. Keep negotiated savings, cost avoidance and realised savings separate too: a lower spend total may reflect volume, mix or currency changes rather than a procurement saving.
02 · Inspect the records
Agree the source data before the dashboard design
Systems such as Coupa, SAP Ariba, JAGGAER, Basware, Ivalua, Zip and an organisation’s ERP may hold parts of this data. The available fields, event history and extraction methods depend on the actual implementation. Confirm access and inspect representative exports before promising a measure.
| Data area | Records and fields | Source and validation |
|---|---|---|
| Sourcing & contracts | Records and fieldsEvent and contract IDs, category, owner, stage, milestone dates, award decision, contract scope, validity, supplier links and agreed savings baseline. | Source and validationSourcing/contract systems and approved registers. Retain stage history and baseline versions; a current status alone cannot reproduce prior pipeline or coverage. |
| Requests, orders & approvals | Records and fieldsRequisition, PO and line IDs; submitted, approved and issued times; quantity/value, currency, requester, buyer, entity, cost centre, status and cancellation/return events. | Source and validationIntake, purchasing and approval systems. Preserve line mappings and each approval step’s owner and timestamps; do not join on supplier name alone. |
| Receipts & service acceptance | Records and fieldsPO-line/schedule reference, promised date, receipt/acceptance date, accepted quantity, unit of measure, reversal and completion status. | Source and validationERP, warehouse or service-acceptance records. Check partial receipts, changed promises, returns and missing confirmations. |
| Invoices, match events & payments | Records and fieldsInvoice header and line IDs, supplier invoice reference, posting date, net/tax/gross amounts, currency, PO/receipt links, first match result, exception reason, due date and payment allocations. | Source and validationAP, invoicing and finance systems. Resolve duplicates, credit notes, reversals, split payments and invoices outside the purchasing platform. |
| Master data & controls | Records and fieldsSupplier crosswalk, category hierarchy, entity, cost centre, contract mappings, owners, exchange rates, calendars and dated classification rules. | Source and validationGoverned master/reference data. Assign owners for unmapped records and define how changes affect historical reports. |
For each feed, document the system of record, extraction method, unique key, record level, update schedule, retention and responsible owner. Obtain examples of cancellations, reopened approvals, split orders, partial receipts, credits and missing references—not only clean transactions.
03 · Protect the totals
Model each transaction at the right level
A PO line can have several receipts, invoice lines and approval events. Joining all of them into one flat table can multiply amounts. Keep transaction tables at defined levels and connect them through governed supplier, entity, category and date dimensions, with explicit mapping tables where documents split or combine.
Microsoft’s star-schema guidance for Power BI explains why consistent fact-table grain matters. Define whether each measure counts invoice headers, invoice lines, requisition lines or delivery schedules before building it.
Reconcile counts and values back to source control totals by entity, period and currency. Do not add order commitments, received value, invoiced spend and payments into one “total spend” figure. Show unmapped suppliers, duplicate keys, missing dates and failed extracts as data-quality exceptions.
Keep the date roles explicit: PO issue, receipt, invoice posting, contractual due and payment dates answer different questions. Retain snapshots or event history when users need to reproduce a prior reporting cut-off.
04 · Design around users
Give each dashboard a decision and an owner
A dashboard should lead from an overview to the records someone needs to act on. Avoid showing a red KPI without explaining the affected items, reason, accountable owner and next step.
| Reporting view | What it should show | Action and owner |
|---|---|---|
| Leadership & category review | What it should showEligible spend, spend under management, contract coverage, supplier/category concentration and data-quality coverage, with period/entity filters. | Action and ownerCategory owners select sourcing priorities, investigate unmanaged spend and assign data-cleanup work. Drill to the contributing transactions and agreed targets. |
| Sourcing & contracts | What it should showEvents by stage and owner, milestone slippage, upcoming contract expiry, renewal lead time and separately labelled savings stages. | Action and ownerSourcing leads unblock decisions and plan renewals. Give each event a next milestone; finance validates realised savings against an agreed baseline rather than inferring them from spend changes. |
| Buying & approvals | What it should showCompleted requisition cycle times alongside open-item age, current approval step, owner and reason for hold. | Action and ownerBuyers and approvers work a prioritised queue, chase missing information and escalate overdue requests. Open the source request from the report. |
| Supplier delivery | What it should showDue schedules, on-time delivery, actual lead-time distribution, partial receipts and overdue open quantities. | Action and ownerBuyers expedite supply; supplier managers review repeated failures. Separate supplier delays from late internal receipt entry and investigate the evidence. |
| Invoice & payment operations | What it should showFirst-pass match, exception reason, current action owner, blocked value, age, due date and overdue unpaid invoices. | Action and ownerAP routes price issues to buyers, missing receipts to requesters and payment issues to treasury. Keep the owner, next action and source-document link in the queue. |
Use consistent filters, visible units and reporting periods, accessible labels and a clear reset route. Power BI drillthrough pages can carry a selected supplier or category into a detailed view. Approval, correction and payment decisions still need to be recorded in the authorised source workflow; viewing a report does not itself complete them.
Worked example · illustrative figures
An 87% match rate still leaves work to do
This is a fictional example, not a Denova client result. An AP team defines a weekly cohort of 100 distinct eligible PO invoices received. At the stated cut-off, 92 have a recorded first-check outcome: 80 passed and 12 failed. Eight have no first-check outcome yet.
The report should show 92% assessment coverage alongside the 87.0% match rate. Calling all 20 remaining invoices “match failures” would mix failed checks with work that has not been assessed. Reporting 80 ÷ 100 as the first-pass rate would answer a different question.
Of the 12 failures, suppose five have missing receipts, four have price differences and three have reference errors, using one agreed primary reason per invoice. The dashboard routes them to requesters, buyers and AP respectively. If an invoice has several reasons, show the overlaps and do not add reason counts as if they were distinct invoices.
A later successful match does not change that invoice’s first-pass outcome. Keep its current resolution status beside the historical result. Invoice value, payment due date and current owner then help the team prioritise the queue; the eight unassessed items need a separate owner and age view.
05 · Make the report dependable
Specify refresh, access and operational ownership
Power BI is not automatically real-time. Import models reflect the most recent successful data refresh; source extracts may already be older. Agree a refresh schedule that supports the decision, display both source freshness and report refresh time, and define who responds when either fails. Microsoft’s data-refresh guidance explains the relevant behaviours.
Name a procurement owner for KPI definitions, a source owner for each feed and a technical owner for the model and report. Document changes to mappings, targets and calculations so users can explain movements in a trend.
Agree access by role, entity and category, including what users can export. Where appropriate, use row-level security and test the intended roles and workspace permissions. Check source-document links separately: access to the report should not imply authority to approve a purchase or make a payment.
Automated extraction can reduce repetitive preparation, but it cannot repair an undefined process or guarantee accurate inputs. Retain reconciliations, exception monitoring and a documented route for correcting source records.
Relevant client evidence
Reliable reporting starts upstream
Denova’s Zip case study describes work on required intake fields, integrations, consistent approval routing and reporting exports, supported by documented processes and change governance.
That is relevant to procurement reporting because the usefulness of a KPI depends on what the operational systems capture. The case supports the importance of ownership and source-data quality; it does not document a Power BI implementation or a measured KPI uplift. The article states that formal metrics were not in place at the time.
Read how embedded support helped a global business gain more value from its procurement platform.
Copy into your reporting brief
Agree the requirements and test the answers
Start with a small number of decisions and test the report against records whose expected results are known. Ask procurement, AP and finance to validate both summary measures and the action queues behind them.
☐ KPI formulas, populations, date roles, exclusions and targets documented.
☐ Spend, tax, credit-note, currency and savings rules approved by finance.
☐ Source fields, document keys, line mappings and event history available.
☐ Duplicate, missing, cancelled, returned and partially completed records tested.
☐ Counts and values reconciled to source totals at the same cut-off.
☐ Unknown data and zero denominators shown explicitly.
☐ Each exception exposes its reason, owner, age, next action and source link.
☐ Access, exports, source permissions and refresh-failure handling tested.
☐ Business acceptance, documentation, handover and support ownership agreed.
Useful acceptance cases include one PO line with two receipts, an invoice that fails then passes, a supplier with two system IDs and an overdue unpaid invoice. Check that totals stay correct when users change filters or drill to detail.
Use the Power BI reporting brief guide to develop the requirements, or the finance reporting guide for related ownership, ageing and reconciliation considerations.
Stay informed
More practical procurement and data insights
Get Denova’s newsletter and occasional updates on procurement, finance and data.
Plan the next step
Build reporting around your procurement decisions
Start with the questions your team needs to answer, then check the data and ownership behind them. Explore Denova’s Power BI consulting services or discuss a procurement reporting requirement with us.