Run the Revenue Recognition program to generate the revenue distribution records for your invoices and credit memos that use invoicing and accounting rules. Accounting rules determine the number of periods and percentage of total revenue to record in each accounting period. Invoicing rules determine when to recognize the receivable for invoices that span more than one accounting period. See: Invoices with Rules.
When you submit the program, Revenue Recognition selects all transactions that have invoicing and accounting rules and that have not yet been processed since you last submitted the program. The program creates the revenue distribution records for all accounting periods specified by the accounting rule on each transaction line:
The Revenue Recognition program creates distribution records for the invoices and credit memos that you create in Receivables and import using AutoInvoice. The Revenue Recognition program uses the accounting distribution sets that you specify in the Transactions window or import into Receivables using AutoInvoice to determine the accounts of your newly created revenue distribution records.
Receivables considers this revenue scheduled.
If a deferred accounting rule exists, then Revenue Recognition will create the distribution records for an unearned revenue account. Receivables considers this revenue unscheduled.
See: Deferred Accounting Rules, Oracle Receivables Implementation Guide.
Revenue Recognition also creates the receivable, tax, freight, and AutoInvoice clearing account assignments which correspond to the GL date of each invoice included in your submission.
Note: Revenue Recognition creates accounting distributions for all periods of status Open, Future, or Not Open. If any period has a status of Closed or Close Pending, then Revenue Recognition creates the distributions in the next Open, Future, or Not Open period.
If you later decide that the GL distributions need to be reclassified, you can change the individual distribution on the transaction. Receivables will automatically create the reverse accounting entries.
If the Revenue Recognition program cannot create accounting distributions for a transaction, then the program generates the accounting for all other transactions in the submission, but completes with a status of Warning. Receivables includes the transaction at the bottom of the Revenue Recognition Execution report so that you know which transaction to correct, incomplete, or delete. See: Revenue Recognition Program Execution Report.
Note: Whenever you run the Submit Accounting program, Receivables first runs the standard Revenue Recognition program. See: Creating Accounting in Receivables.
Matching COGS with Revenue
Oracle Costing integrates with Receivables to ensure that, during revenue recognition and deferral activities in Receivables, COGS (Cost of Goods Sold) is recognized or deferred in the same percentage as revenue. COGS is the expense of manufacturing that is associated with the sale of goods. See: Overview of Revenue and COGS Matching, Oracle Cost Management User's Guide.
Prerequisites
Define accounting calendars and accounting periods, Oracle General Ledger Implementation Guide
Note: You must define accounting calendars for at least as many periods as you plan to recognize revenue.
There are two Revenue Recognition programs: Revenue Recognition and Revenue Recognition Master. The Revenue Recognition Master program is for parallel processing only and takes advantage of the Oracle scalability feature to reduce processing time by running on multiple processors, or workers. The Revenue Recognition Master program determines the maximum number of parallel processors needed for your transaction volume and uniformly distributes the processing over these workers. You can set a maximum number of processors for the Revenue Recognition Master program to use at runtime. This scheduling capability allows you to take advantage of off-peak processing time. You choose the Revenue Recognition program that you want to use at runtime.
Important: You cannot use the Revenue Recognition Master program on a system with less than two processors.
Tip: If you have a high transaction volume, we recommend that you run Revenue Recognition at regular intervals. This minimizes the number of transactions to process and improves performance.
Navigate to either the Run Revenue Recognition or the Requests window.
Choose the Revenue Recognition program you want to run:
Enter 'Revenue Recognition' in the Name field for the single processor program.
Enter 'Revenue Recognition Master Program' in the Name field for the parallel processor program.
Choose a print format of either Summary or Detail.
Select a parameter for the program you chose:
For the Revenue Recognition program, specify whether you want to commit your work. Enter Yes if you want to create the distribution records generated by this submission. Enter No if you want to review the distributions first in the Revenue Recognition Execution report without actually creating the distribution records.
For the Revenue Recognition Master Program, enter the Maximum Number of Workers (parallel processors) you want to utilize for this run. The default is 4.
Choose OK.
Change the language if desired by choosing the Languages button.
Schedule the run as needed. The default is As Soon as Possible. You can run Revenue Recognition more than once, as well, Periodically and/or on Specific Days.
Choose to save the output of the Revenue Recognition program to a file by checking the Save all Output Files box.
Choose Print Options to select print options, including the number of Copies to print, the Style, and the Printer to use.
Choose Submit Request. Receivables displays the Request ID of your concurrent request and creates the Revenue Recognition Program Execution report.
You can use the Request ID to view your submission in the Concurrent Requests Summary window. To see all of the revenue distribution lines that the program creates for this submission, use the: Revenue Recognition Program Execution Report.
Related Topics
Event-Based Revenue Management
Importing Transactions Using AutoInvoice
Use the Revenue Recognition Execution report to review all revenue distributions created for invoices that use invoice and accounting rules. This report displays the account class, GL Date, Accounting Flexfield, 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 Submit Accounting program.
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.
Tip: Always review the execution report after the Revenue Recognition program completes because, even if the program completes without a warning, transactions could still appear at the bottom of this report.
Related Topics
Event-Based Revenue Management
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. See: Revenue Adjustment API User Notes in the Oracle Receivables Reference Guide.
Revenue Accounting uses the Revenue Accounting Management (RAM) wizard to guide you through the process of making and modifying revenue adjustments. You can also use the wizard to update expiration dates of existing revenue contingencies. For example, you can record early acceptance for an invoice line, if the line is associated with a contract that offers an acceptance clause.
Use the RAM wizard to:
Earn revenue
Unearn revenue
Review previous revenue adjustments
Record early acceptance
Manage revenue contingencies
Transfer revenue and non-revenue sales credits
Add non-revenue sales credits
You can make sales credit adjustments to completed invoices, credit memos, debit memos, and deposits only. You can make revenue adjustments to completed invoices and on account credit memos only. In addition, to make revenue adjustments to on account credit memos you must set the AR: Use invoice accounting for credits profile option to No. For all other credit memos, and if the profile option is set to Yes, Receivables prevents revenue adjustments.
Note: When making adjustments to transactions with rules, the invoicing rule must be In Advance.
To enter the RAM wizard, query a transaction in the Revenue Accounting and Sales Credits window and choose either Manage Revenue or Manage Sales Credits.
Tip: These buttons are controlled by function security. See: Function Security in Oracle Receivables, Oracle Receivables Implementation Guide.
Use the selection criteria listed below to optionally limit the lines that are affected by an adjustment or early acceptance:
Inventory item
Inventory category
Line number
Salesperson (limits the impacted lines for adjustments only)
See: Using the Revenue Accounting Management (RAM) Wizard.
When you make adjustments using Revenue Accounting, Receivables uses AutoAccounting to automatically generate all necessary accounting distributions. Before Receivables saves the adjustments, the distributions and/or sales credits resulting from the adjustment are displayed for your review. At this point, you have a final opportunity to approve or cancel the adjustments. In the case of a revenue adjustment, you can also modify the account distributions before saving.
You can also review your early acceptance and other revenue contingency actions before saving. In certain cases, recording early acceptance or expiring a contingency can trigger automatic revenue recognition for the invoice line. See: Evaluating Invoices for Event-Based Revenue Management.
Note: When you create or import an invoice, you can defer all revenue to an unearned account by assigning a deferred accounting rule to the invoice. At the appropriate time, you can recognize revenue manually using the Revenue Accounting and Sales Credits window or automatically using the Revenue Adjustment API. See: Deferred Accounting Rules, Oracle Receivables Implementation Guide.
When you query a transaction, the Revenue Accounting and Sales Credits window displays the following information:
The Transaction tab displays transaction details, including a summary of the scheduled and unscheduled revenue on the transaction.
Revenue is scheduled when Receivables creates, for a transaction line, the revenue distribution records for all accounting periods as specified by the line's assigned accounting rule. Note that scheduled revenue does not mean that the revenue amounts are already earned; rather, Receivables has simply created the distribution records for those amounts.
The Actions History tab displays details about actions already recorded against this transaction. This is a folder region, so you can select and order the columns according to your preference.
Transaction line details appear in the middle of the window. For each transaction line, you can view additional details by choosing either Line Distributions, Line Sales Credits, or Line Revenue Contingencies from the menu.
If you transfer sales credit using the salesperson parameter All and the adjustable revenue parameter All Adjustable Revenue, Receivables transfers 100% of sales credit from all salespersons on the specified lines to the new salesperson.
If you select the salesperson parameter All and the parameter Percentage of Total Value of Selected Lines, Receivables transfers only the specified percent, prorated across the "From" salespersons based on their current sales credits.
For example:
Three salespersons are assigned to a transaction line with a revenue split of 20:30:50. If you transfer all adjustable revenue to a new salesperson, the new salesperson receives 100% (20 + 30 + 50). If you transfer 5%, however, the new salesperson receives 5% of the line total and prorates the transferred amount among the three salespersons. This table illustrates the transfer of sales credits in this example:
| Salesperson | Revenue Split | Transfer Percentage | Prorated Transfer Percentage |
|---|---|---|---|
| Salesperson 1 | 20 | 5% | .05 * 20 = 1 |
| Salesperson 2 | 30 | 5% | .05 * 30 = 1.5 |
| Salesperson 3 | 50 | 5% | .05 * 50 = 2.5 |
When you specify a new salesperson, Receivables defaults the assigned sales group, if one is available. You can change the default.
Warning: Always use the Revenue Accounting Management (RAM) wizard, not the Transactions workbench, to adjust sales credits on a transaction, if that transaction's revenue was previously adjusted via the RAM wizard. See: Entering Revenue Credits.
Use the Revenue Accounting Management (RAM) wizard to:
Prerequisites
Set System Options. Enable the Require Salesperson system option because you must assign sales credit to all invoices that may be adjusted for either revenue or sales credits. If you wish to use the Revenue Accounting feature only for revenue adjustments and do not normally track sales credits, you can use the seeded salesperson value of No Sales Credit.
Note: Although you must assign sales credit to all transactions, you are not required to set up AutoAccounting to derive an Accounting Flexfield segment from the salespersons table. See: Using AutoAccounting.
You may optionally set the Sales Credit Percent Limit system option in the Miscellaneous tabbed region. The Sales Credit Percent Limit imposes a limit on the percentage of revenue plus non-revenue sales credit that a salesperson can have on any transaction line. You can change the value that is defined for the Sales Credit Percent Limit system option at any time. If you do not define a value for this system option, then no sales credit limit validation is performed when using Revenue Accounting. See: Defining Receivables System Options, Oracle Receivables Implementation Guide.
Create Revenue Adjustment Reason Lookup Codes. Receivables provides three revenue adjustment reason codes, but each company has its own reasons for adjusting revenue. Before you make revenue adjustments, you can create company-specific reason code lookups using the REV_ADJ_REASON lookup type.
Recognize Revenue. Before you can adjust transactions with rules, you must run the Revenue Recognition program.
When you navigate to the Revenue Accounting and Sales Credits window, the Find Transactions for Revenue Accounting window opens. In this window, enter query criteria for the transaction that you want to adjust, and click Find.
The Revenue Accounting and Sales Credits window displays the transaction that you selected. If your query returned more than one transaction, then page down until you find the record that you want.
Choose the Manage Revenue button.
Select the type of adjustment that you want to make and click Next:
Unschedule Revenue
Schedule Revenue
If you want to record acceptance, see: Recording Early Acceptance.
Optionally select a salesperson to restrict a revenue adjustment to the portion of revenue that is credited to that particular salesperson.
Select a specific item, item category, or line number to limit the lines that are adjusted.
Warning: If you set AutoAccounting to derive any accounting segments from a standard line, the transaction line must be either an inventory item or standard memo line. Otherwise, AutoAccounting cannot create the valid GL account code combination.
For partial adjustments, select either an amount or percentage. To adjust the full amount, select All Adjustable Revenue.
Note: Oracle Receivables allows you to do revenue adjustments on invoices that have been fully credited. Although the amount you can earn or unearn on a fully credited invoice is zero (under almost every circumstance), this functionality lets you use the Revenue Accounting Management (RAM) wizard to adjust the earned or unearned revenue for an invoice with a deferred rule.
In the Reason field, select the reason code for this adjustment from the list of values.
Optionally change the GL start date and add comments to this adjustment.
When you update the GL start date, Receivables ignores the original rule start date entered via the Transactions workbench and accepts the GL date that you enter as the start date for revenue recognition, provided that:
no accounting rule exists on the transaction line, or
the accounting rule is for a single period, or
a deferred accounting rule exists on the transaction line
If a multi-period accounting rule exists and is not deferred, Receivables ignores the GL start date and uses the original revenue recognition schedule on the transaction, based on the rule start date entered via the Transaction workbench.
See: Deferred Accounting Rules, Oracle Receivables Implementation Guide.
After you make the adjustment, review the adjustment in the Action Results window. You can modify the adjustment's GL distributions before you save the results.
Note: To ensure account reconciliation, any revenue adjustments that you make to an invoice should also be made to that invoice's related credit memos.
You can make revenue adjustments to on-account credit memos only. In addition, you must set the AR: Use invoice accounting for credits profile option to No. For all other credit memos, and if the profile option is set to Yes, Receivables prevents revenue adjustments.
Navigate to the Revenue Accounting and Sales Credits window and enter your query criteria.
Choose the Manage Sales Credits button.
Select the type of adjustment that you want to make and click Next:
Transfer Sales Credits
Add Non Revenue Sales Credits
Specify the From and To Salespersons for this action.
Select the salesperson(s) and the sales credit type that you want to adjust.
Receivables defaults a sales group, if available, for each salesperson that you specify. You can change the default.
Select a specific item, item category, or line number to limit the lines that are adjusted.
Warning: If you set AutoAccounting to derive any accounting segments from a standard line, the transaction line must be either an inventory item or standard memo line. Otherwise, AutoAccounting cannot create the valid GL account code combination.
For partial adjustments, select either an amount or percentage. See: Adjusting Sales Credits.
In the Reason field, select the reason code for this adjustment from the list of values.
Optionally change the GL start date and add comments to this adjustment.
When you update the GL start date, Receivables ignores the original rule start date entered via the Transactions workbench and accepts the GL date that you enter as the start date for revenue recognition, provided that:
no accounting rule exists on the transaction line, or
the accounting rule is for a single period, or
a deferred accounting rule exists on the transaction line
If a multi-period accounting rule exists and is not deferred, Receivables ignores the GL start date and uses the original revenue recognition schedule on the transaction, based on the rule start date entered via the Transaction workbench.
See: Deferred Accounting Rules, Oracle Receivables Implementation Guide.
After you make the adjustment, review the adjustment in the Action Results window. You can modify the adjustment's GL distributions before you save the results.
Navigate to the Revenue Accounting and Sales Credits window and enter your query criteria.
Choose the Manage Revenue button.
Select Modify Revenue Contingencies.
Optionally select a salesperson to restrict a revenue adjustment to the portion of revenue that is credited to that particular salesperson.
Select a specific item, item category, or line number to limit the lines that are adjusted.
Warning: If you set AutoAccounting to derive any accounting segments from a standard line, the transaction line must be either an inventory item or standard memo line. Otherwise, AutoAccounting cannot create the valid GL account code combination.
Select the transaction line whose contingency you want to adjust. Then, in the Line Revenue Contingencies region, adjust the contingency's expiration date attributes:
Number of days (days added to event attribute)
Estimated expiration date
Tip: To expire a contingency, set the expiration date to today's date.
Note: If a parent-child relationship exists from Oracle Order Management, then you can manage contingencies only on the parent lines. Child lines inherit contingencies from parent lines.
Navigate to the Revenue Accounting and Sales Credits window and enter your query criteria.
Choose the Manage Revenue button.
Select the Record Acceptance option and click Next.
Select a specific item, item category, or line number to indicate the line or lines that you want to accept.
The next window displays the lines that Receivables will record early acceptance for.
Click Next to accept the selected lines.
Review the results in the Results window.
Related Topics
Event-Based Revenue Management
The Revenue Management Engine automates the timing of revenue recognition for manually entered invoices, or invoices imported via AutoInvoice. If you use event-based revenue management, then Receivables evaluates these invoices and decides whether to immediately recognize revenue, or temporarily defer revenue to an unearned revenue account.
Revenue is subsequently recognized depending on certain events, such as customer acceptance or receipt of payment.
The automated process occurs as follows:
Receivables evaluates an invoice when manually entered or imported.
When first evaluating an invoice for revenue recognition or deferral, Receivables checks transaction lines to determine if any revenue contingencies exist.
Contingencies are defaulted to invoices when imported from a feeder system or entered manually in the Transactions workbench. Receivables defaults contingencies if the enterprise revenue policy has been violated, or if certain conditions on the related sales order or contract exist.
Receivables does not default contingencies to imported transaction lines that have deferred accounting rules.
If revenue must be deferred, then the Revenue Management Engine does so and records the reason for the deferral.
Receivables then waits for an event that can remove the contingency and trigger revenue recognition. The Revenue Contingency Analyzer monitors contingencies until they expire or are removed. When such an event occurs, the Revenue Contingency Analyzer can automatically recognize the appropriate amount of unearned revenue on the invoice.
Specifically, revenue is scheduled according to the initially assigned accounting rules and rule start dates. For invoice lines without accounting rules, the revenue date is set to the latest contingency removal date.
See: Evaluating Invoices for Event-Based Revenue Management.
This automated revenue management process helps you to comply with the strict revenue recognition requirements mandated by US GAAP and International Accounting Standards.
Note: Even if you enable this automated revenue recognition process, you can always use the Revenue Accounting Management (RAM) wizard to manually adjust revenue. See: Revenue Accounting and Modifying Invoices Under Collectibility Analysis.
However, once you manually adjust revenue, Receivables discontinues the automatic monitoring of contingencies.
Prerequisites
Select the Require Salesperson system option in the Miscellaneous tabbed region in the System Options window. See: Miscellaneous System Options, Oracle Receivables Implementation Guide.
(Optional) In the Revenue Policy page, populate one of the following fields:
Payment Term Threshold
Standard Refund Policy
Credit Classifications region
See: Defining Your Revenue Policy, Oracle Receivables Implementation Guide.
(Optional) Transfer contingency information to Receivables by assigning revenue contingency IDs to billing lines, before invoice import by AutoInvoice or invoice creation by the Invoice API.
See: AutoInvoice Table and Column Descriptions, Oracle Receivables Reference Guide.
Note: When importing parent and child invoice lines from Oracle Order Management, AutoInvoice automatically copies any contingencies from the parent line to the child line. An example of a parent and child is a purchased item and its related services, such as an extended warranty.
(Optional) Define your own revenue contingencies, along with corresponding contingency removal events.
See: Defining Revenue Contingencies, Oracle Receivables Implementation Guide.
(Optional) Define contingency defaulting rules to automatically assign a contingency to an invoice.
See: Assigning Contingencies, Oracle Receivables Implementation Guide.
Note: You cannot use this functionality with Oracle Projects invoices, because revenue from Projects is recorded directly in the general ledger, not in Receivables.
Related Topics
Evaluating Invoices for Event-Based Revenue Management
The Revenue Management Engine controls the process of automatically analyzing collectibility and then making revenue recognition decisions for your manually entered and imported invoices.
This process is automatically enabled if:
You have defined a revenue policy, or
Invoice lines are associated with contingencies
The Revenue Management Engine decides whether to initially distribute revenue to an earned or unearned revenue account.
Once this decision is made, AutoAccounting creates the actual accounting distributions, either by AutoInvoice (for invoices without rules) or by the Revenue Recognition program (for invoices with rules).
Note: Or, to pass accounting distributions to Receivables through the AutoInvoice interface tables, set the Override AutoAccounting flag and assign the Immediate accounting rule to each billing line. See: AutoInvoice Table and Column Descriptions, Oracle Receivables Reference Guide.
The Revenue Management Engine does not analyze collectibility for invoices that are assigned deferred accounting rules. To recognize revenue for an invoice with a deferred accounting rule, use the Revenue Accounting Management (RAM) wizard. See: Revenue Accounting.
Note: The timing of revenue recognition does not impact the timing of recognition of taxes, freight, and late charges. Recognition of taxes, freight, and late charges occurs when the receivable is created.
Tip: You can query an invoice in the Transactions workbench at any time to review the invoice's accounting distributions.
See: Reviewing Accounting Information.
The Revenue Management Engine considers any existing revenue contingencies when evaluating your invoices for revenue recognition.
If an invoice has no such contingencies, then the Revenue Management Engine immediately recognizes revenue (for invoices without rules) or recognizes revenue according to the initially assigned accounting rules (for invoices with rules).
If an invoice has one or more contingencies, then the Revenue Management Engine immediately defers revenue.
The extent of the revenue deferral, and subsequent timing of revenue recognition, depends on the contingency.
Time-based contingencies must expire before the contingency can be removed and revenue can be recognized.
See: Monitoring Contingencies with the Revenue Contingency Analyzer.
Some contingencies require payment before the contingency can be removed and revenue can be recognized.
Post-billing customer acceptance clauses must expire (implicit acceptance), or be manually accepted using the RAM wizard (explicit acceptance) or in Oracle Order Management, before the contingency can be removed and revenue can be recognized.
Pre-billing customer acceptance clauses require the recording of customer acceptance in the feeder system, or its expiration, before importing into Receivables for invoicing. Customer acceptance or its expiration must occur before the contingency can be removed, and the order can be imported into Receivables for invoicing.
See: Customer Acceptance, Oracle Order Management User's Guide.
The Delivery contingency requires proof of delivery before the contingency can be removed and revenue can be recognized.
The following table indicates each contingency that Receivables provides, and its corresponding removal event:
| Contingency Name | Contingency Removal Event |
|---|---|
| Cancellation | Contingency expiration date or expiration period |
| Customer Creditworthiness | Receipt application |
| Delivery | Proof of Delivery |
| Doubtful Collectibility Due to conditions such as:
|
Receipt application |
| Explicit Acceptance | Customer acceptance |
| Extended Payment Term | Receipt application |
| Fiscal Funding Clause | Contingency expiration date or expiration period |
| Forfeitures | Contingency expiration date or expiration period |
| Impaired Loans | Receipt application |
| Installation | Customer acceptance |
| Leasing Doubtful Collectibility Due to conditions such as:
|
Receipt application |
| Pre-Billing Acceptance | Invoicing |
| Refund | Contingency expiration date or expiration period |
Note: You can define your own contingencies, as well as defaulting rules for contingency assignment. See: Defining Revenue Contingencies, Oracle Receivables Implementation Guide.
Related Topics
Event-Based Revenue Management
Contingency-Based Deferred Revenue Report
Certain revenue contingencies place the likelihood of collectibility in doubt. For such transactions, you should not recognize revenue until you receive payment. Oracle Receivables automates this process with Payment-Based Revenue Management.
See: Contingencies for Payment-Based Revenue Management.
If certain revenue contingencies are found on an invoice, then:
The Revenue Management Engine initially defers revenue on the sum of all line balances, excluding taxes, freight, and late charges.
Note: If collectibility of a particular invoice line is doubtful, then Receivables defers revenue only for the line, not the entire invoice. See: Doubtful Collectibility.
When you apply a cash receipt to an invoice that is under collectibility analysis, Receivables analyzes the invoice to determine if deferred revenue exists.
Under certain circumstances, full or partial receipt application on an imported invoice can trigger automatic recognition of previously deferred revenue. In such cases, Receivables initiates the distribution of revenue in the amount of the applied receipt from an unearned revenue account to the appropriate earned revenue account.
If Receivables bases revenue recognition on receipt application, then the total amount of revenue that is recognized can never exceed the original amount due on the invoice line, less any applicable credit memos.
If you later need to reverse a receipt after application, then Receivables automatically moves the amount of the reversed receipt back to an unearned revenue account. See: Modifying Invoices Under Collectibility Analysis.
Note: If you are applying a receipt to an invoice with rules, but you haven't yet run Revenue Recognition, then Receivables automatically runs Revenue Recognition for that invoice only.
See: Evaluating Invoices for Event-Based Revenue Management.
Payment-based revenue management occurs when deferred revenue exists on the invoice due to these revenue contingencies:
Creditworthiness
You can select up to three credit classifications that indicate noncreditworthiness in the Revenue Policy page. See: Defining Your Revenue Policy, Oracle Receivables Implementation Guide.
Receivables uses information from Credit Management to determine a customer's creditworthiness.
If the Revenue Management Engine cannot associate the customer on the invoice with one of these three credit classifications, then the customer is presumed to be creditworthy.
However, if a customer can be associated with one of these three credit classifications, then Receivables assigns the Creditworthiness contingency to all invoice lines and the Revenue Management Engine defers the entire invoice amount.
Extended Payment Term
You can define the payment term threshold in the Revenue Policy page. See: Defining Your Revenue Policy, Oracle Receivables Implementation Guide.
If an invoice payment term exceeds the stated threshold, then Receivables assigns the Extended Payment Term contingency to all invoice lines and the Revenue Management Engine defers the entire invoice amount.
Collectibility of the following line items is typically in doubt, and should not be considered earned revenue until payment is received:
Late charges
Impaired loans
Lease payments for evergreen lease agreements
Miscellaneous leasing fees
Other fees
Decisions about doubtful collectibility are typically made in feeder systems, before AutoInvoice import occurs.
Important: If an invoice line is entered or imported with this contingency, then the Revenue Management Engine defers revenue only on the imported line, not the entire invoice amount.
Deferred revenue can exist on an invoice due to a combination of the contingencies listed above, as well as time-based contingencies. In such a case, applied payments initiate revenue recognition only if time-based contingencies have expired.
See: Event-Based Revenue Management When Multiple Contingencies Exist.
Receipt application has no impact on revenue recognition if:
The receipt is a miscellaneous receipt. Only standard (cash) receipts have potential revenue recognition implications.
You are applying a receipt against an invoice whose revenue was manually deferred by the Revenue Accounting feature using the RAM wizard.
You are applying a receipt against an invoice whose revenue was deferred by the Revenue Management Engine due to unexpired time-based contingencies.
In this case, Receivables keeps the revenue amount for that invoice line in the unearned revenue account, but flags it as revenue that is pending recognition until after the contingency expires.
Related Topics
Event-Based Revenue Management
Contingency-Based Deferred Revenue Report
When applying a partial receipt, Receivables uses a weighted average formula to calculate the revenue amounts to recognize for each line.
For example, you import a $350 invoice with three lines.
When you imported this invoice, the Revenue Management Engine deferred all revenue on this invoice because the customer was not creditworthy.
Later, you apply a receipt for $100 against this invoice. Because customer is not creditworthy, Receivables can recognize revenue only to the extent of the applied receipt. Because this is a partial receipt, Receivables must calculate how much revenue to attribute to each invoice line.
Receivables calculates the revenue for each line as follows:
Line 1 = $50
($50/$350) * $100 = $14.28571
Receivables rounds this amount down to $14.28.
Line 2 = $100
((($100+$50)/$350) * $100) - $14.28 = $28.5771
Receivables rounds this amount down to $28.57.
Line 3 = $200
((($200+$100+$50)/$350) * $100) - ($14.28 + $28.57) = $57.15
Receivables rounds the last amount up to account for the rounding of the previous lines.
For additional receipts against this invoice, Receivables calculates the revenue for each line using this same method.
Tip: You can also apply receipts at the line level. See: Applying Receipts in Detail.
Revenue that is recognized based on receipt application can never exceed the original amount due on the invoice line, less any applicable credit memos. Therefore, in the event of an overpayment, Receivables will not recognize the overpayment as revenue, even if you selected the Allow Overapplication check box on the invoice's transaction type.
These examples illustrate the impact of receipt applications on the event-based revenue management process.
You apply a payment for $200 against invoice 1001.
After reviewing the original invoice 1001, Receivables determines that this transaction was never eligible for automatic revenue recognition. This could be due to several reasons:
The invoice was not imported via AutoInvoice or created by the Invoice API.
A deferred accounting rule is assigned to the invoice.
Event-based revenue management was never activated for the invoice.
Either no revenue policy was entered in the System Options window, or contingencies did not exist on the invoice during import.
In this case, Receivables does not proceed with further analysis of this receipt. Applying a payment to invoice 1001 will not trigger revenue recognition.
You apply a payment for $600 against invoice 2002. The amount due on this invoice is $600.
Receivables reviews the original invoice 2002, and determines that the Revenue Management Engine deferred revenue on this invoice because the customer was not creditworthy.
Since the payment has now been received and applied against the invoice, Receivables recognizes the revenue by debiting $600 from the unearned revenue account and crediting $600 to an earned revenue account, according to the initially assigned accounting rules.
You apply a payment for $400 against invoice 3003. This invoice has 5 lines: Line 1 is $200, Line 2 is $450, Line 3 is $100, Line 4 is $700, and Line 5 is $550.
Receivables reviews the original invoice 3003, and determines that the Revenue Management Engine deferred revenue on this invoice because the invoice was assigned an extended payment term, Line 3 is associated with a non-standard refund policy, and Line 5 is associated with a cancellation provision.
The $400 receipt is a partial payment. Receivables prorates this payment across the invoice lines, based on a weighted average formula. However, for simplicity, assume that Receivables applies $80 to each invoice line.
Receivables recognizes revenue for Lines 1, 2 , and 4 in the amount of $80 each.
Receivables cannot recognize revenue for Lines 3 and 5 due to the unexpired time-based contingencies. However, Receivables flags the $80 payments for Lines 3 and 5 as amounts that are pending revenue recognition at a later date.
When the contingencies later expire, Receivables recognizes revenue for Lines 3 and 5 in the amount of $80 each. See: Monitoring Contingencies with the Revenue Contingency Analyzer.
Future receipts that you apply against this invoice will be analyzed in this same manner.
The Revenue Management Engine immediately defers revenue on any invoice line that is associated with a time-based contingency. Receivables uses the Revenue Contingency Analyzer to monitor contingencies until they expire.
Once a contingency expires, the Revenue Contingency Analyzer automatically initiates revenue recognition for the related invoice line(s).
Note: After a contingency period expires, the Revenue Contingency Analyzer does not initiate revenue recognition if other contingencies still exist which place into doubt the collectibility of the entire invoice. In this case, Receivables can recognize revenue only in the amount of applied receipts. See: Payment-Based Revenue Management.
The Revenue Contingency Analyzer is a concurrent program. You can define a submission schedule that controls how frequently the program will run. For example, you can define your schedule to run the program repeatedly at specific intervals, or on specific days of the week or month.
Note: Whenever you run the Submit Accounting program, Receivables first runs the Revenue Contingency Analyzer.
Time-based contingencies include:
Nonstandard refund policies
You define the standard refund period in the Revenue Policy page. See: Defining Your Revenue Policy, Oracle Receivables Implementation Guide.
An invoice line amount is deferred if the Refund contingency is found on an invoice line.
Fiscal funding clauses
An invoice line amount is deferred if the Fiscal Funding Clause contingency is found on an invoice line.
Cancellation provisions
An invoice line amount is deferred if the Cancellation contingency is found on an invoice line.
Forfeiture allowances
An invoice line amount is deferred if the Forfeiture contingency is found on an invoice line.
Acceptance clauses
An invoice line amount is deferred if the Acceptance contingency is found on an invoice line.
Acceptance clauses can be an exception. Sometimes your customer might send written acceptance before the acceptance period expires. In such cases, use the Revenue Accounting Management (RAM) wizard to record this early acceptance. Once recorded, Receivables determines if revenue recognition can be initiated for the invoice line:
If multiple contingencies exist on multiple invoice lines, then revenue recognition can occur at different times for different lines on the invoice. If multiple contingencies exist on a single invoice line, then revenue recognition for that line occurs only after the latest contingency expires.
If no unexpired contingencies remain on the invoice line, then Receivables initiates revenue recognition according to the initially assigned accounting rules.
If other unexpired contingencies remain on the invoice line, then Receivables does not initiate revenue recognition for the invoice line.
For example, you enter or import an invoice for a creditworthy customer, and one of the invoice lines is associated with both a nonstandard refund policy (50 days) and an acceptance clause (120 days). Receivables will not recognize revenue on this invoice line until the acceptance clause expires after 120 days.
If you obtain written acceptance from the customer after 80 days have elapsed, then use the Revenue Accounting Management (RAM) wizard to record the early acceptance. Since no other contingencies exist, this early acceptance triggers revenue recognition. Note that the GL date when you enter this early acceptance becomes the revenue recognition date for this invoice line.
A single invoice may contain both time-based contingencies, as well as contingencies that require payment before revenue can be recognized. In this case, revenue recognition will occur at different times for different lines on the invoice.
Upon receipt application:
Receivables recognizes revenue for lines that require only payment to initiate revenue recognition.
For the lines that are associated with one or more unexpired contingencies, Receivables keeps the revenue amount for that invoice line in the unearned revenue account, but flags it as revenue that is pending recognition until after the contingency expires.
For example, you enter or import an invoice for a customer who is not creditworthy. Additionally, Line 2 of the invoice is associated with a nonstandard refund policy (80 days).
The Revenue Management Engine initially defers the entire invoice amount to an unearned revenue account.
For all lines except Line 2, the Revenue Management Engine recognizes revenue in the amount of applied receipts only, according to the initially assigned accounting rules.
For Line 2, the Revenue Management Engine flags the amount of any applied receipts as pending revenue recognition. After the contingency expires, receipts that were already applied to Line 2 can be fully recognized as earned revenue.
Beginning on the 81st day, all future receipts applied to Line 2 will be immediately recognized as revenue.
In the examples below, the Revenue Contingency Analyzer runs every 30 days.
You enter a customer invoice with 6 lines. Lines 2 and 3 are associated with a fiscal funding clause (60 days) and Line 5 is associated with a cancellation provision (90 days).
Revenue for Lines 1, 4, and 6 can be fully recognized, either immediately or according to the invoice's initially assigned accounting rules.
After 60 days, the Revenue Contingency Analyzer runs and identifies that the fiscal funding clause on Lines 2 and 3 has expired. The Revenue Contingency Analyzer initiates revenue recognition in full for Lines 2 and 3.
After another 30 days, the Revenue Contingency Analyzer runs and identifies that the cancellation provision on Line 5 has expired. The Revenue Contingency Analyzer initiates revenue recognition in full for Line 5.
You import a customer invoice with 2 lines. Line 1 is $150 and Line 2 is $1,000. Line 2 is associated with an acceptance clause (60 days) and a cancellation provision (150 days). Additionally, the customer has been granted extended payment terms on this invoice.
Due to the existing contingencies, the Revenue Management Engine cannot recognize revenue for either line on this invoice.
After the first 30 days, the Revenue Contingency Analyzer runs, but does not initiate revenue recognition for either line on this invoice.
Another 15 days pass. You apply a $500 receipt against this invoice.
The $500 receipt is a partial payment. Receivables prorates this payment across the invoice lines, based on a weighted average formula.
Receivables recognizes revenue for Line 1 in the amount of $65.21.
Receivables cannot recognize revenue for Line 2 due to the acceptance clause and cancellation provision. Therefore, Receivables flags $434.79 for Line 2 as an amount that is pending revenue recognition.
Another 15 days pass. It has now been 60 days since the transaction date. The Revenue Contingency Analyzer runs on the 61st day, and identifies that the 60-day acceptance clause on Line 2 has expired. However, the $434.79 that is still pending cannot yet be recognized due to the cancellation provision.
75 days after the transaction date, you apply a $650 receipt against this invoice.
Receivables recognizes the remaining $84.79 in revenue for Line 1 and flags another $565.21 for Line 2 as an amount that is pending revenue recognition. The total amount for Line 2 that is pending revenue recognition is now $1,000.
On the 151st day, the Revenue Contingency Analyzer runs again and recognizes the entire $1,000 in revenue for Line 2.
Related Topics
Event-Based Revenue Management
Evaluating Invoices for Event-Based Revenue Management
Contingency-Based Deferred Revenue Report
Submitting a Request, Oracle Applications User's Guide
You can modify invoices or invoice lines that are still under collectibility analysis. Modifications to invoices include:
Manually adjusting revenue using the Revenue Accounting Management (RAM) wizard
Adjusting invoices
Modifying distributions or sales credits in the Transactions workbench
Crediting invoices
Incompleting invoices
Reversing receipts
When modifying invoices under collectibility analysis, however, you should be aware of the following:
You can use the RAM wizard to manually adjust revenue on an invoice or invoice line that is under collectibility analysis.
When you move revenue on an invoice or invoice line from an unearned to earned revenue account, or vice versa, Receivables removes the invoice or invoice line from further collectibility analysis. The invoice is no longer subject to automatic revenue recognition.
Note: Adjustments of sales credits performed with the RAM wizard do not impact future collectibility analysis, because you can use the RAM wizard to adjust sales credits only for revenue that has already been scheduled.
You can manually adjust an invoice that is under collectibility analysis. However, if the GL Account Source for the specified adjustment activity is Revenue on Invoice, then Receivables removes the invoice from further collectibility analysis after making the adjustment.
This is because Receivables calls the Revenue Adjustment API if revenue on the specified invoice is unearned. The Revenue Adjustment API uses AutoAccounting to derive the anticipated revenue accounting distribution accounts and amounts, thereby overriding the event-based revenue management process.
If you want Receivables to continue monitoring an invoice for automatic revenue recognition, then always use a credit memo to adjust an invoice under collectibility analysis.
You can manually change the accounting distributions and sales credits for an invoice that is under collectibility analysis. When making a change in either the Distributions window or Sales Credits window, Receivables removes the invoice from further collectibility analysis if:
You change an existing accounting distribution to a revenue account or unknown account in the Distributions window
You rerun AutoAccounting when you modify sales credits in the Sales Credits window
Warning: You should always use the RAM wizard, not the Transactions workbench, to adjust sales credits on a transaction, if that transaction's revenue was previously adjusted via the RAM wizard. See: Entering Revenue Credits.
If you issue a credit memo against an invoice whose revenue was automatically deferred upon import, then the impact of the credit memo differs depending on the original reason for the revenue deferral. This is applicable only if you set the Use Invoice Accounting for Credit Memos profile option to Yes.
For example, perhaps you apply a credit memo against an invoice whose revenue was initially deferred due to one or more contingencies, but was later partially recognized. A portion of this invoice's revenue, therefore, is still in an unearned revenue account.
If revenue on this invoice was deferred due to unmet payment-based contingencies, then Receivables always debits the unearned revenue account for the full amount of the credit memo, according to the initially assigned accounting rules.
Note: This is a departure from standard functionality. When you credit a typical invoice that is not under evaluation for event-based revenue management, Receivables prorates the amount of the credit memo between the earned and unearned revenue invoice amounts.
If the amount of the credit memo exceeds the amount of the unearned revenue on the invoice, and you selected the Allow Overapplication check box on the credit memo's transaction type, then Receivables records the excess amount as a debit to the unearned revenue account. You can optionally use the RAM wizard to clear the negative unearned revenue on this invoice.
If revenue on this invoice was deferred due to unexpired time-based contingencies, then Receivables always prorates the credit memo amount between the earned and unearned revenue amounts on the invoice. If a multi-period accounting rule exists on a line, then Receivables further prorates the credit memo amount across future periods.
See: Credit Memos Against Invoices Under Collectibility Analysis.
If you apply a credit memo against an invoice whose revenue was already manually adjusted via the RAM wizard, then Receivables follows standard credit memo functionality. Even if the invoice was initially analyzed for collectibility and acceptance, Receivables prorates the credit memo amount between the earned and unearned revenue amounts on the invoice.
In that case, you must confirm that the earned and unearned revenue on the invoice is stated appropriately for each period. If necessary, use the RAM wizard to make any further adjustments.
In the Transactions workbench, you cannot incomplete invoices that initially failed collectibility and acceptance analysis, and which are still under analysis for future event-based revenue management.
If you apply a receipt against an invoice whose revenue was automatically deferred upon import, and you later reverse that receipt, then the impact of the receipt reversal differs depending on the original reason for the revenue deferral:
If revenue on an invoice was deferred due to payment-based contingencies, then Receivables initiates revenue recognition whenever you apply a receipt to the invoice. If you reverse a previously applied receipt, then Receivables automatically unearns the previously earned revenue.
In some cases, you might apply a receipt against an invoice line, but Receivables cannot recognize revenue for that line due to unexpired time-based contingencies. Therefore, Receivables leaves the receipt amount as unearned revenue, but flags the amount as pending revenue recognition at a later date.
If you later reverse the receipt, then Receivables reflects the receipt reversal by simply removing that pending flag from the receipt amount.
If revenue on an invoice was deferred due to unexpired time-based contingencies only, then the reversal of a receipt does not impact the amount and timing of revenue recognition.
You import a customer invoice with 3 lines. All lines are associated with a nonstandard refund policy (90 days). In this case, Receivables recognizes revenue only upon the expiration of the 90-day period. Applying and later reversing a receipt against this invoice has no impact on the timing and amount of revenue recognition.
You import a customer invoice with 2 lines. Line 1 is $226 and Line 2 is $350. Line 2 is associated with a cancellation provision (120 days). Additionally, the Revenue Management Engine finds that the customer is not creditworthy.
You apply a receipt for $126 against this invoice. For simplicity, assume that Receivables applies $63 to each line.
Receivables recognizes revenue for Line 1 in the amount of $63.
Receivables cannot recognize revenue for Line 2 due to the cancellation provision. Therefore, Receivables flags $63 for Line 2 as an amount that is pending revenue recognition.
Several days later, you reverse the receipt.
Receivables automatically unearns the previously earned $63 in revenue for Line 1.
Receivables removes the pending flag that was assigned to $63 for Line 2.
After this receipt reversal, the entire amount of the invoice is in the unearned revenue account.
Related Topics