As noted, trying to fit billing into our stupid calendar system is tricky, because the calendar is stupid. Then, if you want plan upgrades/downgrades, you need to do pro-rata adjustments, and the interactions between that and tax/billing periods/etc makes the entire thing a headache.

And then you often need to add some way for the sales team to change things on an ad-hoc basis for sales/special negotiations/etc because of course big customers are going to negotiate something special, and that's all custom logic. After that, now the marketing wants referral credits, and then they want promotional periods that interact with customer loyalty, and on and on it goes.

Feature-based billing is super hard too, and people underestimate the complexity even more.

We were genuinely surprised that some companies wanted to use Lago even if they ""only"" had a "feature-based/subscription-based" pricing, that someone new would consider as "trivial".

I truly believe in usage-based billing, so I do think pricing are getting more and more complex over time.

Taxes are a nightmare for everyone also (in Europe too...)

This is a wonderful example of how engineers underestimate the complexity of billing.

> Suddenly, months, years, calendars, etc... cease to matter

No they don't. You don't send a bill every hour, or even every day. Typically you invoice monthly. And if you invoice monthly, what date do you aggregate the invoice? Setting aside the obvious problem that months are not homogenous, do you start on the anniversary date of signup, or the start of the month? Well, anniversary date is generally better, because it spreads out payments, collections and cash flow over the whole month, which reduces a lot of effort in collections and finance, and reduces the impact of any issues - but it's also significantly more difficult to engineer; how do you bill February if they started billing on the 31st of January? Monthly billing is far easier from an engineering perspective, but is not generally the ideal method from a business operations perspective. And get this, if you start with monthly billing and have significant income, and then you want to change to anniversary billing, you get all kinds of income recognition (P&L) problems that you have to deal with; it's really complex.

And what do we mean by "signup", anyway? Do we bill services individually based on when they are created, or do we bill based on the account creation date? What if there is an account hierarchy?

Hourly or unit based billing does literally nothing to solve these problems, because they are endemic to the billing domain.

> Similarly, consumption-based plans are relatively straightforward. Simply multiply unit costs with the per-unit costs.

Right - and what happens when you raise or lower your prices? That has to happen at a particular point in time, which is typically in the future. What if we give tiered discounts (first 1000 minutes at 2c, next 1000 minutes at 1c)? In both cases, we no longer can keep a single per-unit cost, but rather we end up with a cost matrix, which can become really complex when you add other factors (such as discounting).

Also, what happens when you are charging, say, 5c per megabyte... and your incoming CDR feed gives you bytes? Do you configure this as 0.00000005 cents per byte? When do you do the rounding? On an hourly basis? Daily? Monthly? What do you display as the unit price to your users? What if another plan is charging 5c per Gigabyte?

> An example of a hard-to-solve essential complexity is currency conversions and taxation when dealing with international customers. That's an externally imposed set of problems that can't be hand-waved away.

Currency stuff should be very easy in practice, but I agree that tax is hard. That's why you need a multi-stage pipeline for invoice generation. But that's perhaps a story for another post...

Billing really is complicated, but the people who set the policies don't understand that. They want to be able to say "Hey, let's give people a 10% discount if they sign up for a yearly bill, but also don't have this service over here, and for governments and students let's cut that down by another 15%" and so on, basically "billing by English spec", and because they think this is trivial and easy it gets handed as a spec written in stone to the billing team. Even in engineering-type organizations, treating this as an engineering problem is often a foreign concept to the org, so the idea of having the eng team estimate effort and then go back to the original requestor and make sure they really want it 1000 engineer-hour's worth, and that the rest of the org is willing to dedicate that much time to it, is generally not done. (Or whether or not there's an alternative thing that could be done at 1/10th the price that achieves the original goals, e.g. "we don't have annual discounts built into the system but we have this other fairly-close concept already built in, can we just slightly tweak the ask to use that, rather than having to implement a whole new complicated concept?") Even a company that has learned the hard way that "Let's just change the button to blue and move it down an inch" is more complicated than it looks thinks that management can just write whatever billing policy they want and there are no costs associated with it.

On a more pure-engineering front, engineers have the tendency to want to implement billing discounts and such by lying to the usage database. "Ah, we will implement this 10% off policy by telling our record-keeping system that they used 10% less stuff." I've banged on how important it is to never lie to your database a few times, and the billing database is what really brought this home to me. This way lies madness, as you start to stack lies on lies on other lies in the database and then counter the lies with other heuristics and then counter the heuristics with other lies and before you know it your database contains no truth anymore, which is a problem because neither does anything else. The database was supposed to be the source of truth.