I've built several billing systems and managed a team that built a much larger one, and it's not <i>that</i> hard, but it does require an attitude and attention to detail that a lot of people lack.<p>E.g. one thing that worked well in the systems I've worked on was to break things into <i>small</i> state transitions, <i>very</i> firmly document the allowed states and their transitions, and <i>log every transition</i> to the database. Wherever possible (anywhere that didn't interact with external API's, and sometimes even when they did) we'd aim for state transitions to be idempotent. When they weren't, we'd seek to reduce the non-idempotent call to an external dependency to <i>just</i> that call as a separate state transition.<p>When something very occasionally went wrong, we could trace things in detail, and pinpoint it, and most of the time we could safely replay transitions around whatever went wrong until we could see what had happened.<p>It wasn't <i>difficult</i> to build these systems that way, but it was <i>tedious</i>, and something where it's easy for people to be tempted into shortcuts.<p>As for scaling, you spit out events for rollups, and can shard invoice generation. We handled millions of revenue on a machine far less powerful than my laptop today. Scaling really would not have been up there for me.<p>To #3, maintaining old pricing isn't generally <i>that</i> hard. Very few people drastically change how they account for usage, which tends to be the most complicated billing scenario. They tend to change amounts and periods and thresholds, which should be data, not code.<p>With respect to a team, I agree. One of the places I worked on billing was Yahoo. At the time it wasn't just one team, but several - my team (responsible for Europe) existed largely because the European finance and product teams didn't trust the US payment services team to take their requirements seriously enough and so wouldn't let them near the European premium services... Billing isn't something you want to do yourself unless it's either a core competency or you're big enough to have to deal with that kind of bullshit.<p>(As for size of teams, I've built a billing system with 2 people, but I've also worked on billing systems managed by 50... You really want to have a good idea whether you're likely to end up towards the former or latter before you go ahead...)