BUSI 170 - Financial Analysis for Leaders (Section 2.1)
August 19, 2026
You buy a coffee. You hand your card to the barista, you take the cup, you walk over to a table. Somewhere in there the shop earned that money. Where?
As soon as they took the card? Do they have to hand you the cup? Do you have to drink it? Half of it? All of this is happening in seconds, so it feels like a strange question. It turns out the answer is that when they have given you the coffee, they have provided the good, they have done their obligation. They tend to be paid right away, so you hand over the coffee, they give you cash or a card, the transaction is done, and that is when the money is earned. Whatever it cost to provide the cup and the coffee gets recognized at that same moment.
That is revenue recognition: saying that this has actually happened. Revenue is the money we get from customers when we either give them a product or provide a service, and recognition is the moment we say we earned it. That sounds like something you would just see happen. It is less clear than you might think.
This can seem like a lot of detail. As long as the money comes in eventually, why get buried in it?
Because we are not only keeping score. We look at financial statements as a measure of performance - we want to know how well you did in this particular period. And we want to know what kind of expenses it took to generate revenues like this. That is what gives us an idea of how well the business is performing. Maybe you want to buy this business and you need to know.
Once things start getting mismatched, we break the relationship between what you have to spend and what you achieve for it, and the whole information value of the statement becomes a lot less valuable.
Without rules, businesses could say whatever they want, or be creative with it, and mislead on their financial statements. Nobody would have a precise idea of what is going on. A lot of people need a clear picture: investors, regulators, and the people running the business.
Two things.
You have to actually deliver the goods or services. You have to fulfill your part of the deal.
The expectation of payment has to be reasonable. Notice that I did not say the payment has to have happened. You should reasonably expect to be paid.
Both of those can fail, and it is worth seeing what failure looks like.
Sometimes you are not making a delivery even though you wanted to. Say you have a construction project and there has been bad weather, or a union strike. What you thought you were going to do, you are not going to actually deliver. If you have not done it yet, it is not right to recognize that you have and be rewarded with the revenue. Even if you get the check. Even if they give you the cash. The delay means you have not delivered, or have not delivered that portion, and so it should not be recognized.
The other condition fails differently. Why would you recognize revenue if you think your customer is going bankrupt? They are probably not going to pay you. It is disingenuous to recognize that revenue and say we are probably going to get this.
It is true that you fulfilled your end of the bargain. It is true that it is not your fault. But when you talk to your managers or investors about the financial position of the business, it is not in good line to say you are going to get something when you know you are not. If you are not sure what they will pay, or whether they will pay at all, it is irresponsible to recognize revenue when the entire idea of that money coming in is in doubt.
The most aggressive revenue recognition I have heard about had a bit of a scam to it.
There was a famous case where a company sold outdoor equipment - pool and lawn goods, the sort of thing nobody buys in winter. They wanted to show higher sales. So the pitch to the customer went: I know you are not going to buy this in the wintertime, but I know you will buy it later in the summer. What if I sold it to you now, so I can say I already made the sale, rather than wait until summer? Then I look good now, for my boss.
The customer said he would buy the equipment, but he had no place to store it. That is okay, came the answer. You say you buy it, and we will store it. We will keep it in our warehouse, put your name on it, and when summer comes we will give it to you.
This violated revenue recognition, and it was later flagged as a violation and became a big controversy. It was too aggressive because they never actually gave the goods away. The equipment was still inside the warehouse. Until they hand it over and the customer takes possession, neither of which had happened here, there was nothing but an agreement.
That is basically cheating. Promises are not the same thing as actually making money.
The matching principle says we want these two things connected in the same period. Revenues minus expenses equals profits, and we want the pair put together: the revenue reported alongside the expenses that were required to generate it.
A bakery reports revenue from selling cupcakes. It also has to buy ingredients, pay labor, pay rent. What we want is for the revenue from those cupcakes and all the cost of the ingredients, labor and rent that went into building them to be matched in the same period. Report the revenue and the cost at the same time. That is matching.
Watch what happens when it breaks.
Say you sell $100,000 in services in December, and you delay recognizing $80,000 in expenses until January. Look at the profit and loss statement for December and it is going to look awesome. A lot of money came in. What you do not see is that there were expenses incurred to earn it, and they are nowhere, because they do not get reported until January. That is a misstatement.
Now run it the other way. Recognize the expenses in December but hold the revenue until the check arrives in January. December looks like a terrible month. All of these expenses and nothing to show for it - except there is something to show for it. It just has not arrived yet.
Both are the same mix-up. If we are going to recognize the revenue, we want to recognize the revenue and the expenses at the same time.
Students often reach for a conservative instinct here. As long as you recognize revenue later rather than earlier, or expenses earlier rather than later, surely that is the cautious choice.
It is bad in both directions, for the same reason. We want to know what happened in this period, and being wrong is being wrong. Take revenue later and today is understated because you pushed things out. Recognize an expense now that belonged later and tomorrow looks rosier than it should have.
Recognizing revenue too early brings performance forward. It inflates, it makes you look like you are doing better than you are, and it creates a false sense of doing well. Delaying it hides issues and makes future performance seem stronger than it is. Either way it is distortion.
The bigger wrong is when we do not match things up. Push revenues out and pull expenses artificially forward, and today’s profitability does not look good while tomorrow looks tremendous. Then we start thinking something about that month was special. Imagine there was a specific person working on it, and we start drawing conclusions about them, when in fact it was an accounting change.
You should not be too early. You should not be too late. And you have to respect the matching principle.
To be tactical about it, here is the sequence.
Most of what makes revenue recognition hard is that step five is easy to describe and hard to observe. Three shapes of business make it hard in three different ways.
Imagine a subscription. A software company sells $1,200 of annual subscriptions starting in October. At calendar year end, December 31, what do you recognize?
Only $300. The other $900 is deferred.
This is an annual contract, so we are providing the benefit throughout the year. Spread evenly, we earn that revenue over twelve months. October through December is three months, at $100 a month, so $300 is recognized and $900 is not recognized until the following year.
You cannot recognize it up front even though you have all the cash, because you have not done the work yet. You still have to deliver for the next eleven months. Even though you have all the dollars in the first month, you have not done all the work, so you should not take credit for it.
Compare that to a landscaping company that finishes all of its work in November on a $5,000 job, and gets paid in January. Both the revenue and the expenses should be recognized in November, because that is when the work actually occurred and when the obligations were fulfilled, even though the payment comes later.
Those two cases point opposite directions, and that is the point. Cash arriving early does not earn you anything. Cash arriving late does not take anything away.
A construction company is halfway through a two-year project. On a $500,000 contract, it recognizes $250,000.
Report the full revenue up front and you are not done yet - you are overclaiming. Report none of it and you wait a long time, as though you have not done anything, when you have actually done some work. It is partially done. Of the revenue that will be earned, how much have you earned so far? We model that at fifty percent.
There is subjectivity in this. If you are running a project over two years and claiming you are sixty percent done, who says you are sixty percent done? How do we estimate that?
It helps to have paperwork, to have milestones, to decide between you and the person you are working with what sixty percent looks like and what the criteria are, so there is a basis. There is a judgment call here. When things happen over a slow period of time and we want to recognize revenue over time, we need some model for how much is done, and percentage of completion is one of them. We cannot pick whatever is convenient. It is good to have criteria we can measure and validate against.
Milestones are like percentage of completion, except that instead of dividing into percentages we divide into meaningful steps we can look at and say: that is done. Then we verify it, and recognize the revenue associated with it.
If the job is linear it barely matters which you use. We are making 99 widgets, and at 33 widgets we are a third of the way through, so the milestones fall at tidy numbers. But sometimes they do not. Software work has to be designed, then built, then tested, then handed off. Those are discrete steps in time that we can observe and say whether they have happened. Reaching one is a good moment to mark the timing and recognize payment for value delivered.
That is also what makes milestones gameable, which is why they have to be written down in advance rather than agreed to afterward.
Think about pizza delivery. You call, you give them your card, and they start making it. If they recognized the revenue at that moment, they would be claiming something they have not done - they do not fulfill the obligation until you have the pizza in your hands. The customer does not benefit from the pizza until it is delivered.
Your money came ahead of time. They still have to wait until they have actually delivered. Only then can they check off that they have provided their end of the obligation and recognize the money.
It does not matter when the money comes in. It matters when you have gotten your part of the job done.
© 2026 Eric Lin. All rights reserved. This chapter is provided for students in BUSI 170 - please do not repost or redistribute without permission.