Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with homemade billing systems

getlago.com

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Problems with homemade billing systems

#41

Post by hk1337 »

lowercased wrote: post #34

Why do I have the feeling that many people starting projects like this get in to situations where functionality is identified and they're beat down with "YAGNI!"? I've been in situations where 'build v buy' comes up - accounting, inventory, and similar domains. Identifying "hey, we need to keep XYZ data to allow for future reporting..." has been met with chants of "YAGNI" from people blind to the complexities. It's j…

That situation is why I don't like about the software development process. YAGNI gets abused to go with the sloppy shortcut that only really saved maybe a day in creation but in reality wastes months worth of maintenance.

Re: Problems with homemade billing systems

#43

Post by swader999 »

vidarh wrote: post #28
6510 wrote: post #26

Earlier quoted context omitted.

> #3, maintaining old pricing I copy the entire product into the order. The thing one buys should be the thing on the screen when the decision is made. Poor pictures, description with typos, wrong categories, old/wrong pricing etc

Yeah, that can be a good approach. Including all the data defining the old product in an unchanging way was one of the sticking points that led to the creation of my team at Yahoo. The US team didn't think twice about changing invoice templates for examples, while the European finance teams broke out in hives at the thought of anything changing on already issued orders, much less invoices. I spent three years holding…

Everything has to be historically available. Think about returns and redoing the entire period and so on. Sometimes even the old code if you want to be perfect.

Re: Problems with homemade billing systems

#44

Post by wredue »

lowercased wrote: post #34

Why do I have the feeling that many people starting projects like this get in to situations where functionality is identified and they're beat down with "YAGNI!"? I've been in situations where 'build v buy' comes up - accounting, inventory, and similar domains. Identifying "hey, we need to keep XYZ data to allow for future reporting..." has been met with chants of "YAGNI" from people blind to the complexities. It's j…

>Once you’re “in”, you’re almost never leaving

Yeah. This problem is real. It’s so expensive to get out that we have had to make business process concessions because the COTS ended up not supporting, what I consider, basic functionality.

We only found out years later on the basis of changing other business processes.

And vendors will bleed you dry if they can. What some vendors consider to be “customizations” is insane.

Re: Problems with homemade billing systems

#46

Post by zer0x4d »

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 2 when user has tier 1.

5. Promotional offers to non-paying users (half off first month)

6. Downgrades

7. Applying coupons to accounts (customer support wants to offer a specific user a free month of service when user has a quarterly subscription: billing schedule change)

8. Differences in tax regulations across countries (VAT vs whole value tax)

9. Differences in display prices (in some countries displayed prices should include tax)

10. Handling currency exchange rate changes.

Re: Problems with homemade billing systems

#48

Post by mlhpdx »

The point the article makes to me (as a leader) is “keep the billing model simple, honest and stick with it”. The cost of change is high, and the value isn’t to the people getting the work done. My peers would likely see this as “naive” and extoll the need to “sell to the buyer”. I see it as being value focused, and keeping the “business needs” rational, and in line.

Re: Problems with homemade billing systems

#49

Post by trollied »

pantulis wrote: post #27

Billing is one of those problems that seem deceivingly easy. Just talk to someone who has worked in telco billing and learn about the 4 horsemen of billpocalypse: metering, mediation, accounting, billing.

Rating can be great fun. US taxes (geocoding, urgh) are an absolute nightmare. Reversed charged calls, revenue sharing. Roaming is a pain (ASN.1 files). Even document numbering is a nightmare in some countries, as are legalities surrounding incorrect bills (corrective invoices) and crediting. Did 15 years in billing (now do finance software), and whenever I thought I knew it all there would be another curve ball thrown.

Re: Problems with homemade billing systems

#50

Post by p_l »

re-thc wrote: post #31
jasode wrote: post #23

Earlier quoted context omitted.

>, how do I know that the OTS solution would actually be much better? For example, [...] how would you have any guarantee that your third party solution would be able to support those? The business (employees in the accounting dept and/or consultants) do a "fit-gap analysis" when evaluating potential software: https://www.google.com/search?q=fit+gap+analysis For the "gaps" of missing functionality, look at either : (…

> Well, he was 20-something at the time and naive about the complexities of financial accounting software for a global business. He must have eventually realized the true scope of the problem because instead of building in-house accounting software, Google bought Oracle Financials. How do we jump to this conclusion? Did he realize the true scope of the problem or was it just left to someone else once Google grew in s…

Don't forget the money sinks that are any attempts to implement something differing with SAP or other big ERP systems.

You delivered extra value for customers (making you more competetive) thanks to some particular ability of your previous (even manual) billing rules? Kiss them bye bye.

Post reply on HN