Live data from Hacker News

Billing systems are a nightmare for engineers

getlago.com

71–80 of 372 posts

Re: Billing systems are a nightmare for engineers

#71
post #27

Earlier quoted context omitted.

Have you looked at existing solutions? Why did not they fit?

Not the OP, but anybody who has built a deep integration with any billing provider (inclusive of Stripe) knows there are some bodies buried, although you typically don't discover them until you're late in the game. 90% of your use cases are covered, and with excellent UX and docs to boot. But that sweet 10%! --- For a concrete example, Stripe has a very nice "subscription" abstraction that makes it easier to operate…

A lot of the time there’s trade-offs that can be made that engineers don’t even consider because they’re not pure. For example, why do you need a one-to-one relationship between your customers and Stripe customers? I am guilty of it myself, where an 80% solution is unacceptable from an engineering perspective but, actually, when balanced against the cost of building out a perfect solution, the business may well find it very acceptable.

One of the most important things I’ve learned about working with third-party systems is that there has to be some amount of surrender to their way of doing things. Essentially, the price of using Stripe is not being able to use invoices as a quote, and that has to be articulated to the business. If that’s not acceptable, then the business should be considering the requirements in aggregate when evaluating a solution, rather than deciding on Stripe and then gradually re-implementing parts of Stripe internally because they aren’t right for the business.

(Obviously that’s easier said than done, and for engineers it’s a fun challenge to make something impossible possible, but it’s almost always a mistake and as engineers it’s our responsibility to articulate the burden of owning workarounds.)

Re: Billing systems are a nightmare for engineers

#72

> To solve this problem at scale, we adopted a radical sharing approach. We’ve started building an Open-Source Alternative to Stripe Billing (and Chargebee, and all the equivalents). This is so great. I personally haven't had to deal with this problem, but I've worked at a number of organizations (and heard about many others!) where this sort of business logic had to be implemented. It's just reinventing the wheel. I…

> We need similar open source frameworks for common business use-cases - billing, subscriptions, order/purchase management, and so on.

You mean like an ERP? There's 2 open source ones I can think of:

- Odoo, which is the bigger one, mostly Open-source (CRM / sales / subscriptions / invoices / webshop / inventory / purchase) but some enterprise-only modules (Rental, Field Services), I work with this software daily as an Odoo Developer (Customizing Odoo for customers' needs).

- Erp-Next, which is completely open source as far as I can tell, through my limited testing it seems to be less advanced than Odoo currently.

EDIT: you can even check runbot.odoo.com for some test-environments which are automatically built, where you can test/experiment, login is always admin:admin

Re: Billing systems are a nightmare for engineers

#73

Reading this article gives me a smidgen of sympathy for Xfinity. They have so many plan options/timed promotional deals, and seem to run into so many issues every seemingly minor change, now it makes sense to me why. But in the same breadth still ... F** Xfinity

Anh-Tho, one of the co-founders of Lago, here! yes totally, each time I open a pricing page, I have full sympathy for the engineering team who made it happen! I used to be the one tweaking with pricing plans on a spreadsheet and handing it over to engineers in a 'just make it happen' fashion!

Re: Billing systems are a nightmare for engineers

#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 would deduct the check amount from whatever invoice ( or even across a range of invoices! ) from us they felt like. We literally had a bucket called "magic money" these random deposits went into that we would use to fill in the A/R gaps from insurance carrier insanity. There was no connection between magic money and whatever invoice they decided to short change us on so it was just a hope-for-the-best process.

Re: Billing systems are a nightmare for engineers

#75

Poked around their site a bit, they claim to be open source but I don't see a link to a git repo anywhere. Also searched GitHub a bit but might have missed it.

Hey @daxaxelrod! I'm one of the cofounders of Lago, the lib will be opened very soon, we're in the final steps of QA, that's why. I will make sure to ping you back here when it is. We wanted to share this post about our first-hand experience with billing a bit ahead of this. Thanks for your patience!

Hi! Cool, can't wait to poke around. I've used killbill https://github.com/killbill previously and would be interested in your offering.

Re: Billing systems are a nightmare for engineers

#76
post #38

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…

Many years ago I led a billing team at Yahoo! responsible for billing for premium services in European markets. My team existed for the sole reason that the European business did not trust that the US payment services team understood European needs, and the "invoice is a legal document" thing was one of them. I spent so many meetings repeating to the US team that no, we could not switch to their invoicing as long as…

I'm Anh-Tho, one of a co-founders of Lago, thanks for your comment! I was the country manager of France for a US Sequoia-backed company before, and I never ever managed to convince HQ to work on EU invoicing, I think they just did not want to open the pandora box you just described!

Re: Billing systems are a nightmare for engineers

#77

Earlier quoted context omitted.

If you wire your dollars onto US soil, for a service performed in the US by US business, good luck getting the US legal system to enforce upon that US business whatever euro-cucked invoicing scheme is called for.

This doesn't matter. For B2B, if you don't show your EU customers a valid invoice, they simply cannot pay you. It's not EU governments or post-purchase issues you have to deal, most of the time - it's trying to persuade a large accounting department to pay you unaccountable money. If you can't follow their invoicing requirements, it's just not going to happen.

>they simply cannot pay you.

Do people ever stop and wonder WHY in nations like Portugal the informal economy is roughly DOUBLE of say the US? When every invoice must be available to the government, what actually ends up happening is non-conforming invoices either get made up by the customer or the money magically flows out under some other auspice.

Making it literally illegal to accept an invoice that is legal in the country in which you obtained it borders on logic even my toddler can understand is absolutely begging for bad business climate or tax evasion.

Re: Billing systems are a nightmare for engineers

#78
post #4

A classic, from http://www.canonical.org/~kragen/tao-of-programming.html > There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?'' > ``An operating system,'' replied the programmer. > The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to th…

Which came first? I am pretty sure it was computer accounting systems.

Which is older, the oldest continuously supported operating system, or the oldest continuously supported (computer) accounting system?

Re: Billing systems are a nightmare for engineers

#79

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 most big companies who agree to pay you net X days, that usually is after the presentation of a correct invoice. The invoice doesn't get to them, or it isn't right the clock doesn't start for them to pay you. Getting invoices wrong can quickly result in major cashflow drops.

I'm Anh-Tho, one of Lago's co-founders here. Indeed, from our experience people see 'billing or invoicing' as a monolith block, whereas there's a whole 'pricing stack', billing > payment > invoicing > cash collection + accounting + CPQ + sales commission. For cash collection, we mentioned the tool used by Lattice called Upflow which helps to manage account receivables.

Re: Billing systems are a nightmare for engineers

#80
Pretty much everything is more complicated than people (including engineers) think.

Take a simple example: selling clothing in a retail store. Sounds simple right? You have an inventory of items and someone pays for it. Should be a simple transaction, right? Well, now you're dealing with:

- How do you determine the price? There might be a retail price but there are sales, discounts, overrides for various reasons (eg defective goods), etc;

- You have to handle different payment options eg cash, credit card, debit card, gift cards, store credit. Payment methods can be mixed;

- You have to handle returns. These generally have to go back to the original form of payment. Some goods might not be eligible for a return. What if the payment is split between store credit and a credit card? Where does the balance go?

- Identity of the person making the sale or handling the return;

- Authorization procedures for returns and price overrides.

Everything is complicated.

As an aside, this is one reason why I'm so bearish on Web3 and smart contracts in general. The edge cases are so complex and possibly unknowable that codifying these, particularly on an immutable blockchain, to remove the need for human intervention seems doomed to failure.

Take Web3 identity. If you lose your password there are methods for recovering your account. The first is a reset password option. That may be insufficient and there'll sometimes be a human avenue to recover your account. Now consider a Web3 identity. I've seen various incarnations of these such as authorizing other identities who with consensus can recover your account. Well, those identities can be compromises so you've just added an attack vector. Alterantively that recovery mechanism may become insufficient as people lose identities themselves.

If these problems weren't complex they'd be solved problems.

Post reply on HN