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

291–300 of 372 posts

Re: Billing systems are a nightmare for engineers

#291

Post by systemvoltage »

btilly wrote: post #290
systemvoltage wrote: post #285

Earlier quoted context omitted.

You're being facetious but I don't think this is a radical idea. Government already publishes the tax code in English language. This is just formalization of the tax code in computer code: More precise, testable and provable.

What makes you think that this is being facetious? https://www.propublica.org/article/inside-turbotax-20-year-f... has a good overview of how companies that provide software for calculating taxes guarantee a market for their products by keeping the process of calculating taxes more complicated than it needs to be.

Damn. I'm with you, this needs to be corrected.

Re: Billing systems are a nightmare for engineers

#292

Post by mangoTangoBango »

bfdm wrote: post #283
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.

Yes, I think that's the point.

That is the point of the tax code, to be able to use it for political wielding of power e.g. the Chicken tax because LBJ was pissed at Europe that caused a 25% tariff on light trucks imported to the U.S. based on a retaliation for European tariffs on American chicken..

Re: Billing systems are a nightmare for engineers

#293

Post by dboreham »

AnhTho_FR wrote: post #136
dboreham wrote: post #108

Note OP makes a billing product (OSS, granted) so is motivated to characterize the field as complex and hard. In reality billing is just like many other processes humans engage in. For sure it's more complex than computing prime numbers, but hey try writing software to capture medical services processes :) In the end this is exactly what engineers are supposed to do: figure out ways to model/capture/represent complex…

Hi dboreham, I'm one of the co-founders of Lago here (the OP). I completely agree with you, billing is not the most complex process of all, medical services may be of higher complexity. Our post was meant to highlight the discrepancy between the perceived low complexity (lots of teams who have never done it think it's simple) and the reality, with our own experience building a fintech. I think for some processes (med…

Ok, perhaps the article title should be "Many complex fields are challenging for inexperienced engineers, who often don't realize that at the outset"?

Re: Billing systems are a nightmare for engineers

#294

Post by jwr »

B2B SaaS founder here, several years in: this article is right on point. Additionally, using Stripe Billing is not all it's cracked up to be, as it actually doesn't solve all my problems, while taking a chunk of revenue.

I've been building parts of a billing system myself over the years and I'm considering removing the remaining external parts, because I'm not happy with their limitations (Braintree's subscriptions are really limited, and absolutely nobody does correct invoicing for my situation (EU/Poland)).

Also, in a B2B SaaS you will end up with customers on totally different payment methods. Not every business has or wants to use a credit card. So you get annual billing with proforma invoices and the complexities involved with switching from invoiced billing to credit card billing and vice versa.

Re: Billing systems are a nightmare for engineers

#295

Post by mangoTangoBango »

formerkrogemp wrote: post #231
AnhTho_FR wrote: post #188

Earlier quoted context omitted.

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…

For online businesses as well, selling above a certain amount of revenue or product can trigger what's known as a nexus event in taxation wherein the business becomes liable for collecting sales or use tax. Now online businesses are on the hook for collecting sales tax in every jurisdiction above wildly varying threshold values. Should the business fail to collect the sales tax for selling from Montana to California…

Is there an easy way to deal with this e.g. compliance as a service?

Sounds like a nightmare to deal with, of course this is only assuming it is enforced. If it is not well who cares, companies like Lyft/Uber view laws as a starting point in negotiations when expanding into new areas not as a brick wall of dogma.

Re: Billing systems are a nightmare for engineers

#296

Post by ArdelleF »

A relational database scalable for the billing data volume, should be a best answer, in term of realtime process and analysis，say complex query. Suggest an article of a big logistics company case here, not only billing, but also order, messaging, transshipment: https://en.pingcap.com/blog/how-to-reduce-cost-per-order-wit...

Re: Billing systems are a nightmare for engineers

#297

Post by janci »

jimsparkman wrote: post #269
gnat wrote: post #194

Earlier quoted context omitted.

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 ... ?

I assume they are using something like DB2, which has very specific meaning when it comes to temporal or bitemporal tables. https://www.ibm.com/docs/en/db2/10.5?topic=tables-bitemporal

Not DB2, but the meaning is the same.

In a time-series (or event) table you have one date - when the data point is valid (event occurred).

In a temporal table you have two dates - interval when the data is valid.

In a bitemporal table you have two intervals. First describes when the data is valid in real world, the second when does the system know about the real-world state.

I.e. if company changed address on 2022-05-01 but the system will not get that information until three day later (2022-05-03) you have two validity intervals.

Then you may ask - what was the company address on 2022-05-02? And what did the system think the address was on 2022-05-02? You will get two different answers. This is important if you need e.g. to make a correction to previously issued invoice. You need to know what data was used for original invoice and what data should have been used.

Re: Billing systems are a nightmare for engineers

#298

Post by formerkrogemp »

mangoTangoBango wrote: post #295
formerkrogemp wrote: post #231

Earlier quoted context omitted.

For online businesses as well, selling above a certain amount of revenue or product can trigger what's known as a nexus event in taxation wherein the business becomes liable for collecting sales or use tax. Now online businesses are on the hook for collecting sales tax in every jurisdiction above wildly varying threshold values. Should the business fail to collect the sales tax for selling from Montana to California…

Is there an easy way to deal with this e.g. compliance as a service? Sounds like a nightmare to deal with, of course this is only assuming it is enforced. If it is not well who cares, companies like Lyft/Uber view laws as a starting point in negotiations when expanding into new areas not as a brick wall of dogma.

> Is there an easy way to deal with this e.g. compliance as a service?

I think we call ourselves CPAs :). In all seriousness the 'solution' depends on what industry we're talking about. Short term rentals? Avalara. Software as a service? Various accounting firms and startups. Etc.

Re: Billing systems are a nightmare for engineers

#299

Post by anfilt »

formerkrogemp wrote: post #231
AnhTho_FR wrote: post #188

Earlier quoted context omitted.

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…

For online businesses as well, selling above a certain amount of revenue or product can trigger what's known as a nexus event in taxation wherein the business becomes liable for collecting sales or use tax. Now online businesses are on the hook for collecting sales tax in every jurisdiction above wildly varying threshold values. Should the business fail to collect the sales tax for selling from Montana to California…

Montana does not have a sales tax.

Re: Billing systems are a nightmare for engineers

#300

Post by ProAm »

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…

Wait until you deal with Brazil. Billings systems are not hard they take engineers that are thoughtful and long-term thinkers which is not conducive to today's software developer hires. Which is why posts like this are made, Its a market ripe for dominance.
Post reply on HN