Skip to main content
DoneThat

AI Adoption GuideFinanceCollect

Risk-tiered prioritization

Agent ranks accounts by recovery probability multiplied by exposure, using tools like HighRadius.

Finance processPlanBudgetInvoiceCollectPayCloseReportAudit

By Don, DoneThat’s AI coach · updated

Rank by recovery probability times exposure

A collections worklist earns its keep when each ranked row is the product of two named factors: recovery probability and AR exposure. Aging buckets and collector judgment still matter. They do not replace that product. The deliverable is a ranked list that cites both inputs. If either factor is missing, that row stays empty of rank. Collections still works the account through the ordinary queue.

Recovery probability is an input you already hold or can derive from history you already store: cash collected against comparable open items, dispute status, whether a promise is current, and the dated cash window you already produce. Exposure is the open AR you would actually fail to collect if the account went cold: invoice principal plus eligible fees, net of unapplied cash you can prove. Multiply them. Sort descending. That order is the worklist.

Do not stamp a score on an account that lacks one of the two factors. A rank without exposure is a preference. A rank that invents a recovery rate is a forecast wearing an operations badge.

Load both factors from the same as-of date

Pull exposure from the AR subledger for the same as-of timestamp you will publish. Typical sources are customer open-item aging, the invoice register, and unapplied cash. Finance systems such as Workday and Salesforce commonly already store the customer and invoice objects. Collections systems such as HighRadius and Tesorio commonly already store collector activity, promise records, and cash-application status. Treat those products as a class of systems of record. Read the fields you need. Do not assume any of them already computes this ranking for you.

Recovery inputs come from collections history on the same customer, not from a slogan. Useful sourced inputs include cash collected on comparable invoices, days-to-pay on the last closed items, open dispute flags, and whether a promise-to-pay is still current. Pair this ranking with a promise-to-pay tracker so a live promise is an input, not hallway knowledge. Pair it with payment-date prediction when you already produce a dated cash window. That window can inform probability. It cannot replace exposure.

Keep the two factors honest with load rules:

  1. Same customer key and same as-of timestamp.
  2. Exposure is open AR you can reconcile to the subledger. If policy takes legal-hold items off the collector queue, exclude them or keep them with a visible hold flag. Do not silently drop dollars.
  3. Recovery probability is sourced. Name the table or report. If you have no source, you have no probability.
  4. Do not backfill a missing probability with a round number because the dashboard looks sparse.

If the close is unfinished, wait or mark the list as draft. Ranking yesterday's exposure against today's promises is how you get a tidy list that fights cash application.

Cite both inputs and leave incomplete rows unranked

Every ranked row should show, in fields a collector can read without a tooltip: exposure amount, the recovery input used, the product, and the as-of date. "Recovery input used" means the evidence, not a nickname: last collected ratio on that customer, dispute-open flag, current promise state, predicted pay-date band. The citation is the control. A number without a cite cannot be challenged, so it cannot be trusted.

Sort on the product. Break ties on exposure, then on oldest open invoice date. Publish a rank only where both factors are present and cited.

When a factor is missing, the row stays empty of rank. Empty means no score, no tier badge, no silent default probability. The account remains on the collector's book. It does not occupy a ranked slot. Park unranked accounts in a bucket labeled missing factor, with the reason: no exposure loaded, or no recovery input. That bucket is work, not a graveyard.

Illustrative path, not a measured case. A collector opens Monday's list. Customer A shows exposure from the AR aging and a recovery input from current promise status plus recent cash on like invoices. The product places A near the top. Customer B has a large past-due balance in the aging, but cash application has not posted unapplied cash, so exposure is not loadable. B has no rank. Customer C has clean exposure and no recovery history because it is a first invoice. C has no rank. The collector still works B and C from the missing-factor bucket, using aging and notes, while A gets the first block of outbound time. Nobody invents a recovery rate for C to force it onto the chart.

Downstream cadences should read the same cites. Adaptive dunning sequences can use the ranked order to decide who gets the earlier outreach. They should not suppress dunning on an unranked account. Unranked means not scored. It does not mean the balance is not due.

Collectors work the list; rank is not a write-off

The ranked worklist is a sequence of outreach, not a credit decision. High rank means work this balance first because dollars at risk and a sourced recovery input say the hour is better spent here. Low rank means work it later the same day or the same week. It does not mean the invoice is uncollectible. It does not mean accounting should reserve or write off. Reserves and write-offs stay on the controller's calendar, with their own evidence.

The collector still owns the account. They place the call, send the notice, log the promise, and request an invoice copy. If the customer disputes a charge, route that through your dispute path. If the items look duplicated or the payor looks wrong, stop re-sorting and run duplicate and fraud detection before you spend more collector time.

What the collector should see on the row, in order: customer name, cited exposure, cited recovery input, product, next action already on the account, last note timestamp. What they should not see: a write-off label inferred from a low product, a guessed recovery percentage, or a vendor name standing in for a cite.

Refresh the list on a cadence that matches cash application. After a payment posts, exposure must drop or the rank is stale. After a promise breaks, the recovery input must update or you will keep calling the account that already moved the date.

Where this ranking quietly fails

Three failure modes appear as soon as the list looks official.

Ranking with no exposure. A score that ignores open AR will float small, easy accounts to the top and bury the balance that actually moves the aging. If exposure did not load, do not rank. Fix the load. An aging-only sort is a fallback queue, not a substitute for the product.

Treating rank as write-off. Teams sometimes stop calling the bottom of the list because the dashboard looks like a loss curve. That converts a sequencing tool into an unauthorized credit policy. Keep the bottom of the list in the same collector's queue. Count contact attempts on unranked and low-ranked rows so silence cannot hide as deprioritized.

Inventing a recovery probability. Empty history is not a midpoint. It is missing. First invoices, new bill-to sites, and customers with all cash sitting unapplied do not get a guessed rate so the heatmap fills. Guessed rates poison the sort, then they poison any dunning or promise workflow that reads the same field. Prefer an empty rank plus a reason code.

A quieter cousin: mixing ineligible dollars into exposure, such as tax-only items you cannot collect, or credits you have not applied, so the product looks large. Reconcile exposure to collectible open AR before you multiply.

When the list is wrong, the fix is upstream. Reload the subledger, cite the recovery table, suppress the row. Do not tune sort weights until both factors exist on the accounts you intend to sequence.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first