Record Revenue @ Daily Rate [White Paper]

Record Revenue @ Daily Rate
[A Deep Dive into Daily Revenue Recognition Options in Oracle Receivables]

Anil Madhireddy
Gautam Ramakrishna
VeriSign Inc

VeriSign Inc is the trusted provider of Internet infrastructure services for the networked world.
VeriSign brings Trust to the Internet with domain name and authentication services allowing
companies and consumers all over the world engaged in trusted communications and commerce.

1. Introduction

The objective of this white paper is to discuss the functional and technical aspects of Oracle
Receivables standard functionality on Daily Revenue Recognition and the detailed setups that are
required to implement Daily Revenue Recognition. The first section of this paper offers the case for
implementing Daily Revenue Rules and how Daily Rules differ from the standard rate offering a
solution framework that is closest to GAAP compliance on Revenue Recognition. The next section
of this paper will discuss building blocks for Daily Revenue Recognition and the configuration that
is required for implementing Daily Revenue Rules. The last section of this paper offers drilldown
on possible Daily Revenue scenarios and solution options on addressing these scenarios. Appendix
A & B to this paper offers technical insights to readers on how to use to Deferred Revenue
Accounting API [supported by a FAQ] and a case study on how VeriSign was able to implement an
automated solution to a unique revenue scenario by working around the possibilities that exists
with Revenue Accounting API.

2. Revenue Recognition – What GAAP Says!!

Before we move into the technical aspects of Revenue Recognition in Oracle EBS, one needs to
understand the Generally Accepted Accounting Principles [GAAP] around Revenue Recognition.
Revenue Recognition is a discussion topic by itself that we consider larger discussion on GAAP
guidelines out of scope of this paper. The objective here is to provide a quick high level summary of
GAAP basics on Revenue Recognition that will prepare the readers for the next sections of this
paper.
Revenue Recognition is different from Invoice Presentment
– Revenue should not be recognized until it is realized or realizable and earned
When Revenue is considered to have been earned?
– When the entity has substantially accomplished what it must do to be entitled to
the benefits represented by the revenues [SAB 101]
Revenue can be recognized only if all the following four criteria is met:
– Persuasive evidence of an arrangement exists,
– Delivery has occurred or services have been rendered,
– The seller's price to the buyer is fixed or determinable, and
– Collectibility is reasonably assured.

Collaborate 10 Copyright ©2010 by Anil Madhireddy Page <1>

If there is a continuing performance obligation related to the product or service sold,
then the related revenue generally is should be deferred and recognized systematically
over the periods that the service obligation is active
If Revenue is recognized over several periods, the direct costs related to the revenue (i.e.
Cost of Goods Sold – COGS) could be spread out and expensed over the corresponding
periods.

3. Revenue Recognition Options in Oracle EBS

Revenue Recognition functionality in Oracle E Business Suite is seeded in Oracle Receivables
application and is a functionality available in Release 11 and Release 12 as well. Receivables both in
Release 11 and Release 12 offer the following Revenue Recognition options:

3.1. Standard Revenue Rules

Standard Rules calculate Revenue @ Monthly rate. Rule Start Date is not a factor in determining
the amount of revenue as long it is the same period for which revenue is recognized. A
transaction that came in with a rule start date of 1st of the Month and a transaction that came in
with rule start date of last day of month will both be charged with revenue for the whole
month.

Standard Rules comes in two variants:

3.1.1. Fixed Duration : used where the schedule is fixed and not subject to change – say a 12
Month Rule


3.1.2.Variable Duration – used where the schedule is variable. This type of rule offers best
flexibility in terms of leverage one variable for transactions required different schedule.
The duration however, needs to be provided at the time of manually creating an invoice or
at the time of populating the record in Auto-Invoice Table

3.2. Deferred Standard Rules
Deferred Rules are extension of standard rules except that revenue is deferred till an unknown
date. These rules are used when there is a requirement to defer recognition of revenue until an
event or a contingency occurs. The revenue for these transactions is staged in Deferred Revenue
Account until the event or contingency occurs.

3.3. Daily Revenue Rules

Daily Revenue Rules are rules that calculate revenue @ a daily rate. Daily Revenue Rules fulfill
the stringent accounting standards introduced by the US GAAP and the Sarbanes-Oxley Act for
recognizing revenue. The difference between Standard Rules and Daily Rules are only with
respect to the amount of revenue calculated. Standard rules calculate at a monthly rate whereas
the revenue amount calculation on Daily Rules is a function of number of days in a month.


Note # 1: Though Daily Revenue rules calculate revenue at a daily rate, they don’t really create
accounting distributions for every calendar day. The accounting distributions are created the
same manner as the standard rules – just that the revenue amount recorded will be different.

Note # 2: Daily Rate Rules are standard functionality in Release 12. This functionality was back-
ported to Release 11 via one-off Patch 5684129 [Metalink Note: 401000.1]. However, Financials
Family Pack G is an absolute pre-requisite for the above 11i patch.

Note # 3: The core daily revenue functionality in AR works fine in Release 11. However the
daily rules are not extensible in other applications like Order Management, Service Contracts
etc. This requires extensive patching on Release 11 and you may contact Oracle Support for the
exact patch requirements.

Daily Rate Revenue Rules come in two flavors:

3.3.1. Daily Revenue Rate, All Periods: Use Daily Revenue Rate, All Periods to have
Receivables use a daily revenue rate to calculate the precise amount of revenue for each full
and partial period in the schedule. This accounting rule type provides you with the most
precise revenue recognition schedule possible. Use rules of this type in cases where you
must meet strict revenue accounting standards for partial accounting periods.

3.3.2. Daily / Partial Periods: Use Daily Revenue Rate, Partial Periods to have Receivables
use daily revenue rate to calculate the precise amount of revenue for only partial period in
the schedule. This rule provides you with an even, prorated revenue distribution across
the schedule's full periods.

Note: See Section 4.2 for calculation differences between Daily Rate / All Periods and Daily
Rate / Partial Periods Rules.


3.4. Deferred Daily Rules

Use Deferred Daily Rules when you want to defer revenue recognition till an unknown date
and when you want to Revenue to be recognized at a daily rate when it is eventually triggered.
In other words, Deferred Daily Rule is an extension of Daily Rule except that revenue is
deferred till an unknown date. The revenue for these transactions is staged in Deferred Revenue
Account until the event or contingency occurs.

The Initial Accounting created at the time of creation of the Invoice will be as follows:

Receivables Account Debit XXXX
Unearned Account Credit XXXX
Tax Account Credit XXXX

Revenue Amount is staged in Deferred (Unearned) Account until Revenue is triggered either
manually via Revenue accounting form (details in the next Section 5.2 of the paper) or using
Revenue Accounting API (details in Appendix B of this paper) as may be the case.

Revenue could be triggered partially or fully, for all line or selected invoice lines which will
generate the revenue accounting as follows:

Unearned Revenue Account Debit XXXX
Revenue Account Credit XXXX

Note # 1: Daily Deferred rules could be Daily Rate / All Periods or Daily Rate / Partial Periods
rules. See Section 4.2 for calculation differences between Daily Rate / All Periods and Daily
Rate / Partial Periods Rules.

Note # 2: In Oracle 11i, there is a bug in terms of how the Revenue Accounting Form creates
revenue distribution calculations when DAILY DEFERRED rules are used. The per month
amount calculation goes out of whack for a couple of periods when you trigger revenue via the
revenue accounting Form. Please work with Oracle to obtain a patch for this bug.


4. Daily Revenue Rules Drilldown
Given the above overview of the functionality of Revenue Accounting rules in Oracle E Business Suite,
next step is drilldown on the Daily Revenue Rules specifically in terms of timing and calculation
differences between daily and standard and deferred revenue rules.

4.1. Timing Differences:

Recognize All At Once Spread Over Periods
Recognize all Revenue on the GL Revenue Recognition begins
Date of the Invoice immediately but spread over a period of
Immediate time.
Recognition Use Immediate Accounting Rules
@ Invoicing with 1 period which takes 100% of Example: service contracts or
Revenue in the same month of maintenance or support agreements
Invoicing where continuing performance
obligation over a period of contract exists
Daily Rate Rules are not relevant
here as the recognition is Use Daily Rate Rule and specify the rule
immediate. Standard Rules could start date and rule end date at the time of
be used for this scenario Invoice Entry or time of population into
Auto Invoice table. Oracle derives the
duration based on the rule start date and
end date. Duration is not a user-
enterable field when Daily Rate Rules are
used.
Posts all Revenue to Deferred Initially Post all Revenue to Deferred
Revenue Account Revenue Account
Deferred &
Recognize Revenue Trigger date could be Revenue once triggered will be spread
Later known date at the time of over a period of time – which is
Invoicing or Unknown i.e. generally the period of continuing
dependent on a contingency or an performance obligation
event
[Note: Revenue Deferral scenarios [Note: Revenue Deferral scenarios are
are discussed in detail later in this discussed in detail later in this
document] document]

4.2. Calculation Differences

The key difference between daily rate rules and standard rules lies in the calculation of revenue
amounts. Standard Rules calculate revenue @ monthly rate and Daily rules calculate revenue @
daily rate. The Daily Revenue calculation is function of number of days in the month and differs
even between Daily Rate All periods or Daily Rate Partial periods – as you can see in the
calculations below.


Exhibit: Revenue Calculation Differences between different types of Rules
[Rule Start Date: 16 Mar 10 / End Date: 15 Mar 11]

5. Daily Revenue Scenarios
Now that we have understood the core-functionality behind Daily Revenue Rules, the next step is to
understand the possible revenue scenarios and how we could handle them. Given the focus of this
paper is daily revenue we will discuss these scenarios in the context of Daily Revenue rules. However
these scenarios equally apply to standard revenue recognition as much as they apply to daily revenue
recognition.

As you may have realized by now, Rule Start Date and Rule Duration are the fundamental building
blocks for revenue recognition. Depending on the case in hand, these values could be known or
unknown at the time of Invoicing. At one end of the spectrum is a simple case where both the rule start
date and rule duration could be known at the time of invoicing and the other end is a complex case
where both these values could be unknown and be determined on an indefinite future date or an
external event.


For ease of discussion, we have captured the Daily Revenue Recognition scenarios in the following 2X2
matrix in 4 distinct quadrants. Let’s study each scenario in detail.

Rev Rec Rule Start Date Rule Start Date
Scenarios Known Unknown
S1 S2
1. Standard [i.e. Non- 1. Deferred Revenue Scenario
Rule Deferred] Revenue 2. Use Daily Deferred Revenue
Duration Recognition Scenario Rules or Use Revenue
Known 2. Use Standard Daily Contingencies where
Revenue Rule appropriate
3. Minimum complexity 3. Medium – High complexity

S3 S4
1. Very unlikely scenario 1. Standard Functionality does
Rule 2. Use Deferred Revenue not meet this requirement
Duration Rule – schedule revenue 2. Requires workaround of
Unknown only when duration is creating 1 month Deferred
known rule
3. Medium - High 3. High Complexity
Complexity

5.1. S1 – Rule Start Date & Duration Known

S1 captures the simplest application of Daily Revenue Recognition rule. This is a case where
both rule start date and duration is known at the time of invoicing. This is a classic case of
application of Daily Revenue Recognition Rules. The rule could be Daily rule for all periods or
Daily Rules for partial periods depending on your organization’s revenue policy. Given that
the daily revenue rules are used, revenue is calculated for the month as a function of number of
remaining days in a month from the rule start date.

1st Month Revenue = [# of Calendar Days in the Month – Rule Start Date] X Total Revenue
# Of Calendar Days in the Year

While Rule Start is known at the time of invoicing, the rule start date could, depending on the
nature of the transaction, be a (a) date in the current open period or (b) a date in the prior period
or (c) a date in a future period.

Date in the current open period is the most common scenario and represents a simple and
straight forward daily revenue scenario.

A software company could let customers renew its licenses 90 days in advance and invoice the
customer in advance but may want to recognize revenue only from license renewal effective
date. In this scenario, you may have rule start dates which are in future passed as part of an


Invoice that is billed in Advance. The point to note is that since the rule start date is known,
Receivables will build the revenue schedule for the entire duration beginning from a future GL
Date.

A security company may permit late renewals of licenses and may want revenue recognition be
effective retrospectively. These cases, the rule start date could be in past. The point to note is
though the revenue recognition program will try to do a ‘catch-up’ on revenue, it will end up
posting all revenue in the current open period – if prior AR periods are in closed status

Point to note is that in all the above cases, revenue schedule is built in the period of invoicing
though the actual distribution entries may begin on a future date.

Lin Revenue Current Duration Rule Start First Month No of First
e# Amount Open Date of Revenue Calendar Month
Period Recognition Days Rev
1 1200 Mar-10 12 Mo 16-Mar-10 Mar-10 16 52.60
2 1200 Mar-10 12 Mo 16-Jan-10 Mar-10 75 [16+28+31] 246.57
3 1200 Mar-10 12 Mo 16-May-10 May-10 16 52.60

5.2. S2 – Rule Start Unknown & Duration Known

S2 captures a deferred revenue scenario within the application of Daily Revenue rules. This is a
case where while rule duration (12/18/24 Months) is known, rule start date is unknown at the
time of invoicing and is expected to be determined on an indefinite future date. This is a classic
case where deferred daily rules [Daily Rules with Deferred Revenue checkbox enabled] come
into play. The rule could be Daily rule for all periods or Daily Rules for partial periods
depending on your organization’s revenue policy. Given that the daily revenue rules are used,
revenue is recorded at a daily rate.

Note # 1: Alternatively, you could use Revenue Contingencies functionality to apply either a
time based (using contingency expiration days or date) or event based contingency (Payment or
customer acceptance dependent) to the transactions, fulfillment of which automatically triggers
revenue. Given that Revenue Contingencies is an elaborate topic by itself, we have kept further
discussion on revenue contingencies out of scope of this paper.

Note # 2: Usage of Revenue contingencies is limited to scenarios where (a) accounting duration
is known and not subject to change and (b) the requirement is to trigger revenue for FULL Line
Amount when the contingency expires or a revenue triggering event occurs (except for payment
based revenue recognition). Deferred Rules offer flexibility in all cases to trigger revenue even
for PARTIAL line amounts (example: you may trigger revenue for half of the items part of the
same Invoice line and continue to hold revenue for the other half.)

In both the cases, when Revenue Recognition is run for the first time for these transactions,
Revenue is staged in the deferred revenue account until an unknown future date. When the
revenue start date is determined or a contingency expires or a revenue triggering event occurs,
you may use the ‘Revenue Accounting Form’ or ‘Revenue Accounting API’ to trigger revenue


or where revenue contingencies are being used, you may let Revenue Contingency Analyzer
program trigger revenue on expiration of contingencies.

a) Using Revenue Accounting Form: Use Revenue Accounting Form to schedule revenue
for transaction lines for which revenue has been deferred. This standard Oracle form
provides users easy front end access to trigger revenue in a 5-step process.

The Form allows search for transactions by Transaction Number, Customer
Number, Transaction Date, Source, Customer etc. ONLY Transactions that are
associated with a deferred revenue rule and for which accounting has been
created are available via this Form to schedule revenue

Navigation: Receivables -> Control -> Accounting -> Revenue Accounting

Once you found the transaction to schedule revenue, you can review the
transaction distribution lines and revenue summary to identify how much
revenue is available for scheduling.


Next steps are identifying which lines to adjust and the percent or amount of
revenue that needs to be scheduled. Amend GL Date if required. You may pass a
GL date in the current period or a past or a future period as may be relevant.

Final step is reviewing the distribution lines and the revenue calculations and
either cancel or save the transactions. Immediately after saving, the system
updates the Invoice Distributions with the scheduled revenue. No need to run
Revenue Recognition program to update the distributions. GL transfer is not
automatically triggered though. The revenue entries are transferred to GL only
after General Ledger Transfer program is run from AR.


b) Using Revenue Accounting API: Alternatively, you may use Revenue Accounting API
to have the system trigger revenue based on a defined trigger point. Revenue
Accounting API offers much more flexibility in terms of scheduling revenue than on the
form; however you will need to write some custom code to call the API and pass
relevant input values. Please refer to Appendix B for technical details around how to use
the Revenue Accounting API in a FAQ [Frequently Asked Questions] format.

c) Revenue Contingency Analyzer: In case of contingencies, Revenue Contingency
Analyzer program can automatically trigger revenue when the contingency expires or
payment or acceptance event occurs. Revenue for payment based contingencies is
automatically triggered when payment is applied to the Invoice.

5.3. S3 – Rule Start Date Known & Duration Unknown

Rule Start Date Known and Duration Unknown is a very unlikely scenario though that could
occur occasionally. You will need to use Deferred Standard Rule and schedule revenue only
when the duration is determined. However, scheduling of revenue using the Revenue
Accounting Form will not work – as the revenue accounting form does not offer the flexibility
to change the accounting rule duration.

Tip: The workaround here is to use a 01 month – Deferred Standard Accounting rule and to
use the Revenue Accounting API to trigger revenue once the duration is known. You could
tweak the Revenue Accounting API to pass amounts with GL Date in such a manner that
revenue is recognized over the new duration determined and at a daily rate. Please refer to
Appendix A and B for more details on Revenue Accounting API.

5.4. S4 – Rule Start Date Unknown & Duration Unknown

There could be revenue scenarios where both Rule Start Date and Rule Duration are not
known at the time of invoice generation. Standard Revenue Accounting functionality does not
meet this requirement as the front end Revenue Accounting Form does not offer the flexibility


to change the accounting rule duration. Accounting rule duration once associated with the
invoice cannot be changed at the time of triggering revenue.

Tip: The only workaround is to use a 01 month – Deferred Accounting rule on the Invoice and
to use the Revenue Accounting API to trigger revenue once the duration is known. You could
tweak the Revenue Accounting API to pass amounts with GL Date in such a manner that
revenue is recognized over the new duration determined and at a daily rate. This requires
some custom coding however could be worked out only if 1 Month – Deferred Accounting
rule is used. Please refer to Appendix A that will discuss a couple of VeriSign scenarios where
we have provided an automated solution using Revenue Accounting API

6. Conclusion
There are several factors that contribute to a successful solution implementation. Perhaps the
most important is the understanding of existing functionality offered by the system and
designing solutions that meet the business requirements. That is the objective of this white
paper and discussion of revenue scenarios in 2X2 matrix.

Obviously, there is more technical stuff to Daily Rate Revenue Recognition than that’s discussed
in this paper. The authors have added Appendix A & Appendix B to address some of the
technical questions you may have and offer some thoughts on how to approach them.

Appendix A is a write-up on the technical solution design on a couple of very challenging
revenue S4 scenarios at VeriSign where rule start date and rule duration were both unknown at
the time of invoice creation. Appendix B is a technical FAQ [Frequently Asked Questions] on
Revenue Accounting API providing guidance how you could use them. Though not elaborate,
authors have tried to address some basic questions and more information could be obtained
from the Oracle implementation guides and technical manuals.

About the Authors:

Anil Madhireddy is the Manager – Business Systems Analysis and the IT lead for Order to Cash
business process at VeriSign. He has a combined 10+ years of Accounting, Audit and Oracle
Financials ERP implementations experience.

Gautam Ramakrishna is a Senior Developer at VeriSign. He has extensively worked on
providing automated solutions using Revenue Accounting API for VeriSign and the author for
Appendix A & B.


Appendix A – Case Study on Complex Revenue Scenarios@ VeriSign

VeriSign Case Study # 1

A division of VeriSign sells coupons to resellers that are redeemable for SSL and other
certificates. These coupons expire and are non-refundable. The results of a financial audit here
stipulate that revenue must be recognized and amortized starting with the actual issuance of the
certificate.

Challenge:

This case ties with the S4 Revenue Scenario mentioned in the Section 5 of the white paper. Here
the rule start date or the date on which the coupons would be redeemed is unknown at the time
of invoicing the customer and also to provide flexibility to recognize revenue immediately if the
coupon is not redeemed but expires at the end of term – which requires changing the
accounting rule which standard functionality does not support.

Solution:

1. We associate the original transaction lines with a ONE MONTH Deferred accounting
rule. When the revenue recognition program is run, the transaction revenue amount is
transferred to unearned revenue account.

2. The Engineering system sends Oracle a file which will contain data on the transaction
lines that have been redeemed or expired. Expired coupons mean that the stipulated one
year period from the coupon purchase has expired without the coupons being
redeemed. For expired coupons, revenue needs to be recognized immediately

3. The revenue accounting API will process these records to generate the distribution
records for these transaction lines. Let’s consider the approach for the redeemed and
expired case below:

Case where coupons are redeemed: - The API will have to be called as many times as
the number of distribution records that needs to be created. Number of times is
determined by the accounting duration of the accounting rule associated with the
coupon item SKU in Oracle Inventory. If the accounting rule duration is 6 months
then the transaction line amount needs to be distributed over 6 GL periods with one
distribution line created in each of the 6 periods. Care has to be taken care to see that
the distribution amount over the 6 periods does not exceed the total transaction line
amount. This can be taken care by passing the amount to the last API call as below,

Amount to be passed to the last API call = (Total transaction line amount -
Sum of the amount passed to the API in the
previous calls)


Case where coupons are expired: - Since the coupon has expired without being
redeemed, the entire transaction line amount will need to be recognized in the same
period in which the data is sent. This will need a single API call with the entire
transaction line amount being passed in the same call.

Example:

Following is the example of revenue distributions lines created by the API based on the above
approach in a case where the coupon has a 6 month accounting rule and the transaction line
amount is $1000. Consider that the coupon is redeemed on Feb 05, 2010.

Revenue Adjustment GL Date Revenue Adjustment
Number Amount
80001 05-Feb-10 167
80002 05-Mar-10 167
80003 05-Apr-10 167
80004 05-May-10 167
80005 05-Jun-10 167
80006 05-Jul-10 165

VeriSign Scenario # 2

Scenario
Procurement orders are created for procuring the tokens on behalf of Reseller/Direct customers.
These procurement orders will flow through the Order Management workflow and
procurement invoices will be created. Revenue will not be recognized on the invoice lines until
the tokens are shipped and fulfilled. Revenue recognition should happen only for the 'Actual'
quantity of the tokens shipped in a month. The revenue should be evenly distributed over the
months that are left in the original accounting duration defined on the token item.

Challenge:

This case ties with the S4 Revenue Scenario mentioned in the Section 5 of the white paper. Here
the rule start date (i.e. the date on which the tokens would be fulfilled) is unknown. Also the
duration over which the revenue would need to be recognized is unknown as it would depend
on how much of the rule duration is remaining from the token service fulfillment date. Ex: -
Let’s say the accounting duration defined on the token item SKU is 48 months. If the token
services are fulfilled on the 28th month, then the duration over which the revenue should be
recognized is from 28th month to 48th month - duration of 21 months.

Approach
We create the transaction lines for the procurement invoice with a deferred accounting rule
having one month duration. When the revenue recognition program is run the transaction line
amount is transferred to an unearned account.

The number of tokens shipped and fulfilled for a customer for the entire month is consolidated
into a monthly order. This monthly order will flow through the Order Management workflow
and monthly invoices will be created. The monthly invoice line will be a zero dollar line and


will have the quantity which represents the total number of tokens shipped and fulfilled for the
customer. Using the token item and the customer from the monthly invoice we will fetch the
matching procurement invoices having the same customer and token item in a FIFO manner
meaning the earliest created procurement invoices will be fetched first. The amount to be
recognized on the procurement invoice is determined by multiplying the unit selling price on
procurement invoice with the quantity available on the monthly invoice. The duration over
which the revenue will need to be distributed is determined by checking the number of periods
remaining in the original accounting duration defined on the token item. The revenue
accounting API will be called as many times as the number of periods over which the revenue
amount needs to be distributed.

Amount to be passed to the last API call = (Total transaction line amount -
Sum of the amount passed to the API in the
previous calls)

Example:

1) The procurement invoice "1000" is created on 01-Jan-2010 for 1000 tokens for customer "XYZ
Corporation". The unit selling price for each token is 5$.

2) The accounting duration of the accounting rule on the token item is 48 months.

3) 500 tokens are shipped and fulfilled for "XYZ Corporation" on 01-Jan-2013. This would
mean that we have a monthly invoice "1001" with quantity as 500 and the amount on the
line would be 0$.

4) The duration over which the revenue would need to be recognized for the procurement
invoice "1000" can be calculated as below.

Number of periods between (A) and (B) including (A) and (B).
(A) End date of the accounting duration on the invoice "1000"
(B) Rule start date of the invoice "1001"

(A) In turn can be calculated by adding the accounting rule duration on the token to the rule
start date of the invoice 1000.

In our case following will be the value for the components.
(A) => 31-Dec-2013
(B) => 01-Jan-2013

Number of periods = 12.
Revenue Amount to be recognized = 500 * 5 = 2500.

Distributions will be created as below.

Revenue Adjustment GL Date Revenue Adjustment
Number Amount
80001 01-Jan-13 208.33


80002 01-Feb-13 208.33
80003 01-Mar-13 208.33
80004 01-Apr-13 208.33
80005 01-May-13 208.33
80006 01-Jun-13 208.33
80007 01-Jul-13 208.33
80008 01-Aug-13 208.33
80009 01-Sep-13 208.33
80010 01-Oct-13 208.33
80011 01-Nov-13 208.33
80012 01-Dec-13 208.37

Appendix B – Commonly Asked Questions on Revenue Accounting API

1) Which API is available to schedule revenue on a transaction?

AR_RevenueAdjust_PUB.Earn_Revenue: - This API transfers the specified amount of
revenue from the unearned revenue account to the revenue account on the specified
transaction lines.

2) What is the pre-requisite on the transaction for it to be processed by Revenue
Adjustment API?

The transaction lines should have a deferred accounting rule. When revenue recognition
program processes the transaction line, then the entire transaction amount is moved to
an unearned account. The revenue adjustment API can then be used to transfer the
revenue from the unearned account to revenue account.

3) What are Input and Output Parameters for this API?

Parameter Type Data Type Required Default Description
Value
p_api_version IN NUMBER Yes Used to compare
version numbers
of incoming calls
to its current
version
number. For the
current version the
value that should
be passed for this
parameter is 2.0.
p_init_msg_list IN VARCHAR2 No FND_API.G_ To initialize the
FALSE message list.
p_commit IN VARCHAR2 No FND_API.G_ To commit the
FALSE processing done


by the API.
p_rev_adj_rec IN AR_Revenue_ Yes Revenue
Adjustment_ Adjustment record
PVT.Rev_Adj_ type.
Rec_Type
x_return_status OUT VARCHAR2 Overall API return
status.
x_msg_count OUT NUMBER Number of
messages in the
API message list.
x_msg_data OUT VARCHAR2 Actual message
date in the stack.
x_adjustment_ OUT NUMBER The ID of the
id resulting revenue
adjustment.
x_adjustment_ OUT VARCHAR2 The number of the
number resulting revenue
adjustment.

4) What are some of the important values in the revenue adjustment record that need to be
passed to the API?

Parameter Description
p_rev_adj_rec.customer_trx_id The transaction on which the
revenue accounting needs to be
triggered.
p_rev_adj_rec.from_cust_trx_line_id The transaction line on which
the revenue accounting needs to
be triggered.
p_rev_adj_rec.reason_code Lookup code for revenue
adjustment reason.
Ex: - ‘RA’ – Revenue Adjustment
p_rev_adj_rec.amount_mode The amount mode specifies
whether an amount, a
percentage (of total value of
selected lines), or all adjustable
revenue is to be adjusted.
Possible
values are:

T - total adjustable revenue
A - amount
P - percent
p_rev_adj_rec.gl_date Date on which the revenue
adjustment will be posted to GL.
p_rev_adj_rec.line_selection_mode Determines how the lines are
selected for adjustment.


S – Specific line
A – All Transaction lines
I – Specific Item
C – Specific Category
p_rev_adj_rec.amount The amount of revenue to be
adjusted.
To be passed if the amount
mode value is “A”.
p_rev_adj_rec.percent The percentage of total selected
transaction line value to be
adjusted.
To be passed if the amount
mode value is “P”.

5) Can you provide a sample API call?

AR_RevenueAdjust_PUB.Unearn_Revenue
(p_api_version => 2.0
, p_init_msg_list => FND_API.G_TRUE
, p_rev_adj_rec.customer_trx_id => <Customer Trx ID>
, p_rev_adj_rec.from_cust_trx_line_id => <Customer Trx Line ID>
, p_rev_adj_rec.reason_code => ‘RA’
, p_rev_adj_rec. line_selection_mode => ‘S’
, p_rev_adj_rec. amount_mode => ‘A’
, p_rev_adj_rec.amount => <Amount needed to be adjusted>
, p_rev_adj_rec.gl_date => <Desired GL Date for the adjustment record>
, x_return_status => l_return_status
, x_msg_count => l_msg_count
, x_msg_data => l_msg_data
, x_adjustment_id => l_adjustment_id
, x_adjustment_number => l_adjustment_number
);

6) What is the number of GL periods over which the revenue amount or the revenue
percentage be distributed by the API?

The number of GL periods over which the revenue will be distributed is decided by the
accounting duration on the transaction line. If the accounting duration is 6 months on
the transaction line then 6 distribution records would be created by the API with each
line amount equal to amount passed to the API divided by 6. The GL date for the created
distribution records would be spread across 6 months.

7) What is the flexibility provided by the Revenue Adjustment API?

The API gives us the flexibility of distributing different amounts across different GL
periods. Also the amount can be distributed across any number of GL Periods. For this
the original accounting rule duration on the transaction line should be one month. The


user can then call the API any number of times with each call having the desired amount
to be distributed in a particular GL period and GL Date indicating the period in which
the distribution needs to be transferred to GL.

8) Can we use Revenue Accounting API for transactions that already have contingencies
applied on it?

Yes, the revenue accounting API can be used to recognize revenue on transactions that
have contingencies applied on it. For time-based contingencies, while Revenue
Contingency Analyzer program can trigger full revenue, Revenue Accounting API
provides the flexibility to trigger revenue partially as well.

9) What needs to be kept in mind while using the API in our custom programs?

The total amount or the total percent for all the distribution records that we are
attempting to create using the API should not exceed the total revenue amount on the
transaction line or 100% of the total revenue amount on the transaction line.

10) What is the advantage of passing amount over percentage as input parameter to the
API?

It has been observed on instances passing the percentage creates rounding issues. Even
when we prorate the percentage accurately and pass to the API, the sum of percentage
on all distribution records exceeds 100% resulting in the API throwing an exception.
This can be overcome by passing amount to the API after appropriately prorating to take
care that the sum total of the distribution revenue amount does not exceed the total
revenue amount on the transaction line.

11) What are some of the warning and error messages from API?

Message Code Message Text Type
AR_RA_AMT_EXCEEDS_ The amount entered is greater than E
AVAIL_REV &TOT_AVAIL_REV, the total available
revenue on the lines selected.
AR_RA_CATEGORY_NOT_ There are no lines with items for category ID E
ON_TRX &CATEGORY_ID on this transaction.
AR_RA_CB_DISALLOWED Revenue cannot be adjusted on chargebacks. E
AR_RA_DEP_DISALLOWED Revenue cannot be adjusted on deposits. E
AR_RA_DM_DISALLOWED Revenue cannot be adjusted on debit memos E
or debit memo Reversals.
AR_RA_FULL_CREDIT One or more credit memos have been applied E
for the full amount of this invoice.
AR_RA_GL_DATE_CHANGED GL date, &GL_DATE, is not in an open or W
future-enterable period. GL date has been
changed to &NEW_GL_DATE.
AR_RA_GUAR_DISALLOWED Revenue cannot be adjusted on guarantees. E
AR_RA_INVALID_AMOUNT_MODE Amount mode &AMOUNT_MODE is E
invalid.


AR_RA_INVALID_LINE_ID Transaction line ID &CUST_TRX_LINE_ID is E
invalid.
AR_RA_INVALID_LINE_MODE Line selection mode &LINE_MODE is E
invalid.
AR_RA_INVALID_REASON Reason code &REASON_CODE is not a valid E
lookup code.
AR_RA_NO_REV_TO_ADJUST There is no adjustable revenue on the E
selected lines.
AR_RA_PARTIAL_CREDIT One or more partial credit memos have been W
applied against this invoice.
AR_RA_PCT_EXCEEDS_AVAIL_PCT The percentage entered is greater than E
&TOT_AVAIL_PCT, the total available
percentage of adjustable revenue on the lines
selected.
AR_RA_TRX_NOTFOUND Transaction number &TRX_NUMBER cannot E
be found.
AR_RA_ZERO_AMOUNT Amount entered cannot be zero E
AR_TAPI_TRANS_NOT_EXIST Transaction does not exist.
(CUSTOMER_TRX_ID:
&CUSTOMER_TRX_ID).


Record Revenue @ Daily Rate [White Paper]

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Record Revenue @ Daily Rate [White Paper]

Similar to Record Revenue @ Daily Rate [White Paper] (20)

Record Revenue @ Daily Rate [White Paper]