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

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <2>

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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <3>

Note # 1: Though Daily Revenue rules calculate revenue at a daily rate, they dont 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 backported 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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <4>

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
Unearned Account
Tax Account

Debit XXXX
Credit
XXXX
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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <5>

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

Immediate
Recognition
@ Invoicing

All At Once

Spread Over Periods

Recognize all Revenue on the GL

Date of the Invoice

Revenue Recognition begins

immediately but spread over a period of
time.

Use Immediate Accounting Rules

with 1 period which takes 100% of
Revenue in the same month of
Invoicing
Daily Rate Rules are not relevant
here as the recognition is
immediate. Standard Rules could
be used for this scenario

Posts all Revenue to Deferred

Revenue Account

Deferred &
Recognize
Later

Revenue Trigger date could be

known date at the time of
Invoicing or Unknown i.e.
dependent on a contingency or an
event
[Note: Revenue Deferral scenarios
are discussed in detail later in this
document]

Example: service contracts or

maintenance or support agreements
where continuing performance
obligation over a period of contract exists
Use Daily Rate Rule and specify the rule
start date and rule end date at the time of
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 userenterable field when Daily Rate Rules are
used.
Initially Post all Revenue to Deferred
Revenue Account
Revenue once triggered will be spread
over a period of time which is
generally the period of continuing
performance obligation
[Note: Revenue Deferral scenarios are
discussed in detail later in this
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.
Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <6>

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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <7>

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

Rev Rec
Scenarios

Rule Start Date

Known
S1

S2
1. Standard [i.e. NonDeferred] Revenue
Recognition Scenario
2. Use Standard Daily
Revenue Rule
3. Minimum complexity

Rule
Duration
Known

S3
Rule
Duration
Unknown

Rule Start Date

Unknown
1. Deferred Revenue Scenario
2. Use Daily Deferred Revenue
Rules or Use Revenue
Contingencies where
appropriate
3. Medium High complexity
S4

1. Very unlikely scenario

2. Use Deferred Revenue
Rule schedule revenue
only when duration is
known
3. Medium - High
Complexity

1. Standard Functionality does

not meet this requirement
2. Requires workaround of
creating 1 month Deferred
rule
3. High 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 organizations 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

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <8>

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
e#

Revenue
Amount

1
2
3

1200
1200
1200

Current
Open
Period
Mar-10
Mar-10
Mar-10

Duration

Rule Start
Date

12 Mo
12 Mo
12 Mo

16-Mar-10
16-Jan-10
16-May-10

First Month
of Revenue
Recognition
Mar-10
Mar-10
May-10

No of
Calendar
Days
16
75 [16+28+31]
16

First
Month
Rev
52.60
246.57
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 organizations 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

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <9>

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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <10>


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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <11>

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

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <12>

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 thats 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.

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <13>

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. Lets 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)

Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <14>

 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
Number
80001
80002
80003
80004
80005
80006

GL Date
05-Feb-10
05-Mar-10
05-Apr-10
05-May-10
05-Jun-10
05-Jul-10

Revenue Adjustment
Amount
167
167
167
167
167
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: Lets 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
Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <15>

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
previous calls)

in the

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
Number
80001
Collaborate 10

GL Date
01-Jan-13

Copyright 2010 by Anil Madhireddy

Revenue Adjustment
Amount
208.33
Page <16>

80002
80003
80004
80005
80006
80007
80008
80009
80010
80011
80012

01-Feb-13
01-Mar-13
01-Apr-13
01-May-13
01-Jun-13
01-Jul-13
01-Aug-13
01-Sep-13
01-Oct-13
01-Nov-13
01-Dec-13

208.33
208.33
208.33
208.33
208.33
208.33
208.33
208.33
208.33
208.33
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
Value

p_api_version

IN

NUMBER

Yes

p_init_msg_list

IN

VARCHAR2

No

p_commit

IN

VARCHAR2

No

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.
FND_API.G_ To initialize the
FALSE
message list.
FND_API.G_ To commit the
FALSE
processing done

Collaborate 10

Copyright 2010 by Anil Madhireddy

Description

Page <17>

p_rev_adj_rec

IN

x_return_status OUT

AR_Revenue_ Yes
Adjustment_
PVT.Rev_Adj_
Rec_Type
VARCHAR2

x_msg_count

OUT

NUMBER

x_msg_data

OUT

VARCHAR2

x_adjustment_
id

OUT

NUMBER

x_adjustment_
number

OUT

VARCHAR2

by the API.
Revenue
Adjustment record
type.
Overall API return
status.
Number of
messages in the
API message list.
Actual message
date in the stack.
The ID of the
resulting revenue
adjustment.
The number of the
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
p_rev_adj_rec.customer_trx_id

Description
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:

p_rev_adj_rec.gl_date
p_rev_adj_rec.line_selection_mode

Collaborate 10

T - total adjustable revenue

A - amount
P - percent
Date on which the revenue
adjustment will be posted to GL.
Determines how the lines are
selected for adjustment.

Copyright 2010 by Anil Madhireddy

Page <18>

p_rev_adj_rec.amount

p_rev_adj_rec.percent

S Specific line
A All Transaction lines
I Specific Item
C Specific Category
The amount of revenue to be
adjusted.
To be passed if the amount
mode value is A.
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
Collaborate 10

Copyright 2010 by Anil Madhireddy

Page <19>

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
AR_RA_AMT_EXCEEDS_
AVAIL_REV

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

Copyright 2010 by Anil Madhireddy

Page <20>

Type
E

E
E
E
E
E
W

E
E

AR_RA_INVALID_LINE_ID
AR_RA_INVALID_LINE_MODE
AR_RA_INVALID_REASON
AR_RA_NO_REV_TO_ADJUST
AR_RA_PARTIAL_CREDIT
AR_RA_PCT_EXCEEDS_AVAIL_PCT

AR_RA_TRX_NOTFOUND
AR_RA_ZERO_AMOUNT
AR_TAPI_TRANS_NOT_EXIST

Collaborate 10

Transaction line ID &CUST_TRX_LINE_ID is

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

Copyright 2010 by Anil Madhireddy

Page <21>

E
E
E
E
W
E

E
E