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

341–350 of 372 posts

Re: Billing systems are a nightmare for engineers

#341

Post by refurb »

codegeek wrote: post #104
spchampion2 wrote: post #5

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

And then just wait until you meet Invoicing's annoying cousin Purchase Orders (PO). THere is a PO. Can I pay this in multiple invoices ? Sorry the PO is not approved yet. We cannot accept an invoice. Sorry the Invoice doesn't have reference to our PO. Can you fix that please ?

Annoying but necessary if you dig into it. If don’t we’ll you avoid paying random invoices emailed to your invoice processor!

Re: Billing systems are a nightmare for engineers

#342

Post by vonunov »

fuklief wrote: post #336
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.

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.

Gee, that's bold, I feel like "try writing in plain English" is already asking a lot of the legal profession (fortunately some of them are taking care of asking it of themselves). I wouldn't want to push it!

Re: Billing systems are a nightmare for engineers

#343

Post by vonunov »

stackbutterflow wrote: post #313
btilly wrote: post #290

Earlier quoted context omitted.

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.

In Bangalore, India, workers put on Smith face masks as they posed for selfies with the man himself. Fittingly, the tour culminated in San Diego, the home of TurboTax, the software that transformed the company’s fortunes. There, Smith arrived at his party in a DeLorean, and as he walked a red carpet, cheering employees waved “Brad is Rad” signs. To Smith’s delight, his favorite rock star, Gene Simmons of Kiss, emerge…

Is it possible to do all of that without being so embarrassed at yourself that you die, or do you have to work up to it?

Re: Billing systems are a nightmare for engineers

#344

Post by jlg23 »

AnhTho_FR wrote: post #193
jlg23 wrote: 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 ha…

Have someone from accounting/legal work at least 50% in bizdev; don't let them talk to engineering until they have sorted out what they want and, much more important, whether it is legal..

But equally important is to cut back engineering's enthusiasm for abstraction/unification": In my experience it is better to have 2 distinct, tested implementations against one pretty generic data model than trying to coerce both into one. Intellectually one can, but "oh so great billing concept" #3 or #4 will break ones neck.

I don't really think anything about billing is hard, it is just incredibly dull if done the pragmatic way.

Re: Billing systems are a nightmare for engineers

#345

Post by datavirtue »

tikiman163 wrote: post #271

I program billing systems, and even account reconciliation systems for payment processes. It's not a nightmare, it just take a greater understand of accounting. If you want to be an engineer that works on financial systems, take the first year of classes that accounts have to take and pay attention.

This. I'm astounded at the gaps in some people's inability to understand business processes because they have no accounting training. It is not that difficult but it is something that needs to be integrated into your mindset.

You might then realize that accountants have been using event sourcing to solve complex problems for hundreds of years.

Very senior developers will nearly always default to juggling updates to database records for everything. I cringe because it is often the source of serious gaps in domain language between developers and business operations people, leading to unreliable systems that are very difficult to reason about.

Immutable ledgers are your friend.

Re: Billing systems are a nightmare for engineers

#346

Post by oger »

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…

Our team was building a telco operator in the U.S. We already did that in several European markets and in Australia - so we assumed that we were mildly proficient in taxation issues. And then came the U.S. - a complete nightmare of overlapping rules that sometimes are not properly published. In essence you cannot do this on your own - you definitely need a tax service provider (like Avalara). Funny thing is though that you still are pretty safe to be noncompliant sometimes somewhere and the provider will not take on the liability if their data / computation was wrong. In short: a mind-blowing disaster. And you had to PRINT your tax forms and SNAIL-MAIL them to every jurisdiction that you were doing business in. I mean: hundreds or even more. Every. Single. Month. And don't get me started on the banking system stuck in Stone Age. I definitely would think twice to set up a business in the U.S.

Re: Billing systems are a nightmare for engineers

#347

Post by DocTomoe »

notch656a wrote: post #206
PeterisP wrote: post #119

Earlier quoted context omitted.

It's not literally impossible - the simple solution to standard invoice being unacceptable is to issue a different invoice that matches the requirements, and almost every vendor is happy to do so in order to make the sale. Also, the informal tax-evading economy relies on personal contacts and 'mutual understanding' - it's not easily accessible to a foreign vendor, and when foreign vendors do want to access that econo…

Yes literally impossible to take something in a format legal in the US, that doesn't match the foreign requirements, based on European testimony above (the exact truth of which IDK). Informal tax-evading (when the seller isn't evading, just the buyer) doesn't require personal contacts. This is just naïve thoughtless statement. It happens all the time. Example: business owner goes to Panama where they know no one. Buy…

> Buys a pallet of llama wool, seller gives a non-conforming receipt. Buyer goes back to France, imports the pallet as "cotton"

Customs catches him (distinguishing cotton from non-cotton is surprisingly easy, so is forged documents for invoicing and freight papers, especially given that Panama is an unusual country to export raw cotton - or raw wool - from), he is now in prison for 5 years for tax fraud and document forging, llama wool is confiscated and auctioned off to legitimate sellers.

Re: Billing systems are a nightmare for engineers

#348

Post by jaywalk »

hoseja wrote: post #303
jaywalk wrote: post #280

Earlier quoted context omitted.

> it's against your freedumbs You don't even know what freedom is or how fundamental an issue it is to the United States.

I don't think US has many relevant freedoms left. Some people cling very hard to legacy 18th century ones while the Moloch just gobbles up all the new ones stemming from progress.

We do in theory at least. But in practice... you're right.

Re: Billing systems are a nightmare for engineers

#349

Post by lowercased »

spookthesunset wrote: post #129
Rafsark wrote: post #117

Earlier quoted context omitted.

For simple subscription-based billing, it's somehow not this hard, you are right. It also depends on how much plans you provide to your customers, and you still need to scratch your head for upgrades and downgrades. I truly believe in usage-based billing, so I do think pricing are getting more and more complex over time. Taxes are a nightmare for everyone also (in Europe too...)

Dont forget price changes. Gotta deal with that. Then discounts, trials, weird durations, and a bunch of other shit I forget. My advice for anybody thinking of building their own subscription management system is to stop and go look at something like Zuora. You do NOT want to get stuck maintaining some home grown subscription management system--it will never be better than Zuora and you'll always be playing catchup,…

Transitioning to any non-homegrown system is not trivial either, as you'll need some process to reconcile info from current system and some external system. However powerful some external systems are, planning a migration to something non-homegrown is itself a monstrous process. Benefits of staying 'in house' can simply be you're not wasting time trying to fit your existing processes and data in to something external.

That's really great that Ford uses Zuora. But for someone trying to work with an inhouse system that doesn't map to what a system like Zuora can handle... you now have technical work and a lot of political and non-technical work, and a lot of internal coordination to get all relevant people on board to commit to a change.

Re: Billing systems are a nightmare for engineers

#350

Post by jacobr1 »

conductr wrote: post #306
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.

True. One is a more realistic reality though. And it results in this thing only being built once instead of a massive headache for all. I have to imagine government workers are already writing software to identify if we’ve all implemented it correctly, when the could have just given us the code/api up front.

> I have to imagine government workers are already writing software to identify if we’ve all implemented it correctly

Because of the jurisdiction issue, even if each local (and for each location all relevant governmental tax authorities) had a clear API, interacting with them all, and dealing with the interactions between them recursively, is itself a large problem.

And from what I've seen from smaller jurisdictions, the automation software is all about simplifying a human-in-loop workflow rather than full machine-driven rules.

Post reply on HN