Order-to-Cash: 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
8. 7Conformance
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 and revision log

0Executive summary

The account's order-to-cash flow is structurally simple and fast. Every sales order maps to at most one fulfillment, one invoice and one payment; 704 of 845 cases (83.3%) run the complete Order → Shipped → Invoiced → Paid chain and 654 of them close on a single calendar day. There is no many-to-many structure, so the object-centric graph, the order perspective and the payment perspective agree everywhere except where documents are absent.

The exceptions, not the main path, are where the value lies:

1. A test-invoice block is distorting A/R. 32 invoices with memo TEST — … (internal ids 42286–42317, no sales order, all status Open) carry $790,017.65 — 85% of the $928,246.62 open invoice balance in scope. Genuine open A/R linked to orders is $138,228.97. Until these are voided or excluded, any A/R aging or DSO figure from this account is wrong by a factor of roughly seven.
2. Twenty orders were billed and paid before shipping (SO4270–SO4287 plus SO3910, SO3985; $25,790.50). Eighteen follow a metronomic 15 / 18 / 12-day rhythm. If real, revenue is recognised ahead of delivery; if seeded, they should be tagged so they stop appearing as exceptions.
3. The fulfillment and approval queues contain probable duplicates. 46 orders have no fulfillment; among the 13 in Pending Approval, Design Excellence Ltd. has two identical trios (SO4314/15/16 and SO4318/19/20 at $5,146.21 / $3,273.99 / $2,697.68) and Godric Motors has SO4293 / SO4313 at the same $1,627.03. One deposited payment, PYMT01 ($934.78, Susan Adams, 2026-08-31), mirrors the applied PYMT675 and is unapplied.

1Method, lineage and assumptions

Data lineage

Figure 1 — Row funnel from raw transaction lines to connected components. Nothing is lost between mainline rows and objects; the reduction from 3,055 to 845 is the linking itself.

Assumptions register

2Event log

Events were built from five document types, one event per document, dated by trandate. Example events: SO2515 Order Created 2026-09-11 · SO2738 Order Created 2026-09-24. Example edges: SO3623 2025-02-11 → INV109 2025-02-11 [OrdBill, OrdRvCom, createdfrom] · SO4102 2026-02-20 → IF5423 2026-02-20 [ShipRcpt, createdfrom].

Objects by type and link reachability

The two link sources agree completely where both apply: all 1,474 order→fulfillment and order→invoice edges are present in both. Invoice→payment edges (736) exist only in nexttransactionlinelink (linktype Payment) because createdfrom is never populated on payments. No edge is reachable from createdfrom alone: it validates the link table but adds no coverage. Credit memos have no links to any in-scope document.

3Structure

Component size distribution: 1 document 91 · 2 documents 22 · 3 documents 8 · 4 documents 724. Example 1:1 chains: SO3542 2024-10-01 → IF4990 2024-10-01 → INV28 2024-10-01 → PYMT17 2024-10-01 · SO3544 2024-10-07 → IF4991 → INV30 → PYMT19, all 2024-10-07.

4Process model

Object-centric directly-follows graph

Figure 2 — Directly-follows graph across all 845 components. Edge labels: count · median wait in days. The dominant path is highlighted; the two minority arcs are the bill-before-ship route. Three single-digit edges (Shipped → Order Created 2, Invoiced → Order Created 1, Order Created → Paid 1) are date-integrity cases and are listed in the table rather than drawn.

Lifecycle lengths by object type: SalesOrd — 1 event 45, 2 events 11, 3 events 8, 4 events 724; CustInvc — 1 event 28, 2 events 736; ItemShip, CustPymt and CustCred are all single-event. Convergence = 1 on every transition (no event touches two objects of the same type) is the numerical statement of the 1:1 finding.

Order perspective versus payment perspective

The perspectives disagree in two places, both explained by object structure rather than error. First, the payment view counts 735 Invoiced → Paid transitions with a P90 of 3 days and a maximum of 273 days, against 724 / 0 / 19 in the order view. The additional eleven are invoice→payment pairs with no linked order — all eleven are TEST-memo invoices (for example INV787 2025-12-14 → PYMT760 2026-09-13, 273 days; INV781 2026-04-27 → PYMT759 2026-09-13, 139 days). They are invisible to the order perspective and they are the only slow payers in the account. Second, the order view sees 83 traces ending before payment (47 order-only, 29 shipped, 7 invoiced) that the payment view cannot see at all, because no payment object exists for them. Neither divergence involves partial shipments or consolidated payments; §3 rules those out.

5Variants and timing

Variants are computed at connected-component level; cycle time is first event to last event in whole days. Percentiles are exact (A11). Twelve distinct variants exist; the top ten cover 842 of 845 components.

Figure 3 — Component count by variant (log-scaled bar length so the minority variants remain legible; exact counts printed).

Remaining two variants: Shipped → Order Created (2; IF4955 2026-09-20 → SO2903 2026-10-01; IF5728 2026-09-07 → SO4305 2026-09-30) and Invoiced → Order Created → Paid (1; INV03 2026-08-25 → SO3129 2026-08-31 → PYMT675 2026-08-31).

Invoiced → Paid waiting-time distribution

Monthly volume by document type

Figure 5 — Documents per month by transaction date, 2024-10 to 2026-09 (2026-10 has a single sales order and is omitted). Volume ran at 27–34 orders a month for twenty months, then rose to 45 in July 2026 and 71 in September 2026 — the September figure is inflated by 57 future-dated orders (§9). Payments (48) exceed invoices (28) in September because the 11 TEST invoices from earlier months were paid that month.

6Bottlenecks

Waiting time by transition (component traces)

The main flow is not a bottleneck: all three normal transitions have a median and P90 of zero days. Waiting time in this account sits entirely in two minority paths — TEST invoices awaiting payment, and orders billed before they ship.

Ten slowest components

7Conformance

Reference model (A8): Order Created → {Shipped, Invoiced in either order, Shipped repeatable} → Paid; exactly one order, one invoice and one payment per component; nothing after Paid; no credit memo. Open prefixes of the model are conforming.

Figure 6 — 845 components by conformance outcome.

Deviation patterns

Figure 7 — The 20 pay-before-ship chains on a common day axis from order date. Markers: order (day 0), invoice, payment, shipment (highlighted). SO3910's shipment at day 365 is clipped at the right edge.

8Exception registers

Complete lists, not samples. Columns are sortable. Amounts in USD. Age and days-past-due are as at 2026-09-04; negative values are future-dated documents.

8-A · Invoices with no sales order (32) — all memo TEST — …

8-B · Sales orders with no fulfillment (46)

8-C · Pay-before-ship chains (20)

8-D · Payments linked to nothing (12)

8-E · Fulfillments with no sales order (10) — out of O2C scope

These are legitimate item fulfillments of transfer orders and vendor returns. They were included because the event log took every ItemShip; a tighter scope would filter on createdfrom type. They are not order-to-cash exceptions.

8-F · Credit memos (3) and the customer-deposit path

8-G · Largest genuine open receivable

SO4296 (Blockster Inc., 2026-06-01, $53,424.00, memo "Invoices > 30 Days > 50000") → IF5722 2026-06-02 → INV759 2026-06-03, due 2026-07-03, $53,424.00 open, 63 days past due. The memo names the demo scenario it exercises. It is the single largest item in the $138,228.97 of order-linked open A/R.

9Data quality — what limits the analysis

10Findings and recommended actions

1. Quarantine the TEST invoice block before anyone reads an A/R report. 32 invoices (§8-A; internal ids 42286–42317; all memo TEST — <customer>; all status Open) hold $790,017.65, or 85% of the $928,246.62 open invoice balance in scope. Genuine order-linked open A/R is $138,228.97. INV790 alone would show Global Information $110,579.17 at 244 days past due; INV762 and INV763 are identical ($16,884.00, Macgruber Incorporated, 2026-08-27). The eleven payments applied to this block are also TEST-tagged and are the account's only slow payers (median 35 days, max 273). Action: confirm with whoever loaded them, then void or delete; until then exclude memo LIKE 'TEST%' from every aging, DSO and collections view.
2. Explain the bill-before-ship cluster SO4270–SO4287. Eighteen orders across eleven customers (§8-C; $25,790.50) were invoiced 15 days after order, paid 18–19 days later and shipped 12 days after payment, with no memo. Two older cases (SO3985; SO3910 shipped 365 days after payment) share the pattern. If these are real, revenue was recognised and cash collected roughly a month before delivery — a cut-off exposure that the order perspective in §4 hides and only the shipment-last variant reveals. If they are seeded scenarios, tag them so they stop surfacing as exceptions. Either way, a saved search on ItemShip.trandate > CustPymt.trandate via nexttransactionlinelink would catch recurrences.
3. Clear the fulfillment and approval queues and resolve the duplicates. 46 orders have no fulfillment (§8-B; $129,046.44): 33 Pending Fulfillment — oldest SO4143 2026-06-15 ($3,952.29, 81 days) and SO4150 2026-07-05 ($12,594.22, 61 days) — and 13 Pending Approval. The approval queue contains two identical trios for Design Excellence Ltd. (SO4314/4315/4316 on 09-01 and SO4318/4319/4320 on 09-14 at $5,146.21 / $3,273.99 / $2,697.68) and a Godric Motors pair (SO4293 / SO4313, both $1,627.03, both 2026-09-30, one in each queue). Collect INV759 ($53,424.00, Blockster Inc., 63 days past due; §8-G). Apply or refund the 12 deposited-but-unapplied payments ($3,245.96; §8-D), starting with PYMT01, which duplicates PYMT675 for Susan Adams on 2026-08-31.

AAppendix A — SuiteQL used

Reproduced verbatim as executed. Q3–Q5 are the three inputs to the reducer passes in Appendix B; the rest are probes, registers and supporting figures. All queries run as the current user with role Administrator.

Q1 — Link-type census between O2C document types

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 ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred','CashSale','CustDep','DepAppl','Deposit')
   OR n.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred','CashSale','CustDep','DepAppl','Deposit')
GROUP BY p.type, n.type, l.linktype
ORDER BY COUNT(*) DESC

Q2 — Header census with date ranges

SELECT t.type, COUNT(*) AS docs,
       TO_CHAR(MIN(t.trandate),'YYYY-MM-DD') AS first_date, TO_CHAR(MAX(t.trandate),'YYYY-MM-DD') AS last_date,
       TO_CHAR(MIN(t.createddate),'YYYY-MM-DD') AS min_created, TO_CHAR(MAX(t.createddate),'YYYY-MM-DD') AS max_created
FROM transaction t
WHERE t.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred','CashSale','CustDep','DepAppl','CustRfnd')
GROUP BY t.type ORDER BY COUNT(*) DESC

Q3 — Streamed line query (keyset on uk, no ORDER BY, 5,000 rows/page)

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 ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred')

Q4 — Materialised headers

SELECT t.id, t.type, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, TO_CHAR(t.trandate,'HH24:MI:SS') AS ttime,
       t.status, t.entity, t.foreigntotal AS total, t.foreignamountunpaid AS unpaid,
       TO_CHAR(t.createddate,'YYYY-MM-DD HH24:MI:SS') AS created
FROM transaction t
WHERE t.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred')

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 ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred')
  AND n.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred')

Q6 — Ship-date population

SELECT COUNT(*) AS fulfillments,
       SUM(CASE WHEN t.shipdate IS NULL THEN 1 ELSE 0 END) AS null_shipdate,
       SUM(CASE WHEN t.actualshipdate IS NULL THEN 1 ELSE 0 END) AS null_actualshipdate
FROM transaction t WHERE t.type = 'ItemShip'

Q7 — Status-change system notes (approval observability)

SELECT t.type, COUNT(DISTINCT sn.recordid) AS docs_with_status_notes, COUNT(*) AS notes
FROM systemnote sn JOIN transaction t ON t.id = sn.recordid
WHERE sn.recordtypeid = -30 AND sn.field = 'TRANDOC.KSTATUS'
  AND t.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt')
GROUP BY t.type

Q8 — Register 8-A: invoices with no inbound link

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, TO_CHAR(t.duedate,'YYYY-MM-DD') AS duedate,
       t.status, BUILTIN.DF(t.status) AS status_label, t.entity, c.entityid AS customer,
       ROUND(t.foreigntotal,2) AS total, ROUND(t.foreignamountpaid,2) AS paid, ROUND(t.foreignamountunpaid,2) AS unpaid,
       TRUNC(SYSDATE)-TRUNC(t.trandate) AS age_days, TRUNC(SYSDATE)-TRUNC(t.duedate) AS days_past_due,
       (SELECT COUNT(*) FROM nexttransactionlinelink l WHERE l.previousdoc = t.id) AS outbound_links, t.memo
FROM transaction t LEFT JOIN customer c ON c.id = t.entity
WHERE t.type = 'CustInvc'
  AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l WHERE l.nextdoc = t.id)
ORDER BY t.foreignamountunpaid DESC

Q9 — Register 8-B: sales orders with no fulfillment

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, t.status, BUILTIN.DF(t.status) AS status_label,
       t.entity, c.entityid AS customer, ROUND(t.foreigntotal,2) AS total, TRUNC(SYSDATE)-TRUNC(t.trandate) AS age_days,
       (SELECT COUNT(*) FROM nexttransactionlinelink l JOIN transaction n ON n.id = l.nextdoc
         WHERE l.previousdoc = t.id AND n.type = 'CustInvc') AS invoices
FROM transaction t LEFT JOIN customer c ON c.id = t.entity
WHERE t.type = 'SalesOrd'
  AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l JOIN transaction n ON n.id = l.nextdoc
                  WHERE l.previousdoc = t.id AND n.type = 'ItemShip')
ORDER BY t.trandate

Q10 — Registers 8-D / 8-F: documents with no links in either direction

SELECT t.type, t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, t.status, BUILTIN.DF(t.status) AS status_label,
       t.entity, c.entityid AS customer, ROUND(t.foreigntotal,2) AS total, ROUND(t.foreignamountunpaid,2) AS unpaid, t.memo
FROM transaction t LEFT JOIN customer c ON c.id = t.entity
WHERE t.type IN ('CustPymt','ItemShip','CustCred')
  AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l WHERE l.nextdoc = t.id)
  AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l WHERE l.previousdoc = t.id)
  AND NOT EXISTS (SELECT 1 FROM transactionline tl WHERE tl.transaction = t.id AND tl.mainline = 'T' AND tl.createdfrom IS NOT NULL)
ORDER BY t.type, t.trandate

Q11 — Register 8-E: source of fulfillments with no sales-order link

SELECT t.id, t.tranid, TO_CHAR(t.trandate,'YYYY-MM-DD') AS trandate, BUILTIN.DF(t.status) AS status_label,
       tl.createdfrom, src.type AS source_type, src.tranid AS source_tranid, t.memo
FROM transaction t
JOIN transactionline tl ON tl.transaction = t.id AND tl.mainline = 'T'
LEFT JOIN transaction src ON src.id = tl.createdfrom
WHERE t.type = 'ItemShip'
  AND NOT EXISTS (SELECT 1 FROM nexttransactionlinelink l JOIN transaction p ON p.id = l.previousdoc
                  WHERE l.nextdoc = t.id AND p.type = 'SalesOrd')
ORDER BY t.trandate

Q12 — Monthly volumes (Figure 5)

SELECT TO_CHAR(t.trandate,'YYYY-MM') AS ym, t.type, COUNT(*) AS docs,
       ROUND(SUM(CASE WHEN t.type IN ('SalesOrd','CustInvc') THEN t.foreigntotal ELSE 0 END),2) AS total
FROM transaction t
WHERE t.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt')
GROUP BY TO_CHAR(t.trandate,'YYYY-MM'), t.type
ORDER BY 1, 2

Q13 — Invoiced→Paid buckets (Figure 4)

SELECT CASE WHEN d = 0 THEN 'a 0' WHEN d BETWEEN 1 AND 3 THEN 'b 1-3' WHEN d BETWEEN 4 AND 7 THEN 'c 4-7'
            WHEN d BETWEEN 8 AND 30 THEN 'd 8-30' WHEN d BETWEEN 31 AND 90 THEN 'e 31-90' ELSE 'f 91+' END AS bucket,
       COUNT(*) AS pairs, ROUND(SUM(amt),2) AS invoice_total
FROM (SELECT DISTINCT i.id, TRUNC(p.trandate)-TRUNC(i.trandate) AS d, i.foreigntotal AS amt
      FROM nexttransactionlinelink l
      JOIN transaction i ON i.id = l.previousdoc AND i.type = 'CustInvc'
      JOIN transaction p ON p.id = l.nextdoc AND p.type = 'CustPymt')
GROUP BY CASE WHEN d = 0 THEN 'a 0' WHEN d BETWEEN 1 AND 3 THEN 'b 1-3' WHEN d BETWEEN 4 AND 7 THEN 'c 4-7'
              WHEN d BETWEEN 8 AND 30 THEN 'd 8-30' WHEN d BETWEEN 31 AND 90 THEN 'e 31-90' ELSE 'f 91+' END
ORDER BY 1

Q14 — TEST-memo census

SELECT t.type, SUM(CASE WHEN t.memo LIKE 'TEST%' THEN 1 ELSE 0 END) AS test_memo, COUNT(*) AS docs,
       ROUND(SUM(CASE WHEN t.memo LIKE 'TEST%' THEN t.foreignamountunpaid ELSE 0 END),2) AS test_unpaid
FROM transaction t
WHERE t.type IN ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred')
GROUP BY t.type ORDER BY 1

Q15 — Status glossary (Appendix D)

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 ('SalesOrd','ItemShip','CustInvc','CustPymt','CustCred') GROUP BY type, status) x
JOIN transaction t ON t.id = x.sample_id
ORDER BY x.type, x.docs DESC

Q16 — Link pairs for the pay-before-ship register (reduced in Worker, Appendix B pass 4)

SELECT DISTINCT l.linktype, p.id AS pid, p.type AS ptype, p.tranid AS ptran, TO_CHAR(p.trandate,'YYYY-MM-DD') AS pdate,
       n.id AS nid, n.type AS ntype, n.tranid AS ntran, TO_CHAR(n.trandate,'YYYY-MM-DD') AS ndate,
       ROUND(p.foreigntotal,2) AS ptotal, BUILTIN.DF(p.status) AS pstatus, c.entityid AS pcustomer, p.memo AS pmemo
FROM nexttransactionlinelink l
JOIN transaction p ON p.id = l.previousdoc
JOIN transaction n ON n.id = l.nextdoc
LEFT JOIN customer c ON c.id = p.entity
WHERE l.linktype IN ('ShipRcpt','PickPack','OrdBill','Payment')
  AND p.type IN ('SalesOrd','CustInvc') AND n.type IN ('ItemShip','CustInvc','CustPymt')

BAppendix B — Reducer logic

Four sqlReduce passes were run. Passes 1–3 share the same three inputs (Q3 streamed, Q4 and Q5 materialised) and the same graph-building core; each returns a different summary so that no single result exceeded the 50 KB cap. Raw rows never entered the model context — only the returned summaries did.

Core: graph and components (shared by passes 1–3)

// fold: keep only 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 from Q5 (ntll) ∪ acc.cf (createdfrom); drop self-links and out-of-scope ids
addEdge(p, n, src, linktype)  // records which source(s) produced each distinct edge
// events: one per doc; objects = own doc + all upstream docs; payments inherit SalesOrd via CustInvc
// same-day tie-break
RANK = { 'Order Created':0, 'Shipped':1, 'Invoiced':2, 'Paid':3, 'Credited':4 }
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 over edges; each component -> sorted event trace, variant string, cycle = daysBetween(first,last)

Pass 1 — event log, reachability, multiplicity

Counts edges by source (both / ntll-only / createdfrom-only), classifies each non-order document by how it was reached, and histograms fulfillments-per-order, invoices-per-order, orders-per-invoice, payments-per-invoice, invoices-per-payment and orders-per-payment (via invoice).

Pass 2 — OC-DFG, perspectives, variants, transitions, conformance

oc = H.ocdfg(events, { tieBreak })            // per-object-type lifecycles and transitions
orderTraces   = SalesOrd → all events whose objects include that order
paymentTraces = CustPymt → { payment, its invoices, their orders, those orders' fulfillments }
H.dfg(orderTraces), H.dfg(paymentTraces)      // perspective edges with median / p90 / max
variants  = groupBy(components, variant) → count, exact median / p90 / max of cycle days
transitions = consecutive event pairs within each component trace → count, median, p90, max, same-day share
conformance per component:
  starts with Order Created; exactly one Order, ≤1 Invoiced, ≤1 Paid; no Credited; nothing after Paid;
  Paid requires Invoiced and Shipped; Shipped after Paid → 'paid before shipped' (flagged separately)
  else complete (has Paid) or open prefix

Pass 3 — registers and open items

Variants 5–12, transition table with examples, ten slowest components with their longest wait, open components by last activity and order status, and the orphan-document registers with totals.

Pass 4 — pay-before-ship register (whole contract over Q16)

Indexes SO→IF, SO→INV, INV→PYMT from the 2,210 distinct pairs; for every order with all three, emits the chain where if_date > pymt_date with the three inter-document gaps; also returns the two hand-check chains in Appendix C.

CAppendix C — Worked hand-check

Two components from the dominant variant, with every internal id, so the chain can be re-derived from the record pages or from Q5 with WHERE l.previousdoc IN (…).

Arithmetic checks. Open invoice balance: 790,017.65 (TEST, §8-A) + 138,228.97 (order-linked) = 928,246.62 ✓. Conformance: 704 + 61 + 80 = 845 ✓; (704 + 61) / 845 = 0.9053 ✓. Edges: 742 + 732 + 736 = 2,210 ✓. Deviations: 33 + 20 + 12 + 12 + 3 = 80 ✓. Invoiced→Paid pairs: 658 + 29 + 20 + 22 + 5 + 2 = 736 ✓ (the component-level transition count of 735 excludes SO3129's payment, which follows Order Created in its trace).

DAppendix D — Glossaries

EAppendix E — Run metadata and revision log

Revision log