Promise-to-pay tracker

A collections promise-to-pay tracker earns its keep only when every stored row is a cite. The row should hold the account or invoice identifier, the customer sentence that contains the commitment, the calendar date that sentence names, and a pointer to the message it came from. If the thread never states both a payment commitment and a date, the correct output is empty. Do not invent a promise so the worklist looks complete.

That quality bar is the whole product. Aging already tells you the invoice is late. The tracker exists to answer a narrower question: did this customer bind themselves to a day, in words you can quote, and has that day passed without cash on the cited invoice?

Language that fails the bar is common in the same threads that contain real promises. "We should be able to get this out next week" does not name a day you can put on a calendar without guessing which week and which day. "I'll try to get AP to release something" does not commit to paying. "Hoping to clear this soon" is a sentiment. Do not promote them to promises. Inventing a promise from a maybe is the first failure mode. It parks the account on a hold that the customer never agreed to, and it leaves you with nothing defensible when a controller asks why dunning stopped.

Collectors still own whether a valid promise is worth a hold. The model only writes or withholds the row.

Work the full thread in order, not the last inbound in isolation. A dated commitment often sits two messages back, after a collector asked for a date and before the customer wandered into PO status or a short-pay explanation. Later messages can supersede earlier ones. When two customer dates conflict, keep the latest dated commitment as the live row and retain the earlier sentence in the history so a reviewer can see the change.

A procedure that survives a quality review:

1. Restrict extraction to customer-authored body text. Drop signatures, confidentiality footers, out-of-office replies, and collector-authored summaries that paraphrase the customer.
2. Require a binding payment clause: will pay, will wire, will send ACH, will release the check, will fund, will settle on a named date. Hedging verbs (hope, try, should, maybe, aiming) fail this step.
3. Require a date expression that resolves to a single calendar day. "Friday the 12th" resolves when the thread date makes that Friday unique. "Next week" and "end of month" do not, unless the customer also named a day. If the date cannot be resolved without choosing among options, leave the date empty and do not write the row.
4. Bind invoice numbers from the same customer message, or from the collector message immediately before it when the customer says "that invoice" or "the one you flagged." If several invoices were in play and the customer did not specify, do not pick a favorite.
5. Write the record only when the clause, the resolved date, and the invoice binding all succeed. Otherwise write nothing.

Illustrative example: a collector writes about INV-4418 and INV-4419 in one reminder. The customer replies, "We can do 4418 on Friday the 12th; 4419 is still with AP." The correct output is one promise row for INV-4418, citing "We can do 4418 on Friday the 12th," with due date the 12th of the month that Friday falls in. INV-4419 has no promise. A later miss is judged against that Friday for 4418 only. The original invoice due dates stay on the aging. They are not the tracker clock.

If the same customer had written "we can probably do 4418 sometime Friday," you would write nothing. Probably is not a cite.

The promise date is a second clock beside the invoice due date. Fulfillment is cash applied to the promised invoice, or a new customer sentence that replaces the date with a new cite. Until one of those happens, the promise stays open.

Do not close on the customer's "payment sent" mail. That message is not cash. Files sit in the bank, land on the wrong invoice, or go to the wrong entity. Treating the tracker as cash applied is the second failure mode. You drop the account from the promise worklist, skip the miss check, and only notice the hole on the next aging. Pair the open promise with cash application via remittance parsing: remittance that matches the cited invoice closes the promise as kept; remittance that hits a different invoice leaves the promise open and flags the mismatch.

Collections and ERP workspaces in this class, including HighRadius, Salesforce, Workday, and Gaviti, already store aging, collector activity, and often a promise-to-pay field. The field is only as good as the cite behind it.

A miss is failure to apply cash to the cited invoice by the end of the stated date, with no superseding cite. It is not "the invoice was already late." If the customer promised 12 September, you do not escalate on 10 September because original terms were 30 August. Escalating before the stated date is the third failure mode. It spends the only pause the extract just bought: a held sequence the customer thinks they earned by naming a day.

Run the miss check on the morning after the stated date, using the timezone implied in the thread if it is clear, otherwise the collector team's operating calendar.

• Cash applied to the cited invoice: close as kept.
• New customer sentence with a new resolvable date: supersede. Keep the old cite in history. Reset the clock. Do not treat a new maybe as a supersede.
• Neither: mark miss and hand the account to collections. The model does not pick the letter, the call, or the hold.

After a miss, collectors typically release any promise pause and return the account to adaptive dunning sequences, raise it in risk-tiered prioritization when the balance or miss pattern warrants it, and read the thread again for dispute language. If the customer has shifted from "I'll pay on the 12th" to "we never received that" or "the PO does not match," chase a new promise last. Run dispute-likelihood scoring before you ask for another date.

Do not auto-send a broken-promise notice from the extract job. Wording, legal posture, and relationship sit with collections.

Split the work on purpose. Models are useful at finding a dated commitment in a messy thread and poor at deciding whether this account gets a courtesy day, a manager call, or a credit hold.

The model extracts or withholds, quotes the sentence, resolves the date, watches cash apply, and flags miss after the date. The collector accepts, rejects, or edits the row, decides whether a promise pause is allowed at all, chooses escalation content, and refuses to promote hedging into a live promise.

Review empty outputs, not only filled ones. If collectors constantly add promises the model left blank, the rules are too tight or the commitment lives in a channel you do not parse. If collectors constantly delete rows, the model is promoting maybes. Both are defects on the same object: a quality record that must stay empty unless it can cite the sentence and the due date stated.

A tracker that invents rows, treats sent-mail as cash, or escalates before the cited date is worse than notes in the activity feed. The useful artifact is a row you can defend in a huddle: this sentence, this date, this invoice, still open until cash or a new cite, then a miss that collections owns.