Update: 20 July 2017
Per an email request, here’s the current version of the spreadsheet we use to make the quarterly accrual adjustments for revenue and salaries in our books.
Example quarterly accrual adjustments
We track Atomic’s financial results on a quarterly basis. This seems to be the right frequency, neither too frenetic (monthly) nor too inattentive (yearly). I don’t believe traditional budgeting is the best way to run our business. Instead, I have a detailed financial model of the company and I compare our results to that model periodically to validate it. That makes consistent and accurate measurement of financial results very important. I see a strong analogy to our project management practices: favor dynamic measurement over up-front, static planning.
Accurately measuring financial results is complicated by the irregularity of the Gregorian calendar system. Everybody who’s ever had to do anything financial notices really quickly that while 52 is evenly divisible by four to get a theoretically consistent 13 weeks per quarter, the calendar periods of the quarters don’t all have the same number of work days. Here they are for 2011:
Quarter | Date Range | Days |
---|---|---|
Q1 | January 1 – March 31 | 64 |
Q2 | April 1 – June 30 | 65 |
Q3 | July 1 – September 30 | 66 |
Q4 | October 1 – December 31 | 65 |
A variance of one day in 65 or so doesn’t matter that much, even for mildly data obsessed people like me. What turns out to be much more significant, however, is that the calendar quarters aren’t aligned consistently with weekdays. Here are the days that 2011 quarters start and stop on:
Quarter | Start day | End day |
---|---|---|
Q1 | Saturday | Thursday |
Q2 | Friday | Thursday |
Q3 | Friday | Friday |
Q4 | Saturday | Saturday |
And of course the following year will have a completely different set of calendar start/stop days.
This movement of quarter start and stop dates through the weekdays happens because the one definition of a quarter, as one fourth of a 52 week year and hence an even 13 weeks, is at odds with its calendar definition in terms of months, since 52 weeks don’t divide evenly by 12 months. (Of course, even if we fixed this problem by defining 13 months, with a nice round 4 weeks in each of them, there would still be the little problem that a year at 365 days isn’t evenly divisible by seven. Oh, and it’s really more like 365.25 days/year, hence the kludge of leap days.)
The problem arises with the fact that our business processes are aligned with weekdays. Specifically, we pay people every two weeks, on Thursdays, and we invoice customers every two weeks, though not always on the same day. This means some quarters have six payrolls, and some have seven. Some quarters have six invoice cycles, and some have seven. Worse yet, since payroll and invoicing aren’t themselves perfectly aligned, some quarters may get an extra payroll, but not an extra invoicing period, or vice versa.
You see this clearly when you juxtapose invoice and payroll periods with quarterly calendar boundaries. The diagram below shows how the second and third quarters of 2011 split payroll and invoicing period 14 roughly in the middle. Period 13 falls entirely in Q2, period 15 falls entirely in Q3, but period 14 is shared.
If you use accrual accounting then you book revenue when you send the invoice, not when you receive the cash. In general this method results in more predictable financial results since you control the sending of invoices, but not necessarily when your customers pay you. Accrual, versus cash accounting, helps, but it isn’t enough to make for accurate financial measurements. With accrual accounting and quarterly reporting you still have the problem of work done in one quarter not being invoiced or covered on payroll until the following quarter.
The second diagram shrinks the time scale to days and covers only period 14. As you can see, four work days of period 14 actually belong to Q2. Yet the work done during those four days won’t be booked until well into Q3. When you run a report on the revenue for Q2 you do so by date range, with an end date of 6/30, those four days of revenue won’t be included. With quarterly reporting, Q2 will be artificially low on revenue and Q3 will be correspondingly and artificially high on revenue.
You might be thinking at this point, “so what – when Q3 closes it’ll give up some revenue to Q4 but what it gained from Q2 will balance things out.” And you’d be partially right. But we found at a quarterly frequency the distortion of financial results can still be significant. In our case, it caused us to waste time chasing bogus discrepancies with our model and skewed our profit sharing calculations. For example, before we began adjusting for calendar vagaries, we’d spend time trying to answer questions like,
Why is cost of production up when we didn’t have new hires?
Why are utilization and hours the same, but revenue is down compared to last quarter?
How can our revenue per billable hour be so high?
The problem is actually even more complicated than I’ve described here, since our invoicing and payroll periods don’t exactly line up with each other as I’ve shown in the simplified diagrams. The worst case distortion happens when a quarterly calendar boundary happens to fall exactly in between the invoicing and payroll transactions. Keep in mind, the delay between a period closing and the corresponding financial transactions taking place can mean that more than a single period is affected. This delay further amplifies the distortion.
The graph below shows the impact of properly accounting for revenue and wages on Atomic’s cash quarterly employee bonus for 2010. Our employee bonus is driven off profit for the quarter. Since quarterly profit is directly dependent on quarterly revenue, the distortions I’ve described in quarterly revenue reporting directly impact the bonus calculation. When revenue is shifted without corresponding wages, the impact on profit is all the more dramatic. The blue line shows the bonus before we started adjusting revenue and wages for the quarterly boundaries effect; the red line is the same data after adjustment. The sum of the employee bonus over the year is the same in both cases, but the blue line is clearly more variable, and that variation is arbitrary, not the result of business conditions. We pay cash bonus quarterly because we believe it’s a good idea to couple some of an employee’s compensation directly to the results the business achieved recently. Profit that varies arbitrarily undermines this goal. The variability is also a problem if your employee base changes over the course of the year, as some people may get more or less than is warranted based on the time they worked for the company.
As with any edge effect phenomenon, the longer the time period and the fewer the edges, the less significant the problem. If you only do yearly reporting you’ll have the same problem, but it won’t matter as much. But with this strategy you’ll only be able to compare against your economic model of the company once a year, and you’ll have a profit sharing scheme that’s de-coupled from recent accomplishments of the business. In my opinion, neither of these is a good idea.
Accountants have terms for the problem I’ve described. Work-in-process (WIP) and accrued wages are what they call the revenue you’ve earned in a quarter but not billed, and the wages you owe, but haven’t yet paid. WIP potentially has other components, like the work you’ve done and not invoiced for whatever reason. In our case, we try to invoice everything we’ve done every period, so this is usually small enough to ignore.
The slightly embarrassing aspect of this significant and strangely complex problem (oh, did I mention the impact of holidays falling around quarter boundaries, and how that impacts revenue differently than accrued wage?) is that I lived with it for many years not fully appreciating its effects. It was only in 2010, when I had a pair to work with, that Mike Marsiglia and I finally got to the bottom of it and figured out how to solve it.
Once we thoroughly understood the problem the solution was easy to implement. We made a simple spreadsheet that determines the number of days that span the quarter boundary and describes the adjusting journal entries for us to properly allocate WIP and accrued wages to the quarter being closed. We then make “mirror image” adjusting journal entries on the first day of the next quarter to reverse the affect of the first set of journal entries.
The spreadsheet considers how many periods are affected (one or two), takes into account holidays, then determines how many days of the closing quarter are affected by the boundary spanning problem. The ratio of the number of days that need to be shifted and the total days in the periods affected is then applied to the total revenue and payroll for the affected periods. This proportional allocation isn’t totally accurate, but it’s very easy to do and close enough for our reporting purposes.
The results have been gratifying, and take only a few minutes each quarter to implement. Since we’ve been correcting our results in this way, we’ve noticed:
- Our results better line up with our guts and our economic model.
- Metrics such as revenue per billable hour and profit margin are more stable.
- Profit sharing doesn’t swing as wildly as it had previously, so employee bonuses are tied to actual business results.
- We can close the quarter more quickly since we don’t have to chase down the source of misleading variance in the metrics we track.
I’m sure there are other ways of solving this problem. Ours is accurate enough, easy to implement, and simple to understand. I’d be happy to share the spreadsheet if anyone’s interested.
- Attention: Spending Your Most Valuable Currency - February 10, 2022
- Slicing the Revenue Pie in a Multi-Stakeholder Company - July 30, 2021
- Commercial versus Existential Purpose - July 19, 2021
- How I Misunderstood Mentorship and Benefited Anyway - June 16, 2021
- Sabbath Sundays and Slow Mondays - June 4, 2021
solidsoftwaresolution
November 8, 2011A lot of companies are using revenue per employee ratio. Did you see a difference in that metric after you implemented your model?