This post may contain affiliate links. If you buy through one, we may earn a commission at no extra cost to you. See our Affiliate Disclosure for details.
The March invoice went out on the first. It is now the twenty-second, and the client who has paid the same amount every month for two years has not paid this one, not because anything is wrong but because the email sat under forty others and nobody at their end opened it. The work is done. The money exists. What's missing is a click, and the only lever available is a reminder that will land in the same inbox as the invoice did.
That gap is the whole difference between the two ways of billing a retainer. The question of recurring invoices vs subscriptions is not really about software. It's about who holds the trigger on the day the money is due.
A recurring invoice automates the sending; a subscription automates the collecting. With a recurring invoice, the system generates and emails the bill on schedule, but the client still has to act before you’re paid. With a subscription, the client agrees once to a saved card or bank account, and the platform charges it every cycle without anyone clicking. Subscriptions win for small, fixed retainers with individuals and small businesses. Recurring invoices win when the client is a larger company that pays by bank transfer through an accounts-payable process, or when the monthly amount changes. Most solo owners end up running both, sorted by client rather than by preference.
Same monthly amount, two different mechanics
Both approaches start from the same place: a client, a fixed fee, and a date. Where they part is what the platform does on that date.
A recurring invoice is a template with a calendar attached. On the first of the month (or whatever cadence you set) the platform creates the invoice, numbers it, and emails it with a pay link. Then it waits. The client opens the email, opens the link, enters a card or pushes a bank transfer, and the invoice flips to paid. Reminders can go out automatically if it doesn't. At no point does money move without the client doing something.
A subscription flips that. The client provides a payment method once, agrees to be charged on a schedule, and from then on the platform generates the invoice and pays it in the same motion. The client receives a receipt, not a request.
Stripe's documentation makes the split unusually explicit, because it's a single setting. Every invoice and subscription on the platform carries a collection_method that is either charge_automatically or send_invoice. Its collection methods page describes send_invoice as generating "an invoice for each billing period" that "requires manual payment," with an adjustable payment window, while charge_automatically tells the platform "to automatically charge your customer's default payment method to pay the invoice generated for each billing period." Same subscription object, opposite behavior on the due date.
Other invoicing apps don't expose the switch by name, but the same fork exists in most of them. The freelancer-oriented tools (Wave, FreshBooks and Square Invoices among them) all have a recurring-invoice feature, and most can attach a saved card so the recurring invoice charges instead of merely sending. Which plan tier that sits on varies by vendor and moves around, so the vendor's own page is the only reliable answer on the day you set it up.
The invoice is the same either way. What differs is whether anyone has to touch it. Photo via Pexels.
Who holds the trigger
Put the two side by side on the things that actually decide whether you get paid on time.
| Recurring invoice | Subscription (card or bank on file) | |
|---|---|---|
| Who acts on the due date | The client | Nobody |
| Client setup | None beyond an email address | One-time payment method entry plus explicit consent |
| Handles a changing monthly amount | Yes, edit before it sends | Awkward; usually a fixed price plus add-ons |
| Fits accounts-payable departments | Yes, they expect a PDF and a due date | Rarely; many can't put a company card on a vendor's file |
| What a late payment looks like | Unpaid invoice, reminders firing | A failed charge, retries firing |
| Client can cancel without telling you | No, they simply stop paying | Yes, if you give them a self-serve portal |
| Cash-flow predictability | Depends on the client's habits | High, until a card expires |
The middle rows are where the decision usually gets made. A solo consultant billing a fifty-person company will almost always end up on recurring invoices, because that company's finance team has a process and a saved card isn't part of it. The same consultant billing three small business owners for monthly maintenance is leaving money on the table by not moving them to a subscription, because those clients pay late out of distraction, not policy.
Which is why this is rarely a single choice. It's a sort.
What a failed charge looks like on each side
Nothing runs cleanly forever, and the two approaches fail in visibly different ways.
When a recurring invoice goes unpaid, the platform's job is to keep asking. Stripe, for example, lets you attach up to three reminders to a send_invoice subscription, "starting at 10 days before the due date and ending at 60 days after," and then take action on the subscription itself 30, 60 or 90 days past due. That's a long, polite runway, and it's the right shape for a client who genuinely intends to pay. The mechanics are the same ones behind automated invoice reminders on one-off work, just scheduled in advance.
When a subscription charge fails, the platform's job is to try again. The Smart Retries documentation describes retrying "a specific number of times within a time period: 1 week, 2 weeks, 3 weeks, 1 month, or 2 months," with a recommended default of eight attempts over two weeks, timed by a model that watches signals like the hour when a given card is most likely to clear. If every retry fails, you choose in advance what happens: cancel, mark unpaid, or leave the subscription past due.
Two details from those same pages are worth knowing before you pick.
Some declines can't be retried at all. A lost or stolen card, an incorrect number, or an issuer that revokes the authorization produces what Stripe calls a hard decline. The scheduled retries keep counting, but the payment "only executes if you obtain a new payment method." No amount of automation gets past that one; it's a conversation with the client.
Card expiry is the quiet killer of subscriptions. A retainer that has run for eighteen months will eventually hit the month the card on file expires. Stripe can send a customer email "when a card on file is about to expire," and the customer emails page lists it as an option you enable in the dashboard rather than something that's on by default. If you turn on card-on-file billing and don't turn on that email, the first sign of trouble is a failed charge, which is the same class of problem as any automation that breaks without raising an error.
The consent step you can't skip
Charging someone's card while they're not looking is a regulated act, and the platforms say so plainly.
Stripe's save-and-reuse guide puts it this way: "When you save a payment method, you can only use it for the specific usage you've included in your terms," and to charge a customer while they're offline you must "explicitly collect consent from the customer for this specific use." The terms are supposed to spell out four things: the client's agreement to a series of payments, the anticipated timing and frequency, how the amount is determined, and the cancellation policy. And then: "Make sure you keep a record of your customer's written agreement to these terms."
For a solo owner this translates into one paragraph in the retainer agreement and one checkbox on the payment form. It sounds like bureaucracy. It's actually the thing that decides a dispute in your favor six months later when a client claims they never agreed to be charged.
Recurring invoices carry none of this weight, because the client re-authorizes every single payment by paying it. That's a real point in their favor for any client relationship that feels even slightly fragile.
One more note from the same documentation, because it catches people: the customer emails page states that to comply with FTC and California subscription rules, Stripe Billing offers a near one-click cancellation flow and says you "must enable Subscription Management" to include manage-subscription links in billing emails. Whether that applies to a services retainer depends on your jurisdiction and your agreement, and this post isn't legal advice. But a subscription that's easy to start and hard to stop is now a compliance question, not just a customer-service one.
Consent, frequency, amount, cancellation. Four lines in the agreement, written once. Photo via Pexels.
A sort, not a switch
The practical version of all this is a short list of questions per client, not a platform decision.
Does the client pay through an accounts-payable process? If a PDF gets forwarded to someone with "approved" in the subject line, that's a recurring invoice. A subscription will get bounced back to you with a request for a proper invoice anyway.
Is the amount genuinely fixed? A retainer that says "up to ten hours, billed at the end of the month for what was used" is a recurring invoice with an editable line. A flat monthly fee is a subscription.
Has this client ever paid late for a reason other than forgetting? If yes, keep them on invoices; the re-authorization each month is protection. If their lateness is pure inbox drift, they're the best candidate you have for a saved card.
Does the client pay by bank transfer? Bank transfers, per Stripe's collection-method docs, "only support send_invoice and can't be charged automatically." Direct debit is a different story and can run on a subscription, but the setup is longer and the consent rules are stricter.
Sort your retainer clients through those four, and most solo owners find a clean split: a few larger clients on recurring invoices, everyone else on subscriptions. Both approaches feed the same ledger, and the cash-flow forecast gets more reliable the more clients sit in the second group.
About fees, checked September 14, 2026
This post prints no prices. Card-processing rates, the percentage some platforms add on subscription volume, and the plan tier that gates automatic charging in the freelancer apps all change often enough that a number here would mislead someone reading it in a few months.
What to look at on any vendor's pricing page, in this order: whether recurring billing costs a percentage of volume on top of the card fee (some platforms structure it that way), whether saved-card charging is on the free tier or a paid one, and whether bank-debit payments cost less than cards for a monthly retainer, which at fixed amounts they often do. Stripe's pricing page is the reference point for the first two; the invoicing apps publish their own. Check the date on any third-party comparison before trusting it.
Move the client who always pays late before their next invoice date
One action, and it takes an afternoon.
Pick the single retainer client whose lateness is habit rather than policy, the one who pays every month and never on time. Open your agreement with them and add one paragraph covering the four consent items above: what you'll charge, when, how the amount is set, and how they cancel. Send it with a saved-card request from whatever invoicing tool you already use, and set their next invoice to charge automatically instead of send. Turn on the expiring-card email while you're in the settings.
Do this with one client, not all of them, because the first one teaches you where your tool hides the setting and how your client reacts to the ask. If it goes smoothly, the sort in the section above takes an hour. If it doesn't, you've learned it on the client most likely to benefit, and your other retainers stay exactly as they were.
저는 한국에서 직원 없이 혼자서 두 개의 소규모 사업체를 운영하고 있습니다. 견적, 회계, 마케팅, 웹사이트 관리까지 모두 제가 직접 하고 있습니다. 개발자는 아니지만, 이 사이트의 자동화 시스템은 AI 코딩 도우미를 활용하여 밤늦게까지 오랜 시간 공들여 구축했고, 모든 콘텐츠 관리 및 게시도 제가 직접 담당하고 있습니다.