Make · Automation breakdown
Invoice dunning & reconciliation
An iterator fans invoice line items into a 4-route router, with a second nested router gating account suspension after a 72-hour dunning delay. Results aggregate back into one warehouse write.
Scroll horizontally to pan the full canvas.
The problem
Failed payments were being chased manually from a spreadsheet. Suspensions were inconsistent — some accounts were cut off immediately, others ran unpaid for months — and finance had no single reconciled record of what happened to each invoice.
Stage by stage
How it actually runs.
Watch & iterate
A scheduled trigger polls for invoices every fifteen minutes. An Iterator splits each invoice into its individual line items so downstream modules operate on one item at a time, which is what makes per-item error handling possible later.
Route by invoice state
The first router splits four ways on invoice state: due, overdue, disputed, and a catch-all fallback. Having an explicit fallback route rather than assuming three states cover reality is the difference between a scenario that runs for a year and one that breaks the first time finance invents a new status.
Due — collect
Cards are charged, the record is marked paid, and the billing channel is notified. This is the happy path and it is intentionally the shortest one.
Overdue — dunning with a second router
A dunning email goes out, then the scenario sleeps for seventy-two hours before a second nested router re-checks payment state. Paid in the meantime clears the flag; still unpaid suspends the account through an API call. The delay-then-recheck pattern is what prevents suspending a customer who paid an hour after the reminder.
Disputed — classify and escalate
Disputes are classified by a model into a structured reason code, then opened as a helpdesk ticket with that context attached, so the person picking it up starts with the dispute already categorized.
Aggregate & reconcile
All routes converge into an Aggregator that bundles the per-item results back into a single array, written to the warehouse in one insert rather than one write per line item. A dedicated error handler with a retry policy catches module failures so a single bad record does not halt the run.
Stack
Decisions that matter
- The nested router re-checks payment state before suspending anyone.
- An explicit fallback route handles invoice states nobody planned for.
- The Aggregator collapses per-item results into a single warehouse write.
- Retries are scoped per-item, so one failure does not kill the batch.
Other automations