Do your hourly invoices look like a heart monitor?
This unpredictability is bad for both you and your client. The client never knows when they might get nailed with a big bill. You never know when you might hit a slow month and run into a cash flow problem.
One way to address this issue is with level billing.
What is Level Billing?
Level billing is a common term in the electricity market, where changes in seasonal usage make it hard for consumers to manage their monthly budget.
Since total annual usage tends to stay consistent from year to year, energy companies offer programs that allow their customers to pay the same amount each month. The specifics of the program vary by company, but the overall concept is the same.
- Energy company estimates total annual usage
- The usage is divided by 12
- Customer makes 12 equal payments
- Any over or underpayment is taken into account in the next plan year
A utility company example
For example, imagine you used $100 of electricity in each of the first four months of the year, $200 in the next four months, and $300 in the last four months. Your total annual usage would be $2,400. With level billing, you would pay $200 per month for all twelve months. This is easier to plan for than having some months where your energy bill triples compared to other months.
Level Billing for Software Development
The concept is pretty much the same for software development, but without the predictable seasonality aspect.
Here's how the concept might work in practice. You have a $100 hourly rate. Your new client anticipates needing about 20 hours per month of your time. You agree that the client will pay you $2,000 per month in exchange for 20 hours of your time.
In accounting terms, that $2,000 received is offset as a liability on your books. You are responsible for delivering 20 hours of service for that $2,000. You may not deliver it all the first month. You may deliver more than that the first month. As you deliver those hours of service, the liability from earlier becomes income on your books (even though no money actually changes hands at that point).
A software development example
Let's say you perform 15 hours of work in month 1. At the end of month 1, you owe the client 5 additional hours of work.
In month 2, the client pays you another $2,000. You are now responsible for delivering 25 hours of work (5 hours from last month plus 20 additional for this month). You perform 30 hours of work in month 2. At the end of month 2, the client is in the hole 5 hours.
In month 3, the client pays another $2,000. You now owe the client 15 hours of work (20 hours of new work less the 5 hours the client owed you from last month). You perform 15 hours of work in month 3. At the end of month 3, you and the client are even.
With regular hourly billing, the client would have paid you $1,500; $3,000; and $1,500 in those first three months. With level billing, the client paid an even $2,000 every month.
Of course, the chances of the arrangement netting out to zero in the first three months is, well, nearly zero.
In reality, what is likely to happen is that over time the balance of hours will trend either positive or negative. At that point, you would sit down with the client and discuss changing the arrangement up or down.
Another option would be to have the client skip one month's payment (if you "owe" them several hours of work) or have the client make a one-time make-up payment (if they "owe" you for several unpaid hours).
The important point is that you need to let the arrangement play out for awhile before jumping in and making adjustments. After all, if you make adjustments every single month, then...well...that's just called hourly billing.
When to Use Level Billing
Level billing makes sense when you have a long-term project with a client that is looking for ongoing development work. The client has a budget set aside for software development, and they don't want any surprises month-to-month.
When NOT to Use Level Billing
Level billing is NOT a good fit for the following situations:
- Projects with hard deadlines where the number of hours worked will tend to skyrocket to meet those deadlines (value pricing or straight hourly pricing are both better fits)
- Projects in maintenance mode, where you are acting as the local fire department providing on-call tech support and putting out fires (fixing bugs) as they pop up (use-it-or-lose-it retainer pricing is a better fit)
- Recurring projects with clearly defined scope (productized service pricing is a better fit)