Thirteen pairs of vendor bills on my NetSuite test account matched on vendor, amount, and date within five days. Every one of them dissolved under the evidence chain. Each bill traced to its own purchase order with its own item receipt, and what looked like duplicates was a business that orders identical replenishment baskets on a rhythm. One supplier shows four $310.00 pairs spread across two years, and they turn out to be two different standing baskets, body care and cosmetics, that happen to total the same amount and reorder on the same six-month cycle.
That's what the Duplicate Payment and Credit Recovery Ledger does with a candidate. It clears it with transaction IDs or it doesn't clear it at all. It went into the Sonar AI Prompt Library in September as the companion to the Supplier Billing Reconciler. 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.
Five Passes
The hunt runs five detection passes over all 1,017 vendor bills and $3.40 million of billing. Same vendor, same amount, within five days. Different vendor records, same amount, within three days, which is the signature of a supplier onboarded twice. Same vendor and amount across different subsidiaries. Bills carrying more than one payment. And a vendor-master scan for duplicate records. The currency axis collapses by configuration, since this is a verified single-currency instance, and the queries carry the multi-currency variant in comments for accounts where it doesn't.
Zero confirmed duplicate payments. The report's own words on scale: the account's procure-to-pay controls are strong, the recoverable ledger is correspondingly small, and the value of the exercise is the verdict, the evidence-chain method, and five standing detectors that will catch the first real duplicate on the day it posts. It says that in a box headed "honest scale statement," and I'd rather have that than a manufactured windfall.
The Near-Miss
The fourth pass found one bill, VB05 from Generation N for $33,700, that briefly carried two $33,700 payments on the same day. The original was voided the same day the replacement posted, and the void preserved the full application trail rather than deleting it. No recovery is due, and the control worked. The report keeps the full chain in the ledger anyway, as the reference specimen for what a real duplicate will look like when one eventually survives, and it notes that this is the second time the off-PO bill family from the companion report has appeared at the center of a payment-control event.
There's a query detail in the appendix that anyone writing this detector should read. The payment-application join fans out across payment lines, and a naive sum reported one bill as paid $341K until the query was fixed to count distinct payment IDs. The report ran the multi-payment detector twice, once excluding voided payments to find live duplicates and once including them to find near-misses.
The Credit Side
Then the prompt turns around and traces every credit-side instrument in the account end to end: vendor return authorizations, bill credits, prepayments, refund checks. No rebate program exists, and the report says so as a scope boundary rather than skipping it silently.
The trace found a live recovery ledger of $369.88. A credit agreed on a return 54 days ago that has never been issued. A credit that was received and has never been applied to any bill, sitting idle while new bills from the same vendor are paid gross. An unapplied credit whose document number is the same sixteen-digit card-formatted string that appears in the memo of the suspect bill from the companion report, with a same-day refund check for the same amount, which the report says to untangle as one case. And a prepayment of $99.97 that went out and has never been offset. Two more items are in the pipeline, a return not yet shipped and a return awaiting approval for sixteen days.
Every credit-side instrument in the account belongs to one vendor. The report calls out the pattern above the dollars: the near-miss, all four recoverables, both pipeline items, and the companion report's $2,984.52 claim all involve Generation N, and together they describe a vendor relationship transacting outside the account's otherwise excellent controls. The recommendation is one consolidated review of that vendor, with every exhibit already evidenced across the two reports, rather than item-by-item whack-a-mole.
What It Recommends
Work the four-line ledger this week, which is minutes of accounts-payable work for the two idle credits plus a demand for the overdue one. Run the single Generation N review. Install the five detectors as monthly controls, with the multi-payment one being the detector that catches a VB05-style event if the void step is ever missed. Add a credit-aging control, because the gap this report exposes is credit latency rather than duplicates: nothing in the current process notices a pending credit at 54 days. Retire eighteen inactive tax-agency vendor shells that a deliberate migration left behind. And don't buy a recovery-audit service on this evidence, because two years and $3.4 million with zero surviving duplicates leaves the classic contingency-fee pitch nothing to find.
How It's Built
Six SuiteQL queries in the appendix, labeled as standing detectors, including the credit-aging query with its current hits listed in the comments. The detection envelope is stated, amount tolerance of half a cent and date windows of five, three, and ten days, and the report notes that doubling the windows found no additional candidates. Vendor return statuses are decoded from the account's live labels. Intent is not concluded anywhere; every item is a process finding pending vendor review.
Wrapping Up
Duplicate Payment and Credit Recovery Ledger 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.
It found zero duplicates in $3.4 million of billing and said so plainly. Then it found the $370 that was leaking anyway.