It seems as if everything has gotten “smarter” these days, even our cars! Some vehicles now need software updates over time and these updates are frequently included in the price of the vehicle. How does the car retailer account for these future updates under ASC 606, Revenue from Contracts with Customers? This question was posed to Chris Brundrett and me in the classroom at the end of 2022 while we were teaching a revenue recognition course. It’s an interesting one! This post will walk the example question scenario through the 5-step revenue recognition model.
ASC 606: 5-step model
Before we dive into the question specifics, let’s refresh the basics of revenue recognition under U.S. GAAP. The core principle found within ASC 606 is that an entity recognizes revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.
Under ASC 606 (and IFRS 15), entities apply a five-step model to determine when to recognize revenue and at what amount.
Looking for more background information on revenue recognition in accordance with U.S. GAAP? Check out our CPE-eligible, e-Learning course (1.0 CPE) Revenue: Overview of ASC 606.
Software updates and revenue recognition
Let’s get back to our classroom question… Tesla was the example used in the question. Tesla vehicles require periodic software updates to “add new features and enhance existing ones over Wi-Fi” according to its website. Tesla’s website also explains that for cars with the full self-driving capability option, “as these features evolve, your car will be continuously upgraded through over-the-air software updates.” The question posed in the classroom was how does Tesla recognize revenue associated with car sales and these software updates? Neither Chris nor I knew exactly how Tesla recognized revenue on these car sales, so we worked it through the 5-step model in the classroom together. (Note that Tesla cars also include supercharging services and internet connectivity, but those weren’t brought up in the classroom question and are left out of this discussion too for simplicity purposes).
Step 1: Identify a contract
This step was pretty easy. A contract exists because the customer is purchasing the vehicle and Tesla vehicles include the software updates at no additional charge (per their website). Step 1 is often an overlooked step when it comes to many entities!
Check out our course on Step 1 to learn why identifying if a contract exists can be quite tricky!
Step 2: Identify performance obligations
Now that we have a contract, in Step 2 we need to identify performance obligations. A “performance obligation” is the unit of account for revenue recognition. Entities are required to assess, at contract inception, the goods or services provided in the contract and identify performance obligations that are distinct. To be “distinct” two criteria must be met, if they are both not met, then the performance obligation is combined with another performance obligation until a bundle of goods or services is distinct. The two criteria that must be met are:
- Capable of being distinct: The customer can benefit from the good or service either on its own or together with other resources that are readily available to the customer
- Distinct within the context of the contract: The entity’s promise to transfer the good or service to the customer is separately identifiable from other promises in the contract
The car itself definitely meets both of the criteria; however, the software updates take a bit more analysis.
Single performance obligation logic
At first glance you may think that this contract contains a single performance obligation because although the car and the software updates are both distinct, the software updates can’t be used on their own (what would we be updating if we don’t have the car?) and thus wouldn’t benefit the customer. However, if we dive deeper into ASC 606, the conclusion changes...
Two performance obligations logic
Above, for the first criterion, the software updates were considered to have no “standalone value” unless the customer has a Tesla. However, ASC 606 explains that a customer can benefit from a service if the service could be used in conjunction with other readily available resources, including goods that the entity will have already transferred to the customer under the contract (e.g., the car) [ASC 606-10-25-20]. Based on this information, the first criterion would be met since the software updates would have value to the customer who received the car as part of the contract.
The second criterion requires determination if the service is distinct within the context of the contract. Without seeing the actual contract, we do not know if the software updates are explicitly identified in the contract; however, based on a quick live chat on Tesla’s website, I was informed that the total purchase price includes both the warranty and the software updates. The service does not need to be explicitly identified in the contract. If the customer has a valid expectation that the entity will provide a good or service, then a constructive performance obligation can also be distinct.
With respect to the warranty, since the warranty is an assurance-type warranty, included in the contract, and not sold separately, Tesla would utilize the guidance found in ASC 460-10 related to product warranties.
Ultimately, this would result in two performance obligations: the car itself and the software updates; however, as you can see above, I think there could be a case for someone to argue only one performance obligation (especially if they had more concrete details on the contract terms)!
As you can see, determining performance obligations isn’t always straightforward. Advance your performance obligation knowledge via our course dedicated to Step 2!
Step 3: Determine the transaction price
The transaction price is the amount of consideration to which an entity expects to be entitled in exchange for transferring promised goods or services to a customer. In our example, Tesla would need to determine the impacts of any rebates, discounts, right of return,
While our example scenario doesn’t dive into concerns of variable amounts, significant financing arrangements, or non-cash consideration, these are all critical in determining the transaction price. Our course on Step 3 covers these and more!
Step 4: Allocate the transaction price
The transaction price determined in Step 3 needs to be allocated to performance obligations determined in Step 2. ASC 606 explains that entities allocate the transaction price to performance obligations based on a relative standalone selling price basis. What gets tricky in our example is that these software updates are not sold separately, which means Tesla does not have an observable price to use in this allocation. The guidance allows for other approaches to be used when observable prices are not available. Estimation methods include (but are not limited to) an adjusted market assessment approach, expected cost plus margin approach, and a residual approach. In some contracts, a combination of methods may be used.
Check out our course on Step 4 of ASC 606 to learn more about allocating the transaction price.
Step 5: Recognize revenue
So, when does Tesla actually get to recognize this revenue? Revenue is recognized either when or as the entity satisfies a performance obligation. This is frequently referred to as recognizing revenue “over time” or at “a point in time.” There are criteria found within ASC 606 that are required to be met to recognize revenue over time and if this criteria is not met, then revenue is recognized when control transfers.
In our example scenario, based on what we have walked through in each step above, revenue would be recognized by Tesla at a point in time for the car. This point in time would be when the customer obtains control of/accepts the vehicle. For the software updates, revenue would be recognized over time. The reasoning is that the customer is receiving benefit from the software updates when Tesla provides them, and Tesla’s provided software update is enhancing an asset that the customer has control over.
For more depth on when an entity is able to recognize revenue, check out our course on Step 5.
So, how does Tesla actually recognize revenue?
Tesla’s 2022 10-K explains:
Revenue recognition under ASC 606
Looks like our “on-the-fly” conclusions in the classroom align with Tesla’s revenue recognition policies! The 5-step model within ASC 606 is very helpful in breaking down a scenario, but as you saw, each step can be filled with its own complexities and quirks! If you’d like to learn more about revenue recognition under U.S. GAAP or IFRS, check out our CPE-eligible, eLearning courses:
As always, feel free to reach out if you have any questions!
About GAAP Dynamics
We’re a DIFFERENT type of accounting training firm. We don’t think of training as a “tick the box” exercise, but rather an opportunity to empower your people to help them make the right decisions at the right time. Whether it’s U.S. GAAP training, IFRS training, or audit training, we’ve helped thousands of professionals since 2001. Our clients include some of the largest accounting firms and companies in the world. As lifelong learners, we believe training is important. As CPAs, we believe great training is vital to doing your job well and maintaining the public trust. We want to help you understand complex accounting matters and we believe you deserve the best training in the world, regardless of whether you work for a large, multinational company or a small, regional accounting firm. We passionately create high-quality training that we would want to take. This means it is accurate, relevant, engaging, visually appealing, and fun. That’s our brand promise. Want to learn more about how GAAP Dynamics can help you? Let’s talk!
Disclaimer
This post is published to spread the love of GAAP and provided for informational purposes only. Although we are CPAs and have made every effort to ensure the factual accuracy of the post as of the date it was published, we are not responsible for your ultimate compliance with accounting or auditing standards and you agree not to hold us responsible for such. In addition, we take no responsibility for updating old posts, but may do so from time to time.
Comments (0)
Add a Comment