I started work for my last company on March 9, 2020, the same day when its main office closed for good. Covid cases were rising in Europe, the stock market was falling, and layoffs for my employer were around the corner. But I felt secure, for I was as close to being an essential worker as I’d ever been: I was a programmer, and the only one at our startup responsible for billing customers.

Even so, I had to admit that billing was something that, as a generalist and backend data person, I knew almost nothing about. Indeed, everyone I talked to – even financial people – felt the same somehow. People who worked in product were most interested in shipping delightful products, people who worked in SRE were most interested in making services reliable, people who worked in sales were most interested in closing deals, and people who worked in finance, while they were interested in quite a lot of things, generally felt provisioning and invoicing to be the least interesting part of their work.

Generalists have little choice, though, but to start learning. And so here I am, after two years, a couple reorgs, and the acquisition of my employer by a former employer. I’ve learned something. And it’s time to account for that, even if this account is quite specific to late stage, usage-based SaaS businesses.

Thus this post introduces a finite series, “The Hard Count,” about working as a programmer and manager in billing. Done right, it should cover at least a few useful aspects of a modern programmer’s encounter with billing and SaaS billing in particular. I won’t celebrate the software engineer’s work here, but rather just offer a picture of how I’ve found billing to work (and not) in a few businesses I’ve come to know.

This series will cover the biggest things you should expect to happen when working in billing, as well as (I hope) a few big lessons that you’re better off learning from reading instead of from experience. These include:

  • why billing is always a distributed system, but why billing services aren’t often developed as one

  • why orders, skus, and a product catalog are important

  • the five or more things that make enterprise billing hard

  • the four or more things that make self-service billing not so easy

  • tax

  • testing

  • what billing vendors can do for you, and not

  • reselling, special deals, and their imperfect conflict with growth

  • why you can’t do without usage-based billing, though you’ll wish you could

  • how billing software and billing software teams evolve or devolve, and finally

  • when it’s a good time to work in a billing team

Done right, it should offer a few good stories, and maybe also help you, should you find yourself working in, leading, or even just trying to understand a billing team.

So, let us begin! You can proceed immediately to the first full post: To bill is to build a distributed system.1


  1. Future posts will show up roughly every 2 weeks under “The Hard Count” on the main page – but you can also catch them by subscribing to the site mailing list or site rss feed.