Two things that look the same on a bank statement:

A designer bills a client $1,500 on the first of every month for an ongoing retainer.
A software company charges that same client $1,500 on the first of every month for a platform licence.

Same amount, same date, same word on the statement. They are not the same arrangement at all, and conflating them is how people end up either scared of setting up recurring billing or, worse, building something their clients come to resent.

The difference is who has to act to stop it

That is the whole distinction, and it is worth stating plainly.

A recurring invoice is a bill you send for work you are doing. Your client decides every cycle whether they still want it. If they stop hiring you, they stop paying you, and the mechanism for that is simply: they tell you, and you stop sending invoices. There is no lock-in because there is nothing to lock. You are not holding their card. The default state is "this ends" and the recurring invoice is just an administrative convenience that saves you retyping the same lines twelve times a year.

A subscription is a standing charge against a payment method you are holding. The default state is "this continues," and the customer has to take an action — find the settings, locate the cancel button, survive the retention flow — to stop it. That asymmetry is the product. It is why subscription businesses forecast so well, and it is also why they go wrong so reliably.

When we read 768 real online discussions about invoicing software before pricing this product, that asymmetry was the source of nearly all of the genuine anger in the dataset. Free features moved behind a paywall once people depended on them. A plan price that roughly doubled with a refund request refused. "Unlimited" sold and then redefined. Cancellation flows that did not actually cancel. People used the phrase "bait and switch" repeatedly, and they did not mean the price was too high — they meant the deal changed after they had committed. We wrote up what that research did to our own pricing in why we built a lifetime plan instead of another subscription.

So if you have been hesitant about setting up recurring billing for your own clients because it feels a bit like that: it is not, as long as you keep the distinction above. You are not creating a trap. You are saving yourself from retyping a retainer.

Why a recurring retainer is worth bothering with

Because the alternative is remembering, and remembering does not scale. The research is unusually grim on this specific point. From someone running marketing for small businesses, in a public thread — not a customer of ours:

I run marketing for small businesses. Sometimes, I will setup a recurring billing as soon as I onboard a client and sometimes I setup a one off invoice and then setup the recurring one later.

And from the same thread, the reason that distinction matters:

I've done the same thing. Sucks to look back through your books and realize you've missed $80K in invoicing.

Eighty thousand dollars of work done, delivered, never billed. Not disputed, not refused — never asked for. That is not an unusual story in the dataset, just an unusually large number. Elsewhere in the research: "I have an embarrassing amount of work I never billed for, spread out amongst 1-2 dozen clients."

A recurring arrangement is exactly where this happens, because nothing prompts you. A one-off project ends and the invoice is the obvious last step. A retainer just quietly continues, and the month it does not get billed feels exactly like the month it does.

How recurring invoices work in Charming Invoices

Here is the actual mechanism, because the point of this section is to be specific rather than to gesture at automation.

You create a template. It holds one client, a frequency (weekly, monthly, quarterly or yearly), the date of the first invoice, an optional date to stop, the line items, a tax rate, a discount if any, and footer notes. The live totals update as you type, so you can see what each generated invoice will be worth before you save it.

A scheduled job raises a draft when one is due. Once per day, a process on our server works out which templates owe an invoice and creates it. The invoice it creates is a draft, every single time. Nothing is ever emailed to your client by the schedule.

You review it, then you send it. The draft sits in your invoices list with its line items, dates and totals filled in. You can edit any of it first — change a line, adjust a quantity, swap the client, add a one-off item for the extra work you did that month. When you are happy, you send it yourself, the same way you would send any other invoice.

You get told it is waiting. Each run emails everyone on the business a short digest: however many recurring drafts are ready to review. That is the prompt the $80,000 story was missing.

The draft does not take an invoice number. Numbers are claimed at the moment you send, so a draft you decide not to send does not leave a hole in your sequence. If you pause a client for two months, your numbering is still gapless.

It copies the surrounding details too, not just the lines. The client's name, address and email, your bank details, your payment link and your footer notes are all snapshotted onto the draft at generation time, so the document is complete rather than half-filled.

The due date is the issue date plus 14 days. That is currently fixed for generated drafts rather than configurable per template. If you want different terms on a particular one, change the due date on the draft before sending — it is a draft, everything on it is editable.

Missed periods catch up, and nothing is ever duplicated. If your server was down, or the template's start date was in the past, each missed period generates its own invoice rather than being skipped or collapsed into one. And a given period can only ever produce one invoice: the database enforces that directly, so two runs overlapping cannot bill a client twice for the same month. We were deliberately careful here, because double-billing a client is a much worse failure than not billing them.

Month ends behave sensibly. A monthly template that starts on the 31st runs on 28 February, then 31 March, then 30 April — it does not permanently slide onto the 28th after passing through February, and it does not overflow into the following month.

You can pause, edit, or end it. Pausing stops generation and keeps the template. An end date retires it automatically once the schedule passes it. If you archive the client or the business, the template holds its place and raises nothing until you unarchive.

What it deliberately does not do

Three honest limitations, because a feature tour that only lists strengths is not information.

It does not auto-send. This is a design decision and we are not planning to change it. A draft is never sent to a client until a human has looked at it, because the failure mode of auto-sending — a wrong amount, a client who cancelled last week, a duplicate — lands on your relationship with your client, not on us. The research had an example of what the other approach feels like from the receiving end: someone's "client's invoice link told him 'no payment required' on a balance that was very much required." We would rather give you a prompt and let you press send.

It does not hold your client's payment method. We are not a payment processor. Your bank details or your own payment link go on the invoice and your client pays you directly. So a recurring invoice here really is a bill, not a charge — which is the entire point of this post, but it does mean you are relying on your client to pay each one rather than on a card being debited.

One template is one fixed set of lines. It is not a tiered billing engine. Someone in the research complained, reasonably, that a competitor's "recurring invoice tool can't even handle two different amounts on two different billing dates, which feels like a day-one feature for anyone running a real business." We will be straight about where we stand: one template produces the same lines every cycle. If you need two different amounts on two different dates, you set up two templates — or you edit the draft before sending, which is a perfectly good answer when the variation is occasional rather than structural. Usage-based billing that computes a different figure each month is not something this does.

It is a paid feature. Recurring invoices are included from the $29 one-time Individual Lifetime licence upward, and are not on the free tier. The free tier has genuinely unlimited clients and invoices; recurring templates, AI-assisted drafting, the saved line-item library, multiple businesses and teammates are the things it leaves out. That full list is on the pricing page and in our terms, and it is limited by scope rather than by volume — nothing in it counts how many invoices you send.

When to use which

Use a recurring invoice when you are billing the same client for the same ongoing thing: a monthly retainer, a maintenance agreement, a content package, a few days a week of shooting, rent, a quarterly review. Anything where the work repeats and the client is free to stop asking for it.

Do not use one when the amount genuinely varies every cycle in a way that needs calculating, or when you are billing per project. A template that you have to rewrite before every send is worse than just making a new invoice, and copying last month's invoice is often the faster move.

Think hard before you build an actual subscription — a standing charge against a card you hold — into your own business. There are good reasons to do it, and plenty of honest businesses run on it. But the thing our research is unambiguous about is that customers who feel locked in start keeping score. The specific stories that produced the harshest language in that dataset were all versions of the same structure: a cheap or free commitment, a dependency, and then a change to the terms. If you do run a subscription, the fix is not better retention copy. It is making the exit as easy as the entrance.

The short version

A recurring invoice bills the same client on a schedule and ends the moment they stop hiring you. A subscription continues until someone cancels it, and the gap between those two defaults is where most software resentment is born.

Ours generates a draft, emails you to say it is ready, and waits. That is the whole promise: the schedule does the remembering, and you still do the sending.