Payment timing optimizer

The usable output of a payment timing optimizer is a proposed payment-run date that cites two things: the vendor's early-pay discount terms as loaded, and the cash position used to judge whether taking the discount is affordable. If either input is missing, the date field stays empty. Empty is the correct quality outcome. Filling a date by guessing a discount, a net period, or a cash figure fails the job even if the calendar day looks reasonable.

The agent does not send money. A proposed date is not a released payment, not a bank file, and not a promise you can read back to the vendor. Treasury still owns the run: who is in the batch, which account funds it, and when the file actually goes.

This is a different question from payment-date prediction. Prediction answers when a payment is likely to clear. Timing optimization answers which run date is worth considering, given terms and cash, so you can capture an early-pay discount without starving working capital.

A quality proposal names the term string, the source of those terms, the last day the discount still applies, the cash snapshot (name and as-of date), and the amount that snapshot was tested against. A note that only says "pay early" is not a proposal.

Do not start with a preferred run day. Start by loading the two inputs the quality bar requires.

Discount terms come from the record your AP process treats as authoritative for that supplier: usually the vendor master, the invoice, or a controlled terms table. Load the full term string (discount percent, discount days, and net days, or the date basis your ERP stores). You need enough structure to derive the last date the discount can still be captured, using the same date basis operations already uses, typically invoice date versus receipt date. If the fields are blank, net-only, or in conflict across PO, invoice, and vendor master, you do not have terms. Stop. Do not pick the version that favors early payment.

Cash position comes from treasury's working-capital view, not from AP's remaining invoice budget. Load a dated snapshot of unencumbered cash, or the named cash-forecast version treasury already uses to decide whether to accelerate payables. Include drains that snapshot already treats as committed, such as payroll, tax, and already-approved runs. Name the snapshot and its as-of date. "Cash looks fine" is not citable.

Spend concentration can tell you which vendors matter enough to bother. A vendor spend benchmark is useful context. It does not create discount terms. A large vendor on net 30 with a blank discount field is still net 30.

Confirm the invoice is actually payable before you time it. Matching and integrity sit upstream. A three-way match agent and duplicate and fraud detection should already have cleared the item. Timing an unmatched, duplicate, or flagged invoice only accelerates a bad payment.

When both inputs are present, derive the last date that still captures the discount, then choose the earliest scheduled or schedulable AP run that still falls on or before that date and that the cited cash snapshot can fund under treasury's liquidity rules.

Write the proposal so someone can audit it without a chat log:

• Proposed run date
• Terms citation: source, full term string, date basis, derived discount-window end
• Cash citation: snapshot name, as-of date, position used, discounted amount tested
• Statement that treasury has not yet scheduled the run

If terms are missing, leave the proposed date blank. Do not substitute a standard 2/10 because that pattern is common in textbooks. If cash is missing, unnamed, or older than the freshness window treasury accepts, leave the date blank. Do not reuse last week's snapshot because the discount window is about to close.

Walk through one invoice as a method check, not as a result. Suppose invoice INV-8841 is $50,000, dated 1 March, and the vendor master (loaded, not guessed) stores 2/10 net 30 with invoice date as the basis. The discount window ends 11 March. The discounted amount is $49,000. Treasury's 4 March unencumbered cash snapshot, after already-scheduled payroll, still covers $49,000. The agent proposes the 6 March AP run and cites those terms and that snapshot. If the vendor-master discount fields had been empty, the proposed date stays empty, even if a buyer remembers an informal discount. Informal terms are not loaded terms.

Treat invoice intelligence, ERP, and planning tools as a class of systems, not as a ranked shortlist. Terms and invoices often live in AP or ERP, including Workday or SAP in many shops. Cash and forecast versions often live in a planning or treasury model, including Anaplan in some shops. AP intelligence layers, Glean.ai among them, may sit on invoice intake. Know which record is authoritative for terms and which snapshot is authoritative for cash, then feed those records to the agent.

None of these systems is the optimizer by itself. They hold data. The agent proposes a dated, cited run. The ERP, or the payment factory treasury actually uses, remains where the run is scheduled and released. If terms in one system disagree with terms in another, that is a data conflict, not a reason to average percents.

Paying early with no terms. Accelerating a net-30 invoice to be a good customer, or because cash is high this week, is a working-capital transfer, not discount capture. If terms were not loaded, the date must stay blank. Early payment without a cited discount misses the quality bar, even when the vendor is happy.

Treating the proposed date as a sent payment. Operations sees 6 March on the proposal, tells the vendor it is paid, and closes the follow-up. The agent proposed a run. Treasury has not put the invoice in a batch, has not approved the bank file, and has not released funds. Status in AP should remain unpaid until the run actually posts. Confusing proposal with settlement creates duplicate-pay risk and vendor noise when the file moves a day later.

Inventing a discount percent. The empty-date rule fails most often at the keyboard: someone types 2% because 2/10 net 30 is the example everyone remembers, or copies last quarter's term string onto a vendor that never had one. Invented percents create false savings in reports and real cash leaving early. If the field is blank or conflicting, do not complete it. Route the conflict to AP master data. Do not let the optimizer fill the gap.

Hand the proposal to the people who already own the payment calendar. They decide whether that date enters a run, whether the invoice waits for the next net-terms run, or whether cash has moved enough that the proposal should be refreshed against a new snapshot.

If the cited snapshot is stale by the time they look, they do not keep the old date out of inertia. They reload cash and either confirm, shift, or clear the proposal back to empty. The agent can re-propose. It still does not release.

Keep the audit trail with the invoice: proposed date, terms citation, cash citation, who scheduled or declined the run, and the actual run date if it differs. That trail is what makes the quality outcome inspectable. A report of discounts captured that cannot show the terms and cash behind each early payment is not evidence you optimized timing. It is evidence you paid early.