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

101–110 of 372 posts

Re: Billing systems are a nightmare for engineers

#101

Post by 0xbadcafebee »

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 implemented in two months. And not only that, but multiple iterations of failing to build said thing, by multiple teams.

Just because a tractor is used for farming doesn't mean a farmer should build her own tractor.

Re: Billing systems are a nightmare for engineers

#102

Post by duxup »

gamblor956 wrote: post #97
duxup wrote: post #69

Earlier quoted context omitted.

Not even legal issues. In my experience invoicing, and really all 'printable' documents is the land of "oh someone did something wrong put X on the document". And then again and again and again... And "this is two pages long that's too much" and on and on ... It's bike shedding insanity with no ideal or end in sight. Every change is arbitrary with no real measure of success. I swear the only time anyone LOOKs at thes…

Just because you don't understand invoicing doesn't mean that the concerns that appear trivial to you are actually trivial. From the perspective of someone who works with the people who process the invoices, putting "X on the document" and "two pages long" can be a huge deal when you have to deal with hundreds of invoices or when "X" can mean that an invoice must proceed down a different processing path. These aren't…

They're trivial... when you make the same change to add something, remove it, add it, remove it and hear that it's all being done "because X" and "X" never stops, it's clearly not working and the changes are trivial.

Re: Billing systems are a nightmare for engineers

#103

Post by gamblor956 »

notch656a wrote: post #83
DocTomoe wrote: post #65

Earlier quoted context omitted.

That american exceptionalism approach will work with private citizen customers. With business customers, leaning back in the legal framework encouraging tax fraud will not fly. They just won't buy from you then. That's why any US company wanting to do business in Europe either has an European subsidiary, or follows something that's compatible with EU invoicing schemes.

>. With business customers, leaning back in the legal framework encouraging tax fraud will not fly. Yes which is why in nations like Portugal, where any business invoice may be subject to accountability to government, there totally isn't a massive informal (read: tax-evading) economy to deal with the fact that the government makes it literally impossible (at least in above words) to accept an invoice legal in the jur…

You keep bringing this up and it's simply not true. The EU has a single set of VAT invoice requirements that applies across the EU (the MOSS invoicing standard). Any VAT invoice that satisfies these rules is legal in all EU countries (https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32..., article 226).

My company does plenty of business with EU businesses and we use a single standard EU VAT invoice without issue.

Re: Billing systems are a nightmare for engineers

#104

Post by codegeek »

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 ?

Re: Billing systems are a nightmare for engineers

#105

Post by bckr »

AnhTho_FR wrote: post #82
onion2k wrote: post #57

Earlier quoted context omitted.

Hi, customer here. We'd like to change our billing period to start on the 31st of every month, and we'd like to pay 90 days in arrears, and we'd also like you to invoice us ahead of the billing month. Oh, and we're big enough that losing our business will end your startup, so don't get it wrong. Thanks!

I'm Anh-Tho, one of Lago's co-founders here. Thanks for sharing! What did you do then? I'm curious!

Hey, Anh-Tho, just as a point of feedback, since you're leaving a lot of comments in this thread, it's not necessary to introduce yourself in each one. Most folks will be scanning the whole thread and seeing your introduction gets repetitive and breaks the conversational tone and makes it overly commercial. Thanks.

Re: Billing systems are a nightmare for engineers

#106

Post by AnhTho_FR »

Brystephor wrote: post #87
AnhTho_FR wrote: post #36

Earlier quoted context omitted.

Hey @Brystefor, I'm @Rafsark's co-founder. We could have spent more time on idempotency, indeed. We have not deep dived into the 3 other aspects you mentioned indeed, we're actually planning to 1/ open-source the articles and add additional challenges as they are mentioned 2/ open our roadmap based on these inputs as well Thanks for sharing! Will ping you back here when it's live PS: we had not thought of financial r…

Oh, I didn't even realize this was a blog for an open source project. I assumed it was someones personal blog. Two other things that you may want to consider: 1. PCI compliance. If you're involved in the storage of payment information, you may want to look into these regulations. 2. Regarding point 3 of your mission "...only integrating with specific partners to lock you in (e.g., Stripe Billing only working with Str…

Hi @Brystephor! I'm Anh-Tho, one of the cofounders of Lago.

We're building an open-source alternative to Stripe Billing indeed, but we want to share our personal experience, hence the personal blog post.

We'll open our repo very soon and our public roadmap too. Thanks for adding the 2 points, we're working on 'a design framework for how a single company could integrate with multiple providers could be beneficial.' indeed!

Will ping you back here when we're live!

Re: Billing systems are a nightmare for engineers

#107

Post by AnhTho_FR »

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 ?

Hey @codegeek! I'm Anh-Tho, one of the co-founders of Lago.

We're working on making the 'CPQ' : Configure Price Quote journey simpler, and this includes the PO dead end. We're on a mission to make the pricing stack more open and customizable for companies (hence the open-source angle), and we're starting with the billing system. Join the journey, we'll share our repo soon, and hopefully we can address these painpoints faster with the community contributions too!

Re: Billing systems are a nightmare for engineers

#108

Post by dboreham »

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 processes and data.

Re: Billing systems are a nightmare for engineers

#109

Post by AnhTho_FR »

notch656a wrote: post #100
AnhTho_FR wrote: post #90

Earlier quoted context omitted.

I'm Anh-Tho, one of a co-founders of Lago. I'm French, and I confirm, in B2B, no invoice (that is compliant, not a mere receipt) -> no payment.

Thank you Anh-Tho for your response. What is the mechanism for French government to subpoena a non-EU business to find this invoice? If the customer (instead of vendor) produced an invoice that matched their bank statements and non-conforming receipt, hypothetically, would anyone really know the difference?

Hey notch656a! I'm not a government expert, but the challenges would start with:

- I am Frenchy (a French co) - Buying software from Ricky (a US co)

If I don't have a proper invoice from Ricky to give to my accountant at the end of the year, and I get a tax control, then, I'll be fined.

If the tax ministry notices large amounts of similar fines, they might look at Ricky.

So the risk is more on Frenchy (risk to be fined). But I'd say that Ricky is safe for a while, unless the invoiced amount are really huge.

Re: Billing systems are a nightmare for engineers

#110

Post by welder »

I implemented billing at WakaTime with Stripe, Braintree, and Coinbase as swappable payment providers. It's definitely a source of edge case bugs, but overall it works pretty well. It supports prorating subscriptions across providers, monthly & yearly billing, trails, discounts.

* We don't remit taxes for customers because that would be impossible to build in-house, but everything else was achievable.

* We have tons of logging, and generate transient Quotes on our end, then check that the expected charge matches what the payment provider actually charged.

* Each Quote is reproducible, so if any bugs come up we can give the "create quote" code the same input and see what went wrong.

* What helped when building was hourly tasks running in the background to make sure customers who should be billed were being charged, and make sure we didn't double charge any customers, and then alerts so we could find and fix those bugs.

I would do it again to support both PayPal and Stripe, but it's definitely a source of complexity for the code base.

Post reply on HN