Thirty-two of the thirty-nine open invoices in my NetSuite test account were created in a single sitting, at 1:04 in the afternoon on May 14, by the administrator. They all carry a memo that starts with "TEST." Together they're $790K of the $928K that the aging report says is open.
I knew that there was test data in the account. I didn't know that it was 85% of the receivables balance until the Cash Application Process Mining prompt told me, and I think that it's a fair picture of what process mining does. It finds the things you would have looked for eventually, all at once, with the numbers attached.
This is the shortest of the seven process-mining prompts that went into the Sonar AI Prompt Library in September, and it's the free one, which makes it the on-ramp to the rest. 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.
What Process Mining Means Here
Process mining rebuilds a business process from the transactions it left behind, as it was executed rather than as it was designed. NetSuite keeps the links between documents in a table called nexttransactionlinelink, and it turns out that table is enough to reconstruct the whole cash flow: which payment settled which invoice and how long it took, and which deposit swept which cash sales.
For cash application, the objects are customer payments, invoices, deposits, and cash sales, plus the handful of deposit applications and credit memos in between. The prompt pulls every link, counts the multiplicity in each direction, measures the lag on each edge, and then goes looking for the documents that have no link at all. Those are where the work is.
Two Shapes of Cash
The test account turned out to have two completely different cash processes running side by side.
Invoice cash is strictly one to one. 736 payments each settle exactly one invoice. No payment has ever been split across two invoices, and only one invoice in the history of the account has received two applications, a $150 customer deposit and a $934.78 payment, which the hand-check confirms add up to the invoice total. 89% of those payments are dated the same day as the invoice, and 60% land exactly on the due date, which is what you'd expect from due-on-receipt terms. Customers pay on or before the due date 94% of the time. The late tail is 44 payments, four of them more than 30 days late, and the worst was 243 days.
Store cash is many to one. 49 deposits sweep 1,026 cash sales, in batches of 12 to 29, on the 23rd through the 25th of every month. A cash sale therefore waits anywhere from 1 to 24 days to reach the bank, median 12, purely because of when in the month it happened.
The prompt also counts touches to settle: one for creating the payment, one for each invoice applied, one for each status change recorded in system notes, and one for each deposit linked. 725 of the 748 payments, or 97%, settled in two touches, meaning they were created already applied and never edited again. That's straight-through processing. The report is honest that the count is a floor, since a UI edit that doesn't change status leaves no note behind.
Matching takes almost no effort in this account. The effort is in the twelve receipts that arrived with nothing to match.
The Twelve
Twelve payments carry $3,245.96 of unapplied cash. That's a small number. The report says it's entirely avoidable, and then it diagnoses every one.
Three are material, and all three belong to customers with no open invoice at all. One of them, a $934.78 receipt from Susan Adams dated August 31, is a same-day, same-amount twin of another payment that was applied to an invoice. It's a duplicate receipt awaiting a refund. Two $32.65 payments from Finch Computing are sitting unapplied while Finch has an invoice with $190.37 open, so those can be applied today. Three identical $32.65 receipts from Dillan Garcia over ten days, with no invoice behind any of them, look like a recurring charge with no billing document. The rest are residuals between $27 and $50.
The recommendation is specific. Apply the two Finch payments, refund the duplicate, contact the two customers who paid for an invoice that doesn't exist, and bill the recurring charges properly. Total effort, an afternoon. Total unapplied afterward, zero.
The Second Cash Path
The finding that I think matters most for a real account is in the exception register. 51 cash sales are not linked to any deposit. Eight of them are from September and haven't been swept yet, seven because the payment was never approved. The other 43 are the interesting ones. They carry a status of Deposited, they've been appearing one or two a month since October 2024, and they were posted straight to the bank, bypassing Undeposited Funds and the twice-monthly sweep entirely.
That's a second cash path with no deposit record. The deposit table under-counts banked cash by $6,370 because of it. On the test account that's a small number. On a real account, a path that lets cash reach the bank without a deposit is the kind of thing a reconciliation misses for years, because nothing is wrong with any individual transaction. The report's recommendation is to decide whether direct banking is permitted, and then either record it as a deposit so reconciliation can see it, or find the form or role that allows it and close it.
The Aging Report Was 85% Noise
Which brings me back to the test invoices. Real open receivables on the account are seven invoices totaling $138K. Six aren't due yet. One is: INV759, Blockster Inc., $53,424, 63 days past due. That's the collection call. Everything else on the aging report is test data, and the report says so, and suggests either reversing the 32 invoices and 11 payments or excluding the memo pattern from every A/R saved search and dashboard before the next aging run.
I want to be careful about what this finding proves. It's a test account, and nobody was making collection calls off its aging report. But the mechanism is real. Test transactions in a production account don't announce themselves, and a process-mining pass that groups documents by creation timestamp and creator is how you find a batch of them in one query.
How It's Built
SuiteQL, over transaction, nexttransactionlinelink, and systemnote. Eight queries, in the appendix, verbatim. The method table states every assumption up front: what counts as a link, how touches are counted, what "unapplied" means, and how test data was identified. Three probes failed during the run because certain account fields aren't exposed to SuiteQL, and the report says which ones and what it did instead, which was to read the landing account from the payment status. The hand-check appendix adds every cohort back up to the totals: 748 payments, 736 invoice-to-payment pairs, $3,245.96 unapplied, $928,246.62 open. Nothing was altered.
Wrapping Up
The other six process-mining prompts in the release follow the same method, with the same audit-grade report format, every query printed in an appendix, and a worked hand-check at the end of each one. Order-to-Cash is the anchor. This one is the smallest. If you want to see whether the approach is useful on your account before spending time on the big ones, then this is where I'd start.
Cash Application Process Mining is in the free tier of the library, so there's nothing to buy. The full sample report from the test account is online, and I covered the whole September release in a separate post.
An afternoon of work clears the twelve. One phone call clears the overdue. The rest of the aging report is somebody's test data from May.