There are four return authorizations on my NetSuite test account, and the first one is dated August 5. All four belong to one customer, each returning a partial quantity of a $51.52 item from a five- or seven-unit order. It's about the smallest return population a process-mining prompt could be pointed at.
I'm leading with that because it's the honest frame for this post. The Return-to-Refund Process Mining prompt is built for volume. On the test account it got nine return-side documents, and the report says in its data-quality section that cycle-time statistics on a population this size are anecdotes, not distributions. What I found interesting is that it still had something to say. A population of four exercised the whole reference path once and broke it three different ways.
This is the fourth study in the process-mining series 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.
The Reference Path
A return should go: return authorized, goods received, credit memo issued, then either a refund or an application of the credit to an open invoice. The prompt follows every return authorization, receipt, credit memo, refund, and cash refund through NetSuite's link table, pulls in the originating sales order or cash sale as the root, and checks each case against that path.
One case ran the whole thing. RMA23 was authorized, received, credited, and refunded on August 5, all on the same day, $154.56 to the cent. The report holds that up as the standard the other three should be measured against, and its closing recommendation is to keep measuring against it as volume grows.
Where the Others Stopped
Every incomplete case is stopped at a different step, which the report notes is a more interesting structure than fan-out.
RMA24 was received the same day it was authorized and has sat in Pending Refund for 19 days with no credit memo. The goods are back, and the customer is owed $103.04, and nothing is moving. RMA25 is awaiting receipt, two days old. RMA26 is awaiting approval and is dated in the future, which is a demo-data artifact the report calls out rather than hides.
Then there are two credit memos with no return authorization behind them at all, open and unapplied, for $108.48 and $152.43. One of them belongs to Susan Adams, who the cash application study found also has an unapplied $934.78 payment, and the report cross-references it. Total customer money owed with nothing moving: $363.95. The report describes that as 100% of the return-side liability stalled and 0% in dispute, which is a good way to say that this is entirely a follow-through problem.
The One That Doesn't Add Up
The single cash-sale refund in the account returns $716.39 against a $241.70 sale. That's a $474.69 over-refund, on a cash sale whose own payment is still unapproved. The link table makes it visible in one query. The report's reading is that a refund at three times the sale value against an unapproved sale is either a data-load artifact or a control gap, and either way it's the single largest return-side figure in the account. The recommendation is to confirm which, and if it's real, then to establish who authorized it.
What It Recommends
Three things, and they're small. Clear the $363.95 today by creating the credit memo for RMA24 and applying or refunding the two orphan credits. Add a saved search to the receivables dashboard for return authorizations in Pending Refund with a linked receipt and no credit memo, and for credit memos open more than seven days, so the stall is visible the day it happens. Investigate the over-refund.
The SuiteQL is in the appendix, four queries, and the hand-check reconciles every amount to unit price times quantity. Nothing was altered.
Wrapping Up
I think that the right way to read this report is as a template. On an account with four returns, it produced a stalled-liability register and a saved-search definition. On an account with four hundred, the same queries produce a cycle-time distribution and a conformance rate, and the stalled register gets longer. The method doesn't change with volume. Only the statistics do.
Return-to-Refund 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.
Unresolved refunds don't appear as problems on an income statement. They appear as customers who stop calling, and as a liability nobody booked.