When will this invoice be paid?

The collector's question is who is late. The CFO's question is when the money lands — and by how much the plan will miss.

Every ledger with terms on it has an open book: invoices posted, not yet paid. Model 06 ranks which accounts to chase. This one answers the question that comes after: for each open invoice, when will it actually clear — not the due date, the real date — and, added up, what does the next quarter's cash look like? A date without a band is a guess dressed up; a forecast without a comparison to the due-date schedule hides how much is slipping. This page gives both, and it is judged against the number a good collector already has in their head: this customer's usual lateness.

Fifty thousand real invoices from one company's receivables — dates, terms, amounts, a masked customer, and the day each one cleared.

The HighRadius B2B invoice dataset, public and anonymised: invoices posted December 2018 to May 2020, in USD and CAD, across a handful of business units. 39,158 have a clearing date; 9,681 are still open — $323.1M, the order book this page forecasts. Terms are mostly net 15; 39% of invoices clear late, 6% more than a week late. It is used here because it is exactly the shape of a receivables ledger: posting_date, due_in_date, amount, customer, clear_date.

Before any model: two date encodings in one file, one customer in forty-three percent of the rows, and a rule that no invoice may know the future.

Hygiene. 1,161 rows were exact duplicates and went. Dates arrive as ISO strings in one column and YYYYMMDD integers in the next — both parsed, and checked against each other. Customer names are masked into variants ("WAL-MAR corp", "WAL-MAR trust", "WAL-MAR llc"…), so the customer id is the key, not the name. One customer accounts for 43% of invoices and $211M — and pays a median four days early, which is why the aggregate cash schedule on this book barely slips. A widely mirrored "new" copy of this dataset has scrambled due dates, some in the year 2157; this page uses the original file, and the README says which.

No lookahead. The strongest features are the customer's history: how late were they last time, how often past a week. Built carelessly, that history leaks — an invoice posted on 3 March must not "know" that an invoice posted on 1 March was paid late on 20 March. So every history feature is computed from invoices cleared before the posting day of the invoice being scored, and the count of that customer's invoices still open on that day is a feature in its own right.

The protocol. A time-based split, not a random one: train on invoices posted before 1 December 2019 (32,395), test on December to February (6,763). Random splits flatter payment models because the same customer's neighbouring invoices land on both sides; a time split is the honest version of "would this have worked last quarter".

# history strictly before the posting day (train.py) — per customer, per invoice
done = (clear < posting_day) & ~isnat(clear)          # only invoices already paid by "today"
f["prior_share_late"]  = (days_late[done] > 0).mean()
f["prior_share_late7"] = (days_late[done] > 7).mean()
f["last3_mean_late"]   = days_late[done][argsort(clear[done])[-3:]].mean()
f["open_count_at_posting"] = (~done & (posting < posting_day)).sum()   # pressure: how much is already outstanding

train = cleared & (posting_date < "2019-12-01"); test = cleared & ~train   # time split, touched once

Most invoices clear within a few days either side of due. The lateness lives in the terms, the unit, and the customer's habit.

Three baselines had to be beaten, and the hardest was the collector's own number. The model beats it — modestly on the date, clearly on the slip, and with a band the baseline cannot give.

By history depth and by amount — where the model helps, and where nobody can

A first invoice from a new customer is a seven-day guess for anyone; with twenty invoices of history the error is two and a half days. Large invoices are the most predictable — they belong to the customers with the longest records. This is the honest shape of the problem: the customer's own history is most of the signal; the model's job is to combine it with terms, calendar and pressure, and to put a band on it.

Describe an invoice and its customer. Four exported models give a date, a band, a slip probability, and the reasons — same trees as the Python.

9,681 open invoices, $323 million. When it is due, when the model says it lands, and how sure it is.

Each open invoice gets a p10, a median and a p90 for days late. Four hundred Monte-Carlo draws through that band turn the book into a weekly schedule with its own band, set against the schedule the due dates promise. On this ledger the two lines nearly coincide — the dominant customer pays early and most terms are net 15 — which is itself the finding: the aggregate is healthy; the risk is concentrated in a tail of ~382 invoices worth $11.3M, listed below.

The chase list — open invoices by amount × probability of slipping past a week

The first row is the kind of thing a ranked list exists for: a $654k invoice from a customer with two prior invoices and a one-in-four chance of slipping — not the latest, not the most likely, but the most expensive to be wrong about. Rows two and three are the opposite: modest amounts, a long record, and a 97% probability of clearing a month late. Different calls, same list.