Revenue Recognition — 5-Step Model (ASC 606)

Instructor Script

Slide 1: Introduction to Revenue Recognition

Alright team, welcome to QuickFire CPA! Today, we're tackling a beast: Revenue Recognition, specifically ASC 606. Now, I know what you might be thinking, 'Ugh, revenue rec... so many rules!' And you're right, it can seem daunting. But trust me, this is one of the absolute *most critical* topics for the FAR exam, and honestly, for your entire accounting career. Think of it as the heartbeat of the income statement. Get this right, and you're well on your way.

The core idea? We record revenue when we *earn* it by satisfying our promises to the customer, not just when the cash hits our bank account. ASC 606, which rolled out in 2018, standardized this across most industries, making it super important and consistently tested. So, let's break it down together.

Slide 2: Why Revenue Recognition Matters

So, why all the fuss? Well, revenue is arguably the number one metric investors and analysts look at. It drives valuations, stock prices, and lending decisions. Get revenue wrong, and the whole picture of a company's health is skewed. Auditors spend *tons* of time on this because it's a high-risk area for errors or even fraud. And for you? It's guaranteed points on the exam, showing up in both MCQs and simulations. Mastering this isn't just about passing; it's about understanding how businesses truly operate and communicate their performance.

Slide 3: The 5-Step Model: Your Revenue Roadmap

Okay, the good news! ASC 606 gives us a clear, 5-step roadmap. Forget wandering lost in the revenue woods. Just follow these steps. And to make it stick, remember the mnemonic: **COPRA**. Like the snake? No, like the steps! **C**ontract, **O**bligations, **P**rice, **R**evenue Allocation, **A**cknowledge (or Recognize) Revenue. COPRA. Say it with me: COPRA! We'll walk through each step, making sure it's crystal clear.

Slide 4: Step 1: Identify the Contract

First things first, do we even *have* a contract? ASC 606 is specific. We need five criteria met: Both sides agree (approval), we know who does what (rights), we know the payment terms, the deal has a real business purpose (commercial substance), and it's likely we'll actually get paid (collection probable). If any of these are missing, hold your horses – you might not have a contract for revenue recognition purposes yet. Think of it like building a house; you need a solid foundation before you start putting up walls.

Slide 5: Step 1: Example

Let's make Step 1 real. TechGadgets sells 100 phones to RetailMart for $50k. They sign a paper outlining everything: delivery, payment in 30 days, returns. Does this meet our five criteria? Yes! Signed approval? Check. Rights identified (phones for cash)? Check. Payment terms (net 30)? Check. Commercial substance (selling phones is their business)? Check. Collection probable (assuming RetailMart is a good customer)? Check. Boom! We have a contract. We can proceed to Step 2.

Slide 6: Step 2: Identify Performance Obligations

Step 2 is about figuring out exactly what promises we made to the customer. These are called Performance Obligations, or POs. A PO is a promise to transfer a *distinct* good or service. What's 'distinct'? Two things: the customer can benefit from it on its own (or with readily available resources), AND it's separately identifiable from other promises in the contract. Think of it like ordering a combo meal – the burger, fries, and drink are usually distinct items you could buy separately.

Slide 7: Step 2: Example

Imagine SoftwareCo sells a $10k package: software license, installation, 1 year of tech support, and 2 years of updates. Are these all one big promise, or separate POs? We need to apply the 'distinct' test. Can the customer use the license without the installation? Maybe. Can they benefit from support separately? Yes. Updates? Yes. Are these promises distinct within the contract? Likely yes. So, we probably have multiple POs here.

Slide 8: Step 2: Example (Answer)

So, for SoftwareCo, we likely have four separate performance obligations: the license, the installation (if it's complex and specialized, maybe not, but often yes), the tech support, and the software updates. Each represents a distinct promise we need to fulfill and account for separately. This is crucial because we'll allocate the $10,000 price across these POs in Step 4.

Slide 9: Step 2: Practice Question

Quick check! You sell a gadget with a 3-year warranty. The industry standard warranty is just 1 year. How many performance obligations? Think about what's bundled versus what's an extra service.

Slide 10: Step 2: Practice Question Answer

The answer is two! The gadget itself comes with the standard 1-year warranty – that's typically considered part of the product, one PO. But the extra two years? That's an additional service, a separate promise, making it a second performance obligation. We'd need to allocate part of the selling price to that extended warranty service.

Slide 11: Step 3: Determine Transaction Price

Step 3: How much money do we actually expect to get? This is the Transaction Price. It sounds simple, but it can get tricky. We start with the fixed amount, but then we have to consider variable amounts (like bonuses, refunds, rebates), estimate them reliably (using expected value or most likely amount), and potentially *constrain* that estimate if there's too much uncertainty. We also need to adjust for financing components (time value of money if payments are spread out), non-cash payments (fair value), and any payments we make *to* the customer (like slotting fees).

Slide 12: Step 3: Example

Let's say ConsultingFirm charges $100k flat, plus a $20k bonus if they finish early. Historically, they hit the bonus 60% of the time. What's the transaction price we should use for our revenue calculations?

Slide 13: Step 3: Example (Answer)

We take the fixed $100k and add the *expected value* of the variable bonus. Expected value = ($20,000 * 60% probability) + ($0 * 40% probability) = $12,000. So, the total transaction price is $100,000 + $12,000 = $112,000. Remember my little tip for variable consideration: **EML**. **E**stimate it, **M**ake sure it's not overly optimistic (constrain it), and know you might need to adjust it **L**ater.

Slide 14: Step 4: Allocate Transaction Price

Okay, we have our total price (Step 3) and our list of promises (Step 2). Now, Step 4 is connecting them: allocating that total price to each separate performance obligation. How? Based on their relative *standalone selling prices* (SSP). This is the price you'd charge for that item if you sold it separately. If you don't have an SSP, you have to estimate it using market data, cost-plus-margin, or, as a last resort, the residual approach.

Slide 15: Step 4: Example

TechCo sells a bundle for $1,200. Separately, the hardware is $800, the software license is $500, and training is $300. How do we split up that $1,200 bundle price among the three items?

Slide 16: Step 4: Example (Answer)

First, find the total SSP: $800 + $500 + $300 = $1,600. Then, allocate the $1,200 proportionally. Hardware gets $1,200 * ($800/$1,600) = $600. Software gets $1,200 * ($500/$1,600) = $375. Training gets $1,200 * ($300/$1,600) = $225. Notice $600 + $375 + $225 = $1,200. Perfect allocation! My mnemonic here is **RAPS**: Allocate based on **R**elative SSPs, **A**llocate the total price, **P**roportionally, and the **S**um must match the total.

Slide 17: Step 5: Recognize Revenue

The final step! When do we actually book the revenue allocated to each PO? ASC 606 says we recognize revenue when (or as) we satisfy the performance obligation by transferring control of the good or service to the customer. This can happen either *over time* or at a *point in time*.

Revenue is recognized *over time* if ANY of these three criteria are met: 1) The customer gets and uses the benefits as we perform (like a cleaning service). 2) We create or enhance an asset the customer controls as we build it (like construction on their land). 3) Our work doesn't create an asset with an alternative use to us, AND we have the right to get paid for work done so far (like building highly customized equipment).

If none of those apply, we recognize revenue at the *point in time* when control transfers (usually upon delivery or completion).

Slide 18: Step 5: Example

Think about building a custom house on the customer's land. They control the land and the partially built house. So, revenue is recognized *over time* as construction progresses (using methods like percentage-of-completion). Now think about selling a standard TV from a store. Control transfers when the customer walks out with the TV. Revenue is recognized at that *point in time*.

Slide 19: Step 5: Practice Question

Okay, scenario time. SoftwareCo is building *custom* software for one specific client. If the client cancels, SoftwareCo gets paid for work done. The software is useless to anyone else. When does SoftwareCo recognize revenue?

Slide 20: Step 5: Practice Question Answer

The answer is A) Over time! Why? Because criterion #3 for over-time recognition is met: the software has no alternative use to SoftwareCo, AND they have an enforceable right to payment for performance completed to date. Even though the software isn't delivered until the end, revenue is earned and recognized as the work is performed.

Slide 21: Common Exam Traps

Watch out for these common pitfalls on the exam! Missing a performance obligation (like that extended warranty). Messing up the variable consideration estimate or constraint. Allocating the price incorrectly (not using relative SSPs). Choosing the wrong timing for recognition (over time vs. point in time). Also, don't forget about contract costs – costs to obtain or fulfill a contract might need to be capitalized, not expensed immediately.

Slide 22: Revenue Recognition Mnemonic: "COPRA"

Let's bring it all back to **COPRA**: **C**ontract (gotta have one), **O**bligations (what are the promises?), **P**rice (how much?), **R**evenue Allocation (split the price), **A**cknowledge/Recognize (when?). Follow these steps systematically, and you'll nail revenue recognition questions.

Slide 23: Quick Review

So, to recap: 5 steps. Identify the contract using the 5 criteria. Identify the distinct performance obligations. Determine the transaction price, considering variable amounts. Allocate that price based on standalone selling prices. Recognize revenue for each obligation when (or as) it's satisfied – over time or at a point in time. Got it?

Slide 24: Final Practice Question

One last check. Equipment ($80k SSP) and 2 years of maintenance ($20k/year SSP) sold together for $100k upfront. How much revenue for the *equipment* when it's delivered?

Slide 25: Final Practice Question Answer

The answer is $66,667! We need to allocate the $100k transaction price. Total SSP = $80k (equip) + $20k*2 (maint) = $120k. Equipment's share = $100k * ($80k / $120k) = $66,667. The remaining $33,333 is allocated to maintenance and recognized over the 2-year service period. Always use those relative SSPs for allocation!

Slide 26: Thank You!

That's the 5-step model! Remember COPRA, practice identifying POs, allocating the price, and determining the timing. This is a huge topic, so hit those MCQs and simulations hard. Thanks for joining this QuickFire session!

Practice Questions