A vendor compliance lifecycle, from review to renewal

Vendors, Documents and Cycles share a single status vocabulary: not sent, sent, received pending review, current or cure required, approved for payee setup, with expiring, lapsed and terminated as side states. 'Assignment blocked' is a separate flag, so a vendor can be blocked without losing their history.

An hourly scenario runs four independent routes, each made idempotent by a flag: a Slack review card with a checklist for each newly received packet; a cure email listing the reasons and a re-open link, sent only once reasons have been written; an approval request when a vendor is current; and a hand-off to finance with the fields needed to create the payee, which asks for the exact payee name back in the thread.

A daily scenario watches every document's expiry. At 60 days it asks the vendor to renew, at 30 it sends a second notice and alerts the manager, at 15 it escalates, and at expiry it marks the document expired, lapses the vendor and blocks new assignments. Matching on the exact day keeps each notice to one send; releasing a vendor is always a person.

The day after a cycle's due date, a scenario lapses every vendor still sent or awaiting a cure, blocks new assignments, reports who lapsed and marks the cycle closed, so it runs once per cycle. Its message states the policy: outstanding invoices are still paid, only new work is blocked. A separate scenario opens the next annual cycle and resets the vendors.

A payment reconciler joins the bank's payee names to the stored payee names exactly, flags any vendor paid while not current (the payment is right, the new work is the exception) and creates a stub vendor for an unknown payee. A weekly audit lists packets sent and not received. A vendor sync keeps the vendor table in step with the property-management system's users and publishes a daily do-not-assign list. A task poll compares a stored snapshot against pending tasks to log reassignments for a person to classify.