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

331–340 of 372 posts

Re: Billing systems are a nightmare for engineers

#331

Post by AnhTho_FR »

asciimike wrote: post #245
AnhTho_FR wrote: post #202

Earlier quoted context omitted.

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?

We have an event-based architecture and offer 'aggregations' at the moment: https://doc.getlago.com/docs/guide/billable-metrics/aggregat... We plan to add more aggregation types, gauge metering as well!

We definitely want to address usage-based pricings, but also all the pricings that are hybrid between usage and subscriptions (ie the vast majority of software pricings). Feel free to reach out if you have more question: anhtho@getlago.com

Re: Billing systems are a nightmare for engineers

#332

Post by AnhTho_FR »

Rafsark wrote: post #210
walnutclosefarm wrote: post #40

Always has been. Marketing and sales create complexity on the front end, devising all kinds of products, plans, discount schemes and related complexity; jurisdiction, taxes, and accounting rules add complexity on the backend. In the middle, measuring what you're billing for is the hook around which all that complexity chaotically orbits. Decades ago - the computer involved was an honest to goodness System 360 (which…

The marketing team of my previous company created a whole fake price plan that never existed in the code base. Somehow it works to drag acquisition, but it’s a pain in the ** to explain why it’s not as easy as updating webflow ;)

Was I really such a pain? :)

Re: Billing systems are a nightmare for engineers

#333

Post by AnhTho_FR »

biermic wrote: post #326
Rafsark wrote: post #217

Earlier quoted context omitted.

Agreed! But I do prefer to build it for me rather than someone else’s startup, though

Curious, what are you working on?

Raffi and I are building www.getlago.com : the open-source Stripe Billing alternative

Re: Billing systems are a nightmare for engineers

#334

Post by thibo_skabgia »

chasd00 wrote: post #74

I spent a lot of time right out of college working on the equivalent of an invoicing system for a pharmacy chain (rx drug pricing, electronic carrier submission, and reconciliation). Account receivables is also another nightmare. We would get checks that randomly show up at corporate for no reason from insurance carriers but then when the carrier realized their error instead of handling it as a separate process they…

Hey, I feel your pain. The "hope-for-the-best process" definitely is something happening in many companies... Yet, it's not a fatality anymore. I work with Upflow (YC 20) and it is exactly what we offer to our clients : 1. Making sure they have clear visibility on their AR 2. designing systematized workflows for their customers (as many as needed) 3. Customer payment portals to help their customers pay on time, with no friction. That's here at www.upflow.io

Re: Billing systems are a nightmare for engineers

#335

Post by giomasce »

kinj28 wrote: post #263
giomasce wrote: post #116

Earlier quoted context omitted.

In Italy too. They specifically developed an XML format for that, and each time you issue an invoice you have to (well, with some exceptions, but they are gradually removing all of them) send a copy to the revenue agency, which will forward it to the recipient (and keep a copy). While it is a bit inconvenient, though, I don't think it is a bad idea. I am pretty sure it helps a lot making the life harder for people ev…

They should rather give a service to issue /cancel an invoice and people will happily use the service

Not sure it is a good idea. It might be more flexible when you issue an invoice and have to modify it, but first it would enable fraud, and second it would mean that you have to monitor incoming invoices to see if anything changed and account for that. I think it's better to ask people to just emit correct invoices: if you need to invoice a bit more you issue another one, if you need to invoice less you issue a credit note. If you can't do that you need to work on your business processes.

Re: Billing systems are a nightmare for engineers

#336

Post by fuklief »

loloquwowndueo wrote: post #279
systemvoltage wrote: post #277

Earlier quoted context omitted.

We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.

“We” the engineers (working for the government) still have to develop those APIs and the backends that power them. The only way to reduce the pain instead of just shifting it around would be to massively simplify the source of truth - tax codes and laws.

You might be interested in [Catala](https://catala-lang.org/en/), a domain specific language for implementing legislative texts. Iirc, they have worked on the french tax code, and are starting on the us one now.

Re: Billing systems are a nightmare for engineers

#337

Post by coffeeblack »

throwaway6532 wrote: post #287
loloquwowndueo wrote: post #279

Earlier quoted context omitted.

“We” the engineers (working for the government) still have to develop those APIs and the backends that power them. The only way to reduce the pain instead of just shifting it around would be to massively simplify the source of truth - tax codes and laws.

The US tax system is the legislative equivalent of spaghetti code / big ball of mud.

Every tax system is. Because the experts who help to develop it are the same people who get paid to help you file your taxes. Making it easier would lose them income.

Re: Billing systems are a nightmare for engineers

#338

Post by [deleted] »

btilly wrote: post #259

Wait until you get into the complexities of taxation. If you think you know them, pay attention to https://twitter.com/aotearoa_ben/status/1526786701750050817 . That's a law that changes the tax rate if 1. The purchase happens in Texas. 2. The payment cleared in a specific 2 day period. 3. The item cost Seriously, calling out just one example, https://comptroller.texas.gov/taxes/publications/98-490/scho... points out…

[deleted]

Re: Billing systems are a nightmare for engineers

#339

Post by rocqua »

loloquwowndueo wrote: post #279
systemvoltage wrote: post #277

Earlier quoted context omitted.

We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.

“We” the engineers (working for the government) still have to develop those APIs and the backends that power them. The only way to reduce the pain instead of just shifting it around would be to massively simplify the source of truth - tax codes and laws.

True, but if the lawmakers writing the tax code bear more of the pain of the complexity of the tax-code (i.e. get complaints and warnings of their own devs that have to implement that API) then they might write better tax codes.

Re: Billing systems are a nightmare for engineers

#340

Post by rocqua »

GrumpyNl wrote: post #190
politician wrote: post #173

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.

Designed and build the system meter readings and calculations for the Dutch market, all mysql, worked like a dream.

I have heard some horror stories about the dutch smart meters.

Apparently the billing system provided for 7 'counters' and hence the smart-meter had to have exactly 7 counters.

Post reply on HN