4 ms·

(I'm a billing engineering team leader with more than 25 years experience.) This is a wonderful example of how engineers underestimate the complexity of billin

(I'm a billing engineering team leader with more than 25 years experience.) 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...

tourist2d 4y ago
Those are all problems which have been "solved" by many companies. I'm sorry but none of this screams complex to me, all your problems have 2-3 "correct" choices, or you could just copy what almost all big companies do.
- doctor_eval 4y ago
  The whole point of TFA is that billing systems are way more complex than they appear to be. If you're trying to build a billing system, how do you "copy" what these big companies do, when most of the effort is neither obvious nor visible?
  - AnhTho_FR 4y ago
    OP here, that's exactly the point. It's easy in theory: 'just do it', 'just copy', BUT the challenges are in - the tiny details (that can have a huge impact: we're talking 'billing' and 'money' here) - the maintenance: it's a living organism: you will inevitably change your pricing, your payment processor, the way you bill, your back-end/front-end etc
  - randomdata 4y ago
    > The whole point of TFA is that billing systems are way more complex than they appear to be. Technically the point of TFA is to market billing software. Billing systems are complex in that they can consist of many different moving parts, but billing system are also simple in that they are easily understood. Billing has to be easily understood, else you'll quickly scare your customers away. Complexity and simplicity are not necessarily at odds with each other. The meat of TFA is mostly about how billing systems can quickly become a time consuming endeavour which again isn't at odds with simplicity.
    - doctor_eval 4y ago
      > Billing has to be easily understood I disagree. Billing has to be correct - that’s billing rule #1. You can have an easily understood pricing plan, but implementing that plan correctly and consistently in a way that you can defend and audit can be very complicated. Just take the simple example of implementing anniversary billing for a customer who signs up on the 30th of the month. What date do you bill them when the month has less than 30 days? What about when it has more than 30 days? What about when your customers are spread through 4 time zones? What about when daylight savings starts and ends? Do most engineers understand time and time zones well enough to get this right? These questions are fundamental to correct billing at any kind of scale, and the answers are not simple, or at least I don’t think they are.

tourist2d 4y ago

Those are all problems which have been "solved" by many companies. I'm sorry but none of this screams complex to me, all your problems have 2-3 "correct" choices, or you could just copy what almost all big companies do.

doctor_eval 4y ago
The whole point of TFA is that billing systems are way more complex than they appear to be. If you're trying to build a billing system, how do you "copy" what these big companies do, when most of the effort is neither obvious nor visible?
- AnhTho_FR 4y ago
  OP here, that's exactly the point. It's easy in theory: 'just do it', 'just copy', BUT the challenges are in - the tiny details (that can have a huge impact: we're talking 'billing' and 'money' here) - the maintenance: it's a living organism: you will inevitably change your pricing, your payment processor, the way you bill, your back-end/front-end etc
- randomdata 4y ago
  > The whole point of TFA is that billing systems are way more complex than they appear to be. Technically the point of TFA is to market billing software. Billing systems are complex in that they can consist of many different moving parts, but billing system are also simple in that they are easily understood. Billing has to be easily understood, else you'll quickly scare your customers away. Complexity and simplicity are not necessarily at odds with each other. The meat of TFA is mostly about how billing systems can quickly become a time consuming endeavour which again isn't at odds with simplicity.
  - doctor_eval 4y ago
    > Billing has to be easily understood I disagree. Billing has to be correct - that’s billing rule #1. You can have an easily understood pricing plan, but implementing that plan correctly and consistently in a way that you can defend and audit can be very complicated. Just take the simple example of implementing anniversary billing for a customer who signs up on the 30th of the month. What date do you bill them when the month has less than 30 days? What about when it has more than 30 days? What about when your customers are spread through 4 time zones? What about when daylight savings starts and ends? Do most engineers understand time and time zones well enough to get this right? These questions are fundamental to correct billing at any kind of scale, and the answers are not simple, or at least I don’t think they are.