Procure-to-Pay: Object-Centric Process Mining Analysis

1. 0Executive summary
2. 1Method, lineage and assumptions
3. 2Event log
4. 3Structure
5. 4Process model
6. 5Variants and timing
7. 6Bottlenecks and payment timing
8. 7Conformance and three-way match
9. 8Exception registers
10. 9Data quality
11. 10Findings and recommended actions
12. AAppendix A — SuiteQL used
13. BAppendix B — Reducer logic
14. CAppendix C — Worked hand-check
15. DAppendix D — Glossaries
16. EAppendix E — Run metadata

0Executive summary

The account's purchase-to-pay flow is disciplined where a purchase order exists. Every PO maps to at most one receipt and one bill; 698 of 740 POs run the complete Order Placed → Received → Billed → Paid chain in a median of four days; every one of the 705 billed POs matches its bill total exactly; and the single voided payment was reversed and re-issued the same day. Unlike the sales side there is one genuine consolidation — a single payment covering seven bills — and a bill-from-receipt path used 19 times, so the perspectives do diverge and the divergences are explained in §4.

The exposure sits outside the PO-controlled flow and in payment timing:

1. The account pays a median 28 days before due. 994 of 1,004 bill→payment pairs (99.0%) were settled early; the typical bill is paid three days after it is entered against 30-day terms. On roughly $1.7M of annual bill volume that is ~$130K of working capital permanently surrendered (§6). Only one episode of late payment exists — and it is the same vendor cluster as finding 3.
2. 44% of bill value bypasses purchase orders. 312 non-PO bills carry $1,489,907.21 of $3,402,733.23; 288 of them are a twice-monthly card-memo cadence from six vendors, but the remainder includes the two largest open payables in the account — Davidson Leasing $120,000.00 and Cloud Consulting $52,550.00 — with no PO, receipt or approval trail. Non-PO bills are 99% of open payables ($182,548 of $184,048).
3. One vendor is the sandbox for every P2P edge case. Generation N accounts for the 7-bill consolidated payment (bills 95–330 days late at settlement), the voided payment, all four vendor returns, both bill credits, the prepayment, seven of fourteen POs pending receipt and the account's longest case (345 days). Separately, 19 POs are received-not-billed — $29,706.97 of accrual exposure, oldest 85 days — and two POs show received quantity with no receipt document.

1Method, lineage and assumptions

Figure 1 — Row funnel. Nothing is lost between mainline rows and objects; the reduction from 3,492 to 1,053 is the linking itself.

Assumptions register

2Event log

As on the sales side, the two link sources agree completely where both apply: all 1,432 PO→receipt and PO→bill edges are present in both. Bill→payment (1,005) and receipt→bill (19, linktype BillRcpt) exist only in nexttransactionlinelink. Example edges: PO1202 2026-09-17 → IR1211 2026-09-18 [ShipRcpt + createdfrom]; PO1204 2026-09-03 → #42202 2026-09-05 [OrdBill + createdfrom]. Example events: Order Placed PO388 2026-06-01; Billed #31726 2026-06-01 (objects: bill, PO388, IR406).

3Structure

Component sizes: 1 doc 39 · 2 docs 307 · 3 docs 2 · 4 docs 702 · 5 docs 1 · 6 docs 1 · 14 docs 1. Strict 1:1:1:1 chains: 704 of 740 POs (95.1%). Lines per PO: median 8, P90 20, max 29.

4Process model

Figure 2 — Directly-follows graph across all 1,053 components. Labels: count · median wait. Main PO path in emerald; the non-PO Billed → Paid entry (291) is drawn as a second start. Grey arcs are the minority routes. Return / credit / void edges (≤ 2 each) are listed in the table.

Lifecycle lengths: PurchOrd 4 events 703 · 1 event 18 · 2 events 16 · 5 events 2 · 3 events 1; VendBill 2 events 1,001 · 1 event 13 · 3 events 3; ItemRcpt 1 event 708 · 2 events 19; VendPymt all single. Convergence = 1 on every transition: no single event touches two objects of the same type, even in the consolidated payment (it touches seven bills but each bill is one object of type VendBill per edge).

PO perspective versus payment perspective

Three divergences, each structural. (1) The payment view has 296 more Billed → Paid transitions and a 110-day maximum: these are the non-PO bills, invisible from any PO. (2) The payment view alone contains Billed → Billed (6) and an 8-event trace — that is the consolidated payment #42228 walking VB01 → VB02 → … → VB08 in one case; the PO view sees none of it because those bills have no PO. (3) The PO view has 36 traces ending before payment (18 unreceived, 16 received-not-billed, 1 in return, 1 billed-unpaid) that the payment view cannot see. No divergence involves partial receipt or split billing; §3 rules those out.

5Variants and timing

Component-level variants; cycle = first to last event, whole days; percentiles exact (A12). Sixteen distinct variants; the top twelve cover 1,049 of 1,053.

Figure 3 — Components by variant, log-scaled bars, exact counts printed.

Remaining four (one each): the 14-event Generation N case anchored on PO1158 (345 days; §8-E); PO1162 with two bills and two payments; VB05 Billed → Paid (voided) → Paid; and one Order Placed → Billed with no receipt or payment.

Monthly volume

Figure 4 — Documents per month by transaction date. The PO/receipt line runs at a flat 18 a month with quarterly spikes (Apr, Jul, Nov) and a step-up from June 2026; bills run at 30 a month — the 12-a-month surplus is the recurring non-PO cadence. September 2026 payment value ($538K) includes the $341,743 consolidated payment.

6Bottlenecks and payment timing

The PO flow has no bottleneck: receipt on the order day, bill the next day, payment three days later. The waiting time worth managing is not a delay — it is the opposite.

Payment timing against due date

994 of 1,004 payments (99.0%) were made before the due date, a median of 28 days early; bill-to-payment is a median of 3 days (30% same day) against what are evidently 30-day terms. Example: #40503 due 2024-12-03 paid by 1010 on 2024-11-01 (−32 days); #40505 due 2025-02-01 paid by 1012 on 2025-01-01 (−31). The only late payments are #206 (Cloud Consulting, +2 days) and the seven Generation N bills settled by #42228 at 95–330 days past due (§8-E). Working-capital estimate: bill value over the 24-month window is $3.40M ≈ $1.70M a year; paying a median 28 days early holds ≈ $1.70M × 28 ÷ 365 ≈ $130K permanently ahead of terms. If no early-payment discount is being captured, that is float given away.

Ten slowest components

7Conformance and three-way match

Figure 6 — 1,053 components by conformance outcome against the two reference models (A8).

Deviation patterns (all 17)

Three-way match at PO line level

Figure 7 — 7,721 PO lines classified by ordered / received / billed quantity.

8Exception registers

Complete lists. Sortable. Amounts USD (absolute). Ages as at 2026-09-04; negative = future-dated.

8-A · Open vendor bills (13) — $184,048.00

8-B · Non-PO bills by vendor (312 bills, $1,489,907.21)

8-C · Received, not billed (19 POs, $29,706.97)

8-D · POs with no receipt (18, $11,900.61)

8-E · The Generation N cluster

One vendor carries every P2P edge case in the account: the only consolidated payment, the only late payments, the only void, all returns, both credits, the prepayment and the longest case. Whether Generation N is a real supplier relationship in distress or the demonstration vendor for procurement scenarios, it warrants one consolidated review rather than eleven tickets.

8-F · Unlinked documents traced to source

9Data quality — what limits the analysis

10Findings and recommended actions

1. Move the payment run to due dates. 994 of 1,004 payments were early, a median of 28 days ahead of terms; only three PO chains (PO388, PO389, PO390) were paid on a 14-day cycle and none on a 30-day one. At ≈ $1.70M of annual bill value that is ≈ $130K of cash permanently surrendered (§6 formula). Either confirm an early-payment discount is being taken on the recurring vendors (FrisCo, Dell, Brocade, Staples, XCOM, CDW — 288 bills) or schedule payment for due date − 2. Exception: the seven Generation N bills settled 95–330 days late by #42228 show the opposite failure and need a vendor-level explanation.
2. Bring non-PO spend under control documents. $1,489,907.21 (43.8%) of bill value has no purchase order, and 99% of open payables — Davidson Leasing $120,000.00 (#27120, due 2026-10-02), Cloud Consulting $52,550.00 (VB843) and $500.00 (VB842) — is non-PO with no receipt or approval evidence. Put the six recurring vendors on blanket POs or vendor contracts so their 288 bills match automatically; require a PO or an approval record above a threshold for the rest. Clear the four bills in Pending Approval, starting with #41773 (Bedline, 35 days past due).
3. Book the GR/IR accrual and run one Generation N review. 19 POs hold $29,706.97 of goods received but unbilled (§8-C; oldest PO1018, 85 days; The Apparel Co and Mac Oca & Co. account for ten) — chase the vendor invoices or accrue at period end. Correct PO383 and PO1174, which show received quantity with no receipt document. Then take the Generation N register (§8-E) as a single agenda: chase the VRMA21 credit ($149.95, 32 days), apply the open credit ($29.99) and prepayment ($99.97), apply or refund payment 167 ($59.98), and receive or close nine small pending POs.

AAppendix A — SuiteQL used

Verbatim as executed. Q3–Q5 feed the shared reducer core; Q6–Q7 feed the three-way-match pass; the rest are probes and registers.

Q1 — Link-type census

SELECT p.type AS prev_type, n.type AS next_type, l.linktype, COUNT(*) AS link_rows,
       COUNT(DISTINCT l.previousdoc || '-' || l.nextdoc) AS distinct_pairs
FROM nexttransactionlinelink l JOIN transaction p ON p.id = l.previousdoc JOIN transaction n ON n.id = l.nextdoc
WHERE p.type IN ('PurchReq','PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth','VPrep','Check')
   OR n.type IN ('PurchReq','PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth','VPrep','Check')
GROUP BY p.type, n.type, l.linktype ORDER BY COUNT(*) DESC

Q2 — Header census

SELECT t.type, COUNT(*) AS docs, COUNT(DISTINCT t.status) AS statuses,
       TO_CHAR(MIN(t.trandate),'YYYY-MM-DD') AS first_date, TO_CHAR(MAX(t.trandate),'YYYY-MM-DD') AS last_date,
       SUM(CASE WHEN t.trandate > SYSDATE THEN 1 ELSE 0 END) AS future_dated,
       SUM(CASE WHEN t.memo LIKE 'TEST%' THEN 1 ELSE 0 END) AS test_memo
FROM transaction t WHERE t.type IN ('PurchReq','PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth','VPrep','Check')
GROUP BY t.type ORDER BY COUNT(*) DESC

Q3 — Streamed lines (keyset on uk, no ORDER BY)

SELECT tl.uniquekey AS uk, tl.transaction AS tid, tl.mainline, tl.createdfrom
FROM transactionline tl JOIN transaction t ON t.id = tl.transaction
WHERE t.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth')

Q4 — Materialised headers

SELECT t.id, t.type, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, TO_CHAR(t.duedate,'YYYY-MM-DD') AS duedate,
       t.status, t.entity, t.foreigntotal AS total, t.foreignamountunpaid AS unpaid, t.memo
FROM transaction t WHERE t.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth')

Q5 — Materialised distinct links

SELECT DISTINCT l.previousdoc, l.nextdoc, l.linktype
FROM nexttransactionlinelink l JOIN transaction p ON p.id = l.previousdoc JOIN transaction n ON n.id = l.nextdoc
WHERE p.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth')
  AND n.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth')

Q6 — Streamed PO child lines (three-way match)

SELECT tl.uniquekey AS uk, tl.transaction AS tid, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS podate, t.status,
       tl.item, tl.quantity AS qty, tl.quantityshiprecv AS qrecv, tl.quantitybilled AS qbill, tl.rate, tl.foreignamount AS amt, tl.isclosed
FROM transactionline tl JOIN transaction t ON t.id = tl.transaction
WHERE t.type = 'PurchOrd' AND tl.mainline = 'F' AND tl.taxline = 'F'

Q7 — Bills per PO for header amount match

SELECT b.id AS bill_id, b.tranid AS bill_tranid, TO_CHAR(b.trandate,'YYYY-MM-DD') AS bill_date,
       ROUND(ABS(b.foreigntotal),2) AS bill_total, l.previousdoc AS po_id
FROM transaction b JOIN nexttransactionlinelink l ON l.nextdoc = b.id AND l.linktype = 'OrdBill'
JOIN transaction p ON p.id = l.previousdoc AND p.type = 'PurchOrd'
WHERE b.type = 'VendBill' GROUP BY b.id, b.tranid, b.trandate, b.foreigntotal, l.previousdoc

Q8 — Live status glossary

SELECT x.type, x.status, x.docs, BUILTIN.DF(t.status) AS label
FROM (SELECT type, status, COUNT(*) AS docs, MIN(id) AS sample_id FROM transaction
      WHERE type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt','VendCred','VendAuth','VPrep','PurchReq') GROUP BY type, status) x
JOIN transaction t ON t.id = x.sample_id ORDER BY x.type, x.docs DESC

Q9 — Approval observability and terms population

SELECT t.type, COUNT(*) AS docs, SUM(CASE WHEN t.duedate IS NULL THEN 1 ELSE 0 END) AS null_duedate,
       SUM(CASE WHEN t.terms IS NULL THEN 1 ELSE 0 END) AS null_terms,
       (SELECT COUNT(DISTINCT sn.recordid) FROM systemnote sn JOIN transaction x ON x.id = sn.recordid
         WHERE sn.recordtypeid = -30 AND sn.field = 'TRANDOC.KSTATUS' AND x.type = t.type) AS docs_with_status_notes
FROM transaction t WHERE t.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt') GROUP BY t.type

Q10 — Register 8-B: non-PO bills by vendor

SELECT v.entityid AS vendor, COUNT(*) AS bills, ROUND(SUM(ABS(t.foreigntotal)),2) AS total, ROUND(SUM(t.foreignamountunpaid),2) AS unpaid,
       MIN(TO_CHAR(t.trandate,'YYYY-MM-DD')) AS first_date, MAX(TO_CHAR(t.trandate,'YYYY-MM-DD')) AS last_date, MAX(t.memo) AS sample_memo
FROM transaction t LEFT JOIN vendor v ON v.id = t.entity
WHERE t.type = 'VendBill' AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l JOIN transaction p ON p.id = l.previousdoc
                                          WHERE l.nextdoc = t.id AND p.type = 'PurchOrd')
GROUP BY v.entityid ORDER BY SUM(ABS(t.foreigntotal)) DESC

Q11 — Register 8-A: open bills

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, TO_CHAR(t.duedate,'YYYY-MM-DD') AS duedate,
       BUILTIN.DF(t.status) AS status_label, v.entityid AS vendor, ROUND(ABS(t.foreigntotal),2) AS total,
       ROUND(t.foreignamountunpaid,2) AS unpaid, TRUNC(SYSDATE)-TRUNC(t.duedate) AS days_past_due, t.memo,
       (SELECT MAX(p.tranid) FROM nexttransactionlinelink l JOIN transaction p ON p.id = l.previousdoc
         WHERE l.nextdoc = t.id AND p.type = 'PurchOrd') AS po
FROM transaction t LEFT JOIN vendor v ON v.id = t.entity
WHERE t.type = 'VendBill' AND t.foreignamountunpaid > 0 ORDER BY t.foreignamountunpaid DESC

Q12 — Register 8-C: received-not-billed POs

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, BUILTIN.DF(t.status) AS status_label, v.entityid AS vendor,
       ROUND(ABS(t.foreigntotal),2) AS total, TRUNC(SYSDATE)-TRUNC(t.trandate) AS age_days,
       (SELECT MAX(r.tranid) || ' ' || TO_CHAR(MAX(r.trandate),'YYYY-MM-DD') FROM nexttransactionlinelink l
         JOIN transaction r ON r.id = l.nextdoc WHERE l.previousdoc = t.id AND r.type = 'ItemRcpt') AS receipt
FROM transaction t LEFT JOIN vendor v ON v.id = t.entity
WHERE t.type = 'PurchOrd' AND t.status = 'F' ORDER BY ABS(t.foreigntotal) DESC

Q13 — Register 8-D: POs with no receipt

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, BUILTIN.DF(t.status) AS status_label, v.entityid AS vendor,
       ROUND(ABS(t.foreigntotal),2) AS total, TRUNC(SYSDATE)-TRUNC(t.trandate) AS age_days, t.memo
FROM transaction t LEFT JOIN vendor v ON v.id = t.entity
WHERE t.type = 'PurchOrd' AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l JOIN transaction n ON n.id = l.nextdoc
                                          WHERE l.previousdoc = t.id AND n.type = 'ItemRcpt')
ORDER BY t.trandate

Q14 — Register 8-E / 8-F: returns, credits, prepayments, voided and unlinked payments

SELECT t.type, t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, BUILTIN.DF(t.status) AS status_label,
       v.entityid AS vendor, ROUND(ABS(t.foreigntotal),2) AS total, t.memo,
       (SELECT COUNT(*) FROM nexttransactionlinelink l WHERE l.nextdoc = t.id) AS inbound,
       (SELECT COUNT(*) FROM nexttransactionlinelink l WHERE l.previousdoc = t.id) AS outbound
FROM transaction t LEFT JOIN vendor v ON v.id = t.entity
WHERE (t.type = 'VendPymt' AND (t.status = 'V' OR NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l WHERE l.nextdoc = t.id)))
   OR (t.type = 'ItemRcpt' AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l WHERE l.nextdoc = t.id))
   OR t.type IN ('VendCred','VendAuth','VPrep')
ORDER BY t.type, t.trandate

Q15 — Consolidated payment reconciliation

SELECT b.id, b.tranid, TO_CHAR(b.trandate,'YYYY-MM-DD') AS bill_date, TO_CHAR(b.duedate,'YYYY-MM-DD') AS due,
       ROUND(ABS(b.foreigntotal),2) AS total, BUILTIN.DF(b.status) AS status_label, b.memo,
       TRUNC(TO_DATE('2026-09-07','YYYY-MM-DD'))-TRUNC(b.duedate) AS days_late_at_payment
FROM transaction b JOIN nexttransactionlinelink l ON l.previousdoc = b.id AND l.nextdoc = 42228
WHERE b.type = 'VendBill' ORDER BY b.trandate

Q16 — Monthly volumes

SELECT TO_CHAR(t.trandate,'YYYY-MM') AS ym, t.type, COUNT(*) AS docs, ROUND(SUM(ABS(t.foreigntotal)),2) AS total
FROM transaction t WHERE t.type IN ('PurchOrd','ItemRcpt','VendBill','VendPymt') AND t.trandate < TO_DATE('2026-10-01','YYYY-MM-DD')
GROUP BY TO_CHAR(t.trandate,'YYYY-MM'), t.type ORDER BY 1, 2

BAppendix B — Reducer logic

Four sqlReduce passes. Passes 1–3 share Q3 (stream) + Q4 + Q5 (materialised) and the core below; pass 4 streams Q6 with Q7 and PO headers materialised. Only the returned summaries entered the model context.

// fold — keep mainline rows and their createdfrom pointer
fold(acc,page){ for (r of page){ acc.linesIn++; if (r.mainline==='T'){ acc.mainlines++;
  if (r.createdfrom) acc.cf.push([+r.createdfrom,+r.tid]); } } return acc; }
// finalize — docs from Q4; edges = distinct(Q5) ∪ acc.cf; drop self/out-of-scope; record source per edge
// events: activity by type; VendPymt status 'V' → 'Paid (voided)'; objects = own + upstream;
//         payments inherit PurchOrd via VendBill; bills inherit ItemRcpt via BillRcpt
RANK = { 'Order Placed':0, 'Received':1, 'Billed':2, 'Paid':3, 'Paid (voided)':3, 'Return Authorised':4, 'Credited':5 }
cmp  = (a,b) => a.ts < b.ts ? -1 : a.ts > b.ts ? 1 : (RANK[a.activity]-RANK[b.activity]) || (a.docId-b.docId)
// components: union-find → sorted trace, variant, cycle = daysBetween(first,last)

// Pass 1: funnel; objects by type; edge/doc reachability by source; seven multiplicity histograms
// Pass 2: H.ocdfg(events,{tieBreak}); PO traces; payment traces (payment + bills + their POs + POs' receipts
//         + BillRcpt receipts); H.dfg on both; variants; transitions; two-model conformance;
//         due-date timing: for each non-voided bill→payment pair, rel = daysBetween(bill.duedate, pay.date)
// Pass 3: payment perspective detail; variants 5–16; slowest 10; open PO components by last activity × status
// Pass 4 (three-way match): per PO line classify (qty, qrecv, qbill, isclosed) →
//         full | openNotRecv | recvNotBilled | billedNotRecv | overBilled | overRecv | partialRecv | partialBill | closedShort
//         exposure: Σ (qrecv − qbill) × rate on recvNotBilled; header: Σ OrdBill bills vs PO foreigntotal (exact / ≤1% / over / under)

Conformance rules — PO-backed: starts with Order Placed; one PO; no return/credit/void; ≤ 1 Billed; ≤ 1 Paid; nothing after Paid; Paid requires Billed and Received; every Received after the Billed → "billed before received". Non-PO: exactly Billed → Paid (complete) or Billed (open); anything else deviant with a named reason.

CAppendix C — Worked hand-check

Arithmetic checks. Conformance 698 + 35 + 291 + 12 + 17 = 1,053 ✓; (1,053 − 17) / 1,053 = 0.9839 ✓. Edges 722 + 705 + 1,005 + 19 + 4 + 1 + 1 + 1 = 2,458 ✓. Bill value: PO-backed 1,912,826.02 + non-PO 1,489,907.21 = 3,402,733.23; non-PO share 43.8% ✓. Open bills: 182,548.00 + 1,500.00 = 184,048.00 = Σ register 8-A ✓. Received-not-billed: Σ 19 PO totals = 29,706.97 = line-level exposure ✓. Due-date buckets 99 + 895 + 0 + 1 + 2 + 7 = 1,004 ✓. Deviations 5 + 3 + 2 + 2 + 1 + 1 + 1 + 1 + 1 = 17 ✓. Component sizes 39 + 307×2 + 2×3 + 702×4 + 5 + 6 + 14 = 3,492 documents ✓.

DAppendix D — Glossaries

EAppendix E — Run metadata