Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

191–200 of 372 posts

Re: Billing systems are a nightmare for engineers

#191
post #179

Implementing and maintaining billing is my daily job for the last 6 years. I would also mention topics like: - Reporting (various data aggregation and audit reports) - High reliability, nothing hurts company more than unability to bill their customers - Rounding, this can be seen as a subset of "taxes" but it's much more complex - Locating user, also can be seen as a subset of "taxes" but user can have country A set…

Wow, thanks for sharing! We found out 'billing engineers' are very rare and really demanded, as it requires to be very detail oriented, technical, and business processes oriented. But even if there is high demand (and I guess: corresponding high pay, as you mention), very few engineers are up to the challenge!

Re: Billing systems are a nightmare for engineers

#192

Earlier 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…

In the SAP R/3 family of products, there is also a component Factory Calendar (IMG -> SAP NetWeaver -> General Settings -> Maintain Calendar, transaction /SCAL) - a component that knows about all the various calendar systems incl. public holidays of the world and the dreaded leap years. If I remember correctly, it's customizable for each customer premise with respect to whether each day of the year is salaried or not.

This is a component classified as "basis technology" relied upon by many modules for billing (e.g. should a daily salaray be calculated in a country for a particular person? Should an invoice be considered "overdue" yet, based on the number of business days passed since issue? etc.).

Re: Billing systems are a nightmare for engineers

#193
post #181

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.

From your experience, who should specify the billing system? The Product team?

We're building Lago so that the right questions / decisions frameworks are asked during the implementation, so it's like a forcing power embedded in the product.

Our experience is, unless the Product/Biz team has been exposed to billing, they will never specify in a way that is precise enough, so the engineers who implement billing will have to think/assess/decide themselves.

Re: Billing systems are a nightmare for engineers

#194
post #183

Earlier quoted context omitted.

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.

By "temporal model" do you mean relational tables of "customer X used Y amount of this resource at price Z from timestamp A to timestamp B" or ... ?

Re: Billing systems are a nightmare for engineers

#195
post #179

Implementing and maintaining billing is my daily job for the last 6 years. I would also mention topics like: - Reporting (various data aggregation and audit reports) - High reliability, nothing hurts company more than unability to bill their customers - Rounding, this can be seen as a subset of "taxes" but it's much more complex - Locating user, also can be seen as a subset of "taxes" but user can have country A set…

Yep you are right, indeed. We could have mentioned Reporting/Analytics for revenue, which is always a huge pain for companies!

Re: Billing systems are a nightmare for engineers

#197

The reason billing systems are hard is because they tend to just accumulate features/behaviours/requirements. Forever. Although billing is not my specialty I have had to involve myself in it as product owner and business unit manager. Try and imagine the amount of logic, complexity, rules, and exceptions involved in a system that has accumulated perhaps 30-40 years of customer sign-ups. Umpteen contracts, umpteen ite…

Yep, totally right. Same at the previous company we worked for and built the billing logic. You start doing it in house because the first version is simple. It’s getting complicated when you keep adding paying features to a product. Often see product managers becoming experts in taxes and accounting :)

Re: Billing systems are a nightmare for engineers

#198

I've worked at two companies in their payment systems. This post does a good job of mentioning many of the billing system challenges. I think it understates how difficult and important idempotency is to maintain at scale with multiple teams though. 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…

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

It's not like SAP/Oracle/etc have some magical power. They just pay attention to these things, build the product, THEN release the product. And initial releases are buggy just like most software.

So more agile players can get involved more quickly and entrench position.

Re: Billing systems are a nightmare for engineers

#200

I work at a b2b company with a 25+ years history, and OH MY GOD... * Sales is payed (partially) off commissions, so they do their very best to sell whatever the customer wants, not what the engineers know how to bill, or that product management has prepared. It's really hard to push back against a contract with revenue 10x your yearly salary "just" because the new features to bill it don't fit together with existing…

The article just scratches the surface too. I could have written a book to describe it!

Reporting for revenue is a hard game, indeed. Spent a lot of time trying to reconcile revenue streams in the same company we ended up building the whole billing system. It’s also not easy because metering is not something that is predictable nor easy to make it fit into a finance report.

Post reply on HN