4 ms·

The article considers billing systems in an interesting way. There are topics presented as problems that I'd hand off to accountants or other specialists we're

The article considers billing systems in an interesting way. There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. > Billing systems are of high complexity; I recognise that. [...] They're less complex than whatever your developers are working on. The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. Parts of the process do change frequently, but those parts are well labeled and well explained. > Indeed, there's no better approach than the one that serves you. If you're a subscription-based SaaS, you have specific solutions for your business. If you're a usage-based API, you have specific solutions to the billing. I mean, will your customers allow you to shift the burden of responsibility? Is your income important enough to verify? Can you afford the haircut?

doctor_eval 3y ago
> There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. But aren’t we supposed to be automating this stuff? What software do you think the accountants use? You go to the accountants to ask the questions, but if you’re billing at scale you can’t just push the problem aside. The accountants already have jobs to do and billing is not one of them. > They're less complex than whatever your developers are working on I worked on billing systems for a long time. They are definitely more complex than whatever your developers are probably working on. It’s all in the article. Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If you think this is an easy question, you don’t understand billing. > The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. That’s the funniest thing I’ve read here in a while! The legislation is not even kept in one place. It’s often opaque. You need an accountant to explain it to you. It gets worse when you’re working with public companies. I’m sorry but your replies are the typical “billing is not that hard” of an inexperienced engineer, posted to an excellent article explaining exactly why billing is hard.
- meekaaku 3y ago
  > Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If n days of m day month is used, the charge will be n/m * monthly_rate, no? And it would be just another line item in the monthly invoice.
  - arnon 3y ago
    1. You assume monthly_rate exists. It's usually not defined that way... 2. Imagine some things are billed on a recurring basis (e.g., every 30 days), and some are every 1st of the month... 3. Assume, for example, that you charge per-user. What if there are 300 users added and 20 removed in one day. Do you refund the remaining time in the month? Is this a credit on their next invoice, a negative item on the current invoice, etc... There are many more situations that can mess this up even further.
  - doctor_eval 3y ago
    Ok. Hold my beer. What time zone is the billing performed in? And what time zone is the user in? Is the user part of a group billing scheme that is billed in a different time zone? Or do you bill everyone in the same time zone regardless of where they sign up? You need to know this in order to compute both "n" and "m". Do you need to break the billing into separate line items, for example, a service component and an entitlement component? What about addons or powerups? Are they all prorated? are you sure? What about fixed up-front charges? Surely these are not prorated? Do you charge in arrears or in advance? If you charge in advance, how many days/months in advance? If in arrears, when do you actually raise the charge? You need to know this to compute "m" and "n". How do you remember to pro-rate it? Bonus question: what's the process you use to ensure that arrears charges are always raised? Not a cron job, surely? Is your billing cycle even monthly? Could it be quarterly? Weekly? Annual? Do you need to prorate entitlements? What about quantity entitlements like download volume? What about fixed entitlements like per seat licenses? Do you prorate to the millisecond, or the day? Is there a minimum proration period? Are there any accounting rules related to proration in the accounting regime of the user being billed? If you provide a signup bonus or coupon that exceeds the value of the prorated first billing period, how do you apply it to the account? Ok. That covers the stuff I can think of off the top of my head. There are probably just as many questions that I’ve forgotten. Ultimately, the problem is not determining how to prorate, since that's a simple ratio. The problem is to work out what "m" and "n" even means, and to compute their values in a way that works within the policies of the business you're billing for. And even a simple business will change requirements over enough time. Then, of course, there’s dealing with things like refunds and cancellations. Which, in my experience, everyone gets wrong and pushes off to manual processes. And then there's the other 12 things in TFA, each of which has at least as many twists and turns. (edited to focus only on proration.)
jacurtis 3y ago
Billing systems are complex... but so are most other SaaS systems. If you take any other SaaS product, it generally seems simple, "i could build it in a weekend". But having worked at these "simple" SaaS products, there is always a long tail of edge cases that you need to deal with that get deeper and deeper into complexity. That is what these articles about billing systems usually dive into. I agree they exist, but you see this on any system or platform when you start building it for many customers/users. I say this because building your own Billing System isn't any harder than any other platform problem. The difference is that most companies aren't in the business of building a billing system. They could hire engineers to focus on it, and they could build it just fine (it's not THAT difficult). It would just cost a lot of money and all they would do is recreate something similar to Stripe, Chargebee, and the other billing platforms out there, which have already solved these problems for you. These platforms charge you a relatively low fee (lower than the cost of a team of skilled engineers and PMs) to use it, so it doesn't make sense. It's not that the problem is debilitatingly difficult. There is just not enough value in building it when off-the-shelf solutions exist. There are some businesses that might benefit from a custom billing solution because they are too unique to use an off-the-shelf solution. These companies do build their own billing systems and do just fine, but maintain a large team of developers dedicated to the billing product. Examples of this might include AWS with their billing, AT&T or Verizon with their billing, and so on. For most companies though, it would cost far more to build and maintain your own billing system, than it might generate in revenue. Especially relative to just paying a 3% finance fee and getting it "for free" with a provider like Stripe or paying a low fee for a wrapper like Chargebee (which charges only $500 for $100,000k in MRR). So if you generate $100k MRR, would you rather go through the headache of building a billing system and spend $50k a month in a small team of engineers to maintain it, or would you rather just pay $500 for essentially the same thing with no headache? THe choice seems simple to me. So it's not that Billing Systems are hard... they just don't make sense to build. Any competent engineering team could solve the problems from a billing system, it just isn't worth it.

doctor_eval 3y ago

> There are topics presented as problems that I'd hand off to accountants or other specialists we're probably already employing. But aren’t we supposed to be automating this stuff? What software do you think the accountants use? You go to the accountants to ask the questions, but if you’re billing at scale you can’t just push the problem aside. The accountants already have jobs to do and billing is not one of them. > They're less complex than whatever your developers are working on I worked on billing systems for a long time. They are definitely more complex than whatever your developers are probably working on. It’s all in the article. Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If you think this is an easy question, you don’t understand billing. > The article tries to paint hard legal requirements as a difficulty, but in practice this means the specs are easy to find and well documented. That’s the funniest thing I’ve read here in a while! The legislation is not even kept in one place. It’s often opaque. You need an accountant to explain it to you. It gets worse when you’re working with public companies. I’m sorry but your replies are the typical “billing is not that hard” of an inexperienced engineer, posted to an excellent article explaining exactly why billing is hard.

meekaaku 3y ago
> Just take proration. The user joins half way through the month and you have a monthly billing cycle. How much do they get charged? If n days of m day month is used, the charge will be n/m * monthly_rate, no? And it would be just another line item in the monthly invoice.
- arnon 3y ago
  1. You assume monthly_rate exists. It's usually not defined that way... 2. Imagine some things are billed on a recurring basis (e.g., every 30 days), and some are every 1st of the month... 3. Assume, for example, that you charge per-user. What if there are 300 users added and 20 removed in one day. Do you refund the remaining time in the month? Is this a credit on their next invoice, a negative item on the current invoice, etc... There are many more situations that can mess this up even further.
- doctor_eval 3y ago
  Ok. Hold my beer. What time zone is the billing performed in? And what time zone is the user in? Is the user part of a group billing scheme that is billed in a different time zone? Or do you bill everyone in the same time zone regardless of where they sign up? You need to know this in order to compute both "n" and "m". Do you need to break the billing into separate line items, for example, a service component and an entitlement component? What about addons or powerups? Are they all prorated? are you sure? What about fixed up-front charges? Surely these are not prorated? Do you charge in arrears or in advance? If you charge in advance, how many days/months in advance? If in arrears, when do you actually raise the charge? You need to know this to compute "m" and "n". How do you remember to pro-rate it? Bonus question: what's the process you use to ensure that arrears charges are always raised? Not a cron job, surely? Is your billing cycle even monthly? Could it be quarterly? Weekly? Annual? Do you need to prorate entitlements? What about quantity entitlements like download volume? What about fixed entitlements like per seat licenses? Do you prorate to the millisecond, or the day? Is there a minimum proration period? Are there any accounting rules related to proration in the accounting regime of the user being billed? If you provide a signup bonus or coupon that exceeds the value of the prorated first billing period, how do you apply it to the account? Ok. That covers the stuff I can think of off the top of my head. There are probably just as many questions that I’ve forgotten. Ultimately, the problem is not determining how to prorate, since that's a simple ratio. The problem is to work out what "m" and "n" even means, and to compute their values in a way that works within the policies of the business you're billing for. And even a simple business will change requirements over enough time. Then, of course, there’s dealing with things like refunds and cancellations. Which, in my experience, everyone gets wrong and pushes off to manual processes. And then there's the other 12 things in TFA, each of which has at least as many twists and turns. (edited to focus only on proration.)

jacurtis 3y ago

Billing systems are complex... but so are most other SaaS systems. If you take any other SaaS product, it generally seems simple, "i could build it in a weekend". But having worked at these "simple" SaaS products, there is always a long tail of edge cases that you need to deal with that get deeper and deeper into complexity. That is what these articles about billing systems usually dive into. I agree they exist, but you see this on any system or platform when you start building it for many customers/users. I say this because building your own Billing System isn't any harder than any other platform problem. The difference is that most companies aren't in the business of building a billing system. They could hire engineers to focus on it, and they could build it just fine (it's not THAT difficult). It would just cost a lot of money and all they would do is recreate something similar to Stripe, Chargebee, and the other billing platforms out there, which have already solved these problems for you. These platforms charge you a relatively low fee (lower than the cost of a team of skilled engineers and PMs) to use it, so it doesn't make sense. It's not that the problem is debilitatingly difficult. There is just not enough value in building it when off-the-shelf solutions exist. There are some businesses that might benefit from a custom billing solution because they are too unique to use an off-the-shelf solution. These companies do build their own billing systems and do just fine, but maintain a large team of developers dedicated to the billing product. Examples of this might include AWS with their billing, AT&T or Verizon with their billing, and so on. For most companies though, it would cost far more to build and maintain your own billing system, than it might generate in revenue. Especially relative to just paying a 3% finance fee and getting it "for free" with a provider like Stripe or paying a low fee for a wrapper like Chargebee (which charges only $500 for $100,000k in MRR). So if you generate $100k MRR, would you rather go through the headache of building a billing system and spend $50k a month in a small team of engineers to maintain it, or would you rather just pay $500 for essentially the same thing with no headache? THe choice seems simple to me. So it's not that Billing Systems are hard... they just don't make sense to build. Any competent engineering team could solve the problems from a billing system, it just isn't worth it.