A status change raises the invoice; a schedule chases it
Six Make scenarios raise and email an invoice when a CRM status changes, write the invoice back onto the record, and chase unpaid invoices on a schedule with friendly, firm and sales-toned reminders.
Where this applies
Training providers, agencies and any business that bills from a CRM and wants an invoice raised by a status change.
- invoice types: recurring, enrolment, upfront
- 3
- days from issue to due date
- 7
- runs, one error
- 78
The problem
When billing is done by hand from a CRM, an invoice is raised late, or twice, or not at all, and the record never says whether it was sent. Chasing unpaid invoices is the first job to be dropped.
A better model makes the CRM status the single source of truth: change it, and an invoice appears, goes out, and is written back so everyone can see its state.
What we built
A status as the trigger
Three scenarios, one for each kind of fee (a recurring monthly fee, an enrolment fee and an upfront fee) fire when a student's billing status changes to the matching label.
Create, send, write back
Each finds the contact in the accounting system, creates an authorised invoice due in seven days with a line built from the CRM's price, item code and description and a revenue tracking category, fetches the online invoice link and sends it through the accounting system's own email. It then writes 'Waiting Payment', the invoice number, the issue date and the link back onto the CRM item.
A fallback for a new contact
The enrolment and upfront scenarios match the contact by email and have a router that creates the contact if it is missing. The recurring scenario matches by name and has no fallback, so a contact it does not know is skipped.
Reminders read the state
Three scheduled scenarios read that status: a daily friendly reminder before the due date, a daily firmer one once overdue, and a twice-weekly sales-toned chaser for the upfront fee, each sent by email from Microsoft Outlook.
The outcome
Across the six scenarios: 78 runs and 782 operations in Make's counters, with one error, a duplicate contact name in the create-contact step.
The three invoicing scenarios are live. The three reminders have run 14 times between them and are switched off.
Where it stops
Nothing here writes 'Paid' or 'Overdue' back to the CRM, so something else must set those. Creating an invoice is not idempotent: selecting the trigger label again raises a second one. The reminders have no counters or cool-downs and read lists capped at twenty-five items, and with all three switched off an unpaid invoice currently gets no chaser from Make. None of the scenarios has an error route. A one-time-invoice prototype and a copy mid-fix are not described.
Built with
- Make.com
- monday.com
- Xero
- Microsoft Outlook
Patterns used
- Status as trigger
- Write the invoice back
- Contact fallback
- Reminder tiers
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no