Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

Post reply on HN
Print view View original

241–250 of 372 posts

Re: Billing systems are a nightmare for engineers

#241

Post by kdeldycke »

0xbadcafebee wrote: post #101

Don't spend time, effort and money on things that do not bring business value. Any time I see a company with engineers building something they could buy off the shelf [and the thing they're building is not the product] I know their priorities are whack. I've worked for several companies that had more money than brains. They'd spend years , and millions of dollars in salaries, to build shit they could have bought and…

The essence of MVP I guess.

Now, back to the article's topic, the real question is: is there an off-the-shelf billing product available out there?

Re: Billing systems are a nightmare for engineers

#243

Post by D-Coder »

deltarholamda wrote: post #50
bombcar wrote: post #15

Earlier quoted context omitted.

And even worse - your biggest customers won't even smell your invoice unless you enter it line by line into some ancient SAP system developed 20 years ago, where everything cloud related is classified as telephony except storage space which must be classified as filing cabinets (movable) or your invoice will be (very slowly) rejected. And if it is rejected you have to enter it all again by hand; editing isn't a featu…

I said, over and over again, that moving away from goats and salt as currency was a mistake, but nobody listened to me.

But the different conversion rates for each kingdom/duchy/province/parish were a nightmare even then.

Re: Billing systems are a nightmare for engineers

#244

Post by kdeldycke »

epberry wrote: post #118

Usage based billing is not only hard to implement but hard to consume. No one really knows what they are spending and how much particular customers or products cost. I did a writeup a week ago on CDNs and ended up spending several hours in spreadsheets. I had felt this pain vaguely before but actually seeing it everyday at my current job makes me realize there are engineers suffering on both sides of software billing…

This.

Usage-based billing is incomplete without its suite of reporting, consolidation and visualization tools. No wonders there is a cottage industry of cloud computing consultants and SaaS solutions focused on helping you to make sense of your AWS/GCP/Azure invoices.

Re: Billing systems are a nightmare for engineers

#245

Post by asciimike »

AnhTho_FR wrote: post #202
asciimike wrote: post #130

Nit: there's a lot of noise being made in comments about it being an open source product, but I haven't found the source (maybe I have to speak to an expert to get it?). github.com/getlago has the docs, which is nice (and gives a lot more info than is available on the website about how the product works), but not quite the same. Also note: > Our open-core version is forever free. We will introduce paying add-ons in t…

It's coming soon, we're in the final steps of QA, but we could not wait to share this post! Thanks for the comments on the documentation, by the way!

Awesome, glad to hear, would love to take a look whenever it's available! Looking at the docs it seems like the current state of the product is much more about subscriptions than usage based billing (e.g. no aggregation or rating). Any plans to add those in?

Re: Billing systems are a nightmare for engineers

#246

Post by kdeldycke »

hammock wrote: post #163

Double-entry accounting is tough for a lot of people. It's a different domain and trying to fit it into traditional "math" will only cause headaches.

Still, someone tried in the "Algebraic Models for Accounting Systems" book: https://www.amazon.com/Algebraic-Accounting-Systems-Salvador...

Source: https://github.com/kdeldycke/awesome-billing#finance

Re: Billing systems are a nightmare for engineers

#248

Post by indymike »

radicalbyte wrote: post #70
trollied wrote: post #11

Earlier quoted context omitted.

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.

A credit note. How the ** do you handle it in the US without issuing credit notes in your bookkeeping?

We issue a credit note*

* Except (these aren't the right thing to do, but I've seen it in the wild many times):

- When someone in sales issues an invoice with a negative amount on line 3. Hey, if I take payments with invoices, why not give back?

- When someone agrees to settle up by providing free services and throws it on the next bill.

Re: Billing systems are a nightmare for engineers

#249

Post by mirchiseth »

AnhTho_FR wrote: post #42
tablespoon wrote: post #33

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…

SAP and Oracle are always easy targets. Not sure about Oracle but SAP has a relatively newer (10 yr old) subscription and usage billing product - https://www.sap.com/products/subscription-billing.html
Post reply on HN