How to Settup Oracle Receivables in R12

As with any of the applications, the setup values you use provide the foundation on which the system is built. Having a complete knowledge of how Oracle Receivables uses the setups and what you can do to make them work for you are key to providing the strongest foundation possible.

There are almost as many setup screens as transaction screens in Oracle Receivables (which tells you something about the decisions you need to make). Some are more critical than others, they include: Transaction Types, AutoAccounting, System Options, Profile Options and the various payment related setups.

Transaction Types

First, what is a transaction? Oracle uses transaction as a catch-all term for invoices, credit memos, debit memos and commitments (activities you perform with the customer). Receipts may even be considered a transaction in some instances but I will exclude them from this discussion.

A Transaction Type is a name you give to a transaction. It:

- Provides the rule for how activities are processed, for instance, will there be tax and/or freight?

- Determines if this activity will be posted to the General Ledger

- Identifies the type of transaction: invoice, credit memo, debit memo, chargeback, deposit or guarantee

- Defines if this item will create an open receivable (appear on the aging)

- Provides the default accounts to use when processing this transaction

- Tells, if this is an invoice, the name of the related credit memo type.

The Transaction Type is also used to select what you wish to view on many of the standard reports and is usually displayed with each transaction on the reports and screens.

As you can see, it is a very powerful tool! And, with the proper planning, you can take advantage of it - without customizations!

By asking the following questions, you easily come up with a plan for defining what your Transaction Types will be and how you will use them.

1) List each Accounts Receivable account you wish to use. There should be at least one Transaction Type per account.

2) Do you have any transactions that exclude tax? Exclude freight? If this is not applicable for all of the transactions, make a list of which types will include tax and/or freight and which will not.

3) When reporting, what is the most important factor in grouping the data? Plant? International or Domestic? Type of business? Division?

- What is the next most important?

- And the next?

- And for each, what are the possible values?

4) Will you need to create any transactions that do not create journal entries? Any that do not create open receivables (items to appear on your aging)?

Why would you create a transaction that does not post to the General Ledger or crate an open receivable? Typical scenarios are proforma invoices (for customs): they need to look complete, professional and accurate. But, you really do not want to book the activity to the General Ledger or to create an open item for the Aging. You can set up a special Transaction Type and un-check "Post to GL" and "Create an Open Receivable."

Some companies with high volumes of credit card activities may check "Post to GL" but leave "Create an Open Receivable" as unchecked. They then use Journal Entries to post the cash and offset the Receivables account. How will this work for you?

5) Will you use Commitments? Deposits (where the customer gives you money up front and you just use it until you run out). Or, Guarantees (where the customer commits to buy a certain dollar amount and you track their sales to ensure that they do actually spend as much as they said they would).

Either of these options must be set up as specific Transaction Types with special Class values.

6) Will you use deferred revenue recognition (Unearned Account)? Deferred Receivables recognition (Unbilled Account)? If Yes to either, what will the Unearned Revenue and Unbilled Receivables accounts be and what Accounts Receivable account is associated with each?

7) Will you ever create debit memos? These may be for special activities such as creating Refund Checks, non-project related or non-order related sales (for example, scrap sales). If Yes, set up another Transaction Type.

Another consideration is how you name the Transaction Types. On most of the standard reports you can only see the first four characters of the name. If you call one Transaction Type "International Product Sales" and another "International Service" they will both appear as "Inte" on standard reports and you will have lost the distinction. With this in mind, I like to build "intelligence" into the name of the Transaction Types by assigning values to the 4 characters you can see. I assign a separate value to each character or assign a value to the first three characters and use the last character for the type of transaction.

This example is for a company where plant is the most important consideration, followed by international or domestic sale, followed by government or commercial customer and then by the type of activity. We set up the transaction types as follows:

1^st Character: P = Phoenix, W = Weston, K = Kings Beach

2^nd Character: I = International, D = Domestic

3^rd Character: C = Commercial, G = Government

4^th Character: I = Invoice, D = Debit Memo, C = Credit Memo

e.g., PIGI is a Phoenix, International, Government Invoice

WICI is a Weston, International, Commercial Invoice

Another example is where the first three characters represent the country that is legally responsible for the sale, while the last character indicates the type of transaction:

e.g., UKII = UK Invoice

FRAC = France Credit Memo

ITLD = Italy Debit Memo

Note that by using the Transaction Types to select which data to print on the standard reports, you can easily select all activity by the first character (e.g., plant - the first type that starts with P through the last type that starts with a P). However, to see just the international activity - based on the third character, you need to either use a custom report or run the report with multiple subsets of the data. It is still worth "coding" the Transaction Type since you can learn a lot about a transaction - all in the 4 characters.

After answering the questions and considering the naming conventions, you are ready to define your Transaction Types. The values you use should naturally fall out of the above process, but you need to take the next step, evaluating how AutoInvoice will work, since that will also impact how you define your types.

If most of your transactions are created outside of Oracle Receivables and imported using AutoInvoice, it is easy to use lots of different Transaction Types. If you are manually creating your transactions, 20 - 30 Transaction Types is probably a good maximum number (otherwise, they may be too overwhelming).

Note that if you are using Oracle Order Entry or Oracle Projects, using the vanilla set up, they both are set up to have very narrow options in terms of the default Transaction Types. One Transaction Type per Order Type and all Projects activity going to the Transaction Type of "PA Invoices." This is not consistent with all of the work you did above to define the specific Transaction Types. To get past this issue, I usually create a program that runs before AutoInvoice and updates the transactions with the applicable Transaction Types (overriding the defaults from the feeder system). This lets the other applications work the way they work, but still gives you the option to build "intelligence" into the types in Receivables.

Tip: I suggest that you always set up Transaction Types with the options set to never allow over application and to use Natural Application only; otherwise you have transactions that are confusing and difficult to undo.

AutoAccounting

AutoAccounting is the process that Oracle Receivables uses to assign default values for the key General Ledger accounts for Accounts Receivable activity. The accounts that use AutoAccounting include:

- Accounts Receivable

- Revenue

- Tax

- Freight

- Unearned Revenue (for deferred revenue recognition)

- Unbilled Receivables (for deferred receivables recognition)

- AutoInvoice Clearing (used for items created through AutoInvoice where the quantity * the unit price does not equal the Extended Amount).

AutoInvoice allows you to define the source of each segment (piece) of each of the above Accounting Flexfield values. These values are automatically used when you create transactions using AutoInvoice (the transaction import program) and are automatically provided (but may be overridden) when you create manual transactions.

The type of account you are defining determines the possible sources of the value. The sources are other setup screens that you have setup using the basic account values. AutoInvoice combines the values from the sources you specify for each segment to create what should be the perfect Accounting Flexfield for what you are doing. See Diagram A, AutoAccounting Worksheet for a representation of how this works. For instance, for the Receivables account, you can attain segment values from the Transaction Type or from the Salesrep. For Revenue, you also have the option of the using the Memo Line or Item account values to complete the segments. And, so on.

You need to ask yourself what is the lowest common denominator? Do we you salesreps? If not, could you use "dummy salesreps" as a way to achieve the accounting values that we want? Is the salesrep the lowest common denominator? Would they sell for multiple regions? Divisions?…

If salesreps work along lines that are similar to the way you wish to complete the account, they are often the best sources of the values. If not, you may need to define a few more Transaction Types. See Diagram B for a typical use of the AutoAccounting Worksheet.

To use the worksheet, list your Accounting Flexfield segments in the left column. Then, for each type of account, indicate (using the list of possible sources) the best source for each segment.

Once you have come up with a "straw model," test it out (a white board works well for this exercise). List the setups that would be entered for the sample salesrep, for the Transaction Type, etc. Then determine, if you used the values according to the sources indicated, what would the value be in each segment? Would the combination of segments result in a valid or invalid Accounting Flexfield? If any problems arise, reevaluate your assumptions and keep testing until you get what you really want.

Once you have tested outside of the system, setup Oracle Receivables with the values you determined and verify the combinations. If the results are anything other than what you expected, back to the drawing board until you are satisfied.

Note that if you are using Oracle Projects, they have a similar feature called "AutoAccounting." This is a much more powerful tool and it takes precedence over the values in Oracle Receivables for transactions imported from Projects to Receivables.

Receipt Setups

Setting up for receipts processing can be a confusing and seemingly redundant process with numerous interrelated steps that must be completed in the proper sequence. See Diagram C.

Again we need to start with definitions. A receipt is any form of payment, typically including checks, wires, credit card payments, and cash.

An "Automatic Receipt" is a process by which you withdraw funds directly from your customer’s account using either a Letter of Credit or a Direct Debit.

Automatic Lockbox is a process you use to load, verify and create receipts using information provided by your bank or service provider about the receipts they processed for you. Despite the name, these are NOT "Automatic Receipts."

As you are processing the receipts they have various status’s:

- Unidentified (when you do not know who the customer is)

- Unapplied (when you know the customer but all or part of the receipt has not yet been matched to open invoices)

- Applied (when 100% of the receipt has been matched to open invoices)

- On-Account (where you intentionally set aside payments as a pre-payment or cash in advance until the service or goods are provided or the invoice is created).

Miscellaneous Receipts are receipts that are not tied to Accounts Receivable activity. They may be for things such as COBRA payments, employee activities, investment income, employee postage, etc.

When setting up receipts, one of the key concepts is how the accounting is recorded.

When the receipt passes through the status’s of unapplied, on-account and unidentified, the proper accounts are noted in the system. For example; when applying a receipt to an invoice, the accounting is as follows:

Debit Credit

Cash Unapplied

Unapplied AR

When the payment is unapplied, it looks like:

Debit Credit

Cash Unapplied

When the payment is created as on-account, it looks like:

Debit Credit

Cash On-account

When you apply the unapplied amount:

Debit Credit

Unapplied AR

When you create a Miscellaneous Receipt:

Debit Credit

Cash The account(s) you assigned to the receipt and so on.

The Accounts Receivable account comes from the invoice to which you are applying the payment. The cash account is from the bank where the cash was deposited. In the initial entry, the unapplied, on-account and unidentified accounts are from the Receipt Sources setup. When they are re-applied, the unapplied account comes from the original transaction. There is no visibility to any of these accounts since it is all done for you behind the scenes.

The accounts you set up for unapplied, on-account and unidentified are critical to your processing and to your ability to reconcile the accounts. You define the Accounting Flexfields to use by bank account. You may use a different account for each (unapplied, on-account, unidentified) or the same account for all three. I recommend that you create at least one special account for unapplied, and if desired, other accounts for unidentified and on-account. Never use your Cash or Accounts Receivable accounts for your unapplied, on-account and unidentified accounts or you will cause yourself serious reconciliation issues. You can set the accounts to roll-up to the Accounts Receivable accounts, but they still should be separate. You should also make these stable accounts. When you change the account, activity may still use the original account (that you do not want to use anymore). If you do not change the account, you will not have a problem.

This accounting is 100% behind the scenes. You cannot change it and you have no visibility as to what is happening. The unapplied, on-account, unidentified, cash and discounts (earned (within the terms) and unearned (outside of the terms)) are all based on the values you enter for Receipt Sources. The Accounts Receivable account you use is the Accounts Receivable account assigned to the invoice when it was created.

The steps for setting up for receipts are described as follows:

Banks Where you set up your banks and bank accounts. Note that this information is shared with Accounts Payable. Even if you share actual bank accounts with Accounts Payable, you may want to define them as separate bank accounts in Oracle and use different GL Accounts for each. This will ease the reconciliation since a single account is not shared by users of two applications (you can always roll them together for financial reporting).

- Define if you will be using Automatic or manual receipts.

Receipt Classes

This setup is really used to define if you will be using Automatic Receipts or not and if so, how. Usually you only need to define one generic class such as "Cash" with a Type of "Manual."

Receipt Sources Where you combine bank accounts and receipt classes and assign the default accounts for Cash, Unapplied, Unidentified, On-Account, Earned Discounts and Unearned Discounts. This is the most critical step for the accounting. This is also the name the user sees when entering the batch information.

If you are using Automatic Lockbox, you have additional setups:

Lockboxes Where you assign the bank, provide the lockbox number, and define the basic rules as to how the data is to be processed.

Transmission Formats Where you define in detail the layout of the data to be received from the bank. The data must exactly match this description or you will have results other than what you expect or it just will not work. Note the you must also create a SQL*LOADER control file (in the $AR_TOP/bin directory) that exactly mirrors the values in this setup, or again it will not work. Oracle provides standard definitions called Default (based on standard banking layouts), change as needed.

Note that if you can have payment of more than 398 invoices on a single receipt, you will need to increase the length of the overflow sequence field from the default length.

For more efficient processing, I suggest you include both the number of the invoice to be paid, and the amount to be paid (as indicated on the remittance advice).

Otherwise, Oracle Receivables applies until it runs out of money which may not be what the customer had intended. Then you have to go back in and change it -- why do the extra work?

You will need to work with your bank to ensure that the data you receive is in the format you expect. Even with minor changes in the current layout, it may take weeks for the bank to respond so be sure to allow for this in your schedule. Allow for several test loads from the bank and be sure to let them know when you are ready to start using the new format.

I have not included any explanations for setting up Automatic Receipts since I have never known of anyone who used this feature.

System Options

For Oracle Receivables, you have two places for entering high level rules for how the system is to process your data: the System Options screen (in Oracle Receivables) and the Profile Options (updated by the System Administrator). Both are critical to how the system works.

System Options encompass various areas:

- Accounting Options

- Tax Options

- Invoices and Customers Options

- Miscellaneous Options

Use Accounting to:

- Assign this instance to the proper set of books. This is key if you want to pass anything to Oracle General Ledger;

- Define the default accounts for currency exchange gains and losses, taxes, and unallocated revenue;

- Determine how to deal with discounts;

- Indicate whether or not you want interest charges (as calculated as part of the statement process) to be added to the customer balance.

Use Tax to:

- Define how you will process taxes;

- Assign the Sales Tax Location Flexfield;

- Decide how to format the tax information on documents such as invoices.

Note that even if you use the default Sales Tax Location Flexfield you must key over it and then save in order to initiate the processes to create the applicable views. This is critical for any tax processing.

Use Invoices and Customers for:

- Tuning AutoInvoice (if your Message Level is higher than one and you do not really need to trace your data, you greatly increase your run time). Set to "1" unless you have a problem you need to research.

- Defining how you wish customer and address numbering to occur. Note that you can import your existing customers prior to going live using the old number and then switch to automatic numbering once you go live.

- Deciding whether or not you will allow deletion of incomplete invoices (usually OK).

- Indicating if you will allow payment of unrelated invoices. This is helpful if you occasionally have one customer pay the bills for another customer and you do not want to create relationships. But, note that this is touchy area regarding possible kiting of funds.

Use Miscellaneous for:

- Defining parameters for the Collections Effectiveness Indicators report;

- Indicating how information is to appear on the printed documents such as invoices;

- Specifying if you will require a salesrep on a transaction (based on your business);

- Deciding if you will require an address to apply receipts (rarely a good idea but there may be reasons to do this for your business).

You also have the ability to determine the due dates for chargebacks (when the customer short pays a specific invoice and you create a new invoice for the difference). I recommend that you always use the "Invoice Due Date" for the Chargeback date otherwise, you are rewarding the customer for short paying.

Profile Options

Profile Options are additional rules that are critical for how the system works. They are updated by the System Administrator and are usually set at the site level

System Options for Oracle Receivables usually start with "AR:" or "Tax:" But, you need to watch out for "OE: Inventory Validation Organization" which you must define whether or not you are using Oracle Order Entry or Oracle Inventory. Select the applicable value.

For the Accounts Receivable values the following are the most critical:

AR: Allow Transaction Batching - If you enter small volumes of manual transactions, it is not necessary to use batches for transactions. If you enter high volumes, you should use batching for transactions. You should always use batching for receipts since you get immediate feedback of what you have done and any potential problems.

AR: Cash Allow Actions - As part of the cash application process, the applier has the option to create adjustments (write-offs) and chargebacks if you set this option to Yes. I recommend that you do that, you can always control the amounts they write-off using approval limits.

AR: Cash - Default Amount Applied - Always set so the default is the amount remaining on the receipt, not the amount remaining on the invoice. If you allow the receipt amount to default to the invoice balance, this allows you to apply more than you really have.

AR: Change Customer Name - In reality customers change their names and this is a valuable feature but, I recommend that you set it "Yes" only after to have been live for a few weeks. This is a good way to keep novice users from overlaying good names with invalid names, until the know what they are doing.

AR: Close Period - Run Collections Effectiveness - I recommend that you set this option to "No." Most users do not use this report and it will just slow the close process.

AR: Update Due Date - Allow change to due date. In rare instances it is desirable to change the due date on an invoice (for example, you have negotiated this with the customer). By setting this profile option to "Yes," you have the option of doing this. What this really does is to allow you to make your aging look better. Consider whether or not this is desirable in you business situation.

AR: Use Invoice Accounting For Credit Memo - In most cases, if you know the original invoice, it is desirable to offset the accounts that were used for the invoice when creating the related Credit Memo. This option allows you to do that.

Receivable Activities

Receivables Activities are set up in Oracle Receivables for several uses:

- Miscellaneous Cash (non-Accounts Receivable receipts)

- Adjustments (write-offs for transactions)

- Finance Charges.

They allow you to pre-define the default values for activities you will typically perform. You can control procedurally whether or not the default GL Accounts should be overriden and, if so, how? (for example, override to use the appropriate department).

Note that when you create adjustments, they automatically offset the Accounts Receivable account. You never want to set up these activities using your Accounts Receivable account (that way you have created a wash entry). The accounting for a negative adjustment looks like:

Debit Credit

Account (from AR (From the

the activity) invoice)

Typically you will want to minimally set up the following values:

For Adjustments:

- Freight Adjustment (if applicable).

- Tax Adjustment (if applicable).

- Finance Charges - Even if you do not use Statements or Dunning Letters, you still may want to account for interest paid. For example, the government will pay interest if they pay late, whether you ask for it or not.

- Bank Fees (specially applicable if you receive payments via wires).

- Small Balance Remaining - It is usually easier to write these off rather than to collect them. This activity generally uses a "cost of doing business" account.

- Bad Debt - Write-off un-collectable items to your bad debt account.

- Inter-company Offsets - If you have intercompany receivables for which you do not receive actual payments but which you need to offset (i.e., to a special intercompany account)

For Miscellaneous Receipts:

- COBRA payments

- Bank Fees

- Company Activities

- Employee Postage

- Other (catch all)

Watch the setup of these accounts. If you use Account Security, you need to be allowed access to all of the possible accounts for miscellaneous cash (and the list can often include most anything).

Conclusion

You now have tips for what you can do with the set ups. Now all you have to do is to give them a try and test, test, test!

About the Presenter

Cathy Cakebread, an independent consultant, specializes in Oracle Financials implementations and upgrades. Cathy has over nineteen years’ experience in designing, developing, and implementing financial applications and was one of the original designers of Oracle Receivables and Revenue Accounting.