Invoice receipt before goods receipt
These items reverse the expected receipt-before-invoice order and can be opened for timing and matching review.
Power BI Reporting
Purchase-to-Pay Flow and Bottleneck Review
A working six-page Power BI report and verified event-log build using the complete BPI Challenge 2019 source to show purchase-order routes, waiting time, repeated work, payment risk and individual item history.
Working purchase-to-pay Power BI reportOpen working purchase-to-pay power bi report
Six Power BI Desktop pages connect the overall process position to route, transition, exception and item-level evidence.
One purchase-order item, eleven recorded events
An invoice was blocked, cancelled and later cleared twice.
Item 4507020650/00140 belongs to the anonymised purchasing process published for BPI Challenge 2019. It moved from purchase-order creation to goods receipt and invoice receipt, then passed through a payment block and invoice cancellation before clearing.
A process owner, procurement manager, receiving manager, Accounts Payable manager and process analyst can inspect the full sequence, compare it with common routes and decide whether the recorded hand-offs warrant investigation.
The process-owner question
Which purchase items wait, repeat work or encounter a payment block?
The analysis keeps every event in order, groups identical complete sequences into variants and measures the elapsed time between adjacent activities. It helps the process owner select a route and its exact items for investigation without claiming that sequence alone proves the cause.
- Complete sequence variants
- 11,973
- Items with repeated activities
- 22,438
- Explicit payment-block items
- 122
The recorded purchase-to-pay route
Actual activity names replace an abstract process diagram.
Purchase-order creation, goods receipt, invoice receipt and clearing form the main route. Invoice-first cases, repeated work and recorded payment blocks remain visible as branches that can be opened down to the underlying item and events.
What the complete log shows
The common route covers one item in five, not the whole process.
The most frequent complete sequence is purchase-order creation, vendor invoice creation, goods receipt, invoice receipt and clearing. It contains 50,286 items, or 19.98% of the full log. Across all items, the median recorded duration is 64.0 days.
Median invoice-to-receipt wait
This elapsed time is calculated only where an invoice receipt is followed by a goods receipt with valid timestamps.
Median block-removal-to-clearing wait
The recorded transition is about 25.1 days at the median and is a practical hand-off for the process owner to examine.
Purchase-order item 4507020650_00140
The block was removed before clearing, but the route still needs review.
The item was created on 16 Apr 2018. A quantity change was recorded immediately before goods receipt. Accounts Payable recorded the invoice on 06 Aug 2018. The Set Payment Block event followed eight minutes later.
Cancel Subsequent Invoice followed fourteen days later. Remove Payment Block was then recorded, the invoice cleared nine days later and a second clearing event appeared in November. The project retains both clearing events: it does not silently delete the repetition.
- Item category
- 3-way match, invoice before GR
- Document type
- Standard PO
- Recorded duration
- 200.2 days
- Outcome
- Invoice cleared
Investigate the cancelled invoice and payment-block route. The block was removed before the invoice was cleared.
Working Power BI report
Six report pages connect process scale to routes, waits, exceptions and one item.
The supplied PBIX contains six connected Desktop pages and 63 visual containers. Use the page selector to inspect each original report page, then open it full size when the record labels need closer review.
The report's broad payment-block flag covers 55,934 items. The separately verified event-log build counts 122 items containing an explicit Set Payment Block event. They answer different questions and are not presented as reconciled measures.
Download the working PBIXPage 01 of 6
Where does purchase to pay slow down?
- Question answered
- Where does purchase-to-pay work slow down, and which hand-offs should be reviewed first?
- How someone would use it
- Start with hand-offs that combine high volume with high median or p90 waiting time, then open the retained transition evidence.
- Main insight
- The report covers 251,734 purchase-order items and 1,595,923 events. The typical adjacent-event wait is 51.3 hours across 11,973 recorded routes.
- What not to conclude
- The time series retains timestamp exceptions and historical outliers. Sequence and elapsed time identify records for review but do not establish root cause.
Full-log scale and validation
The website figures are generated from the retained build.
251,734purchase-order items
1,595,923recorded events
42activities
627recorded users
11,973complete variants
17/17checks passed
- 01
The XES checksum matches the publisher file before transformation begins.
- 02
All 251,734 purchase-order items and 1,595,923 events reach the process model.
- 03
Events stay in source order when two activities share the same timestamp.
- 04
Every item belongs to one complete activity-sequence variant.
- 05
Repeated activities remain separate from named changes, cancellations and reversals.
- 06
The 320 timestamp exceptions stay in event counts but are excluded from elapsed-time measures.
- 07
The retained trace reproduces its eleven source events and final clearing outcome.
Build result
PASS: 17 of 17 checks
The build keeps 2018 and 2019 events for valid elapsed-time calculations. The complete source range is retained because 320 publisher records fall outside that window.
- Documents
- 76,349
- Elapsed-time period
- 2018 to 2019
- Timestamp exceptions
- 320
- Trace
- 4507020650_00140
Data origin and stated limits
The process analysis and working Power BI report are retained with clear release limits.
The process analysis uses the BPI Challenge 2019 event log published by 4TU.ResearchData under CC BY 4.0. The records are historical, anonymised research data and do not describe current performance.
The PBIX, six Power BI Desktop captures and report structure are retained in the repository. A dated refresh log, representative Performance Analyzer capture and native accessibility review are not retained, so the example is not described as a production deployment. Event sequence, frequency and elapsed time can identify records for investigation, but they do not establish root cause. The source is historical, its monetary values were translated by the publisher and missing events may reflect the systems represented in the log.
Industrial purchasing and Accounts Payable
Purchase Order, Receipt and Invoice Reconciliation
An Accounts Payable analyst holds an invoice until the purchase order, warehouse receipt and supplier bill agree within tolerance. Every unresolved difference keeps its reason and the team responsible for the next step.
Decision: Can the supplier invoice be released for payment, held for investigation or returned for correction?
- Platform
- BPI Challenge 2019 with a SQL and Python matching build
- Data scale
- 251,734 purchase order items and 1,595,923 events from the complete BPI Challenge 2019 event log, verified
- Maturity
- Built and checked with SQL and Python. All 21 controls pass, the item and event totals agree, and the rebuild is repeatable.
Next step
Connect process findings to the purchase items behind them.
Start with the question the report needs to answer, the records that supply it and one result that needs checking.