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

231–240 of 372 posts

Re: Billing systems are a nightmare for engineers

#231

Post by formerkrogemp »

AnhTho_FR wrote: post #188
janci wrote: post #170

I was working on a billing system for utility company and it was a nightmare but not for the reasons from the article. Dates are no problem, everything is billed at the end of month, quarter or year. Upgrades are downgrades are simplified, customer can legally change tariff only on predefined dates/events. Usage - yes, but exampled in the article do not even scratch the complexity of this Idempotency is not really ne…

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 for instance, then the business will be liable for sales tax not collected for products or services sold to California residents online even though the business might physically reside in Montana.

Re: Billing systems are a nightmare for engineers

#232

Post by folmar »

bombcar wrote: post #15
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 even worse - your biggest customers won't even smell your invoice unless you enter it line by line into some ancient SAP system developed 20 years ago, where everything cloud related is classified as telephony except storage space which must be classified as filing cabinets (movable) or your invoice will be (very slowly) rejected. And if it is rejected you have to enter it all again by hand; editing isn't a featu…

I don't get what you're talking about. Our biggest customer reluctantly agreed to accept preliminary invoices for acceptance over fax instead of signed-for mail, provided that we also ship a paper version with a red stamp promptly.

Re: Billing systems are a nightmare for engineers

#235

Post by flappyeagle »

lelandbatey wrote: post #12

Billing is a nightmare, and if I had one piece of advice for people building a pay-for-what-you-use system like most SaaS, it's this: DO NOT bill against your business logic entities. They change, and doing a COUNT at the end of the month won't catch all things which changed or which cost you money during the month. Instead, figure out what you bill for and and when you do that thing, record a row in a DB or into a s…

If you squint, this is similar to how e-commerce billing is done. You have stock keeping units that represent the logical item being sold, and every transaction clones that row as part of the order record.

This way, if the price changes, the item description changes, the images on the item change, etc, you can still have a record of what was actually sold and how much to refund a return etc.

Re: Billing systems are a nightmare for engineers

#237

Post by ab_testing »

I think companies should not try to reinvent the wheel with building billing systems. It is better to implement an ERP to take care of billing rather than building out your own. If you ever grow large enough, this homegrown system will never be SOX compliant and will not stand up to audits.

Re: Billing systems are a nightmare for engineers

#239

Post by herdrick »

biermic wrote: post #62

Absolutely agree with the poster. This is my life at the moment. Just to take money for a small piece of software I built. Multiple currencies, trial periods, when in the process do you ask for the creditcard, country specific taxes,... And the worst: invoices. While paddle.com takes care of many of those things - I was shocked after realizing how much work this is going to be. Please think carefully about those thin…

Have you looked at Outseta? https://www.outseta.com/billing and https://www.outseta.com/demo . I haven't used it but it looks great. I'd love to hear what you think.

Re: Billing systems are a nightmare for engineers

#240

Post by yobbo »

Rafsark wrote: post #141
yobbo wrote: post #49

One design decision that, for me, seems to simplify things is to consider the "business system" a type of state machine that records all business events and serves as a "source of truth". If the events are not recorded, they have not occurred from the business perspective. A ledger-type architecture can be useful. This means that business events or user operations generate state transitions, which eventually are impl…

For sure; I do think an event based solution working as a source of truth for the billing is the right solution. However it still creates engineering difficulties (making sure you don't ingest the event twice for instance). The ledger-type architecture can definitely work. When we built the system for a fintech, it was actually an event-based architecture connected to a ledger (taking the money out of a wallet). I th…

And that events, as much as possible, are formulated as observations or state-changes rather than operations. Events in the form of "set x=1" or "y=0 was observed" are idempotent, where as "do this with that" is problematic.

In the framework of state-transitions, actions such as "price this with that" are implicit in the state matrix, and shouldn't be called from APIs. Rather, API calls should be used to produce reports which are print-outs of the "current state". Webhooks in this framework are attempted state-transitions. User interactions generate events, and requests for reports (for example invoices), but as little as possible in the form "do this with that".

My opinion currently is that there is little value in sharing code (libraries/frameworks) for these sorts of solutions because the code is trivial, application/language/domain-dependent, and coupled to everything else in the system.

But design patterns, templates, and concise examples are hugely valuable because they help illustrate the complexity and solutions up front.

Post reply on HN