A Billing Project Horror Story (And What I Learned)


A Halloween story should start with a line like, “It was a dark and stormy night as we approached the castle…” or something similar. But this particular horror story didn’t begin on a dark and stormy night – it was more like a sunny afternoon, something uncommon enough in that part of England that my colleagues and I decided to take our catered lunch and sit outdoors on the lawn. And though there weren’t any zombies roaming the English countryside on that fateful afternoon, it turned out there was a monster lurking in the shadows, waiting to consume our brains and resources.

We were in a bind. We were a global company, growing rapidly through an aggressive acquisition program. We needed to standardize financial processes across business units, preferably on a single platform. So someone (I’m not owning this one) came up with the idea of challenging our ERP provider to create a solution that would handle our recurring revenue billing needs.

So there we were, visiting our ERP provider and picnicking under the English sun, unaware of the horrors soon to be unleashed upon us. Our vendors were great hosts, and they provided a brilliant series of PowerPoint presentations that checked off all the boxes. We even followed up with a ‘proof-of-concept’ that seemed to, well, prove the concept.

I’m often amazed at how good things can look and sound in PowerPoint and how differently they work out in real life. It’s kind of a Jekyll and Hyde thing. In retrospect, some of what we saw and heard from the vendor that day was wildly inconsistent with reality (I know you’re shocked). Our solution combined out-of-the-box functionality with a large dose of customization. The end result turned out to be the software equivalent of Frankenstein’s monster, complete with neck bolts.

The ensuing project was our own personal Nightmare on Elm Street. Out of the gate we had data problems, trying to put lots of square pegs into round holes. Data migration is often the long pole in the tent on billing projects. Most legacy systems do a poor job of enforcing data integrity, so over time data gets out of synch, especially in complex B2B environments. No one ever really knows how badly out-of-synch until you try to load it into a new system. In our case, system testing was delayed by months while we sorted out the data.

When we finally got to system testing, we found that our custom software didn’t work very well. The first time we tried to run monthly invoices, we found that the job might complete in time to run next month’s invoices. It took months of tuning databases, servers and software to get performance to acceptable levels – months of people working nights and weekends and questioning why we had ever gotten into this business.

We finally went live, five years ago this month (on Halloween night, no less). We were only nine months late. No one died, but we did lose one key resource to stress related illness; and by the time we went live a couple of us felt (and looked) like the walking dead. No one knows how far over budget we were, because it was in everyone’s best interest to stop keeping track. It was our own fault, we should have known better. Actually, I think a couple of us did know better, but we didn’t have a lot of choices at the time.

With the emergence of a new crop of SaaS-based billing solutions over the past few years, you do have choices. And here’s something to keep in mind:

The systems you’re using to support your business today were designed for your current use cases, or maybe to be more accurate, they were designed for the use cases that were in place years ago when the systems were originally deployed. And that’s the whole point of this story. We tried to take an existing solution that was really good at what it was designed to do, and make it do something else entirely. The end result was predictable – a billing project that sucked the life out of everyone involved. Don’t repeat our mistake.

There is no silver bullet solution for recurring revenue monetization, but today there is a market full of options – options that weren’t available to us and that are designed specifically for the use cases you will encounter in the recurring revenue world. Find a monetization system that is designed for the use cases that will be a part of your future rather than trying to fit into a system that meets the use cases of your past.

The right choice will go a long way towards ensuring that your recurring revenue deployment does not turn into your own private sequel of Halloween.