safety controls
What Should Automatically Stop an Invoice Follow-Up?
A safe invoice-reminder system stops or diverts on payment, reply, dispute, opt-out, missing consent, invalid contact data, manual holds, legal escalation, and stale source state.
An invoice follow-up system is defined as much by what it refuses to send as by the reminders it schedules. The sequence was created from a snapshot. Every payment, reply, office note, opt-out, or delivery failure can make that snapshot stale.
The safe pattern is simple: recheck the source and suppression state immediately before every proposed action. If a stop condition exists, do not send. Either close the action or route it to the person who can decide.
Hard stops
Hard stops end the automated sequence for the current use case.
Payment or zero balance
Reconcile the current invoice balance. Full payment ends follow-up. A partial payment changes the amount and may also reflect an arrangement that requires review.
Any customer reply
A reply is new information. It may report payment, dispute the work, ask for time, request a call, or identify a wrong number. Automation should not guess the meaning and continue on schedule.
Opt-out
Honor STOP and other supported opt-out mechanisms across every path that could send the same use case. A sender-level re-opt-in does not by itself create use-case-specific invoice-reminder consent.
Missing affirmative consent
Having a number in the source record is not the same as permission to use it for automated Revenue Recovery SMS. Eligibility should require the evidence and disclosure appropriate to the campaign and channel.
Wrong or invalid contact
Wrong-party replies, disconnected numbers, invalid addresses, and repeated hard failures should suppress the destination and create a data-quality task.
Dispute, complaint, or legal status
Workmanship concerns, amount disputes, legal representation, bankruptcy, and formal collection activity require a different process. Stop routine reminders and route the record under the business’s policy.
The invoice follow-up control guide puts these stops into a complete workflow.
Human-review stops
Some conditions do not close the opportunity, but they remove it from automatic handling.
- a payment arrangement or promised date;
- a hardship request;
- a financing or insurance dependency;
- a requested invoice correction;
- a warranty or callback issue;
- an unusually high balance;
- a high-value or sensitive customer relationship; or
- conflicting source records.
The action queue should show the reason and source evidence. “Blocked” without an explanation just creates another mystery for the office.
Delivery-based stops
Provider delivery status is operational evidence. It is not proof that the customer read the message, but it can show that the destination is failing.
A message that is queued or sent can still become undelivered or failed. Repeated permanent failures should suppress further attempts on that channel. Temporary provider errors may be retried under a bounded policy. The system should distinguish the two and cap retries.
Do not send an extra confirmation when a messaging provider already handled an Advanced Opt-Out response. Duplicate confirmations create a poor experience and may violate provider expectations.
Source-state stops
The invoice record itself can change:
- paid, void, canceled, bad debt, or draft status;
- balance reduced to zero;
- due date moved;
- credit or adjustment applied;
- customer or invoice merged; or
- source connection disconnected.
The worker should compare the latest version with the version used to create the action. If material fields changed, the old action is stale and must be rebuilt or canceled.
Business-level stops
The business needs a master pause and category-level controls. Examples include:
- Revenue Recovery inactive for the tenant;
- invoice follow-up category disabled;
- SMS or email channel disabled;
- delivery mode disabled;
- sender identity unavailable;
- daily or per-customer cap reached;
- quiet hours;
- campaign compliance status incomplete; and
- an incident or operator pause.
These checks should be enforced server-side immediately before delivery. Hiding a button in the interface is not a delivery control.
Record the outcome of every blocked action
An audit log should capture the opportunity, proposed action, stop reason, time, rule version, and whether a human task was created. Do not include unnecessary customer content in a general analytics event.
Repeated stop reasons reveal product and process work. Many stale balances may mean reconciliation is late. Many missing-consent blocks may mean the business needs a better disclosed consent flow. Many wrong numbers may point to source-data quality.
Test the negative path
A control is not proven because a unit test says the helper returned false. Plant the condition in a realistic action path and confirm no provider call occurs. Test payment, generic START without invoice-specific consent, opt-out, reply, disabled delivery, wrong tenant, stale version, and duplicate action delivery.
RelayHitch’s free Revenue Leak Scan never reaches the delivery path. It is read-only and performs no customer outreach. Paid Recovery remains separately gated, and disabling delivery must fail closed even when an opportunity and action otherwise look valid.
Run a free Revenue Leak Scan to review potential invoice opportunities before any follow-up is enabled.