How to build a collections workflow from scratch
A collections workflow is built from three parts: stages, triggers, and owners. This blueprint shows how to define each one and wire them into a working end-to-end system.
To build a collections workflow from scratch, define three things: the stages an invoice moves through, the triggers that move it between them, and the owner responsible at each stage. Once those are written down and connected, chasing stops depending on memory and starts running on a schedule. This guide gives you the blueprint to design one from a blank page.
A workflow is different from a process you have inherited and want to fix. Here you are starting clean, so you get to design the logic deliberately: what counts as overdue, how fast escalation happens, who steps in and when. Get the blueprint right once and every invoice follows the same reliable path.
The building blocks of a collections workflow
Every collections workflow, no matter how simple or sophisticated, is made of the same three parts.
- Stages. The discrete steps an invoice passes through, from current to fully escalated. Each stage has its own message, tone, and intent.
- Triggers. The conditions that move an invoice from one stage to the next. A trigger is usually a number of days past due, a balance threshold, or an event like a customer reply.
- Owners. Who is responsible at each stage. Early stages can be owned by an automated sender. Later stages need a named person who makes a call or a judgment.
If you can fill in those three columns for your business, you have a workflow. Everything else is refinement.
Defining stages, triggers, and owners
Start with stages, because they frame everything else. Sketch the journey of a single invoice from the day it is issued to the day it is either paid or written off. A standard B2B journey has six stages: a pre-due courtesy reminder, a due-date prompt, a first overdue notice, an escalation notice, a final notice, and a handoff to a person or agency.
Then attach a trigger to each transition. The cleanest triggers are time-based: move to "first overdue" at 5 days past due, "escalation" at 20 days, "final notice" at 45 days. Layer in event triggers that override the clock: a dispute pauses the whole workflow, a promise to pay pushes the next touch to the promised date, a payment closes the invoice out. Time triggers keep the workflow moving; event triggers keep it from doing something dumb.
Finally, name an owner for each stage. The early stages, where the action is sending a templated reminder, can be owned by an automated system. The later stages, where the action is a phone call or a decision to escalate legally, need a person. Write the owner next to each stage so no invoice ever sits in a stage with nobody responsible for it.
A sample end-to-end workflow
Here is a complete blueprint for net-30 terms. Adjust the day counts to your own terms.
| Stage | Trigger | Owner | Action |
|---|---|---|---|
| Pre-due reminder | 3 days before due | Automated | Courtesy email with payment link |
| Due-date prompt | On due date | Automated | Friendly nudge, invoice and amount restated |
| First overdue | 5 days past due | Automated | Past-due notice, slightly firmer |
| Escalation | 20 days past due | AR specialist | Firmer email plus a follow-up call |
| Final notice | 45 days past due | AR manager | Final notice stating next steps |
| Handoff | 60 days past due | AR manager | Personal call, then collections or legal |
Three event triggers cut across every stage. A dispute pauses the workflow and routes the case to a named owner. A promise to pay reschedules the next touch. A payment closes the invoice and stops all further messages. These overrides are what separate a workflow that helps from one that emails a customer who already paid.
Templates for each workflow stage
A workflow only runs if the message for each stage is written and ready. You do not want anyone drafting an email in the moment, because that is where consistency dies. Prepare one template per automated stage with bracketed placeholders the system fills in.
Subject: Invoice [Invoice number] is due [Due date]
Hi [Customer name],
A quick reminder that invoice [Invoice number] for [Amount] is due on [Due date]. You can pay it here: [Payment link].
If anything looks off, just reply and we will sort it out.
Thanks,
[Your name], [Company name]
When to use: the pre-due and due-date stages, as a courtesy before anything is overdue.
Subject: Action needed: invoice [Invoice number] is [Days overdue] days overdue
Hi [Customer name],
Invoice [Invoice number] for [Amount] was due on [Due date] and is now [Days overdue] days overdue. Please settle it here: [Payment link].
If you cannot pay in full right now, reply and we will set up a date rather than let this keep aging.
Regards,
[Your name], [Company name]
When to use: the escalation stage, once an account crosses your firmer threshold with no response.
For the wording at every other stage and the right gaps between them, drop in a ready-made payment reminder email sequence rather than writing all six from scratch.
Testing and refining the workflow
A workflow you build on paper will be wrong in small ways, and that is fine. Run it on a slice of your ledger first, maybe one customer segment, and watch what happens at each transition. Are invoices moving to escalation too fast and annoying good customers? Are they sitting too long before anyone calls? Adjust the trigger day counts based on what you see, not what you guessed.
Watch the override triggers especially closely. A dispute that does not pause the workflow, or a payment that does not close the invoice, will send a customer a chasing email they should never have received. Those are the failures that damage relationships, so test them deliberately. Once the workflow runs clean on the test slice, widen it to the full ledger. Then revisit the day counts each quarter as your payment behavior shifts.
How Rex executes your workflow automatically
A workflow on paper still needs something to run it, touch by touch, across every invoice, all day. That execution is where teams fall down. Someone has to send the right message at the right age, watch for the disputes and promises that change the path, and hand off the accounts that need a person. Done by hand across a full ledger, the workflow degrades back into chasing by memory within weeks.
Rex is an AI accounts receivable agent that takes a workflow like the one above and runs it as a live, self-driving engine. It moves each invoice through the stages on your triggers, sends and personalizes the message for each one, and watches every reply so a dispute pauses the path and a promise reschedules it. It does this across the whole ledger at once, not just the accounts a person had time for, and escalates only the cases that need a human decision. To see how a built-from-scratch workflow compares to fixing an inherited one, read how to improve your AR collection process. The mechanics of keeping each message personal at scale are covered in how to automate payment reminders.
See how Rex runs collections end to end.
Frequently asked questions
- What are the building blocks of a collections workflow?
- Three things: stages (the steps an invoice moves through from current to escalated), triggers (the conditions that move an invoice from one stage to the next), and owners (who or what is responsible at each stage). Define all three and the workflow runs itself.
- What is a trigger in a collections workflow?
- A trigger is a condition that moves an invoice to the next stage, like reaching 7 days past due, crossing a balance threshold, or a customer raising a dispute. Triggers replace the human decision to act, so chasing happens on schedule instead of from memory.
- How many stages should a collections workflow have?
- A typical B2B workflow has five to six stages: pre-due reminder, due-date prompt, first overdue notice, escalation notice, final notice, and handoff to a person or agency. Match the count to your payment terms and the value of the accounts.