Premature Or Fictitious Revenue Recognition [A Closer Look]

Premature Or Fictitious Revenue RecognitionPremature revenue recognition and fictitious revenue recognition differ in the degree to which aggressive accounting actions are taken. In the case of premature revenue, revenue is recognized for a legitimate sale in a period prior to that called for by generally accepted accounting principles. In contrast, fictitious revenue recognition entails the recording of revenue for a nonexistent sale. It is often difficult, however, to assign a label to such revenue recognition practices because of the large gray area that exists between what is considered to be premature and what is considered to be fictitious revenue recognition. How do we know if certain revenue is premature or fictitious? In other words; how to detect and uncover them?

Through this post, I discuss these most used among other aggressive accounting practices, its theory and concept and practical overview. Please note the purpose of this post is a basic-knowledge-sharing of the existence of such aggressive practice to be aware of. This post is broken down into two pages, use the page navigation button to explore this topic. Enjoy!

Update: As a supplement of this post, I provide separate checklist to detect premature or fictitious revenue recognition. It may useful

 

 

Goods Ordered But Not Shipped

Revenue recognized for goods that have been ordered but that have not been shipped at the time of recognition would be considered by most to be premature.

 

Goods Shipped But Not Ordered

A more aggressive action than recording sales for goods not yet shipped would entail product shipment and revenue recognition in advance of an expected order. Given the lack of an actual order, such an act would, in our view, entail fictitious revenue recognition. If the expected order is received later, some might argue that the transaction involved, at worst, premature revenue recognition.
 

More Egregious Acts

In going beyond simply recognizing revenue for product shipments prior to an expected order, some companies will record sales for shipments for which orders are not expected, or, even worse, they will record sales for nonexistent shipments. Revenue recognized in such situations would be considered fictitious.

 

 

Cover-up Activities

Commonly found among cases of fictitious revenue recognition are steps taken by management to cover up its acts. Such cover-up activities might take the form of backdating invoices, changing shipping dates, or creating totally false records. The actions taken often are limited only by the imagination of those concocting the scheme and may be more offensive than the original acts of fictitious revenue recognition themselves.

 

 
A Precise Demarcation Is Not Practical

It seems that identifying when revenue has been recognized prematurely is very straightforward. Most would agree that revenue is recognized prematurely when it is recorded for a shipment made immediately after a period’s cutoff date to fill a valid order from a creditworthy customer. The revenue is not fictitious because the sale exists. It was recorded early. Most also would agree that revenue recorded for nonexistent sales to nonexistent customers is fictitious. Here a sale simply does not exist. Between these two extremes, however, within that gray area noted earlier, it is difficult to get consensus on what constitutes premature and what constitutes fictitious revenue recognition. Fortunately, such a precise demarcation is not necessary.

For purposes of analysis, a precise labeling of premature or fictitious revenue is less important than acknowledging that revenue has been recognized improperly. In both cases, revenue has been reported on the income statement that does not belong.

 

Expectations about earning power will have been unduly influenced in a positive way. Certainly the more egregious the acts of improper revenue recognition become, the greater will be the penalty that ultimately is exacted. But all forms of improper revenue recognition typically will have some form of penalty, including a negative market reaction. Accordingly, the point of view taken here is that all forms of improper revenue recognition, whether premature or fictitious, should be avoided whenever possible.

So, now you may have a clear idea about what is considered as fictitious and what is prematurely recognized. The next question is; when should revenue be recognized? I have discussed about revenue recognition from the old concept to every bit upadate of possibly the most recent from the accounting bodies [FASB/IASB]. In this post, I am going to reveal guidance from the SEC house. But, before that, let’s recall the FASB/IASB’s first, to not make it a waste, I picked computer software as a base of this quick overview and I pick Microsoft Corp, the biggest computer software maker on the planet as a live example. I promiss it’s gonna be a quick reading… Move on…

 

 
When Should Revenue Be Recognized?

Managers, accountants, and regulators have struggled for decades with the question of when revenue should be recognized. As our economy evolves and new forms of products, services, and transactions arise, the appropriate timing of revenue recognition becomes more difficult to define. In its most elemental form, revenue should be recognized when it is earned and realized or realizable. Revenue is earned when a company has substantially accomplished what it must do to be entitled to the benefit represented by the revenue being recognized. Revenue is realized when goods and services are exchanged for cash or claims to cash. Revenue is realizable when assets received in exchange for goods and services are readily convertible into known amounts of cash or claims to cash.

While this definition of revenue might appear to be appropriate for most transactions, often it is deficient. In particular, problems often arise in determining when revenue is earned. Consider the software industry, which has struggled with problems of revenue recognition for years. The industry has evolved from what was effectively the sale of a product—the software—to something that is more of an ongoing subscription. Services provided by the software firm, which extend well beyond the date of sale, include not only installation and training but also such customer services as ongoing telephone support and unspecified product upgrades and enhancements. With such services being provided over extended periods, determining when the revenue is earned becomes a problem.

Initially, there was no specific guidance as to when revenue should be recognized in the software industry. Accordingly, the industry struggled to determine when its revenue was earned, and companies formulated revenue recognition practices that were quite divergent.

Generally, for software that does not entail significant production, modification, or customization, SOP 97-2 indicates that the following four criteria must be met before software revenue can be recognized:

  • Persuasive evidence of an arrangement exists.
  • Delivery has occurred.
  • The vendor’s fee is fixed or determinable.
  • Collectibility is probable.

 

More specifically, SOP 97-2 requires that before software revenue can be recognized, there must be a valid order from a third-party customer, the software has been shipped, the price is not dependent on a future varying number of users or units distributed, and the total sale price is collectible.

SOP 97-2 also provides direction for software arrangements involving multiple elements, such as upgrades and enhancements, ongoing telephone support, and other services, such as installation, training, and consulting. Such services go well beyond the actual shipment of a software product and require special attention. When such additional elements are part of a software sale, the total software license fee must be divided among the various elements, including the software itself, based on their relative fair market values. Revenue then is recognized over time as performance takes place for each element of the total package. As a result, revenue recognition is delayed beyond the software delivery date for what can amount to a significant part of the total sale.

Consider the revenue recognition policy for Microsoft Corp., as provided in the company’s annual report:

Revenue from products licensed to original equipment manufacturers is recorded when OEMs ship licensed products while revenue from certain license programs is recorded when the software has been delivered and the customer is invoiced. Revenue from packaged product sales to and through distributors and resellers is recorded when related products are shipped. Maintenance and subscription revenue is recognized ratably over the contract period. Revenue attributable to undelivered elements, including technical support and Internet browser technologies, is based on the average sales price of those elements and is recognized ratably on a straight-line basis over the product’s life cycle. When the revenue recognition criteria required for distributor and reseller arrangements are not met, revenue is recognized as payments are received. Costs related to insignificant obligations, which include telephone support for certain products, are accrued. Provisions are recorded for returns, concessions and bad debts.

 

The policy is very descriptive and appears to abide well with the requirements of SOP 97-2. Note that revenue is not recognized until product is shipped, either by the company itself or by its OEMs (original equipment manufacturers).

Revenue associated with maintenance and subscription activities and other elements, such as technical support and browser technologies, is deferred and recognized over time, as earned. The company describes this policy further as follows:

A portion of Microsoft’s revenue is earned ratably over the product life cycle or, in the case of subscriptions, over the period of the license agreement. End users receive certain elements of the Company’s products over a period of time. These elements include items such as browser technologies and technical support. Consequently, Microsoft’s earned revenue reflects the recognition of the fair value of these elements over the product’s life cycle.

Microsoft’s policy has led to the deferral of a significant amount of revenue. Using amounts provided in the company’s annual report, deferred revenue at June 30, 2000, was $4.87 billion, up from $4.2 billion in 1999.

In some instances, a software sale requires significant production, modification, or customization to suit a particular customer’s needs. In such cases, SOP 97-2 calls for use of contract accounting.

In particular, the percentage-of-completion method should be used when the software vendor can make reasonably dependable estimates of the extent of progress toward completion, of contract revenue and contract costs. Here software revenue is recognized as progress is made toward completion of the total software installation. When conditions for use of the percentage-of-completion method are not met, the completed-contract method is appropriate. Here software revenue is not recognized until the software installation is complete.

 

Until this point, you just a half way to the answer of a question, how to detect fictitious and [or] and premature revenue recognition? which is the essence this topic. I suggest you to follow on the next page of this post. As I have mentioned earlier, SEC clarifies a comprehensive criteria for revenue recognition which I will cover on the next page, as well as criteria for recognizing revenue in advance of shipment. Here are huge goodies you can find on the next page:

  • Persuasive Evidence of an Arrangement;
  • Channel Stuffing;
  • Side Letters; 
  • Rights of Return;
  • Related-Party Revenue;
  • Delivery Has Occurred or Services Have Been Rendered;
  • Sales Revenue; Service Revenue;
  • Up-front Service Fees;
  • Contract Accounting;
  • The Seller’s Price to the Buyer Is Fixed or Determinable;
  • Collectibility Is Reasonably Assured;

 

Most importantly are these:

  • Detecting Premature Or Fictitious Revenue;
  • Steps Taken to Thwart Detection;

 

Use the page navigation below to explore this topic [if somehow links are appeared on the above, please DO NOT USE the links, you will be brought to the related topic, not the second page].