Pages

OracleEBSpro is purely for knowledge sharing and learning purpose, with the main focus on Oracle E-Business Suite Product and other related Oracle Technologies.

I'm NOT responsible for any damages in whatever form caused by the usage of the content of this blog.

I share my Oracle knowledge through this blog. All my posts in this blog are based on my experience, reading oracle websites, books, forums and other blogs. I invite people to read and suggest ways to improve this blog.


Monday, November 7, 2016

VSOE and Revenue Recognition

What is Vendor specific objective evidence(VSOE)==========================================Vendor Specific Objective Evidence, is Fair Value for Software. 
SOP 97-2 was designed for Software companies, and works fairly 
well for certain traditional business models.
The concept was introduced in 1997 by the AICPA in their Statement 
of Position (SOP) 97-2: It governs how any company that licenses, 
sells, leases or otherwise markets software (unless it’s incidental to 
the product or service as a whole) must recognize the revenue. 

In particular, it governs how companies must recognize revenue from
so-called “multiple-element arrangements” – bundles of software and
related products or services sold as a unit at a single price. 

Today, more and more companies find themselves dealing with 
VSOE as embedded software becomes an increasingly essential 
element in traditionally non-software sectors - consider cell 
phones, medical devices, computer networks, even cars with GPS
services, etc.

According to SOP 97-2: you allocate relatively, splitting the fee
amongst the products and related elements based upon VSOE – 
which is the price established by the vendor for the separate sale 
of each element. Each VSOE price is usually established through 
accumulation of a quantity of discrete sales “sufficient” to prove 
that the market, in it’s willingness to pay that price, thinks the 
price is fair. And here’s the big catch: 

You can not recognize revenue for any element either until VSOE 
exists for each and every element, or until all of the elements 
have been delivered. 

Sec's Statement of Postion (SOP) 97-2, Software Revenue 

Recognition and SOP 98-9, Software Revenue Recognition with 
respect to certain transactions, applied to all entities that license, 
sell, lease or market computer software. It specifies that revenue 
from an arrangement involving multiple elements should be 
allocated to the various elements based on VSOE fair values to 
the customer.

Sections of SOP 97-2 were amended with SOP 98-9, Software 

Revenue Recognition with respect to certain transactions, 
SOP 98-9 states that the residual method of revenue recognition is 
required when:
1. There is vendor specfic objective evidence of the fair values of all
undelivered elements in a multiple-element arrangment that is not
accounted for using long-term contract accounting.
2. VSOE of fair value does not exist for one or more of the delivered
elements in the arrangement and 3. All Revenue recognition criteria
in SOP 97-2 other than the requirment for VSOE of the fair value of
each delivered element of the arrangement are satisfied.

Elements of VSOE:
==================

-Software Licenses
- Warranty
- Installation
- Support and professional Services
- Training
Fair Market Value (FMV):
========================

The FASB defined 'fair value' in FAS 159 as "The price that 
would be received to sell an asset orpaid to transfer a liability
in an orderly transaction between market participants at the 
measurement date. " The key points in this definition are 
'orderly transaction' and 'market participants.' Thus fair value
can't be established by looking at an exchange of assets in a 
bankruptcy or between 'related parties' as defined by the SEC. 

Fair value is established by multiple, non- related market 
participants in 'normal, orderly transactions. ' VSOE, on the other
hand, is fair value as established by looking at the historical 
transactions of a specific vendor and does not consider what other
vendors are charging for similar products.

Revenue Recognition:

====================
Revenue recognition in today's regulatory and business 

environment involves sophisticated revenue scheduling and 
allocation, Vendor- specific Objective Evidence (VSOE) carve-outs
and Sarbanes-Oxley compliance. Thus having a common system 
for global compliance is key to reducing complexity.
Revenue recognition is a principle prescribing that revenue is 
recognized when earned. 

It has two considerations - when to recognize revenue, and how 
much to recognize. Revenue recognition is relevant for companies
to be able to adhere to legal compliance as per the US GAAP 
requirements.

Improper revenue recognition increases the risk of financial 
restatement, and financial restatements. Revenue for ISV's is 
typically divided into three categories: Software, Maintenance, and 
Services. Assuming that software customization is not required, 
revenue can be recognized when all of the following criteria are met: 

There are four basic criteria that must be met to recognize
revenue
- Evidence
- Delivery 
- Fixed or determinable fee
- Collectibility.

Revenue Accounting:
===================
Use the Revenue Accounting feature to quickly and easily adjust

revenue and sales credits at the transaction or line level. You can 
make manual adjustments using the Revenue Accounting and 
Sales Credits window. Alternatively, use the Revenue Adjustment
API to automatically perform these adjustments. Revenue 
Accounting uses the Actions Wizard to guide you through the process
of makingand modifying revenue adjustments.
You can also use the wizard to record early acceptance for an 

invoice line, if the line is associated with a contract that offers an 
acceptance clause.
Invoicing Rules:
===============
Use Invoicing Rules to specify whetherto record receivables 
amounts in the first (Bill in Advance) or Last (Bill in Arrear) 
Period. 
Invoicing rules determine when to bill the customer inrelation to
the accounting rule Periods. Accounting rules determine the 

accounting periods for revenue recognition and Billing.
Two invoicing rules are available: 




Bill in Advance: Use this rule to recognize receivables immediately.

Bill in Arrears: Use this rule to recognize the receivable at the end of 

the revenue recognition schedule.


•Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
•Once the invoice is saved, you cannot update an invoicing rule.
•If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.
Accounting Rules: 
=================
Use Accounting Rules to determine when to record revenues.
Accounting Rule determine the number of periods and percentage 
of total revenue to record in each accounting period.

Each invoice can have different accounting rule.
Use the Accounting, Fixed Duration type to recognize revenue evenly 
over a specific number of periods. Revenue can be spread evenly or a 
percentage can be specified for each period. 

Variable Duration type to recognize revenue by a percentage for 
the first period. The remaining revenue is spread evenly across 
the number of periods you specify during transaction entry.

Accounting rules determine when to recognize revenue
amounts. Each invoice line can have different accounting rule. 


Oracle Receivables uses the First GL Date field in the Transactions 
window to determine when to start recognizing revenue. The number
of periods in which revenue is recognized is determined by the 
value in the Number of Accounting Periods field in the Transactions
window.Value defaults from fixed ruleValue must be entered for 
variable rule. Accounting distributions are created only after you run
the Revenue Recognition program. 

•Accounting distributions are created only after the Revenue 

Recognition program is run.
•For Bill in Advance, the offset account to accounts receivable 

is Unearned Revenue.
•For Bill in Arrears, the offset account to accounts receivable i

s Unbilled Receivables.
•Accounting distributions are created for all periods when 

Revenue Recognition is run.

Revenue Recognition Program Execution Report :
=======================================
Use the Revenue Recognition Execution report to review all 

revenuedistributions created for invoices that use invoice and 
accounting rules. 

This report displays the account class, GL Date, Accounting 
Flex field, the currency, amount, and accounted amount for 
the revenue distributions Revenue Recognition creates for 
each transaction.

Receivables automatically creates the Revenue Recognition 
Execution report whenever you run the Revenue Recognition
program, the Revenue Recognition Master program, or the 
General Ledger Interfaceprogram.

When the Revenue Recognition program encounters transactions 
with problems that prevent the creation of distributions, the 
program completes with a status of Warning, and Receivables 
includes these transactions at the bottom of this report.

•The Revenue Recognition program gives control over the creation
of accounting entries.
•Submit the Revenue Recognition program manually through the 

Run Revenue Recognition window.
•The Revenue Recognition program will also be submitted when 

posting to Oracle General Ledger.
•The program processes revenue by transaction, rather than by 

accounting period.
•Only new transactions are selected each time the process is run.


References:
https://oracleappsebsyashrajvarsity.blogspot.com/2009/05/vsoe-and-revenue-recognition.html
https://blogs.oracle.com/FinancialsMkting/entry/new_revenue_recognition_rules

1 comment:


  1. Regards
    Sridevi Koduru (Senior Oracle Apps Trainer Oracleappstechnical.com)
    Please Contact for One to One Online Training on Oracle Apps Technical, Financials, SCM, SQL, PL/SQL, D2K at sridevikoduru@oracleappstechnical.com | +91 - 9581017828.

    ReplyDelete