Payment-date prediction

A usable predicted pay date is a calendar date on an invoice, paired with the customer payment history that produced it. If that history is too thin to cite, the date field stays empty. Treasury still owns the cash forecast. Collections uses the date to time outreach, not to book cash.

The quality bar is citation, not a published hit rate. A model that says this invoice pays on the 18th, without pointing at prior invoices, typical days-to-pay, or a recurring weekday pattern, is a guess. Do not invent an accuracy percent to make the field look trustworthy. Hit rates shift with customer mix, season, and who is in the book. Publishing one number trains the rest of the company to treat the date as cash in the bank.

When the date is present, it should be specific enough that a collector can act: skip a reminder that would land before the customer usually pays, or hold a call until the cited window has passed. When it is absent, the invoice still exists in aging and in risk-tiered prioritization. It simply does not get a fabricated cadence.

Prediction starts with a complete billed-and-paid file, not with the open AR aging alone. For each customer you need invoices that were issued, the dates they were billed, the dates they were paid or the date cash was applied, amounts, and enough identifiers to join remittances back to invoices. Partial payments and short-pays belong in the history. They are how some customers actually settle.

Pull closed invoices, not only open ones. A customer who currently has three past-due invoices may still have a stable pay pattern on the invoices they did pay. Aging shows stress. Paid history shows cadence. You need both.

Join cash application carefully. If remittances land in a lockbox and get applied days later, the paid timestamp you train on may be the apply date rather than the customer-initiated pay date. That lag is real operational delay. It is not the customer's behavior. Where you can, prefer the date on the remittance or the bank posting date, and keep the apply date as a separate field. Cash application via remittance parsing is what makes those timestamps trustworthy at volume.

Exclude first invoices from learned cadence until they have a sibling. A brand-new bill-to with one open invoice has no prior pay behavior to cite. Predicting that invoice as if it had a monthly cycle is a failure mode, not a feature. The model should return empty and let collectors use terms, the credit file, and risk tier instead.

Watch for customers who pay on a schedule that is not days after invoice. Some pay every Friday. Some pay on the second Thursday after statement. Some batch all vendors on a monthly run. Those patterns only appear if you load a long enough paid history and keep calendar features, not only a mean days-past-invoice.

Once history is loaded, the model produces a date per open invoice and a citation of the behavior it used. The citation can be compact: last three paid invoices, median days-to-pay, the weekday they typically settle, or a note that they pay on statement close plus a fixed lag. A collections lead should be able to open the invoice and see why the date is there.

Suppress when you cannot cite. Thin accounts include new bill-to records, customers with a single paid invoice, customers whose last several payments were exceptions (chargebacks, rebills, disputed short-pays), and customers whose pay dates jump around with no stable window. Empty stays empty. Filling those gaps with a portfolio average is how you start treating the date as cash in bank.

Do not attach a site-wide accuracy percent to the field. If someone asks how often this is right, answer with the review process, not a fabricated hit rate. You can track, internally, how often cash actually arrives in the predicted window for accounts that had a citation. That measurement belongs in a treasury working file. It does not belong on the invoice as a badge.

A mid-market distributor has paid the last six invoices to one supplier in a cluster around the third Friday after invoice date, after a weekly AP run. The next open invoice gets a predicted date in that same window, with those six invoices listed as the cite. A second customer on the same aging list is a new logo with one billed invoice and no paid history. That invoice's predicted date stays blank. Collections still works the account on terms and risk, but the cash forecast does not pretend a cadence exists.

After predictions land, use them to set cadence, not to invent a second aging bucket. Adaptive dunning sequences should wait until the cited window has passed before escalating, and should not send a you-are-late tone on an invoice whose cited pay date is still ahead. If the date is empty, fall back to terms and risk tier rather than a synthetic date.

Collections owns the sequence of reminders, calls, and holds. The predicted date tells them when a nudge is premature. It does not tell them the cash has arrived. Cash in bank is a bank statement and an applied remittance, not a model output.

Treasury owns the cash forecast. Predicted pay dates are an input to that forecast, the same way open AR, terms, and known disputes are inputs. They are not a substitute for a forecast that treasury will stand behind in a liquidity meeting. If the book is heavy with thin accounts, the forecast should show a larger unscheduled remainder, not a wall of invented dates.

Feed predicted dates into the rolling view as dated expected receipts, with a clear flag for cited versus unpredicted. ML rolling revenue forecast work should consume those flags rather than assuming every open invoice has a trustworthy settle date. Unpredicted invoices can sit in a later, wider bucket, or stay in a manual overlay that treasury adjusts.

Do not let FP&A treat the sum of predicted dates as committed inflows. That is the date-as-cash-in-bank failure mode at company scale. A predicted Friday is a working assumption for staffing collections and for shaping the near-term cash curve. It is not a lockbox posting.

When a customer misses the cited window, the date should update or clear, and the invoice should re-enter dunning and risk queues. A stale predicted date that sits past due without a collector seeing it is worse than an empty field.

Payment-date prediction shows up in collections platforms, in ERP-adjacent AR suites, and in planning tools that consume AR as a cash input. Tesorio, HighRadius, Workday, and Anaplan are vendors in that class. Treat them as places the same workflow can live, not as a ranked shortlist.

Whatever system holds the open invoices should store a predicted date, a citation, and a blank. Whatever system collections works from should delay or advance outreach using that date. Whatever system treasury uses for cash should ingest the dates as assumptions with an owner, not as banked cash.

Do not assume any one of those products invents a capability you have not seen in your own tenant. Map the workflow to the objects you already have: invoice, customer pay history, collector queue, cash forecast line. If a tool cannot suppress thin accounts, keep the suppression in a rules layer you control. If a planning model cannot distinguish cited dates from blanks, keep the overlay in treasury's file until it can.

The operating rule does not change with the vendor. Load billed and paid history. Predict only where you can cite prior pay behavior for that customer. Leave the rest empty. Let collections set cadence from the dates that exist. Leave the cash forecast with treasury.