Online businesses should consider engineering implications of complicated billing models when developing products

When I worked for a utility company, I was responsible for the billing system, and it was a living nightmare—but not for the reasons given in the article.
There is no need to be concerned about dates because everything is billed at the end of each month, quarter, or year.

Customers are only allowed to legally change their tariff on predetermined dates or events, which has simplified both upgrading and downgrading.

Utilization, yes; however, the examples given in the article do not even begin to scratch the surface of the complexity of this.

Because the billing process is not continuous but rather performed in batches, idempotency is not really necessary.

The gathering of money is outside the purview of billing software.

The tax burden was obvious. There were multiple billable items, each with a unique tax rate, but the process was not overly complicated. Every single one of our customers was local.

The most terrifying aspect was when:

• Customers have the ability to have multiple consumption locations, each location can have multiple meters, and customers have the option to request that their bill be broken up onto multiple invoices or consolidated into a single invoice, depending on their preferences.
• Meters may be changed out at any point in time.
• Readings from the meter can be retrieved on dates that are completely unrelated to the billing cycle. The vast majority of the data on consumption are merely projections.
• Everything needs to be recalculated and compensated once the actual consumption data is made available (on a correction invoice showing the difference).
• The data on actual consumption may be inaccurate and may be updated at a later date, possibly even more than once.
• Consumption points can be added, removed, or moved to a different customer at any time; however, this information is not accessible until after the event has already taken place.
• For some customers, the prices may change in the middle of the billing cycle; however, the consumption data is not available with that level of granularity.
• The legally required information of the customer (such as the company name and address) may change in the middle of the cycle.

Indeed, we have only skimmed the surface of the complexity that is metered billing; however, we will be conducting a more in-depth discussion on this subject very soon (it does deserve its own post).

I think for the 'nightmares' you mention:

• Some might be specific to utility companies (not applicable to an online business), such as "meter readings are available on dates totally independent from the billing cycle".
• Some subjects could be easier for a utility company, such as taxes, for example (you know where your users are, and they are limited to a geographic region).

However, certain nightmare scenarios, such as "the prices can change mid-billing cycle for some customers, but the consumption data is not available with that granularity," do really resonate for online businesses as well.

A Story from Experience

Once upon a time, I was the first product person hired at a company that is now a decacorn, and the first thing I had to do was fix the billing system. It was quite the beast, and in the end, we decided to implement a combination of Zuora and an internal system because there were some aspects of the billing model that Zuora was unable to manage on its own.

The most important takeaway for me is that whenever you are contemplating a complicated billing model, you should first think about the engineering implications of doing so. When developing most products, engineering considers customer feedback. Quite frequently, product will propose something, engineering will break it down, and then product will realize that feature X is significantly more complicated than they thought and is not worth the effort. As a result, the product's requirements will be changed to simplify or remove it.

The one thing that never seems to be accurate is the pricing models; this decision is made at the very top and then handed down with no opportunity for feedback from lower-level employees. If the people responsible for designing the billing system were aware of the costs, I believe they would find ways to simplify the process. If the complexity of your billing system means that three percent of your engineering team (plus additional people in support and finance) is going to be working on it forever, but if you simplified it a bit you could keep ninety percent of it and only have one percent of engineering working on it, that might be a good tradeoff—after all, that leaves you more engineers to build features, which should drive additional sales. Unfortunately, this analysis never seems to get done up front, and the cost is only understood after the billing system has been deeply integrated into everything, at which point changing it would require an insurmountable amount of effort.