I've implemented a few billing systems and "the nightmares" were never related toengineering but always to specification: If bizdev does not know what they want, no outsourced imlementation will be able to help them.
Billing systems are a nightmare for engineers
181–190 of 372 posts
Re: Billing systems are a nightmare for engineers
#182Earlier quoted context omitted.
> Additionally, it didn't mention financial regulation changes. India had changes sometime in the last few years which required whole new systems built that were specific to India customers. One example of complexity is this: does the system apply to customers who are in India or does it apply to businesses who are in India (the owners might not be)? IIRC, I've read this is one of the reasons that systems like SAP ar…
Hey @tablespoon, I'm one of the cofounders of Lago here. Products like SAP do seem complex because of (i) the complexity of the billing problem and all the edge cases, (ii) they were not built with an API-first or engineer-first mindset We're only at the beginning of the journey, but that's one of the reasons why we thought of open-sourcing our billing API, so that the work could be forked and tweaked to address edge…
I am the last one to defend SAP, but they do have an API first approach since some time, check this out: https://api.sap.com/products/SAPS4HANACloud/apis/all Also edge cases are taken care of, sometimes before you even small updates, via notes, mostly tax regulation changes. So yeah, for these things SAP is really made for. If you have a SAP account, you can check out, just to see how many changes are coming in: https://launchpad.support.sap.com/#/solutions/notesv2/?q=pol...
Re: Billing systems are a nightmare for engineers
#183I was working on a billing system for utility company and it was a nightmare but not for the reasons from the article. Dates are no problem, everything is billed at the end of month, quarter or year. Upgrades are downgrades are simplified, customer can legally change tariff only on predefined dates/events. Usage - yes, but exampled in the article do not even scratch the complexity of this Idempotency is not really ne…
Did the company use a relational database to deal with the billing and subsequent adjustments? I've been there: it can be more straightforward to use an event streaming approach that recalculates billing as new events arrive.
Yes, almost everything ended as temporal or bitemporal model. Pain to work with. Even for simple questions like "What is the customer #1234 company name?" the system needs to know when are you asking.
Re: Billing systems are a nightmare for engineers
#184If you try to keep it simple, it's not that hard.
Re: Billing systems are a nightmare for engineers
#185Earlier quoted context omitted.
They're trivial... when you make the same change to add something, remove it, add it, remove it and hear that it's all being done "because X" and "X" never stops, it's clearly not working and the changes are trivial.
No, the changes aren't trivial. It sounds like you simply don't understand why they're doing it and you just assume that they're trivial because you have no knowledge of the domain. Off the top of my head, I can thing of a dozen reasons for why they'd require something to be added, then removed, then added, etc., from one invoice to the next.
> It sounds like you simply don't understand why they're doing it
I don’t know why you would think that considering I work with them and you do not…
Re: Billing systems are a nightmare for engineers
#186Just wait until you meet billing's angry roommate: invoicing. In the US, an invoice is just a weird PDF that you might glance at before sending off to your accounts payable team. But in other countries, especially those that use VAT style taxing systems, an invoice can be a legal document that expresses costs and taxes in a legally prescribed way for accounting purposes. Many countries have prescriptive rules over ho…
Yup, it's a nightmare. Invoices needing to be in specific number sequences. Any corrections need to be dealt with by reissuing a special "corrective invoice". Don't even get me started on geocoding for taxes. Urgh. Also, when you've got the invoicing right, you've got to work out how to do the feeds to the accounting systems so that it all posts to the right place.
I’ll add that the accounting side can get complicated really quickly. You end up with lots of different scenarios. Earned but unbilled: out of bundle call charges, for example. Billed but unearned: a paid in advance monthly fee, for example - this may need to be recognised as a percentage per day. Etc etc. So much to take into account when feeding to ledgers.
Re: Billing systems are a nightmare for engineers
#187billing is a chronological typesystem and is only hard to build because most languages don't offer time-safe types
(and because municipalities don't expose their tax rules as types)
Re: Billing systems are a nightmare for engineers
#188I was working on a billing system for utility company and it was a nightmare but not for the reasons from the article. Dates are no problem, everything is billed at the end of month, quarter or year. Upgrades are downgrades are simplified, customer can legally change tariff only on predefined dates/events. Usage - yes, but exampled in the article do not even scratch the complexity of this Idempotency is not really ne…
Thanks janci for sharing your experience!
Indeed, we only scratched the surface of the complexity of metered billing, we'll do a deep dive soon on this topic (it does deserve its own post).
I think for the'nightmares' you mention: - some might be specific to utility (not applicable to an online business), such as '- meter readings are available on dates totally independent from billing cycle'. - Some topics might be simpler for a utility co: tax for instance (you know where your users are, and they are limited to a geographic region)
- But some nightmares 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 too, indeed
Thanks for sharing, great insights for our future post!
Re: Billing systems are a nightmare for engineers
#189Earlier quoted context omitted.
No, the changes aren't trivial. It sounds like you simply don't understand why they're doing it and you just assume that they're trivial because you have no knowledge of the domain. Off the top of my head, I can thing of a dozen reasons for why they'd require something to be added, then removed, then added, etc., from one invoice to the next.
> It sounds like you simply don't understand why they're doing it I don’t know why you would think that considering I work with them and you do not…
I work with the A/R and A/P teams all the time. It's a large part of doing tax in-house.
Re: Billing systems are a nightmare for engineers
#190I was working on a billing system for utility company and it was a nightmare but not for the reasons from the article. Dates are no problem, everything is billed at the end of month, quarter or year. Upgrades are downgrades are simplified, customer can legally change tariff only on predefined dates/events. Usage - yes, but exampled in the article do not even scratch the complexity of this Idempotency is not really ne…
Did the company use a relational database to deal with the billing and subsequent adjustments? I've been there: it can be more straightforward to use an event streaming approach that recalculates billing as new events arrive.
Designed and build the system meter readings and calculations for the Dutch market, all mysql, worked like a dream.