Service Billing is Hard

Service billing is hard. It’s hard to get invoicing and settlement overheads low. And billing is often one of the last and least thought of components of a for-fee online service systems. Billing at low overhead and high scale takes engineering and this often doesn’t get attention until after the service beta period. During a service beta period, you really don’t want to be only working out the service kinks. If you have a for-fee service or up-sell, then you should be beta testing the billing system and the business model at the same time as you beta test the service itself. It’s hard to get all three right, so get all three into beta testing as early as possible.

Billing being hard is not new news. The first notable internet service billing issue I recall was back in 1997 ( during which MSN was unable to scale the billing system and collect from users. Services weren’t interrupted but revenue certainly was. Losses at the time where estimated to be more than $22m.

One way to solve the problem of efficient, reliable, and low-overhead billing is to use a service that specializes in billing. It was recently announced that Microsoft Online Services (includes Exchange Online, Sharepoint Online, Office communicator online, and Office Live Meeting) has decided to use Metratech as billing and partner settlement system. The scope of partnership and whether it includes all geographies is not clear from the press release: Microsoft Online Services Utilizes MetraTech’s Billing and Partner Settlement Solution.

I suspect we’ll see more and more sub-service categories popping up over time and the pure own-the-entire stack, vertically integrated services model will only be used by the very largest services.


James Hamilton, Amazon Web Services

1200, 12th Ave. S., Seattle, WA, 98144
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | | | blog:

12 comments on “Service Billing is Hard
  1. I agree William. Prices should very closely model costs. If there are differences in how you price, developers will find the nooks, crannies, and inconsistencies and they will be exploited. My first rule of billing is you should price the units that drive your costs. The further they diverge, the greater the risk that users will find inconsistencies and exploit them.

    I also agree that prices layer upward and each subsequent layer has, as costs, the prices of the layer below.


  2. Some other points to bear in mind.

    One persons billing (or pricing though they can be different) model is another persons cost model (at least partially). Will become more so with commoditization.

    What one views as an metered activity another views as a priced resource. This is especially through when costing/metering/pricing/billing different layers on the software stack.


  3. Hi James,

    After working on various billing engines for telecommunication companies I would agree that they are indeed separate systems though I would argue that any billing should be based largely by the cost model, the service (software) activity levels of users, and the quality aspects of the service delivered (I think this is extremely important especially for some social/networking companies trying to figure out a business model that is viable and sustainable).

    I did publish a small article on how to apply this in practice though I did not dig deep into the various challenges in creating a ABC model irrespective of data collection techniques.

    ABC for Cloud Computing

    That said I should point out that in some companies there are at least two billing models/solutions. One actual (and subsidized) and another that models much more closer the actual cost structure and ignores strategic objectives (grab market share) – "I wish we could charge a users this way".

    This second one is used to justify future enhancements of services by way of an internal (and future/planned) pricing model. Cost benefit analysis is much easier for accountants here as it is much more concrete.


  4. William, I actually see some value in there being a clear architectural boundary between metering and billing. I 100% agree that they need to work well together — I’m just arguing that clear separation between billing and metering is a good thing.

    Thanks for the comment William.


  5. The problem with billing on its own is that it creates a disconnect between the underlying cost management model (resource metering) and the performance management model (quality at a cost).

    A Unified Approach to Performance Management and Cost Management for Cloud Computing


  6. eVapt is another company in this space.
    Website :

  7. Opsource and IP Application, thanks for making me aware of your services. I’ve checked out both of your web sites. Thanks.


  8. vraniga says:

    James, I couldn’t agree more. Having a billing system that runs in parallel with your business objectives is much harder than it looks. Particularly when dealing with flexible reoccurring monthly bills. For example attempting to meter usage by a variable (say per GB) becomes inordinately complex for a company that is worrying about its core competency.

    Here at IP Applications our paramount concern is to take care of billing and subscription management automation so our customers can focus on their main product.

  9. john rowell says:

    James. You are right. It is hard!, and while it is critical for ISVs it isn’t core to their business.

    We’d love to give you a demo of the solution.


    OpSource, Inc.

  10. Kristoffer Sheather says:

    OpSource purchased LeCayla billing for their billing solution:

    They also had (may still have) a billing relationship with Aria Systems as well.

    Another company worth looking at is which is backed by several ex SFDC execs.


  11. I hadn’t come across them before Jeff. Thanks for the pointer.


  12. jeff says:

    yo james, not sure if you’ve seen these guys, but opsource is a hosting provider that provides billing services: they’re very popular among saas/cloud companies.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.