When you create a group of recurring memberships, you choose a billing day — the day of the month when the client is charged on a regular basis.
Zenamu gives you two options:
Automatically, based on the purchase date (default)
Always on the 1st of the month (with a prorated first payment)
This article will help you decide which approach suits your studio better.
Option 1 — Automatically, based on the purchase date
This is the default setting, and it's what most studios use in practice.
How it works:
A client buys a membership on, say, 15 April.
They're charged on 15 April, and then again on 15 May, 15 June, 15 July…
So the billing day is different for each client. It depends on when they first bought the membership.
Example:
Client | Purchase date | Next payments |
Anna | 3 April | 3 May, 3 June… |
Petr | 15 April | 15 May, 15 June… |
Eva | 28 April | 28 May, 28 June… |
When to choose it:
The familiar subscription model, like Netflix, Spotify and so on.
The client pays the full amount for the first period right away — clear and fair.
You don't have to deal with prorated price calculations.
Minor variations:
If a client buys on, say, 31 January, the next payment falls on 28 or 29 February (Stripe adjusts it, because February doesn't have a 31st day), then 31 March, 30 April, and so on. In cases like these, Stripe tries to keep the charge at the "end of the month".
Option 2 — Always on the 1st of the month
The client is charged regularly on the 1st of the month, no matter when they bought the membership.
How it works:
A client buys a membership on 15 April.
The first payment is prorated: they're charged only for the remaining days until the end of April (from 15 to 30 April = 16 days out of 30).
On 1 May, the full amount is charged for all of May.
From then on, the full amount is always charged on the 1st of the month.
Example — a monthly membership for €60:
Client | Purchase date | First payment (prorated) | Next payments |
Anna | 3 April | €56 (28 of 30 days) | 1 May €60, 1 June €60… |
Petr | 15 April | €32 (16 of 30 days) | 1 May €60, 1 June €60… |
Eva | 28 April | €6 (3 of 30 days) | 1 May €60, 1 June €60… |
The client sees the prorated amount in the form before they confirm the purchase, so the final figure won't catch them off guard.
When to choose it:
Your bookkeeping runs on a monthly basis and you want all payments on the same day.
Your clients used to pay you on the 1st of the month, and you want to keep that habit.
Minor variations:
If a client buys on 1 April, nothing is prorated and the full €60 is charged for April straight away.
If a client buys on 30 April, they're charged a small prorated amount (1 day) and then the full amount the very next day (1 May). The client sees both amounts before confirming the purchase, so they know about it.
Which model to choose
Situation | Recommendation |
A typical studio that doesn't want to deal with monthly bookkeeping | Automatically, based on the purchase date |
You bill regularly on the 1st of the month and want to align all payments | The 1st of the month |
Clients are coming from a studio where they paid on the 1st of the month | The 1st of the month |
Most of your clients buy at the start of the month | Automatically (from the 1st onward the result is almost identical) |
Yearly or quarterly memberships | Automatically (tying long intervals to the 1st of the month doesn't make sense) |
Tip: The billing-day setting applies to the whole group. If you want a different billing day for different variants, create them in separate groups.
Can the billing day be changed after the group is created?
The group's billing-day setting only applies to new purchases. Existing members keep the day they originally started on.
In other words: if you
create a group set to automatic,
50 clients buy a membership on different days,
and you then switch the group to the 1st of the month,
the existing 50 clients keep paying on their original days (the 3rd, 15th, 28th, and so on). But new purchases from the moment you switch will fall on the 1st of the month, with a prorated first payment.
What if a client pays at the end of the month?
Stripe tries to keep the charge on the same day each period. If a client pays on 31 January and February only has 28 days, Stripe charges on the 28th (or the 29th in a leap year), and the following month it goes back to the 31st (or the last day of the month, if that month has fewer days).
The client always sees the exact date of their next payment in their account, so they know about it.
Frequently asked questions
What if a client forgets to update their card before the billing day?
If Stripe can't take the payment (an expired card, not enough money in the account), payment retries kick in (see the article When a payment fails). The client gets an email notification and has a few days (the grace period) to update their card.
Can I move a client's billing day manually?
You can't change the billing day for an individual client from the Zenamu admin. If a client wants to change the day, the simplest route is to cancel their current membership at the end of the period and have them buy it again (with a new day based on the purchase date).
What happens if a variant has an interval of "1 × week" or "1 × year"?
The 1st of the month setting mainly makes sense for monthly intervals:
Daily and weekly intervals — combining "the 1st of the month" with a daily or weekly variant isn't possible. Zenamu blocks this combination in several places at once: in the admin when you create or edit a group and a variant, when you save, in the preview of the first invoice, and when the subscription is actually created in Stripe:
In the admin, you can't select "the 1st of the month" if the group has at least one daily or weekly variant — an explanation appears next to the billing-day toggle: "The "1st of the month" setting can't be used because one of the variants has a daily or weekly billing period (Stripe doesn't allow this combination)." And the other way around: if the group is set to "the 1st of the month", you can't choose a daily or weekly interval for a variant — the interval field shows "The group has a fixed billing day (the 1st of the month), so a variant can only use a monthly or yearly interval. Stripe doesn't support daily and weekly intervals in this combination." If you tried to save an incompatible variant anyway, the admin shows the message "The "1st of the month" billing day can only be set for monthly and yearly variants. Stripe doesn't support daily and weekly intervals in this combination."
If you somehow got around this combination (for example, by editing the database directly), the backend rejects it both in the preview of the first invoice and when it actually tries to create the subscription in Stripe. In that case, the client only sees a generic message in the purchase form — "We couldn't load the price summary. Please refresh the page and try again, or contact the provider if the problem persists." — and they won't be able to complete the purchase.
Recommendation: if you use daily or weekly variants, leave the group set to Automatically, based on the purchase date.
Yearly interval — Stripe does apply the 1st of the month setting: the billing day moves to the next upcoming 1st of the month. If a client buys on 15 April, they're charged a prorated amount for 15–30 April at purchase, and from 1 May (the next upcoming 1st) the full yearly period runs; every following year, the full yearly payments then go through on 1 May. This behaviour can be surprising. For yearly billing, you usually want automatically, based on the purchase date.
We recommend using the 1st of the month setting only for monthly intervals, where it makes the most sense.
What if a client has a membership shorter than a month?
If a client buys on 28 April with the 1st of the month setting, they're charged a prorated amount for just 3 days (until 30 April). That's a very small amount. Stripe has its own minimum for each transaction, which varies by the studio's currency and country. You'll find the exact figures in the Stripe documentation (the section on minimum payment amounts). If the prorated amount drops below this minimum, Stripe rejects the purchase: the client sees an error from Stripe (Zenamu doesn't add its own message for this case). The client always sees the final amount in the purchase form before they confirm the purchase, so they know about it.
Related articles