How to spot invoice risk before the due date.

Predict only what changes the order of work.

An aging report is valuable, but it answers a backward-looking question: which invoices are overdue now? A finance team planning this week’s work needs a second view: which open invoices are most likely to become late, and which of those balances would matter most?

A percentage by itself is not a collections plan. A small invoice with an 80% chance of delay may deserve less attention than a much larger invoice with a 55% chance of delay. Combine likelihood with value:

Estimated cash at risk = open invoice amount × chance of late payment

This calculation gives the team a starting order. It does not know about a phone call yesterday, an active dispute, a missing purchase order, or a strategically important relationship. The account owner still reviews that context before acting.

Late payment is a widespread problem. Intuit’s 2025 survey of 2,487 US small businesses reported that 56% were owed unpaid invoices. That establishes the business need, but it does not prove that your own history can predict future delays. Your data must pass its own check. Read the survey methodology.

Keep the files narrow and consistent.

You need one file of closed invoices and one file of open invoices. Closed invoices show what happened in the past. Open invoices are the balances you want to prioritize today. Use the same field names and date format in both files wherever possible.

Use stable internal account keys instead of customer names. Leave out email addresses, phone numbers, bank details, free-text notes, card information, credentials, and fields you are not authorized to use. More columns do not automatically produce a better result; they often create privacy and interpretation problems.

Write the rule before calculating anything.

For a simple first version, an invoice is late when the payment date comes after the contractual due date. Days late measures the size of the delay:

paid_late = payment_date > due_date
days_late = max(payment_date - due_date, 0)

Agree on this definition with the finance team before running the analysis. Some businesses allow grace periods or treat disputed invoices separately. If the operational definition changes, the historical labels must change too.

Payment date is needed to label closed invoices, but it cannot be used as an input for an open invoice. The same restriction applies to fields that are known only after the due date, such as final collection outcome, write-off status, or a dispute recorded after the fact. Using future information can make a historical test look excellent while producing useless real-world estimates.

Recreate what was knowable at the time.

For each historical invoice, build the account history using only invoices that came before it. Useful signals can include the account’s previous late-payment rate, average delay when late, invoice value, invoice value compared with that account’s normal amount, payment terms, time of year, and the amount of prior history available.

An account with no previous invoices should begin near the portfolio’s typical late-payment rate. An account with a long record can rely more heavily on its own behavior. This balance prevents one old invoice from creating an extreme conclusion.

Sort historical invoices by invoice date before creating these values. If all customer history is calculated first and then copied backward onto older rows, later outcomes leak into earlier examples. The check would no longer represent the decision you will make on a genuinely open invoice.

Keep the future side of the check untouched.

Do not randomly mix old and new invoices. Payment behavior, customer mix, pricing, and collection practices can change over time. Train the calculation on the oldest portion of the history and test it on a newer portion that was kept aside.

PaidWhen uses the oldest 75% of closed invoices to learn the pattern and the newest 25% to check it. The result is compared with a very simple rule: assigning every invoice the historical late-payment rate from the older period. A more complicated calculation should not earn trust unless it performs better than that rule.

Look at more than accuracy. If 90% of invoices are on time, a system can be 90% accurate by predicting “on time” for every invoice. Ranking quality shows whether delayed invoices tend to appear higher. Probability error shows whether the percentages are reasonably calibrated. Always record the date window and number of invoices used.

Turn the estimate into a reviewable order.

For every open invoice, show the estimated chance of delay, invoice value, estimated cash at risk, due date, expected payment date, and a short reason for the ranking. Sort by estimated cash at risk from highest to lowest.

The suggested action should depend on both risk and timing. A high-ranked invoice that is not yet due may need a friendly payment-date confirmation. An overdue invoice may need the owner to check for a dispute, missing purchase order, or promised payment date. A low-risk invoice far from its due date may need no action.

Do not send messages automatically in the first version. A finance tool cannot see the full customer conversation, commercial importance, contract, tone, or an update that has not reached the accounting export. Treat the list as a weekly meeting aid: confirm context, assign an owner, record the next step, and review again.

Five reasons not to trust the result.

1. The calculation used payment outcomes or other information that would not exist when the invoice was open.
2. Old and new invoices were randomly mixed instead of tested in date order.
3. The result is not compared with a simple historical late-payment rule.
4. The history is too small or contains too few examples of both late and on-time payment.
5. An uncertain estimate is used to contact customers without a person reviewing the relationship.

If any of these conditions is present, fall back to transparent rules based on due date, amount, disputes, and account-owner knowledge. A simpler review that the team understands is better than a confident-looking percentage built on weak evidence.

You can inspect the complete PaidWhen workflow with sample data, then use the downloadable templates to prepare your own authorized exports.