http://www.cathycakebread.com/papers/_accouting.

htm
Accounting For Oracle Receivables
Cathy Cakebread, Consultant
Almost everything you do in Oracle Receivables has an accounting impact, but you may be unsure of
what that impact is, where to find the information and where the values came from. Learn how
AutoAccounting works, the accounting transactions associated with the standard activities, and which
setups determine the values. When I am illustrating how the accounting works, I have noted the source of
the value in the parenthesis ( ).
Flow of Accounting Information
First, it is important to understand where the values come from, how you pass the values to Oracle
General Ledger and how to verify the values.
If you are using Oracle Order Entry (without customizations), no accounting information is available until
you run AutoInvoice. You pass the transactions to Oracle Receivables using the Receivables Interface.
You then run AutoInvoice which creates the actual transactions and uses AutoAccounting to derive the
segment values for the GL Accounts. If you are using Oracle Projects the account segment values are
derived by a Projects process also called AutoAccounting and passed as values to Oracle Receivables
via the Streamline process, also using AutoInvoice.
Whether you are manually entering your receipts or processing them through AutoLockbox, the
accounting information is automatically determined by Oracle Receivables when you create and apply the
receipts (not when it is still a "QuickCash" batch). The values used are based on the setup values for the
bank where the receipts were deposited and the invoices they are paying.
General Ledger Interface
You pass accounting information from Oracle Receivables to Oracle General Ledger using the General
Ledger Interface. If you have properly set up Oracle Receivables, you should never have to create
manual journal entries in your General Ledger and the two systems should always be in sync.
When you invoke the General Ledger Interface process, you initiate multiple programs that:
Finds all of the records for the period you specified that have not yet been passed to the General
Ledger;
Determines if the debits equal the credits;
Passes the data to GL for editing; and
Marks the records as having been passed (so they will not pass twice).
If you have specified that you want the Journal Import to also run, this process verifies that the
individual segments and combinations of segments are valid. Only when the Journal Import
completes successfully are the Journals available for posting.
Tip: Always run the General Ledger Interface using the starting date of the period through the last day of
the period. This is applicable no matter when you are running the process or if you know you will never
have activity for that date, since sometimes the system uses dates other than the dates you expect.
Depending on which patches you have applied, you may or may not see the Unposted Items Report. If
this report does run, always check each page to ensure that you have no items that could not be passed
to the General Ledger. If anything besides headings appears, work with your IT department to resolve
(since this is usually caused by a bug).
Verify that the amounts in the General Ledger Interface Report are reasonable and that the debits equal
the credits.
Verify that the Journal Import has a status of "SUCCESS." If not, you had a problem that will need to be
resolved or none of the items in the batch will be available for posting. Generally you have a problem if an
account was valid when the activity was created, as you know, you cannot save with invalid values but,
someone has since disabled either a segment or the combination. An example of this is your Accounts
Receivable account that may have been valid when the invoice was originally created but it is not longer
valid, and a receipt was just applied against it. When you apply a receipt to an invoice it always causes an
offsetting entry against the original Accounts Receivable account.
Should this occur, I suggest that you:
1. Re-enable the segment or combination;
2. Re-run the Journal Import (in GL -- be sure to include the applicable id);
3. Create a manual journal entry (also in GL) to move the activity from the bad account to
the proper account (this is my one exception to never creating manual journal entries);
and
4. Re-disable the segment or combination.
By making the corrections in this way you are able to keep your GL in sync with your AR activity and you
have an audit trial of what you did to make the correction. You have the option to correct in the Import
Corrections form (in GL), but you lose the audit trail of what you did and why. I also recommend noting
what you did and why and storing the notes in a handy binder so you will be prepared when the auditors
ask why you did what you did.
Journal Entries Reports
The Journal Entries reports are the best way to verify the actual accounting for Oracle Receivables
activities and the only way to view the accounting for the foreign currency gains and losses. There are
actually four reports that give you varying levels of details regarding the journal entries you will be
creating or have already created. These reports may be run at anytime before or after you run the
General Ledger Interface. Your options are: Detail by Account (very large), Summary by Account, Detail
by Category (also large) and Summary by Category.
Tip: I always recommend that you at least run the Summary by Category and review to insure that there
are no invalid or illogical accounts, prior to running the General Ledger Interface. If you find funny
accounts, you can correct or create offsetting entries prior to posting. Run the Detail by Category (just for
that category and account) to see which specific activities used the funny account. Correct the activity if
possible. If not possible (i.e., adjustment), create an offsetting entry using the proper account.
Tip: If you run this report for Unposted Items only, you must leave the Posted Date range blank or
nothing will appear on the report.


Period Close Procedures
Tip: I suggest that you never have more than one AR period open at one time. There have been
problems with entries appearing partially in one period and partially in another. Also, you may accidentally
enter activities in a period other than the period you intended.
Create a checklist to insure that you always know where you are and what you have to do next, so you
will not forget anything.
Balance your AR activity to the Aging:

Old Aging Balance (Aged Trial Balance - 7 Buckets by Account)
+
+
+
New Invoices
Debit Memos
Chargebacks
(Transaction Register)
(Transaction Register)
(Transaction Register)
- Credit Memos (Transaction Register)
- Receipts Applied (Applied Receipts Register)
+/- Unapplied Activity (Unapplied Receipts Register)
+/- Adjustments (Adjustment Register)
- Items Not Aged (Invoice Exceptions Report)

-----------------------


New Aging Balance (Aged Trial Balance - 7 Buckets by Account)
Also balance your AR activity to your GL activity using the Journal Entries Report - Summary by Category
and the Account Analysis report (in GL). Note any manual journal entries that used "your" accounts.
Accounting Details
The GL Accounts may or may not appear on the form (depending on what you are doing) but almost
every activity you perform has an accounting impact. In order to understand this impact it is necessary to
know:
1) what accounts are impacted by each transaction;
2) what are the related set ups;
3) what you may change and/or override and what is out of your control.


AutoAccounting
AutoAccounting a very powerful setup feature that tells Oracle Receivables how to determine the
individual segment values for your Transactions (invoices, debit memos, credit memos, chargebacks and
commitments) using the rules that you specify. You may use this feature when creating Transactions
manually or through AutoInvoice. The types of accounts impacted by AutoAccounting include:
(Accounts) Receivable
Revenue
Tax
Freight
Unearned Revenue (for deferred revenue recognition)
Unbilled Receivable (for deferred receivables recognition)
AutoInvoice Clearing (for problems with extended amount)
Possible sources of this information are the values you set up for the following:
Transaction Types
Salesreps
Standard Lines (Items or Memo Lines)
Taxes
And/or hard coded values.
You may get one segment value for one type of account from a different place than for another. See
Appendix 1 for an example of a typical AutoAccounting setup.
You can use a similar worksheet to test the setup of your AutoAccounting rules. List your Accounting
Flexfield segments in the left column. For each type of account select the source of each segment (based
on the list of available sources) and fill in that box. Test your theory by listing what all the setup accounts
would be for a Transaction Type, Salesrep, Item, Tax and Memo Line. Then use a white-board and fill
in each segment, for each type of account, with the values from each of the related sources. Verify that
the combinations are actually valid, if not, redesign how they will be set up or redefine your
AutoAccounting rules. Once you are satisfied with the results, enter your AutoAccounting rules into your
test system and start creating manual invoices. Verify that you have not created invalid account values as
the defaults.
Tip: I prefer to assign all segments to sources versus using hard coded values. This seems more flexible
for future changes.

Invoices
When you create an invoice either through AutoInvoice or manually, you take advantage of
AutoAccounting to provide the default Accounting Flexfield values. For manual invoices you have the
option to override the default values.
For a standard Invoice:
DR AR (AutoAccounting - may
override)
CR Revenue (AutoAccounting -
may override)

Tax (AutoAccounting - may
override)

Freight (AutoAccounting -
may override)
You may also create invoices with special accounting and invoicing rules that allow you to defer revenue
recognition for the percentage and number of periods that you specify. The following is an example of an
invoice created with deferred revenue recognition for $12,000 split evenly over 12 periods:
For invoices with deferred revenue:
When first created:
DR AR (AutoAccounting - may
override) 12000
CR Unearned Revenue
(AutoAccounting) 12000

Unearned Revenue
(AutoAccounting) 1000

Revenue (AutoAccounting -
may override) 1000
For each of the next 11 periods:
DR Unearned Revenue
(AutoAccounting) 1000
CR Revenue (AutoAccounting)
1000
If you are using deferred revenue recognition, you need to run the revenue recognition process for each
period (Run Revenue Recognition) and runs automatically as part of the General Ledger Interface.
Tip: To reduce the time it takes to close the period, run Revenue Recognition prior to the time when you
are actually closing (e.g., the night before the close). This will process the majority of the updates prior to
the actual close.
Recurring Invoices (Transaction Copy) are treated like regular invoices, except they have different GL
dates. Once you have created an invoice copy, it really is just another invoice with different dates.
Debit Memos
Debit memos work just like standard invoices (you even create them on the same forms) -- taking
advantage of AutoAccounting but with overridable segments. If you defined Memo Lines for use with
your debit memos, they will provide the default accounting segments if you have set up AutoAccounting
to use Standard Lines values for your Revenue accounts.
Credit Memos And On Account Credits
There are two types of credit memos: credit memos that you create to offset an individual invoice are
called "Credit Memos." Credit memos that impact a customers account but are not initially tied to a
specific invoice are called "On-Account Credits." On-account credits may be tied to invoice(s) using
the Receipts Applications window, at any time. The accounting for Credit Memos usually offsets the
applicable accounts from the original invoice (if you set your System Profile option AR: Use Invoice
Account For Credit Memo to "Yes"). Credit memos and on-account credits that are created using
AutoInvoice take advantage of AutoAccounting and/or hard coded values. You may override the default
values if you are entering manually.
Credit Memo tied to an invoice:
DR Revenue (from the related
invoice - may override)
CR AR (from the related
invoice - may override)

Tax (from the related
invoice - may override)


Freight (from the related
invoice - may override)

On-account credits take advantage of AutoAccounting and Standard Lines (Memo Lines) depending
on how you set up your AutoAccounting rules for the default credit and debit GL Accounts. You may
override the default values at entry time if you are entering manually.
DR Revenue (Memo Line -
may override)
CR AR (AutoAccounting - may
override)
When you apply an on-account credit to invoice(s), you debit the credit account you used when you
created the on-account credit. The Accounts Receivable account for the invoice being offset is credited.
You may not override these values.
DR AR (from the On-Account
Credit)
CR AR (from the invoice)
Cash Receipts (Excluding Miscellaneous Receipts)
The accounting for receipts, except for Miscellaneous Receipts, is totally controlled behind the scenes by
Oracle Receivables. The GL Accounts are determined by the values you defined in Receipt Class for the
batch.
NOTE: You have one Cash, Unapplied, On-Account, Unidentified, Earned Discount and Unearned
Discount account for each bank and class, which does not allow you to split the Unapplied, etc. accounts
for the applicable cost center or division.
You may set up different values for each bank and class that you use (especially important for the cash
account). Or, you may share the GL Accounts for multiple bank accounts (i.e., the unapplied and discount
accounts). The key accounts are:
Your cash account (the default debit account for that bank account);
Tip: Often AP and AR share the same bank account but it is helpful to use a different but sequential GL
account for each. This eases the reconciliation but you can roll together for FSG reporting.
Your unapplied payments account (the default used until you match the payment to an invoice);
Your on-account account (used to account for pre-payments until you apply them to invoice(s));
Your unidentified account (used for receipts where you do not know which customer sent the
receipt);
Tip: Often companies use the same GL Account for unapplied, on-account and unidentified. This
is fine as long as: the account is not used for anything else and it is not an Accounts Receivable
or cash account.
Your earned and unearned discount accounts (used when a client pays invoices in accordance
with the early payment terms. These are also often the same. Earned discounts are for payments
made within the discount terms, unearned discounts are paid after the discount term but are
allowed anyway.
When you match a receipt to an invoice, the cash account (debit) defaults from the Receipt Class for the
Receipt batch. The Accounts Receivable account (credit) defaults from the invoice that is being paid.
NOTE: Even if you instantly match a payment to an open invoice, Oracle still creates credits and debits to
the unapplied account.
Payment applied to an invoice without discount terms:
DR Cash (Receipt Class) CR Unapplied (Receipt Class)

Unapplied (Receipt Class)

AR (from the invoice)

Payment applied to an invoice with discount terms:
DR Cash (Receipt Class) CR Unapplied (Receipt Class)

Unapplied (Receipt Class)

AR (from the invoice)

Discount (Receipt Class)


When you leave a receipt as unapplied:
DR Cash (Receipt Class) CR Unapplied (Receipt Class)

When you identify a receipt is as a pre-payment or deposit:
DR Cash (Receipt Class) CR On-Account (Receipt
Class)

For unidentified receipts:
DR Cash (Receipt Class) CR Unidentified (Receipt
Class)

When you apply unapplied, on-account or unidentified receipts, the accounting is determined by the
original status. The accounts used are based on the accounts you currently are using for the Receipt
Class. The Accounts Receivable account still comes from the invoice.
DR Unapplied (Receipt Class)
On-Account (Receipt
Class)
or Unidentified (Receipt
Class)
CR AR (from the invoice)

When you unapply a receipt, the accounting is just the opposite of the application accounting. You debit
the AR account for the original invoice and credit the unapplied account based on the current unapplied
account for the Receipt Class:
DR AR (from the invoice) CR Unapplied (Receipt Class)

When you reverse a receipt, you have two possible options: re-open the invoices you previously paid or
create a debit memo for the amount of the reversed payment. If you re-open the invoices, the system
offsets the accounts used when you originally applied the payment (from the invoice and the cash
account). Note that this process also impacts the unapplied account.
DR Unapplied (Receipt Class) CR Cash (Receipt Class)

AR (from the invoice)

Unapplied (Receipt Class)

If you create a debit memo, you credit the original cash account but debit the Accounts Receivable
Account for the Debit Memo type you selected. You may override the Accounts Receivable account when
you enter the payment reversal.
DR AR (Transaction Type -
may override)
CR Cash (Receipt Class)
Chargebacks
You create Chargebacks when you are applying cash to close the original invoice and create a new
invoice for the amount that the customer short paid. By definition, there is a one to one relationship
between a Chargeback and the original invoice. You need to set up values for Chargebacks in 3
places: Receivables Activity where you specify the "wash" account used when creating a
Chargeback. Transaction Types where you specify the default AR account. A Memo Line
("Chargeback Line") is seeded by Oracle but it is just used for the line description when you print the
Chargeback and has no accounting impact. The Accounts Receivable account for the new invoice is
based on the Accounts Receivable account for the Chargeback but you may override it at entry item.
Oracle credits the Accounts Receivable account for the original invoice (note that these two accounts may
be different).
In the Category of Adjustment:
DR Chargeback Adjustment
(Receivables Activity)
CR


In the Category of Adjustment (AR):
DR

CR AR (from the original invoice)

In the Category of Chargeback:
DR

CR Chargeback Adjustment (Receivables
Activity)

In the Category of Chargeback (AR):
DR AR (from the chargeback -
you may override)
CR


In the Category of Trade Receipts:
DR Cash (Receipt Class) CR


In the Category of Trade Receipts (AR):
DR Unapplied (Receipt Class) CR AR (from the original invoice)

Unapplied (Receipt Class)
Miscellaneous Receipts
Miscellaneous Receipts are any receipts that are not for open receivables. Examples include Cobra
payments, T-shirt sales, utility refunds, and returns on investments. Due to the nature of this activity, you
may need to credit any account within the chart of accounts. The Distribution Window in the Receipts
form allows you to do just that. You may run into an Account Security Rule set up to restrict usage of
accounts by application. If you find that you may not use an account that you need, work with your
System Administrator to change the Account Security Rules.
You may pre-define the credit accounts that you usually use to speed entry (using Receivables Activity)
but you also have the flexibility to override the values at entry time. You also have the ability to split a
single receipt into multiple accounts (you may also pre-define those accounts using Distribution Sets).
If you will always be splitting the accounts, you should define a Distribution Set. A distribution set is a
name and one or more GL Accounts and percentages that you define. You must create a Receivable
Activity that refers to the Distribution Set.
When you enter Miscellaneous Receipts, you refer to the Receivables Activities that you defined above.
However, you may override the default GL Accounts, the individual segments, the percentages and/or the
amounts. The cash account used defaults based on the Receipt Class for the bank you specified on the
Batch Screen, and you may not override or view the value.
DR Cash (Receipt Class) CR Miscellaneous Account(s)
(Receivables Activity or
Distribution Set - may
override)
Receivable Adjustments
Receivable Adjustments are generally write-offs, or changes to the invoice balance due for over- or
under-payment by the customer, or the addition of finance charges. Pre-define commonly used
adjustment types using theReceivables Activity form. This speeds entry, but you may override the
default values as you enter the adjustments. NOTE: Always define a GL Account and not a Distribution
Set when you define Receivable Activities for adjustments.
Tip: When entering an adjustment, never use an Accounts Receivable Account. Oracle Receivables
already automatically offsets the AR account for the invoice being adjusted and you will create a wash
entry.
A Receivables Adjustment is always applied to a specific invoice so it impacts the Accounts Receivable
account for that invoice. Receivables adjustments may either be positive (debit AR, and increase the
invoice balance) or negative (credit AR and decrease the invoice balance). Examples include:

Add a finance charge (note that this is a positive adjustment that increases the balance due):
DR AR (from the invoice) CR Finance Charges
(Receivables Activity -
may override)
Reduce the freight amount:
DR Freight (Receivables
Activity - may override)
CR AR (from the invoice)
Write-off the invoice balance:
DR Cost of Doing Business
(Receivables Activity -
may override)
CR AR (from the invoice)
You may use AutoAdjustments to perform mass cleanup of open invoices and on-account credits. The
Accounts Receivable account credited is the Accounts Receivable account for the transaction. The
account debited is based on the Receivables Activity you select when you submit the AutoAdjustment
process. Note that ALL adjustments made during this process will use that exact same "write off" account
even if the original invoices are for different companies, or cost centers. This may be a consideration in
determining if you can actually utilize AutoAdjustments, or if you want to run multiple passes of
AutoAdjustment by Transaction Type and Adjustment Activity.
Foreign Currency Gains and Losses
Transactions that are not in your base currency may cause gains or losses to occur due to fluctuations in
the exchange rates. This is automatically accounted for by Oracle Receivables. When you enter the
Transaction, the applicable exchange rate for the date you enter it is stored with the transaction. When
you enter the related receipt the applicable exchange rate for the date you enter the receipt is stored with
the receipt. The gain or loss is determined based on the difference in the value of the money (in your
base currency) between when the invoice was created and when the receipt was created. The gain and
loss accounts are derived based on the values in yourSystem Options and how you set up Flexbuilder.
Note that most companies use the default setup for Flexbuilder. Note that there is no gain or loss if you
apply an adjustment since both the adjustment and the invoice use the same rate. You can predict Gains
and Losses using the Projected Gains/Losses Report. You can only view the gain/loss accounting
activity by running the Journal Entries Report.
Gain - now worth more:
DR Cash (Receipt Class at the
receipt rate)
CR AR (from the invoice at the
invoice rate)

Unapplied (Receipt Class
at the receipt rate)

Unapplied (Receipt Class
at the receipt rate)

Gain (System Options -
difference between the
invoice and receipt values)
Loss - now worth less:
DR Cash (Receipt Class at the
receipt rate)
CR AR (from the invoice at the
invoice rate)

Unapplied (Receipt Class
at the receipt rate)

Unapplied (Receipt Class
at the receipt rate)

Loss (System Options -
difference between the
invoice and receipt values)

Conclusion
By knowing the sources and the accounting impact of each activity and the ways to track and reconcile
that activity, you have greater control over the outcome of your data and greater confidence that the
processes work as you expect.
About the Author
Cathy Cakebread -- Consultant
I am an independent consultant specializing in implementing and upgrading Oracle Financials, primarily
Oracle Receivables. I have over twenty years experience in designing, developing and implementing
financial software and I was one of the original designers of Oracle Receivables and Revenue
Accounting. I have been an independent consultant since 1990.






APPENDIX1:
ORACLE RECEIVABLES
AUTOACCOUNTING WORKSHEET -- EXAMPLE
Release 10
ACCOUNTING
FLEXFIELD
SEGMENTS
AUTO
INVOICE
CLEARING
FREIGHT RECEIVABLE REVENUE TAX UNBILLED
RECEIVABLE
UNEARNED
REVENUE
(Possible Default
Sources)
-Salesreps*
- Standard
Lines
-Transaction
Types
- Salesreps
- Standard
Lines
-Transaction
Types
-Salesreps
-Transaction
Types
-Salesreps
-Standard
Lines
-Transaction
Types
- Salesreps*
- Standard
Lines*
- Taxes
-Transaction
Types
-Salesreps*
-Standard Lines
-Transaction
Types
-Salesreps*
-Standard
Lines
-Transaction
Types
Company Type Type Type Type Tax Type Type
Business Unit Type Type Salesrep Salesrep Tax Type Type
Cost Center
(division)
Type Type Salesrep Salesrep Tax Type Type
Account Type Type Type Line Tax Type Type
Subaccount Type Type Type Line Tax Type Type
Activity Type Type Type Line Tax Type Type
Location Type Type Type Line Tax Type Type

Special use AutoInvoice -
where

- Bill in Arrears - Bill in
revenue not =
qty * price
- Guarantees Advance
- Guarantees
- Deposits

POSSIBLE SOURCES OF INFORMATION INCLUDE:
SALESREPS
TRANSACTION TYPES
STANDARD INVOICE LINES
TAX RECORDS
* = not really filled in on those screen