Of the 845 end-to-end cases in my NetSuite test account, 704 ran the complete chain from order to shipment to invoice to payment, and 654 of those closed on a single calendar day. The order-to-cash flow on this account is about as clean as one gets. The report spends two paragraphs on that, and then it turns to the 80 cases that didn't conform, because on a flow this clean the exceptions are where all the value is.
That's the Order-to-Cash Object-Centric Process Mining prompt, and it's the anchor of the seven process-mining prompts that went into the Sonar AI Prompt Library in September. If you're new to this, Sonar AI is an AI agent that runs inside NetSuite. Every prompt in the library is a playbook that I engineered and tested against live NetSuite data, and you run it inside your own account, against your own records. Nothing leaves the account, and nothing is written to it.
Documents as Objects, Links as Edges
Process mining rebuilds a business process from the records it left behind, as it was executed rather than as it was designed. The object-centric version treats every document as an object, every link between documents as an edge, and every connected cluster of documents as a case. NetSuite keeps those links in a table called nexttransactionlinelink, and the prompt unions them with the created-from pointer on each transaction line so that neither source has to be trusted alone.
On the test account that meant streaming 21,032 transaction lines in five pages, keeping the 3,055 mainline rows, merging 2,942 distinct link pairs down to 2,210 edges, and running union-find over them to get 845 components. The report prints that funnel as a table so you can see that nothing was lost between the raw rows and the cases. The two link sources agreed on every one of the 1,474 edges where both applied, which validates the link table without adding coverage.
Then it builds the event log, the directly-follows graph, the variant table, the waiting-time distributions, and a conformance check against a reference model it states up front: one order, then shipment and invoice in either order, then exactly one payment, nothing after payment, no credit memo.
What the Exceptions Said
Twelve distinct variants exist. The top one covers 704 components. The rest is where the report earns its keep.
A test-invoice block was distorting receivables. Thirty-two invoices with a memo starting "TEST," contiguous internal IDs, no sales order behind any of them, and all of them open, carry $790,017.65 of the $928,246.62 open invoice balance. Genuine order-linked open A/R is $138,228.97. The eleven payments applied to that block are also test-tagged, and they're the account's only slow payers, at a median of 35 days and a maximum of 273. Until the block is voided or excluded, any aging or DSO figure from this account is wrong by a factor of about seven.
Twenty orders were billed and paid before they shipped. Eighteen of them form a cluster, SO4270 through SO4287, ordered June through August across eleven customers, and they follow a metronomic rhythm: invoice 15 days after the order, payment 18 or 19 days after that, shipment 12 days after payment. Total value is $25,790.50. If these are real, then revenue was recognized and cash collected about a month before delivery, which is a cutoff exposure. If they're seeded scenarios, then they should be tagged so they stop appearing as exceptions. Either way, a saved search on fulfillments dated after their payment would catch a recurrence. The order perspective hides this pattern entirely. Only the shipment-last variant reveals it.
The queues contain probable duplicates. Forty-six orders have no fulfillment. Among the thirteen in Pending Approval, Design Excellence Ltd. has two identical trios, entered on September 1 and September 14 at $5,146.21, $3,273.99, and $2,697.68 each time. Godric Motors has a pair at the same $1,627.03 on the same date, one in each queue. And one deposited payment for $934.78 from Susan Adams is an exact mirror of another payment that was applied, dated the same day, and is sitting unapplied.
Two Perspectives on the Same Flow
One thing that I like about the object-centric method is that it lets you read the same account from the order's point of view and from the payment's point of view, and then compare them. On the test account, the two disagreed in exactly two places, and the report explains both.
The payment view counts eleven more invoice-to-payment transitions than the order view, with a maximum wait of 273 days instead of 19. Those eleven are the test invoices, which have payments but no orders, so the order view can't see them. And the order view sees 83 traces that end before payment, which the payment view can't see at all, because no payment object exists for them. Neither divergence involves a partial shipment or a consolidated payment. The structure section rules those out with a multiplicity table where every value is zero or one.
What the Report Says About Its Own Limits
All 3,055 transaction dates carry a time of midnight, so same-day events can't be ordered by time, and a same-day bill-before-ship is undetectable. Both ship-date fields are null on all 752 fulfillments. Status-change system notes exist on 46 documents out of 2,300, so approval lead time can't be measured, and the thirteen orders in Pending Approval have no record of when they entered it. And 169 documents are dated after the analysis date, which is a demo-load artifact that makes recent ages unreliable and produces two fulfillments dated before their orders.
There's a revision log at the end, and I'd point to it as the most honest part of the document. Revision 1 read the 32 order-less invoices as a collections problem. Revision 2 noticed the memos, reframed the finding as data quarantine, traced ten unlinked fulfillments to transfer orders and vendor returns and moved them out of scope, and corrected a status label from a generic reference table to the account's own. The report says what it got wrong the first time.
How It Runs
The prompt uses sqlReduce, which streams the transaction lines through a JavaScript reducer in pages of 5,000 rows, keyed on the line's unique key, so that the raw rows never enter the model's context. Four passes share one graph-building core and each returns a different summary, which keeps every result under the size cap. The SuiteQL is in Appendix A, verbatim, including two probes that failed with "invalid or unsupported search" and what the reducer did instead. Appendix B is the reducer logic. Appendix C walks two complete chains through every internal ID so the edges can be re-derived from the record pages, and then checks the arithmetic: the two open-receivables cohorts sum to the total, the conformance buckets sum to 845, the edges sum to 2,210.
Nothing was created or changed.
Wrapping Up
Six more prompts in the release apply the same method to other flows. Procure-to-Pay is the mirror image on the purchasing side and was run on the same day against the same account. Cash Application is the free one and the smallest. The Record-to-Report study is the odd one out, because the close turned out to have almost no recorded trail to mine, and the report is honest about that.
Order-to-Cash Object-Centric Process Mining is in the paid tier of the library. The full sample report from the test account is online, and I covered the whole September release in a separate post.
On the test account, 91.9% of orders ran a strict one-to-one chain and the median cycle time was zero days. That's the easy part to report. The eighteen orders that were paid a month before they shipped are the part someone needs to explain.