Comment by doctor_eval | Hacker News Reader

Comment by doctor_eval | Hacker News Reader

Parent Full thread

> 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.

I built out billing in grocery, supply chain, oil & gas, tabs and subscriptions and without a doubt, they all have annoying complications that a person without experience would probably not consider.

I wouldn’t call billing “difficult” as much as it is “annoying”, but I also have ~18 years experience in it.

I think it’s difficult because it’s like an iceberg, there is so much more to it than what’s obvious.

I build billing systems in telco for 20+ years, so I don’t think it’s difficult any more either, but with that experience, I’d certainly do it very differently to how most people would approach it.

Yeah. Maybe what I’m calling “annoying” is what makes it “difficult”.

The features and ideas billing usually needs aren’t “difficult” to write, but if you have someone inexperienced designing the system, your project is inevitably going to run face first in to these “annoyances” and this may present as somewhere between difficult and impossible where if you had an experienced person at the helm from the get go, you won’t be running in to the same issues.

Yeah. I guess the iceburg will present as difficulty in some ways.

Yeah, I don't disagree. There are a small number of "actually difficult" problems but the vast majority are run-of-the-mill.

For example when presenting an invoice, you end up needing to be able to access just about any part of the system. In telco you need the invoice, line items, past payments, CDRs, entitlement, pre-paid, ...

Without a global data model this becomes really complicated. It's not hard (we settled on GraphQL), but it ends up being big. And it needs to be pretty fast, too.

I have worked in billing for 20 years. Each country has its own laws & quirks. Things like having to issue corrective invoices instead of refunds/adjustments in some countries. Others require document numbering to be sequential in different ways (by customer, period etc). Rounding is another fun thing - want that done at an invoice level, line level? Up or down? Taxes are not fun, especially geocoded US taxes. You've got a leased line with rented equipment at both ends - Which of these is the service address for tax purposes? Both with different rates? Something else?

I could go on.

Just when you think you've learned it all, another crazy requirement pops up.

You're correct when you say people underestimate the complexity.

Yes exactly. The thing I learned is that it all has to work independently, then you glue it together with policies. Even the simplest hard coded decision is going to be wrong in some context.

Even with such an approach, you’ll still miss something, but at least policy mechanisms provide a pattern for refactoring and new features.

I ended up building what we might call a declarative billing platform. You tell it what you want, and it tries to make it happen. Very successful, technically, but sadly I left the industry before it got into serious production.

If you're able to open source it, I'd encourage you to do so. After all, old projects might have an after life in the open.

> 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.

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.

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.)

+1 for the details, and it gets even worse when we have to bring these kinds of billing complexity into our product designs! Especially when we need to take care of budgeting... which has all of its own complexity as well.

Thanks, yes I have to say I get a bit frustrated with the frequent cycle of “ proration is not easy”, followed up by someone posting “proration is a simple division”! And then repeat for all the other complexities.

Reply on news.ycombinator.com