Live data from Hacker News

Problems with homemade billing systems

getlago.com

61–70 of 105 posts

Re: Problems with homemade billing systems

#61
post #59

When we launched in 2017, we went "in-house" with our billing. We found an open-source project and uses that for all billing as it had a recurring option and a billing portal. Fast forward a number of years, we now sync invoice data in the app and have a tiny billing portal there. We can still adjust invoices, keep old pricing, setup new pricing, auto-bill, check balances to see if a customer hasn't paid yet. Total L…

What open source project did you use?

Re: Problems with homemade billing systems

#62
Worked in mobile Telecoms billing back in the relatively early days. Remember discovering that Orange at the time made a good feature of competing (and acquired lots of new customers) by offering "competitor match" billing options. They made this as a business choice, but it cost them a team of over 100 contractors developing that system. Other telcos had packages but were constrained by what the packages offered as to what their marketing could offer. You pays your money and makes your choice! p.s. things learned the hard way in those early days - customers realised that a call held open for over 24 hours resulted in a reset of billing due to counter wrap around!

Re: Problems with homemade billing systems

#63
Another problem with billing systems I've seen repeatedly is that the billing demands flows one way; marketing or product management basically scribbles on a napkin how they'd like to bill the customer, and that napkin gets passed to the billing team as a specification carved into stone. Basically, in practice it gets run as Waterfall, actual factual Waterfall, except the design phase is skipped. It goes straight from features to implementation.

Now, on a business level I acknowledge that frequently the monetary costs of the billing system are negligible compared to the business advantages of the "correct" billing system. My complaint is more that the scribbled note often ignores what the rest of the company is doing for billing, e.g, "yes usage based billing is great but do you really need to bill on furlongs per fortnight when the rest of the company is billing based on seats or some basic, easy-to-understand resource allocation?", ignores that maybe there's an easy thing that's close to what you said but since it reuses all the existing stuff you can have it in two weeks instead of four months, etc. Do you really need to issue a discount coupon that takes off a percentage proportional to the length of the customer's first name, unless the customer is in a jurisdiction where that's illegal in which case we roll a die, unless the customer is in a jurisdiction where that's illegal in which case we give them $10 off their first $100 and take off every prime-numbered dollar after that? Because I've got code that just takes 10% off their first month right here. Do you really need to bill on the first of the month unconditionally when the rest of the company bills based on subscription start date, or vice versa? Even if you're not too worried about the costs of paying 6 months of developers, I bet you are worried about those 6 months of opportunity cost.

I can't even count the months of delays caused by treating napkin scribbles as carved stone I've personally witnessed, and I'm only tangentially involved in billing over all.

And somehow managers who are deeply familiar with costs and benefits and tradeoffs and make sensible decisions all the time just become the most obstinate customers when it comes to billing. No matter how small the tweak proposed and how many months forward it may bring your release date to do something just slightly different (and consistent with the rest of the company's existing policies), they will go to the wall for their billing deviation, even when it was frankly clearly nothing more than a whim or a transient thought at some point by somebody somewhere of no strategic or marketing consequence.

It isn't just engineers who underestimate the complexity of billing until it's too late; it's everyone, really. "Just" print an invoice turns out not to be so simple.

Re: Problems with homemade billing systems

#65
Why are we against modifying our processes to align with a particular software platform? Maybe it is much easier to follow such guidelines during the early stages of a company, but much harder later on. Do standards exist in billing systems?

Re: Problems with homemade billing systems

#66
post #5

Having gone through /exactly/ what this article is about, I know the pain. But I will point those that don't read the article to the last paragraph: > We considered implementing an off-the-shelf billing solution but there was nothing flexible enough and the switching costs were too high. Algolia also tried to migrate to Zuora before backing out and rebuilding their billing system for the fourth time. Most (all? I hav…

I came here to pretty much make the same comment. If you have a business that can get away with OTS software, more power to you. But complicated things are complicated and complex billing rules can be make-or-break for a company. Whether you start with 3rd party or start home grown, billing systems often need humans and there really isn't a substitute.

Re: Problems with homemade billing systems

#68
post #59

When we launched in 2017, we went "in-house" with our billing. We found an open-source project and uses that for all billing as it had a recurring option and a billing portal. Fast forward a number of years, we now sync invoice data in the app and have a tiny billing portal there. We can still adjust invoices, keep old pricing, setup new pricing, auto-bill, check balances to see if a customer hasn't paid yet. Total L…

What open source project did you use?

InvoiceNinja. The install instructions had a few misses but has an API and webhooks so it's great to integrate with.

Re: Problems with homemade billing systems

#70
post #46

Billing in general is very hard. Especially subscription billing. Just from my experience in building billing and also later on using a third party system for another projects, I can mention so many edge cases: 1. Grandfathering 2. Upgrading across different length memberships (monthly tier 1 to yearly tier 2) 3. Crossgrading across different lengths (monthly tier 1 to quarterly tier 1) 4. Offering free trial to tier…

Sounds a lot like Autodesk.
Post reply on HN