I am a military officer with upcoming interviews at both Bain and McKinsey and this helps a ton.
Going over the profit/loss framework I wondered something--what about # of units produced (as opposed to sold) in the cost side of the equation?
I mean, you have Revenue and Cost both broken down by # of units sold. But doesnt that assume the company sells everything it produces?
What if revenue per unit went way up, cost/unit went way down, # of units sold stayed the same from past years, but this year the company decided to make 200% more of the product expecting an increased demand--but only sold its usual amount.
Wouldn't the cost incurred of producing the extra inventory weigh on the company's bottom line? Or, am I just messing up basic accounting principles?
Is the cost of producing unsold merchandise or carrying large amounts of inventory not associated with profits in the traditional accounting sense?
Forgive me if my question is elementary--I am an engineer with no business experience.
You raise in insightful question... in the interview process, generally we simplify the process to assume the two are the same.
In real life, if we had a qualitative reason to believe production doesn't equal sales, then we would probably calculate those separately.
Financial accounting (what you need to show to wall street) counts costs for goods produced but not yet sold, as "inventory" which is technically an asset because it has some unrealized worth.
Managerial accounting - business operators, think in terms of cash. So they think more in terms of total production cost divided by units sold which encompasses the scenario you describe (even if the terminology is a little inaccurate).
If you had some reason to suggest a hypothesis that the scenario you describe is happening during a case interview, you would want to ditch the profit framework breakdown I've used in my handout and used a different type of break down such as:
cost = overhead cost + total production cost
total production cost = produced and sold + produced but not sold
And do a break down that way instead. My frameworks include common ways to segment numbers, but it is not dogma... you have to adapt as you go depending on the specifics of the case.