Tesla’s Revenue Recognition for Cars and Software under ASC 606

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 us in the classroom at the end of 2022 while teaching a revenue recognition course. It’s an interesting one! This post will walk through the answer to this question by taking you through the 5-step revenue recognition model under ASC 606.

Revenue Recognition: 5-step model under ASC 606

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.

Refer to our Revenue Recognition topic page for more information as it relates to ASC 606 and IFRS 15!

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? We didn’t exactly know 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 straightforward. 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:

1. 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
2. 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.

ASC 606 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:

Final thoughts

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:

• U.S. GAAP – ASC 606: Revenue from Contracts with Customers
• IFRS – Revenue: Overview of IFRS 15

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 view training as an opportunity to empower professionals to make informed decisions at the right time. Whether it’s U.S. GAAP, IFRS, or audit training, we’ve trained thousands of professionals since 2001, including at some of the world’s largest firms. Our promise: Accurate, relevant, engaging, and fun training. Want to know how GAAP Dynamics can help you? Let’s talk!

Disclaimer
This post is for informational purposes only and should not be relied upon as official accounting guidance. While we’ve ensured accuracy as of the publishing date, standards evolve. Please consult a professional for specific advice.