The Income Statement (aka Profit & Loss Statement or simply P&L) is critical for understanding the financial performance of your company from an operational standpoint. The economic model of your company that I believe is so important (and which makes budgets much less important) should be based on the P&L. At the most abstract level, the P&L has three major sections: Income, Cost of Sales, and Expenses. While the meaning of each section depends on the industry you’re in and the nature of your business, the classical definition is:
- Income – the money you receive for your goods or services.
- Cost of Sales – the cost of producing your goods or services.
- Expenses – the money you spend operating your business that’s not directly tied to producing goods and services.
How should a software development businesses organize the P&L? Income and Expenses match up to the classical usage pretty well. Income is what clients pay you for your work; Expenses are things like rent, utilities and office supplies. But what is the Cost of Sales for a service business?
One thing it’s not, but it sounds an awful lot like, is the cost of selling your service, i.e. a salesperson’s salary, travel, advertising, plane tickets, marketing materials, tradeshow booths, etc. When you’re educating your employees about the economics of your company this potential confusion is a good one to point out.
The traditional three sections of the P&L were created for product companies. If you make widgets, the Cost of Sales is the raw material and labor that goes into making your widgets. If you make software, the material cost is nothing and the labor to “produce” it corresponds to a button push in your IDE, an order for more CDs, or execution of a deployment script — it’s essentially free. Of course to get to the point where you’re able to manufacture your software may require hundreds or thousands of hours of design, development and testing.
The “cost of producing your service” for the software development firms I’m talking about with GNB is primarily the cost of people. The wages, benefits, and payroll taxes for your designers, developers, testers and project managers are what it costs you to create the software you sell to your customers. To do more work requires more of these people, but not necessarily more rent, electricity, paperclips, or administrative support. That’s the defining difference between Cost of Sales and Expenses.
Once your company is over a certain size then you probably have people who support the company but aren’t directly billable on projects. The expense for these people go into Expense, not Cost of Sales. For example, if you’re a 10 person firm with eight makers, one office manager, and one manager/salesperson/dishwasher/marketer, then you’d put the salary and benefits of the office manager into Expense, not Cost of Sales. Hiring a bookkeeper wouldn’t increase your capacity for projects, so he’d be in Expense. And hiring a ninth developer probably wouldn’t require you to hire another office manager, but would let you do more client work, so they’d be in Cost of Sales.
There are some other things I’ve always tracked in Cost of Sales. These are expenses that are associated directly with the makers in my firm such as laptops and professional development (conference travel and registration).
Since we use a “doer/seller” model I had to wrestle with people like me who were partially billable and partially internal. I solved that problem by using our time tracking system to measure how my time was split between customer projects and internal work. Then I’d allocate the corresponding portions of my compensation to either Cost of Sales or Expense. Making an adjustment each month was pretty simple and more than adequately accurate.
While this system of arranging the P&L and assigning expenses is logical and worked pretty well for me for nearly 10 years, there were some shortcomings. We’ve recently made some changes to address these shortcomings. I’ll write about those in a few weeks after our first quarterly accounting review when I know more how they’ve worked.
- What identifying a company architecture did for us - July 19, 2017
- A milestone reached in Atomic’s goal to employ more women - June 7, 2017
- Firing people: feelings, perspectives, and practical advice - April 9, 2017
- Succeeding with outside leadership hires - March 31, 2017
- Expecting perfect understanding from your writing is a leadership pitfall - January 22, 2017