Hello. Welcome back!
Many folks have asked me to explain how I create effective cash flow profit models for clients; the ones that predict seemingly ridiculous things such as how increasing accounting profit can actually destroy cash profit. I thought I'd cover it at a high level and let questions and requests dictate where to go, if anywhere, from there.
Described here is the approach I've used for the past 20+ years or so. I started developing the concept in the '90s in my consulting work. Our company had a value proposition: "We will make you more money or you don't pay." Improving accounting data did not ensure clients made more money, so we needed a better tool. I first published these ideas in their entirety around 2000 when I wrote, Explicit Cost Dynamics. The approach I use, called Operations & Cash Flow Modeling, or OCM, is the only one I have experience with. It's the one I use with clients seeking to improve cash vs accounting profit. Others may have different or better ways. I'd love to learn more if you do.
Disclaimer: In blog posts, presentations, and social media discussions, folks want to ask detailed questions about specific situations and make determinations about what this approach can and cannot do vis-à-vis cost accounting. What I am sharing is foundational information about creating a mathematical cash model for a company, not the details of OCM. A 2000 word blog will not solve all your accounting woes or answer all your challenges. If you want to learn more, reach out to me. I'd be happy to help, answer, or debate any time.
When I help companies develop cash flow models, there are five steps involved:
Establish the notion, cash modeling isn't accounting
Create fundamental cash model
Establish the scope
Understand the cash dynamics
Focus on right company issues
Cash modeling isn't accounting
For some reason, folks call all things money related accounting. They aren't. In business, you buy things, you consume them, and you create output (Figure 1). Decisions are made, capacity is bought, money is spent, business activities occur, and output of all sorts is created. This all happens before, and independently of accounting (Figure 2). Accounting is used to create a perspective of what happened for reporting or managerial purposes.
Figure 1: What I call the Operations-Cash (OC) Domain focuses on modeling the operational components of the business. When you model operations, there is an inherent cash component involved. When you pay someone, cash is involved. When you rent space or lease equipment, there is cash involved. What you bought, what it costs, and when you pay for it is clear. Additionally, data about what you did with what you bought is also available, allowing you to construct output, efficiency, and productivity metrics and tie them directly to business and cash transactions.
Figure 2: Accounting attempts to offer explanations of what happened in the OC Domain. Accounting algorithms take data from the OC Domain and transforms them to the Accounting Domain. Here's an example. In the OC Domain, a person worked eight hours, was paid $120, and made 12 sales calls. The data are clear and unambiguous. Determining a cost per call is an Accounting Domain, not OC Domain issue. Operations and cash data are transformed into the Accounting Domain using data and assumptions. For instance, if you assume an average cost per call can be calculated by dividing $120 by 12 calls, you end up with $10/call. Another approach may consider the notion she only spent half her time making calls, so the cost per call is $5 not $10.
Accounting takes raw operational data and transforms it, based on rules and opinions, into one of many possible descriptions of what happened. There are rules, for instance, about revenue recognition and depreciation. There are opinions about when to recognize revenue and the method chosen to depreciate. There is also opinion related to scope (Include warehousing and overhead in product costs?) and method chosen to calculate costs (Activity based? Average? Standard?).
If your product cost is $25/unit cash, who are you giving that $25 to every time you complete a unit?
To model cash accurately, you must model it before accounting touches it. Once accounting touches it, the operations and cash data are transformed from what I call the Operations-Cash (OC) Domain to the Accounting Domain where it is no longer cash. Recognizing revenue you haven't received isn't cash. Neither are your calculated product costs. If you don't believe me, answer this question. If your product cost is $25/unit cash, who are you giving that $25 to every time you complete a unit? If your revenue and costs aren't cash, neither are your profits.
That would be like Glock focusing on making a better musket.
When I build cash models, the purpose isn't to recreate cost accounting or to build another cost model. That would be like Glock focusing on making a better musket. Cost accounting is 1800s technology, and I believe it does not offer a fraction of the data and information that properly designed cash models offer. My cash models are built entirely in the OC Domain and exist independently of accounting.
Ultimately, cash profit modeling is about understanding the levels of cash the organization has, what affects it, when, and why. It does not concern itself with trying to calculate costs and variances, inventory valuations, or when to recognize revenue. Revenue is recognized when it comes into the company. Costs are incurred when they leave the company. Inventory value is completely useless metric in the OC Domain.
This also isn't cash accounting. To calculate a product cost or an inventory value, for instance, an opinion-based transformation from the OC Domain to the Accounting Domain must still occur. To determine a depreciation schedule, an opinion must be acted upon. These are decisions that don't directly affect the flow of cash. They're answers to Accounting Domain questions.
OCM describes what has, and is happening before anything hits accounting. Doing so, you haven't lost any data. The transformation input data haven't changed after transformation into the Accounting Domain. Just the interpretation of what happened from an accounting perspective - the information calculated from the data - has changed (Figure 3). Ultimately, though, one must ask if the accounting information is useful from a managerial perspective at all.
Figure 3: The data used for the transformation from the OC Domain to the Accounting Domain don't change. The customer service rep still made 12 calls before (point A) and after (point B) the transformation. What is created as a result of the transformation is accounting data; each call costs $10 or $5 or something else based on the transformation algorithms.
Cash is money. To understand cash dynamics, you need to know how much money you start with, a timeframe (week, month, quarter, year), and what I call cash rates - the flow of money in and out during that timeframe (Figure 4). For instance, today, I started with $11. During the day, I made $5 (cash revenue rate in) and I spent $6 (cash cost rate out). At the end of the day, I ended up with $10.
Figure 4: The amount of money you have at any given point is determined by what you started with at the beginning of any given analysis period, the money that came in ($-revenue/time), and left ($-cash costs/time) during the period.
Consider the following with accounting. I sell you a pen in 2017 for $50. I can recognize the $50 even though I've allowed you to pay me in 2018 (revenue rate = $0 for 2017). Additionally, I could have spent money making or buying the pen in 2016, so cash costs would have flowed in 2016 (cost rate = $0 for 2017). Additionally, if I made the pen, the accounting value of that pen is an opinion. Which costing technique was used? What approach was used for inventory value - LIFO? FIFO? In the end, none of these models what happened from a cash perspective. The Accounting Domain allows you to calculate a profit in 2017 when no money flowed. None. How, again, is profit related to money if you can do this?
This flies in the face of profit centers
Establish the scope
When I develop cash models, I look at the entire company rather than a portion of the company. The purpose is to model whether the company is making money, not whether a division or department is. By doing this, cash is being modeled on a macro scale rather than a micro scale. Micro modeling leads to bad decision making. For instance, if an internal group charges a department $7.50 for a service that the department can buy externally for $5.00, from a departmental perspective, it makes sense to go outside. However, from an organizational perspective, the company ends up spending more money. The cost rate includes the cash of having and maintaining the support department per unit time, and the cash of paying the outside vendor.
This flies in the face of profit centers. They make no sense in the OC Domain. There are ways to get more accurate information to determine if a capability is valuable or not inside the company without creating incentives for managers to make bad decisions.
The cash dynamics are not only what cause the model's data to change, but how and why. In other words, what are the factors that do and don't affect the revenue and cost rate. For instance, when you receive money from a sale, your revenue rate changes. Recognizing revenue in the Accounting Domain doesn't mean your revenue rate has changed in the OC Domain. Similarly, equipment payments affect the cash rate. The purchase, itself, does not unless the payment coincides with the purchase.
If you make someone more efficient and claim a $10K cost savings, you must ask the question, "When and why are we going to spend 10K fewer dollars?"
In your cash model, it's important to make sure you consider, and model, material factors that relate to revenue rate and cash rate. Doing so will do the following very effectively:
It will let you know when, how, and why you did or you didn't make money in a period
Force you to be diligent about things such as contractural agreements with both vendors and clients, the effect of overtime and managing labor hours, and the timing of expensive IT and equipment upgrades
It will force discipline when it comes to money conversations. If an investment will lower costs, when, how, and why will the cost rate decrease? If you make someone more efficient and claim a $10K cost savings, you must ask the question, "When and why are we going to spend 10K fewer dollars?"
The last point captures the craziness and fake money savings that management consultants, IT consultants, and lots of Lean-Six people promise, but the company never sees. The next time a consultant promises you big savings, consider this model and ask them to justify, specifically, how you will be spending $4M fewer dollars as a result of their invoice management software. If they cannot tell you how you will spend $4M fewer dollars, and if all they focus on is the cost per invoice, better information, fewer touches etc, the savings are bogus.
If you want to reduce costs and improve cash profit, the ONLY way to do that is to spend less money
Focus on right operational information
Once you understand the cash dynamics and the factors that affect them, look to model the scenario operationally. For instance, take someone's salary. You pay them $240 per day. That is the cash out. For that $240, you get eight hours. Let's say in that eight hours, they create client reports.
If you want to reduce costs and improve cash profit, the ONLY way to do that is to spend less money and this happens from managing in the OC Domain. If they create four client reports, you may be tempted to say each report costs $60 (Accounting Domain). However, there is no $60 transaction that affects cost rate whenever they write a report, so there is no cash effect. Likewise, your Lean-Six team may be tempted to say they've saved $20 per report by eliminating waste allowing six ($40) versus four reports ($60). However, again, increasing what happens in the time you purchased doesn't affect what you paid for that time (Figure 5). Things that translate into positive results in the Accounting Domain don't necessarily translate into positive results in the OC Domain. I regularly see companies that make decisions in the Accounting Domain that kill their cash profitability. In fact, it's so bad, I created an offering to help companies address it.
Figure 5: In the OC Domain, output and the cost of capacity are independent. What you pay to rent space is truly independent of what goes on in that space. Similarly, labor costs in the OC Domain doesn't change with output. These costs only change with how much you buy and/or what you pay for each unit you purchased.
All of this is really operational data. You received X reports for the $240 you paid and the eight hours they worked. If you get more output, you're more efficient, but you haven't directly saved money. Again, the only way you save money is to change the rate of money leaving your company.
All of your operations can be modeled in the OC Domain. This creates alignment between operations (resources we have, what they do, how we use them, and what they created) and accounting (what we spent, output created, value of resources consumed). Accounting can't do this. Ask yourself, if this widget costs $2.73, what do I know about it? Do I know who made it? How efficiently and effectively they did so? What else they made? No. You really know little or nothing about how you got to $2.73.
I hope this was helpful. Please reach out to me with questions. I look forward to your feedback. Thank you for your comments, e-mails, and texts related to the other blog posts. Make sure you follow me on Facebook and Twitter to get the latest updates!
For more information about these concepts, feel free to grab a copy of Lies, Damned Lies, and Cost Accounting.