Optimising working capital with ML

Optimising working capital with ML means predicting, per invoice, customer or SKU, when cash actually moves, then acting on that before quarter-end instead of explaining the gap afterwards. The models sit on receivables, payables and inventory. The point is a shorter cash conversion cycle that does not cost you a supplier or a stockout.

Most treasury dashboards report the cash conversion cycle as three averages: days sales outstanding, days payable outstanding, days inventory on hand. Averages are where the money hides. A DSO of 47 days can mean everyone pays on day 47, or it can mean 70% pay on day 30 and a long tail drags the mean up. Those two worlds need different interventions, and the headline tells you nothing about which one you are in. So model the distribution per counterparty and per line. The aggregate number cannot.

Model DSO where the labels are honest

Receivables are the right place to start because the label is unambiguous. An invoice is issued on a date, cash clears on a date, and the gap is what you are predicting. That clarity is rare in finance ML, and you should exploit it.

The trap is leakage. The single most common bug we find in a DSO model is a feature that quietly encodes the payment it is meant to predict. Someone joins in the customer’s current credit limit, which was cut after the invoice went unpaid. Or a dispute flag raised during collections. Or a cleared-date field that stays null until the cash arrives and then suddenly is not. Each of these turns an out-of-sample test into a memorisation exercise, and the model looks brilliant until it meets a live invoice.

Point-in-time correctness is the discipline that fixes this. Every feature has to be reconstructed as it was known on the invoice date:

• Payment history for that customer, truncated to invoices already cleared at that point.
• The credit terms in force on that date, not today’s terms.
• Open balance and aging bucket as of issue, computed from the as-of subledger rather than the current one.
• Seasonality and calendar features, which are safe because they are known in advance.

Build the training set from a feature store that holds these as-of snapshots, and your eval numbers start meaning something. The output that matters is then a payment-date distribution per invoice, not one point estimate. That shape drives two decisions: which accounts to prioritise in collections, and how much of the AR book to treat as reliable near-term cash in the forecast.

Payables and the discipline you actually want

DPO is tempting to maximise and dangerous to optimise naively. Stretching every supplier to the contractual limit looks like free financing right up until a critical vendor tightens terms or drops you down their allocation list. So the modelling question is which payment timings cost nothing in the relationship and which ones quietly cost a lot.

We model payables as a set of constraints rather than a target to push. For each supplier: the contractual terms, any early-payment discount, the observed tolerance for late payment, and the strategic weight of the relationship. The optimisation schedules payments to hold cash as long as the constraints allow, capturing early-payment discounts only where the implied annualised return beats the cost of the cash. That comparison is where finance teams leak money in both directions. They pay early for a trivial discount, or they miss a 2/10 net 30 that annualises to roughly 37%, well above most costs of capital.

Inventory is a forecasting problem wearing a working-capital costume

Inventory is the hardest of the three because the label is contested. The cash tied up in stock is real and measurable. What that stock should have been is a counterfactual that depends on a demand forecast, and demand forecasts are wrong in structured ways.

The modelling stack here is a demand model per SKU-location, a lead-time model for replenishment, and a service-level target that management sets. The working-capital lever is safety stock, the buffer held against demand and lead-time variance. Overstate the variance and you freeze cash in a warehouse. Understate it and you stock out, which is a revenue problem that the commercial team will always weigh more heavily than the carrying cost. The false-positive budget here is asymmetric and political, so make that trade-off explicit instead of letting a loss function settle it in silence.

A few things we hold to on inventory models:

• Fit the demand distribution, not just the mean. Safety stock is a function of variance, so a model that nails average demand and misses its spread will size buffers wrong.
• Model lead time as a distribution too. Supplier lead-time variance often dominates demand variance in the safety-stock calculation, and it is the part teams most often treat as a constant.
• Watch for drift after any assortment or supplier change. A model trained on last year’s lead times mis-sizes buffers the moment a route changes, and nobody notices until the stock report looks off.

Making the numbers survive an audit

None of this is worth much if the treasurer cannot trace a freed-cash number back to its inputs. Every prediction that moves a payment date or a stock level needs lineage: which invoice, which features, which model version, which snapshot. When quarter-end arrives and someone asks why DSO moved four days, the answer has to be reconstructable from the record rather than reverse-engineered from a dashboard.

Two practices make that hold. Keep an eval set of settled invoices and closed inventory cycles, refresh it as new labels land, and report the model against it on a fixed cadence so drift shows up as a number rather than a surprise. Then reconcile the model’s cash predictions back to the general ledger, so the working-capital story the models tell matches the story the books tell. When those two diverge, the divergence is itself the most useful signal you have.