What is payment recovery and collections automation?
Payment recovery and collections automation connects billing events, current invoice balances, customer context, and access policies to recover outstanding payments without incorrectly restricting a paying customer. This blueprint combines three connected workflows: failed payment recovery and revocation review, a 30-60-90 day overdue invoice loop, and payment promise follow-up.
A failed payment is a signal; it is not permission to revoke access. Verify the current financial state, customer and workspace mapping, dispute status, active promises, grace period, and contract policy before any access change. Independently verify restrictions and restore access when the outstanding condition is resolved.
Use this guide to design an implementation in n8n, Make, Zapier, or a custom orchestrator. Provider names describe possible integrations; validate connector capabilities and configure company collection rules, thresholds, and approval requirements before deployment. All timelines below are examples, not enforced policy.
1. Objective
Build three connected workflows:
Failed Payment Revocation Sequence
30-60-90 Day Overdue Invoice Loop
Payment Promise Follow-Up
The complete lifecycle becomes:
PAYMENT / ACCOUNTING EVENT
↓
VERIFY FINANCIAL STATE
↓
IDENTIFY CUSTOMER + INVOICE
↓
NORMALIZE PAYMENT STATUS
↓
APPLY COLLECTION POLICY
↓
ROUTE BY AGE / RISK / DISPUTE
↓
REMIND / ESCALATE / RESTRICT
↓
VERIFY AGAIN
↓
REVOKE ONLY IF POLICY ALLOWS
↓
RESTORE AFTER PAYMENT
↓
AUDIT
2. Supported Event Sources
The workflow should not depend on a single payment platform.
Possible sources include:
Stripe
Square
QuickBooks
Xero
Chargebee
Paddle
PayPal
Bank / ACH processor
ERP / Accounting platform
Custom billing system
Payment processors will typically provide more immediate transaction events.
Accounting systems may provide invoice and receivable state.
The workflow should normalize both into the same internal billing model.
3. Core Architectural Principle
Use three distinct layers.
Payment Provider
Provides transaction evidence:
payment_succeeded
payment_failed
payment_pending
payment_refunded
payment_disputed
Accounting System
Provides receivable truth:
invoice_open
invoice_partially_paid
invoice_paid
invoice_overdue
credit_applied
invoice_void
CRM / Customer System
Provides commercial context:
Customer
Account Owner
Contract
Customer Tier
Contact Information
Service / Subscription
Then the access system manages:
ACTIVE
GRACE_PERIOD
RESTRICTED
SUSPENDED
REVOKED
RESTORED
Do not treat the webhook itself as the final financial truth.
4. Event Normalization Layer
Different platforms use different event names.
Normalize incoming events into an internal model.
Example:
{
"event_id": "evt_123",
"provider": "PAYMENT_PROVIDER",
"event_type": "PAYMENT_FAILED",
"customer_id": "CUS-1024",
"invoice_id": "INV-2041",
"subscription_id": "SUB-451",
"amount_due": 2500,
"amount_paid": 0,
"currency": "USD",
"payment_status": "FAILED",
"invoice_status": "OPEN",
"event_time": "timestamp"
}
Internal event types could be:
PAYMENT_FAILED
PAYMENT_SUCCEEDED
PAYMENT_PENDING
INVOICE_OPEN
INVOICE_OVERDUE
INVOICE_PARTIALLY_PAID
INVOICE_PAID
PAYMENT_DISPUTED
PAYMENT_PROMISE_CREATED
PAYMENT_PROMISE_BROKEN
5. Shared Billing Record
Recommended fields:
customer_id
account_id
invoice_id
subscription_id
contract_id
billing_contact_id
invoice_amount
amount_paid
amount_remaining
currency
invoice_date
due_date
payment_status
invoice_status
days_overdue
dispute_status
partial_payment_status
payment_promise_status
promise_amount
promise_due_date
access_status
access_restriction_reason
collection_stage
last_reminder_at
next_action_at
account_owner
collections_owner
workflow_version
updated_at
6. Financial States
Standardize payment state:
CURRENT
PAYMENT_PENDING
PAYMENT_FAILED
OPEN
PARTIALLY_PAID
OVERDUE
DISPUTED
PROMISE_TO_PAY
PAID
WRITTEN_OFF
VOID
7. Access States
Keep access status separate from invoice status.
ACTIVE
GRACE_PERIOD
AT_RISK
RESTRICTED
SUSPENSION_PENDING
SUSPENDED
REVOKED
RESTORATION_PENDING
RESTORED
This distinction is critical.
An invoice can be overdue while access remains active.
BLUEPRINT 1 — FAILED PAYMENT REVOCATION SEQUENCE
8. Trigger
Primary trigger:
[TRIGGER]
Payment / Invoice Webhook
Examples:
Payment Failed
Invoice Payment Failed
Subscription Renewal Failed
Invoice Became Overdue
The webhook only starts the workflow.
9. Verify Webhook
Before doing anything:
[VERIFY]
Webhook Signature / Authentication
Then:
[LOOKUP]
Processed Event ID
If already processed:
STOP
Audit:
DUPLICATE_EVENT_SKIPPED
This protects against provider webhook retries.
10. Fetch Current Financial State
Immediately after receiving the webhook:
[FETCH]
Current Payment / Invoice Record
Do not rely only on the event payload.
The payment may already have:
succeeded on retry;
been manually paid;
received a credit;
been voided;
entered dispute;
been partially paid.
11. Customer Lookup
[LOOKUP]
CRM Customer
Resolve:
customer
billing contact
account owner
contract
service
subscription
customer tier
If customer cannot be mapped:
CUSTOMER_MAPPING_FAILED
Do not revoke access automatically.
Route to manual review.
12. Payment Status Router
[ROUTER]
Current Financial State
Possible branches:
PAID
→ Stop / Restore if needed
PENDING
→ Wait
FAILED
→ Recovery Sequence
PARTIALLY_PAID
→ Partial Payment Policy
DISPUTED
→ Dispute Workflow
OVERDUE
→ Aging Workflow
13. Failed Payment Sequence
A reasonable generic sequence:
PAYMENT FAILED
↓
Verify Current State
↓
Notify Billing Contact
↓
Grace Period
↓
Retry / Await Payment
↓
Verify Again
↓
Still Unpaid?
↓
Apply Policy
The exact timing should remain configurable.
14. Example Recovery Timeline
Example only:
Hour 0
→ Failed payment detected
Hour 0–1
→ Verify invoice + payment state
Hour 1
→ Payment failure notification
Day 1
→ Retry / reminder
Day 3
→ Second reminder
Day 5
→ Account owner notification
Day 7
→ Access risk warning
Day 10
→ Restriction eligibility review
Day 14
→ Suspension / revocation review
The organization should define its own grace period.
15. Access Should Not Be Revoked Directly From a Webhook
Before any restriction:
[FETCH]
Latest Invoice
↓
[FETCH]
Latest Payment
↓
[LOOKUP]
Customer Contract
↓
[LOOKUP]
Existing Dispute
↓
[LOOKUP]
Payment Promise
↓
[VERIFY]
Access Restriction Allowed?
Only then continue.
16. Revocation Eligibility
Example:
payment_status != PAID
AND
invoice_status = OVERDUE
AND
grace_period_expired = true
AND
dispute_status != OPEN
AND
payment_promise_status != ACTIVE
AND
manual_hold != true
AND
contract_allows_restriction = true
Then:
SUSPENSION_PENDING
17. Independent Pre-Revocation Verification
Immediately before removing access:
[FETCH]
Current Financial State
Then:
[VERIFY]
Still Unpaid?
and:
[VERIFY]
Still Eligible for Revocation?
This protects against race conditions.
Example:
10:01 Payment received
10:02 Revocation workflow wakes up
Without the second verification, a paying customer could lose access.
18. Staged Access Restriction
Where possible, avoid jumping directly:
ACTIVE → REVOKED
Prefer:
ACTIVE
↓
GRACE_PERIOD
↓
AT_RISK
↓
RESTRICTED
↓
SUSPENSION_PENDING
↓
SUSPENDED
For some products:
RESTRICTED
could mean:
no new projects;
read-only access;
disabled premium features;
limited API activity.
The exact behavior depends on the product.
19. Accidental Access Removal Safeguard
Before revocation:
[VERIFY]
Customer Identity Matches?
[VERIFY]
Correct Subscription?
[VERIFY]
Correct Workspace / Tenant?
[VERIFY]
Correct Invoice?
[VERIFY]
No Active Payment?
[VERIFY]
No Manual Hold?
Then:
[ACTION]
Restrict Access
20. Post-Revocation Verification
Do not assume a successful API response means access was removed correctly.
[ACTION]
Restrict Access
↓
[FETCH]
Current Access State
↓
[VERIFY]
Expected Access State?
If not:
ACCESS_REVOCATION_FAILED
Escalate internally.
21. Payment Recovery
When payment succeeds:
[TRIGGER]
Payment Succeeded
↓
[FETCH]
Invoice
↓
[VERIFY]
Amount Satisfied?
↓
[ACTION]
Restore Access
↓
[VERIFY]
Access Restored?
↓
[UPDATE]
CRM + Billing + Audit
Do not restore full access if a remaining balance still violates policy.
BLUEPRINT 2 — 30 / 60 / 90 DAY OVERDUE INVOICE LOOP
22. Scheduled Overdue Monitor
Run:
[SCHEDULE]
Daily
Then:
[FETCH]
Open / Overdue Invoices
Calculate:
days_overdue =
current_date - due_date
23. Aging Router
[ROUTER]
Days Overdue
Suggested buckets:
1–29 DAYS
30 DAYS
31–59 DAYS
60 DAYS
61–89 DAYS
90+ DAYS
This allows more nuanced routing than checking only exactly day 30/60/90.
24. Example Collection Policy
1–29 Days
Standard Reminder
30 Days
Billing Contact Reminder
+
Account Owner Notification
60 Days
Escalated Collection Notice
+
Finance / Collections
+
Account Owner
90 Days
Final Collection Stage
+
Management Review
+
Access / Contract Review
The organization decides whether suspension happens at 30, 60, 90, or another threshold.
25. Re-Check Payment Before Every Notice
Before sending:
[FETCH]
Latest Invoice State
Then:
[FILTER]
Still Outstanding?
If paid:
STOP
This prevents:
“Your invoice is 60 days overdue.”
being sent after the customer paid that morning.
26. Collection Stage Model
CURRENT
REMINDER
EARLY_OVERDUE
30_DAY_COLLECTION
60_DAY_COLLECTION
90_DAY_COLLECTION
FINAL_NOTICE
SUSPENSION_REVIEW
COLLECTIONS_ESCALATION
RESOLVED
Store the stage on the billing record.
27. Duplicate Reminder Protection
Use idempotency:
invoice_id
+
collection_stage
+
reminder_version
Example:
INV2041_30DAY_V1
Before sending:
[LOOKUP]
Previous Communication
If already sent:
SKIP
28. Contact Cadence
Do not repeatedly send the same message every day.
Store:
last_contacted_at
next_contact_at
contact_count
Use controlled spacing.
29. Account Owner Escalation
Collections should not exist separately from customer ownership.
At configured thresholds:
[ACTION]
Notify Account Owner
Include:
Customer
Invoice
Outstanding Balance
Days Overdue
Previous Contacts
Payment Promise
Dispute State
Access State
30. Customer Tier Rules
Organizations may apply different policies by account class.
Example:
STANDARD
STRATEGIC
ENTERPRISE
PARTNER
For example:
Enterprise
→ Manual Review Before Suspension
while:
Self-Service
→ Automated Policy
This should be configuration-driven.
BLUEPRINT 3 — PAYMENT PROMISE FOLLOW-UP
31. What Is a Payment Promise?
Example:
Customer says:
“We will pay this invoice Friday.”
Instead of continuing the normal collection loop, create:
PAYMENT_PROMISE
with:
promise_date
promise_amount
promise_source
promise_owner
32. Promise Creation
Possible triggers:
[TRIGGER]
CRM Field Updated
or:
[TRIGGER]
Accounting Note
or:
[TRIGGER]
Collections Agent Action
Optional AI extraction can identify a promise from customer communication, but it should be verified before becoming authoritative.
33. Payment Promise Record
promise_id
invoice_id
customer_id
promise_amount
promise_due_date
promise_status
source
created_by
created_at
reminder_sent_at
verified_at
States:
ACTIVE
FULFILLED
PARTIALLY_FULFILLED
BROKEN
CANCELLED
MANUAL_REVIEW
34. Promise Pauses Standard Collection
If:
payment_promise_status = ACTIVE
then:
[FILTER]
Pause Standard Collection?
The exact policy depends on the business.
This prevents the customer from receiving:
“You promised to pay Friday.”
and simultaneously:
“FINAL 60-DAY OVERDUE WARNING.”
35. Promise Due-Date Monitor
[SCHEDULE]
Daily Promise Monitor
↓
[FETCH]
Active Payment Promises
↓
[ROUTER]
Promise Due Date
Possible:
Upcoming
Due Today
Past Due
36. Promise Reminder
Example:
1 day before
→ Internal reminder / optional customer reminder
Due date
→ Payment check
1 day after
→ Broken promise evaluation
37. Verify Promise Fulfillment
On promise date:
[FETCH]
Invoice
↓
[FETCH]
Payments
↓
[CALCULATE]
Amount Received
Then:
[ROUTER]
Promise Outcome
38. Promise Outcomes
Full Payment
promise_status = FULFILLED
Resume normal customer state.
Partial Payment
promise_status =
PARTIALLY_FULFILLED
Then determine:
Remaining Balance
and route according to policy.
No Payment
promise_status = BROKEN
Resume collection at configured escalation level.
39. Broken Promise Escalation
Example:
Promise Broken
↓
Notify Collections Owner
↓
Notify Account Owner
↓
Recalculate Days Overdue
↓
Resume Collection Stage
↓
Evaluate Access Policy
Do not restart aging at Day 0.
Original invoice aging remains authoritative.
EDGE CASE — PARTIAL PAYMENT
40. Partial Payment Logic
Example:
Invoice = $10,000
Paid = $6,000
Remaining = $4,000
The invoice is not simply:
PAID
Store:
invoice_status = PARTIALLY_PAID
amount_paid = 6000
amount_remaining = 4000
41. Partial Payment Router
[ROUTER]
Partial Payment Policy
Possible outcomes:
Remaining balance below tolerance
→ Finance Review
Approved installment plan
→ Pause escalation
Unexpected partial payment
→ Continue collection on remaining amount
Do not revoke access based solely on the original invoice total.
EDGE CASE — DISPUTED INVOICE
42. Dispute Detection
Possible sources:
Payment Provider Dispute
Accounting Dispute Flag
CRM Record
Finance Action
Customer Support Case
Then:
invoice_status = DISPUTED
43. Dispute Should Override Automatic Revocation
Recommended:
[FILTER]
Invoice Disputed?
If yes:
PAUSE AUTOMATED REVOCATION
and route to:
FINANCE / ACCOUNT OWNER
unless company policy explicitly states otherwise.
This is one of the strongest safeguards against incorrect access removal.
EDGE CASE — MULTIPLE OPEN INVOICES
44. Account-Level Exposure
Do not evaluate only one invoice when access is account-wide.
Calculate:
total_outstanding
oldest_invoice_age
number_of_overdue_invoices
Example:
Invoice A
15 days overdue
Invoice B
95 days overdue
The account-level collection state may therefore be:
90_DAY_COLLECTION
45. Account-Level Risk Object
customer_id
total_outstanding
total_overdue
oldest_overdue_days
overdue_invoice_count
active_disputes
active_payment_promises
access_status
collection_stage
46. Failed Payment Master Workflow
01 [TRIGGER] Payment / Accounting Event
02 [VERIFY] Webhook
03 [LOOKUP] Event ID
04 [FILTER] Already Processed?
05 [FETCH] Current Invoice
06 [FETCH] Current Payment
07 [LOOKUP] CRM Customer
08 [LOOKUP] Contract
09 [LOOKUP] Access Mapping
10 [LOOKUP] Dispute
11 [LOOKUP] Payment Promise
12 [TRANSFORM] Normalize Billing State
13 [ROUTER] Payment Status
14 [FILTER] Revocation Eligible?
15 [ACTION] Send Failure Notice
16 [WAIT] Grace Period
17 [FETCH] Current Financial State
18 [VERIFY] Still Outstanding?
19 [ROUTER] Access Policy
20 [ACTION] Restrict / Suspend
21 [VERIFY] Access State
22 [UPDATE] CRM + Billing
23 [AUDIT] Record Event
47. 30-60-90 Workflow
01 [SCHEDULE] Daily
02 [FETCH] Outstanding Invoices
03 [CALCULATE] Days Overdue
04 [LOOKUP] Customer
05 [LOOKUP] Previous Collection Activity
06 [LOOKUP] Payment Promise
07 [LOOKUP] Dispute
08 [ROUTER] Aging Bucket
09 [FETCH] Latest Invoice
10 [FILTER] Still Outstanding?
11 [ACTION] Send Appropriate Notice
12 [ACTION] Notify Internal Owner
13 [UPDATE] Collection Stage
14 [AUDIT]
48. Payment Promise Workflow
01 [TRIGGER] Payment Promise Created
02 [LOOKUP] Invoice
03 [VERIFY] Promise Data
04 [UPDATE] Collection State
05 [SCHEDULE] Promise Due Check
06 [FETCH] Payment State
07 [ROUTER] Full / Partial / None
08 [ACTION] Update Promise
09 [ACTION] Resume / Close Collection
10 [AUDIT]
49. Access Restoration Workflow
[TRIGGER]
Payment Received
↓
[LOOKUP]
Customer + Invoice
↓
[VERIFY]
Outstanding Condition Resolved?
↓
[LOOKUP]
Current Access
↓
[ACTION]
Restore Access
↓
[VERIFY]
Access Restored?
↓
[UPDATE]
CRM + Billing
↓
[AUDIT]
50. Vault Architecture
Credentials remain outside workflow logic.
Automation
↓
[VAULT]
↓
Payment Provider
Accounting
CRM
Email
Messaging
Access Management
Protect:
Webhook Secrets
API Tokens
Payment Credentials
Accounting Credentials
CRM Credentials
Access Management Tokens
Never place them inside:
workflow nodes;
CRM notes;
customer emails;
audit logs.
51. Audit Model
Recommended:
event_id
provider_event_id
customer_id
invoice_id
subscription_id
event_type
invoice_status_before
invoice_status_after
payment_status
amount_due
amount_paid
amount_remaining
days_overdue
collection_stage
dispute_status
payment_promise_status
access_status_before
access_status_after
action_taken
recipient
workflow_run_id
workflow_version
created_at
52. Important Audit Events
PAYMENT_FAILED_RECEIVED
PAYMENT_STATE_VERIFIED
DUPLICATE_WEBHOOK_SKIPPED
OVERDUE_STAGE_CHANGED
PAYMENT_REMINDER_SENT
PAYMENT_PROMISE_CREATED
PAYMENT_PROMISE_FULFILLED
PAYMENT_PROMISE_BROKEN
PARTIAL_PAYMENT_RECEIVED
DISPUTE_DETECTED
ACCESS_RESTRICTION_STARTED
ACCESS_RESTRICTED
ACCESS_REVOCATION_BLOCKED
PAYMENT_RECEIVED
ACCESS_RESTORATION_STARTED
ACCESS_RESTORED
MANUAL_REVIEW_REQUIRED
53. Critical Edge Cases
Payment arrives during revocation workflow
Re-fetch state immediately before revocation.
→ Stop revocation.
Partial payment
Calculate remaining balance.
→ Do not treat as fully unpaid.
Open dispute
Pause automated revocation according to policy.
Payment promise active
Pause or modify standard collection cadence.
Duplicate webhook
Use provider event ID and idempotency.
Invoice voided
Immediately stop collections.
Credit note applied
Recalculate balance.
Multiple invoices
Evaluate both invoice-level and account-level exposure.
Access API fails
Never record access as revoked until independent verification succeeds.
Wrong tenant mapping
Block revocation if invoice/customer/subscription/workspace relationship cannot be independently verified.
Customer pays after suspension
Trigger restoration workflow immediately.
54. Recommended Safeguard Before Any Access Change
Use a final control gate:
[VERIFY]
Customer Match
+
Invoice Match
+
Subscription Match
+
Current Balance
+
Current Payment State
+
Dispute State
+
Promise State
+
Grace Period
+
Contract Policy
+
Manual Hold
Only if all conditions support restriction:
ACCESS CHANGE ALLOWED
55. Final Architecture
PAYMENT / ACCOUNTING SYSTEM
│
↓
WEBHOOK
│
↓
VERIFY + NORMALIZE
│
↓
CUSTOMER + INVOICE
│
↓
FINANCIAL STATE
│
┌──────────────┼──────────────┐
↓ ↓ ↓
PAID OVERDUE DISPUTED
↓ ↓ ↓
RESTORE AGE ROUTER PAUSE
│
┌──────────┼──────────┐
↓ ↓ ↓
30 DAY 60 DAY 90 DAY
│ │ │
└──────────┼──────────┘
↓
ACCESS POLICY
│
↓
[VERIFY]
│
┌──────┴──────┐
↓ ↓
SAFE BLOCKED
↓ ↓
RESTRICT MANUAL REVIEW
↓
VERIFY
↓
AUDIT
The principle I’d put at the center of the blueprint is:
A failed payment is a signal — not permission to revoke access.
The automation should first determine:
What was not paid?
Is it still unpaid?
Is the amount correct?
Is there a dispute?
Is there an active payment promise?
Has part of the balance already been paid?
Does the contract permit restriction?
Are we about to change access for the correct customer and workspace?
Only then should the system act.
That turns a basic dunning workflow into a proper Accounts Receivable, Payment Recovery & Access Governance system.
Related implementation guides
- Billing & Milestone-to-Invoice Automation Blueprint: validate invoice creation, approval, and accounting reconciliation before collections begins.
- Identity & Access Automation Blueprint: connect verified billing decisions to identity and access operations.
- Explore all automation blueprints or browse workflow templates for implementation starting points.