When should you bill a recurring payment?

Suppose you're running a service that charges its users $10 a month. Now, suppose that a user joins on June 15th. It seems like there are two possibilities for how to handle his billing:

(1) Give him a billing date of the 15th of this (and every other) month: You immediately bill him for $10 on June 15, and then again on July 15, August 15, etc.

(2) Give him, and all your users, a billing date of the 1st of the month, and pro-rate his initial payment: You bill him $5 on June 15, and then $10 on July 1, August 1, and so on.

Does anyone have any experience, and recommendations, with these alternatives? I've seen this done both ways; the prorated approach seems a little more complicated at start but then easier(?) later, but I kinda like the idea of distributing your payments throughout the month so you maybe have a better ongoing read of customer maintenance. But I don't know, really -- any advice out there?

Mahesh J
Been working with startups for more than 4 years, building goldenhour.co

July 5th, 2017

I'm in the same boat, trying to figure this out. I'm personally inclined towards the second approach because it feels like I'll have better view of my cash flow.

If I get all the payments on 1st of each months, I can plan my expenditure, etc for the rest of the month in a better way.

Unless you have a special arrangement with your payment processor, the first one is the ONLY option you have. Setting up permission and a subscription account with a payment processor follows very strict guidelines. No customer cares how convenient it is for you.

Know also that transactions billed on the first day of the month face the highest rate of declines, because day-one transactions are the most commonly fraudulent. You'd spend extra time defending and processing transactions that occur on the first day of the month that compete with all kinds of other transactions. If you had to pick a day, pick some other day, but not the first.

But back to the first point...your payment processor only allows you to establish a recurring charge when it is an IDENTICAL amount each month. You do not want to accept the liability for storing and protecting customer card numbers (or bank accounts) so you have to follow the processor's rules for setting up recurring billing. That means you won't be able to pro-rate your accounts because the second charge won't be identical to the amount of the first charge.

Lastly, if you are SO BAD at accounting that you cannot graph recurring payments that come in on any day of the month instead of one specific day of the month, you may not be ideally suited to be in business at all. You also risk the appearance of seasonality, in the same way that welfare check recipients or social security check recipients get payments on the first of the month, you have this temptation to splurge when you are cash rich, and then falter when you have spent all the money before the month is over.

Recommended for responsible banking is the no-set-date subscription model. If you aren't focused on one cash-heavy day of the month, you will train yourself to be more fiscally responsible on a continuous basis and to think long-term about the daily health and growth of your business. With a synchronized billing scenario, if something were ever to go wrong and delay your deposits for that day, you'd risk screwing up all the things you stacked behind it.

Like Mahesh J said in the answer below, the second option might be good since it allows you to plan expenditures for the next month. Keep in mind that either way you're going to be planning expenditures based on last month's revenue so, in reality, it doesn't make much of a difference. You're still going to have the same reports as with any other plan, except all your money will come in on one day (the 1st).

I think there's an issue with the second option. What happens if someone joins on the 10th, 16th, 20th? Those make for really ugly numbers if you end up having to divide them. $10 / 30 days = ~$0.333/day. The system works great if they register on the 15th (0.333 * 15 = $5) but if they register on the 23rd (0.333 x 23 = $7.66), it doesn't work out as nicely but it can still be made to work. Not sure if this problem has been tackled by you yet (maybe I'm missing something), but I can see how it would be far more complicated to set up than just billing based on when they registered.

So far each online service I have signed up for bills you the day of the month you registered. It honestly doesn't make a difference for me because I just write a repeating schedule on my calendar that says: "X is billing you $10 today" on each day I get billed. No fuss on my part.

Now if we're looking at the general public, their payments are already spread out throughout the month! Companies all around the world generally (I find) use the first method. Now your company starts using the second method? Well, it honestly doesn't make a difference in the eye of a consumer. Their payments are still spread out around the month, and yours just happens to be on the 1st of each month. No change, really.

All in all, it's really up to you. Seeing as you have already looked into both methods yourself and are leaning towards the second method, then go with your gut. If you want to save time engineering the more complex system and avoid having to tell people "we'll subtract the days in the month after the 1st you missed on registration date, charge you that, then charge you on the 1st of each month the full amount blah blah blah", then go with the first method. Wouldn't this look better? "We bill you each month the day you registered". It sounds simpler, doesn't it? Anyhow, it might be simpler to avoid focusing on these tiny details and really work on your product more than anything else. Just pick a system, run it and if people hate it, switch it! Simple.

So option 1 / billing on signup date is much more commonly used and it's the easiest route especially if you're building the subscription feature from scratch. However I believe platforms like Chargify allow you handle more complex cases such as prorata, Upgrade/Downgrade in the middle of the month and so on