Recurring Invoice Schedule Builder

Set the first invoice date, the frequency and how many to generate. The series comes back as dated invoices with their due dates — anchored to the day you started from, so a schedule set on the 31st does not quietly become the 28th forever.

What this tool does

Retainers, subscriptions and maintenance agreements all bill a repeating amount on a cycle, and the difficulty is never the amount. It is the calendar: which day the invoice goes out, what happens in months that do not contain that day, and when the money is actually due once a payment term is applied to each one.

The failure worth naming is date drift. Generating each invoice by adding a month to the previous one turns 31 January into 28 February, then 28 March, then 28 April — the anchor day is lost after the first short month and never comes back. Every date here is computed from the original anchor instead, so February is the only month that moves and March returns to where it belongs.

How it works

  1. Anchor the series

    The first invoice date is the anchor. Every later date is computed directly from it rather than from the invoice before it, which is the entire mechanism that stops the day of the month sliding backwards.

  2. Choose the cycle

    Weekly and fortnightly step in days and are immune to all of this. Monthly, quarterly and annual step in months and hold the anchor day wherever the month has one.

  3. Short months clamp, then recover

    A series anchored on the 31st lands on the last day of February and returns to the 31st in March. The builder says so in a note rather than leaving you to spot it in the list.

  4. Apply the term once, across the run

    Each occurrence carries the same payment term, so the series shows issue date and due date side by side for the whole run — which is what makes overlapping invoices visible before they happen.

Worked example

A £1,500 monthly retainer, first invoiced on 31 January 2026, generated for six months.

Inputs

Amount per invoice
£1,500.00
Frequency
Monthly
First invoice
31 January 2026
Number to generate
6

Result

Invoice 1
31 January 2026
Invoice 2
28 February 2026
Invoice 3
31 March 2026
Invoice 4
30 April 2026
Total billed
£9,000.00

Why it matters: February clamps to the 28th and March returns to the 31st. Built by adding a month each time, the same series would read 31 Jan, 28 Feb, 28 Mar, 28 Apr — three days a month given away permanently, on a schedule that no longer matches the agreement it came from and that nobody will think to check.

Best practices

  • Bill retainers in advance and subscriptions on their anniversary. Both remove any argument about what had been delivered when the invoice went out.
  • Avoid anchoring a monthly cycle on the 29th, 30th or 31st when you have the choice. The 1st or the 15th behaves identically in every month and eliminates the whole class of problem.
  • Name the period each invoice covers — "retainer, March 2026" — not just its issue date. It is what makes a run of twelve reconcilable a year later.
  • Agree what happens when the agreement ends mid-cycle before it happens. Pro-rata, full period, or no final invoice are all defensible; deciding after the event is not.
  • Review the amount on a fixed date rather than when resentment sets in. A retainer that has not moved in three years is a discount neither party consciously agreed to.

Common mistakes

Letting the issue date drift

Stepping from the previous invoice rather than from the anchor loses the day permanently after the first short month. On a monthly cycle the whole series moves three days earlier for the rest of its life, and it surfaces only when a customer asks why the March invoice arrived in February.

Generating a run and never revisiting it

A twelve-month series created once and left alone keeps issuing after the agreement has ended, to a customer who has quite reasonably stopped paying. Set the end date at the point you build the series, while you still remember what it was.

Reusing one number across the series

Every occurrence is a separate document and needs its own number. One number repeated monthly produces twelve documents that cannot be told apart in either party’s records — and cannot be individually paid, credited or chased.

Billing an unchanged amount for a scope that has grown

Recurring billing is where scope creep hides best: the work expands gradually, the invoice does not, and no single moment makes the change visible to either side. The issue date is the natural checkpoint, and almost nobody uses it as one.

Frequently asked questions

What happens to a monthly series anchored on the 31st?

It falls on the last day of any month shorter than 31 days and returns to the 31st afterwards. That is what a monthly cycle means. The alternative — the series permanently relocating to the 28th after one February — is drift, and it is the behaviour most naive implementations produce.

Should a retainer be billed in advance or in arrears?

In advance is the norm, because a retainer buys reserved availability rather than delivered work. In arrears is common where the retainer is a minimum drawn against measured time. Either is fine as long as each invoice states which period it covers.

How is this different from a payment schedule?

A payment schedule divides one agreed project value into stages that must add back to it. A recurring series repeats the same amount with no total to reconcile against and, usually, no defined end. Different shape, different arithmetic, different tool.

What separates a retainer from a subscription?

Commercially, a retainer reserves capacity while a subscription grants access to something. On the document they look alike, but the period covered and what happens on cancellation are normally written very differently — and that difference is what a dispute turns on.

Can I change the amount partway through a series?

End the current series at the change date and start a new one. Editing amounts inside a running series leaves records where the same recurring line carries two values with nothing on the face of it explaining why.

Does every occurrence need its own payment term?

Each invoice needs its own due date, and applying the same term to every occurrence is the simplest way to get one. Watch for overlap: Net 30 on a weekly cycle means four unpaid invoices in flight at all times by design, which is fine if you planned it and alarming if you did not.

Turn the answer into an invoice

The result above transfers straight into the invoice generator — dates, amounts and terms already filled in. Free, no account needed.

Open the invoice generator

Sources & further reading

Related

Invoice types

Published · General information, not legal, tax or financial advice.