I'll see you're billing and raise you localization. All in? Here, have some timezones for good measure.
Ok for the one-upmanship I raise you billing systems for telecommunications. 1000x the transactions per customer and 1000x the complexity of the business rules.
Eg. An SMS on an off peak time is cheaper. If the user makes 100 or more calls a month a special rate. How do you charge data per plan? If the user roams to another country there's an entirely new set of complex billing rules.
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!
I was illustrating the point that customers are often unreasonable about billing, and there's no magical solution that fixes the problems. The answer is really to try to make sure you're not overly reliant on a single customer. That's hard as a startup though especially if you're in B2B.
You're being facetious but I don't think this is a radical idea. Government already publishes the tax code in English language. This is just formalization of the tax code in computer code: More precise, testable and provable.
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, emerged.
I have no words to describe what I just read. That's straight out of the TV show Silicon Valley.
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…
Did the company use a relational database to deal with the billing and subsequent adjustments? I've been there: it can be more straightforward to use an event streaming approach that recalculates billing as new events arrive.
In my opinion, the best way to do it is ingesting events in a relational db with an idempotency key to prevent duplicated events. Some companies don't need real time billing data, so you could just use it to aggregate these events with the aggregation function that fits your need for a certain feature. Thus, you have the flexibility of (i) calculating pretty much everything you want, (ii) give granularity of usage to your customers and (iii) be closer to real time (you play the query anytime you need it).
Basically everything about enterprise is a nightmare for engineers. What amazes me (after having worked at some of the most profitable companies in the world) is just how little intelligence the leadership has about their own revenue or costs, beyond "wow huge amounts of money is coming in or going out". And how many critical processes are implemented manually, by individuals, with personal spreadsheets, on their lap…
It's a difficult topic to tackle; The financial leader has different needs than the tech one. One needs a perfect report with exact match day over day, month over month, year over year. The second one needs to do the math to calculate instant consumption of the product. If we add marketing leaders of a company to it, it brings creativity to the extreme (like inventing new prices, just to use it "as a hack"). Same goal (revenue), but definitely not the same path to success
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.
“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.
> reduce the pain instead of just shifting it around
Nay. Shifting pain from thousands of projects to a single org obviously reduces overall impact.
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.
You are totally right. But, somehow, most of the engineers working on those topics don't want to work on financial system. They are just part of a company and take this topic "because someone has to take it". They accumulate the tech knowledge, but not necessarily the whole accounting part
Can corroborate, my experience working on an upgrade to an existing multi-platform (iOS IAP + Strip for web product) subscription service was certainly a bit painful.
Yes, upgrades and downgrades were painful for me too. I think it's due to different subscription dates between all our customers, having to create specific code for each edge case. In the end, it works, but so much harder than I thought
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…
We should demand governments to maintain and provide an API for their tax codes. Let them have skin in the game. If the taxes are incorrect, businesses can point out that it’s the government API’s fault. Completely developed in the open, and with full test coverage. This should be required to collect taxes. No API? No taxes. API down? Tax waived.
Tax codes are hard. “Get the government to build an API” now you have two problems….
Source used (non-US) government api to do with legislation. The freaking ambiguity and cludges. Luckily they had a team of good people to help.