Recurring billing — monthly retainers, subscription-style services, ongoing maintenance contracts — needs a different trigger pattern than one-off, status-triggered invoicing: instead of firing when something changes, it needs to fire on a schedule.
The core difference from one-off invoicing
A status-triggered invoice (covered in our main invoicing guide) fires because a job finished. Recurring billing fires because a date arrived — regardless of any other status on the item. Your board needs a date-based automation rather than a status-change automation.
Structuring your board for recurring clients
Set up one board item per recurring client or contract (not per invoice) with columns for: client name, monthly/recurring amount, billing day of month, and contract start/end dates if the retainer has a fixed term. The recurring automation reads this same item every cycle rather than needing a new item created manually each time.
Handling amount changes
Keep the amount in a Numbers column on the recurring item (not hardcoded in the template) so a change to that column is reflected automatically in the next generated invoice, with no template edits needed.
What to do when a contract ends
Build an end condition into the automation — either an end date column that stops the recurring trigger, or a status field the automation checks before firing. Without this, a cancelled retainer will keep generating invoices indefinitely.
Numbering and record-keeping for recurring invoices
Recurring invoices still need sequential numbering like any other invoice — make sure your numbering scheme accounts for the fact that the same client will generate a new invoice every cycle indefinitely.
Delivery timing
Because recurring billing is predictable, most teams are comfortable with fully automatic delivery once the setup has been tested for a cycle or two — there’s no “is this job actually done” judgment call the way there is with status-triggered invoicing.
Testing before relying on it
Let a recurring automation run through at least one full cycle on a test item (or a real client, closely watched) before trusting it fully — confirm the date logic fires on the day you expect and that amount changes made mid-cycle show up correctly in the next generated invoice.
A recurring invoice template is available in our template gallery; for one-off, status-triggered invoicing instead, see the main invoicing guide.