Accounting for Receivables

Opening and Closing Accounting Periods

Open and close accounting periods in your calendar to control the recording of accounting information for these periods. Receivables lets you open future accounting periods while your current period is still open. Receivables also lets you reopen previously closed accounting periods and enter receivables activities without transferring transactions to the general ledger when you set your accounting periods to 'Future.'

Define your receivables calendar in the Accounting Calendar window. Receivables references the statuses of these accounting periods to control transaction entry and journal entry creation to your general ledger. You cannot enter an activity in a closed accounting period.

When you close an accounting period, Receivables automatically generates the Collection Effectiveness Indicators report.

Period Status

An accounting period can have one of the following statuses:

Closed: Posting and transaction entry are not allowed unless the accounting period is reopened. Receivables verifies that there are no unposted items in this period. Receivables does not let you close a period that contains unposted items.

Note: In Oracle Receivables unposted items are those which have not been finally accounted in Receivables. These items may or may not have been posted to General Ledger.

Close Pending: Similar to Closed, but does not validate for Unposted items. Posting and transaction entry are not allowed unless the accounting period is reopened.

Note: Before using the Close Pending status, you must run Revenue Recognition for transactions with accounting rules.

Future: This period is not yet open, but you can enter transactions in this period. However, you cannot post in this period until you open it.

Not Opened: This period has never been opened but you can enter transactions in this period. However, you cannot post in this period until you open it.

Open: Transaction entry and posting are allowed.

Prerequisites

• Define your ledgers, Oracle General Ledger User Guide

• Define your accounting periods, Oracle General Ledger User Guide

• Define your accounting calendar, Oracle General Ledger User Guide

To open or close an accounting period:

1. Navigate to the Open/Close Accounting Periods window.

2. To update the status of an accounting period, place the cursor in the Status field next to that period, then enter a new status.

   Note: Note: You cannot close an accounting period if there are any unprocessed accounting events or unposted journal entries in Oracle Subledger Accounting (SLA) for the period. You can identify the incomplete transactions by running the Period Close Exceptions report for Journal Source Receivables, and take any of the following actions to close the period:

   • Change the GL_DATE on the transaction to move it to next open period.

   • Complete the transaction.

   • Delete the transaction.

3. To open the next accounting period after the Latest Open Period, choose Open Next Period. Receivables changes the status of the next period to 'Open.'

Related Topics

Entering Transactions

Accounting in Receivables

You create accounting entries for invoices and other transactions in Oracle Receivables using the Oracle Subledger Accounting architecture.

Oracle Subledger Accounting is a rule-based accounting engine, toolset, and repository that centralizes accounting across the E-Business Suite. Acting as an intermediate step between each of the subledger applications and Oracle General Ledger, Oracle Subledger Accounting creates the final accounting for subledger journal entries and transfers the accounting to Oracle General Ledger.

Receivables includes a set of predefined accounting rules that Subledger Accounting uses to create accounting, but you can define your own detailed accounting rules using a centralized accounting setup in a common user interface.

Leveraging this accounting architecture, Receivables lets you:

• Store a complete and balanced subledger journal entry in a common data model for each business event that requires accounting

• Maintain multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements

• Retain the most granular level of detail in the subledger, with different summarization options in the general ledger, allowing full auditability and reconciliation because the link between transaction and accounting data is preserved

For more information about Subledger Accounting, see: Oracle Subledger Accounting Implementation Guide.

How Does Accounting in Receivables Work?

Each business event that has accounting impact is called an accounting event. See: Receivables Accounting Event Model.

For each accounting event, Receivables uses AutoAccounting to derive the default accounting. You then submit the Submit Accounting program to create the accounting in Subledger Accounting. (Receivables predefines setup in Oracle Subledger Accounting so that the Submit Accounting program accepts the default accounts that AutoAccounting derives without change.) See: Creating Accounting in Receivables.

Finally, Subledger Accounting transfers the final accounting to Oracle General Ledger. See: Posting.

You can optionally define your own accounting rules in Subledger Accounting to create accounting that meets your business requirements. See: Subledger Accounting Setup for Receivables, Oracle Receivables Implementation Guide and Oracle Subledger Accounting Implementation Guide.

If you customize the Subledger Accounting setup to create your own accounting, then Subledger Accounting overwrites the default accounts, or individual segments of accounts, that AutoAccounting originally derived during transaction entry. However, you must still set up AutoAccounting. See: Using AutoAccounting.

Related Topics

Oracle Subledger Accounting Implementation Guide

Multi-Fund Accounts Receivable

Multi-fund accounts receivable is an optional accounting feature that lets you post invoices, receipts, debit memos, credit memos, and adjustments to multiple balancing segment values or funds.

A fund is a source of money. Public sector entities have multiple funds in a single transaction. Examples of typical public sector funds include a general operating fund, an endowment fund, and a gift fund. Every fund has a different purpose and a different reporting requirement.

Many public sector entities must report the amount of cash that was deposited and disbursed by fund. To assist public sector organizations in meeting their reporting requirements, Oracle Financials provides predefined application accounting definitions that can be assigned to the subledger accounting methods. The predefined accounting definitions used for multi-fund accounts receivable are:

• Multi-Fund Accrual - Account Method

• Multi-Fund Accrual - Balancing Method

These accounting definitions let agencies track receivables, receipts, and adjustments by fund. With multi-fund accounts receivable, you can:

• Post multiple matching revenue and receivables entries to many different operating funds

• Create matching cash receipts, adjustments, and discount journal entries against the receivables balances in all necessary operating funds

• Record revenue, tax, and freight in multiple funds within a single invoice

• Automatically record matching receivables balances in each corresponding fund

Important: For a multi-fund accounts receivable, you should first create accounting for the invoice and only after that for the receipt. This is because the receipt derives the CCIDs from the invoice.

Related Topics

Multi-Fund Accounts Receivable Balancing and Accounting Method Example

Cash Receipts in Multi-Fund Accounts Receivable Model

Credit Memo Examples

Multi Fund Accounts Receivables Receipt Examples

Adjusting Multi-Fund Accounts Receivable Invoice Examples

Receivables Accounting Event Model

An accounting event is a business event in Oracle Receivables that has accounting impact. For example, creating or applying a receipt is an accounting event. Not all business events have accounting impact; you can modify the accounting setup to create accounting for some events and not for others.

In Oracle Subledger Accounting, accounting events are categorized into event types. Event types are grouped into event classes that in turn are grouped into event entities. The overall grouping of these components is called an event model. The Oracle Receivables accounting event model is predefined for you, and includes each Receivables transaction type (event class) and its life cycle. You should understand the Receivables accounting event model because the model classifies Receivables accounting events, which are the basis for creating subledger accounting.

As the foundation of the event model, Receivables predefines event entities. An event entity enables Oracle Subledger Accounting to handle the accounting for similar business events in a consistent manner. The event entities for Receivables are as follows:

• Transactions

• Receipts

• Adjustments

• Bills Receivable

Each event entity is associated with one or more event classes. An event class represents a category of business events for a particular transaction type or document. For example, some event classes that Receivables predefines for the event entity Transactions include Receivables Invoice, Credit Memo, Debit Memo, and Chargeback.

Event classes group similar event types and enable the sharing of accounting definitions. An event type represents a business operation that you can perform for an event class. An accounting event has both an event class and an event type that affect how the Submit Accounting program determines the subledger accounting for it. Event types provide the lowest level of detail for storing accounting definitions. For example, the Receivables event class Miscellaneous Receipt is subject to three types of business operations that are represented by the following event types: Miscellaneous Receipt Created, Miscellaneous Receipt Reverse, and Miscellaneous Receipt Updated.

Receivables provides a predefined set of event classes and event types for each accounting event entity. For detailed information on the accounting entities, event classes, event types, and other data that Receivables predefines, see: Predefined Setup for Oracle Subledger Accounting, Oracle Receivables Reference Guide.

Transactions Event Entity

This table describes the event classes and types that Receivables predefines for the Transactions event entity.

Event Class	Event Types
Chargeback	Chargeback Created
Credit Memo	Credit Memo Created Credit Memo Updated
Debit Memo	Debit Memo Created Debit Memo Updated
Deposit	Deposit Created Deposit Updated
Guarantee	Guarantee Created Guarantee Updated
Invoice	Invoice Created Invoice Updated

Receipts Event Entity

This table describes the event classes and types that Receivables predefines for the Receipts event entity.

Event Class	Event Types
Miscellaneous Receipt	Miscellaneous Receipt Created Miscellaneous Receipt Reverse Miscellaneous Receipt Updated
Receipt	Receipt Created Receipt Reverse Receipt Updated

Adjustments Event Entity

This table describes the event classes and types that Receivables predefines for the Adjustments event entity.

Event Class	Event Types
Adjustment	Adjustment Created

Bills Receivable Event Entity

This table describes the event classes and types that Receivables predefines for the Bills Receivable event entity.

Event Class	Event Types
Bills Receivable	Bill Receivable Created Bill Receivable Updated

Using AutoAccounting

AutoAccounting is a powerful, flexible, and time saving feature that automatically creates your general ledger Accounting Flexfields. You can set up AutoAccounting to create Accounting Flexfields that meet your business needs.

When you run AutoAccounting, Receivables:

• Assigns valid Accounting Flexfields to your invoices and credit memos.

• Automatically generates valid Accounting Flexfields for your Freight, Receivable, Revenue, AutoInvoice Clearing, Tax, Unbilled Receivable, and Unearned Revenue Accounts.

• Controls how your Accounting Flexfields are created and defined.

AutoAccounting and Oracle Subledger Accounting

The default accounting that AutoAccounting creates is considered interim accounting only. Receivables integrates with Oracle Subledger Accounting, the E-Business Suite's centralized accounting engine, which accepts the default accounts that AutoAccounting derives without change. However, you can modify the accounting rules in Subledger Accounting to create accounting that meets your business requirements. See: Accounting in Receivables.

Automatic Accounting Flexfield Creation

Receivables automatically creates default Accounting Flexfields for your revenue, freight, receivable, and tax accounts for each invoice and credit memo. AutoAccounting also creates the proper unearned revenue or unbilled receivable accounting entries you need when you use invoicing and accounting rules. You can quickly enter your invoices and credit memos without worrying about entering the correct account.

User Definable Structure

AutoAccounting lets you determine how to create your Accounting Flexfields. For each Accounting Flexfield segment, you can choose to use a constant value or have Receivables derive it from a specific table. For example, you may have a four-segment Accounting Flexfield like this: 01-100-2025-345. With AutoAccounting, you can specify that the first segment is a constant, the second segment is determined by the salesperson, the third segment is determined by the transaction type, and the fourth segment is determined by the product.

Important: Receivables uses AutoAccounting to derive the default accounting, and predefines setup in Oracle Subledger Accounting so that the Submit Accounting program accepts the default accounts that AutoAccounting derives without change. However, if you modify the Oracle Subledger Accounting setup to define custom accounting, then select a constant value for all Accounting Flexfield segments.

User Changeable Defaults

AutoAccounting always lets you override the default Accounting Flexfields.

Related Topics

AutoAccounting Structure

How to Use AutoAccounting

AutoAccounting, Oracle Receivables Implementation Guide

Defining AutoAccounting - Overview

To implement AutoAccounting, define your AutoAccounting structure using the Automatic Accounting window. Then, define information for each salesperson, transaction type, product, and tax code for AutoAccounting to properly create your default accounts. If AutoAccounting cannot determine all of the Accounting Flexfield segments, it will create what it can and display an incomplete Accounting Flexfield. You must provide any missing Accounting Flexfield information before you can complete your transaction. See: AutoAccounting, Oracle Receivables Implementation Guide.

Related Topics

Using AutoAccounting

AutoAccounting Structure

AutoAccounting Structure

Receivables automatically creates default Accounting Flexfields for your Freight, Receivable, Revenue, AutoInvoice Clearing, Tax, Unbilled Receivable, and Unearned Revenue Accounts. You must define your AutoAccounting structure before you can enter invoices and credit memos and you can only define one structure for each account type.

Variable	Description
AutoInvoice Clearing Account	AutoInvoice uses the AutoInvoice Clearing account for your imported transactions. Receivables uses the AutoInvoice clearing account to store any differences between the specified revenue amount and the price times the quantity for imported invoice lines. Receivables only uses the AutoInvoice clearing account if you enabled the Create Clearing option for the batch source of your imported invoices; however, you must define a clearing account in either case. You can select constant, customer bill-to site, salesperson, transaction type, and standard item values for your AutoInvoice clearing account. If you select salesperson or standard item, the Revenue Flexfield that you specified in the setup window is used.
Freight	The freight account controls the account in your general ledger to which you post your freight amounts. You can use constant, customer bill-to site, salesperson, transaction type, and standard item values to specify your freight account. If you choose standard item, the Revenue Flexfield that you specified in the setup window is used. In addition, if you choose standard item you will not be able to import invoices with header level freight through AutoInvoice. If the transaction has a line type of "LINE" with an inventory item of freight, "FRT", AutoAccounting will use the accounting rules for the freight type account rather than the revenue type account.
Receivable	The receivable account controls the account in your general ledger to which you post your receivable amounts. You can use transaction types, customer bill-to sites, salespeople, and constant values to specify your receivable account.
Revenue	The revenue account controls the account in your general ledger to which you post your revenue amounts. You can use transaction types, customer bill-to sites, standard items, salespeople, and constant values to specify your revenue account.
Tax	The tax account controls the account in your general ledger to which you post your tax amounts. You can use information from your tax codes, customer bill-to site, salesperson, transaction type, standard item, and constant values to specify your tax account. If you select salesperson or standard item, Receivables uses the Revenue Flexfield that you specified in the setup window.
Unbilled Receivable	Receivables uses the unbilled receivable account for transactions that have invoicing and accounting rules. If your accounting rule recognizes revenue before your invoicing rule bills it, Receivables posts this amount to your unbilled receivable account. You can select constant, customer bill-to site, salesperson, transaction type, and standard item values for your unbilled receivable account. If you select standard item, Receivables uses the Revenue Flexfield that you specified in the setup window. If you select salesperson, Receivables uses the salesperson's Receivable Flexfield.
Unearned Revenue	Receivables uses the unearned revenue account for transactions that have invoicing and accounting rules. If your accounting rule recognizes revenue after your invoicing rule bills it, Receivables posts this amount to your unearned revenue account. You can select constant, customer bill-to site, salesperson, transaction type, and standard item values for your unearned revenue account. If you select salesperson or standard item, the Revenue Flexfield that you specified in the setup window is used.

Below is a table showing what types of information you can use to create each type of account. (Rec) and (Rev) indicate whether the account information will be taken from the corresponding Receivables or Revenue Accounting Flexfield.

Information Source / AutoAccounting Type	Constant	Customer Bill-to Site	Salesperson	Transaction Type	Standard Item	Tax Code
AutoInvoice Clearing Account	Yes	Yes	Yes (Rev)	Yes	Yes (Rev)	No
Freight	Yes	Yes	Yes	Yes	Yes (Rev)	No
Receivable	Yes	Yes	Yes	Yes	No	No
Revenue	Yes	Yes	Yes	Yes	Yes	No
Tax	Yes	Yes	Yes (Rev)	Yes	Yes (Rev)	Yes
Unbilled Receivable	Yes	Yes	Yes (Rec)	Yes	Yes (Rev)	No
Unearned Revenue	Yes	Yes	Yes (Rev)	Yes	Yes (Rev)	No

If you set up AutoAccounting for AutoInvoice Clearing, Tax, or Unearned Revenue to be based on salesperson, Receivables uses the account segment from the Salesperson's Revenue Flexfield. If AutoAccounting for Unbilled Receivable is based on salesperson, Receivables uses the segment from the salesperson's Receivable Flexfield. If AutoAccounting for AutoInvoice Clearing, Tax, Unbilled Receivable, or Unearned Revenue is based on the standard item, Receivables uses the segment from the standard item's Revenue Accounting Flexfield.

Note: If AutoInvoice Clearing, Revenue, Tax, Unbilled Receivable, or Unearned Revenue are based on Salesperson, and there are multiple salespersons, then multiple distributions will be created. For example, you have $100 of Unearned Revenue based on Salesreps, and you have two salesreps. One salesrep gets 60% revenue credit and the other gets 40%. Then, two distributions will be created for Unearned Revenue - one for $60 and the other for $40.

Related Topics

How to Use AutoAccounting

AutoAccounting, Oracle Receivables Implementation Guide

How to Use AutoAccounting

Define how you want Receivables to create your default Accounting Flexfields in the Automatic Accounting window. You can use this window to define the information source for each segment of your freight, receivable, revenue, AutoInvoice clearing, tax, unbilled receivable, and unearned revenue accounts.

Important: Receivables uses AutoAccounting to derive the default accounting, and predefines setup in Oracle Subledger Accounting so that the Submit Accounting program accepts the default accounts that AutoAccounting derives without change. However, if you modify the Oracle Subledger Accounting setup to define custom accounting, then select a constant value for all Accounting Flexfield segments.

Below are two examples of how Receivables uses the AutoAccounting structure you define to determine your Accounting Flexfield defaults:

Example 1

If you want to define a four segment Revenue Flexfield, 00-000-0000-000 (Company-Cost Center-Account-Product), you can define AutoAccounting to create defaults for each segment. The first segment can be a constant 01, the second segment can come from the salesperson (John Doe), the third segment can come from the transaction type (Standard Invoice), and the fourth segment can come from the standard line (20 Megabyte Hard Disk). Salesperson John Doe enters a one line Standard Type invoice for a 20 Megabyte Hard Drive.

Using AutoAccounting to Create Flexfield Segments

Example 2

If you want AutoAccounting to only use information from the transaction type (Standard Invoice) for segments 1 and 2, and standard line (consulting services) for segments 3 and 4, you can define your AutoAccounting structure to create the revenue Accounting Flexfield.

Using AutoAccounting to Create Flexfield Segments

Creating Accounting in Receivables

For each accounting event, Receivables uses AutoAccounting to derive the default accounting. You then submit the Submit Accounting program to actually create accounting entries in Oracle Subledger Accounting. Receivables predefines setup in Oracle Subledger Accounting so that the Submit Accounting program accepts the default accounts that AutoAccounting derives without change.

You can optionally define your own accounting rules in Subledger Accounting to create accounting that meets your business requirements. If you do so, then Subledger Accounting overwrites the default accounts, or individual segments of accounts, that AutoAccounting originally derived. However, you must still set up AutoAccounting. See: Using AutoAccounting.

Submitting the Submit Accounting Program

From the Submit Requests window, run the Submit Accounting program in either draft mode, if you want to review the results before you create the final accounting, or final mode.

For a description of the program parameters, see: Create Accounting Program, Oracle Subledger Accounting Implementation Guide.

During program submission, if you create final accounting, then those entries are automatically transferred to Subledger Accounting's interface table and, depending on other entered parameters, imported by the Journal Import program and posted in General Ledger. Draft accounting cannot be transferred to General Ledger. See: Posting.

At the conclusion of the process, the Submit Accounting program generates the Subledger Accounting Program Report. See: Oracle Subledger Accounting Program Report, Oracle Subledger Accounting Implementation Guide.

You can also create accounting entries from the Transactions window for a specific transaction, in either draft or final mode. See: Creating Accounting Information.

Prerequisites

• Open the period in Receivables. See: Opening and Closing Accounting Periods.

• Set up AutoAccounting. See: Using AutoAccounting.

• Set up receivables activities. See: Receivables Activities, Oracle Receivables Implementation Guide.

Related Topics

Viewing Accounting Lines

Using Oracle Subledger Accounting Inquiries

You can query accounting events, journal entries, and journal entry lines based on multiple selection criteria. You can perform the following subledger accounting inquiries:

• View information about an accounting event or journal entry error

• View detailed information about the subledger journal entry headers for an accounting event

• Compare subledger journal entry information for any two journal entries

• View subledger journal entry lines for multiple documents or transactions

• View subledger journal entry in a t-account format

• View transactions for an accounting event or journal entry

Related Topics

Accounting Events Inquiry, Oracle Subledger Accounting Implementation Guide

Subledger Journal Entry Headers Inquiry, Oracle Subledger Accounting Implementation Guide

Subledger Journal Entry Lines Inquiry, Oracle Subledger Accounting Implementation Guide

Oracle Subledger Accounting Reports

Oracle Subledger Accounting provides accounting reports that you can run from an Oracle Receivables responsibility to review accounting information:

• Journal Entries report

• Account Analysis report

• Third Party Balances report

• Multiperiod Accounting reports

• Subledger Period Close Exceptions report

• Open Account Balances Listing

Related Topics

Subledger Accounting Reports Overview, Oracle Subledger Accounting Implementation Guide

Open Account Balances Listing, Oracle Subledger Accounting Implementation Guide

Posting

To initiate the transfer of Receivables accounting information from Oracle Subledger Accounting to Oracle General Ledger, run the Create Accounting program in final mode. When you create final accounting, the Create Accounting program transfers data about your adjustments, chargebacks, credit memos, commitments, debit memos, invoices, and receipts to a Subledger Accounting interface table and, depending on other entered parameters, runs Journal Import and posts the journal entries in General Ledger.

Or, you can create draft accounting first; later, when you create the final accounting, you can complete the transfer and posting process. Draft accounting entries cannot be transferred to General Ledger.

See: Accounting Program Defaults Region, Oracle Subledger Accounting Implementation Guide.

Reconcile Customer Balances

To internally reconcile your outstanding account balances before submitting the Create Accounting program, use standard Oracle Receivables reports. For more information, see: Reconciling Receivables.

Posting Detail

Depending on your subledger accounting options setup, you can post to the general ledger in either summary or detail. See: Subledger Accounting Options Setup Description, Oracle Subledger Accounting Implementation Guide.

Posting Reports

When you run the Create Accounting program, the program automatically generates the Subledger Accounting Program Report. This report documents the results of the Create Accounting program at either the summary or detail level. See: Oracle Subledger Accounting Program Report, Oracle Subledger Accounting Implementation Guide.

Related Topics

Reconciling Receivables

Reconciling Receivables

Periodically, you need to reconcile the transactions in your accounts receivable system, both before and after you post to the general ledger. Oracle Receivables reduces the amount of manual reconciling activity typically required and simplifies the overall reconciliation process by:

• Providing a set of reports that let you quickly and easily view how transactional and accounting data tie together.

• Highlighting potential reconciling items whose underlying causes can be corrected, to prevent future occurrences of similar errors.

This section describes the recommended Receivables reconciliation process, which consists of two main phases:

1. Internal reconciliation: Reconcile the period's operational activity with Receivables accounting data, before posting to the general ledger.

   See: Reconciling Subledger Details.

2. External reconciliation: After posting, reconcile subledger details with the general ledger.

   See: Reconciling General Ledger Details.

Related Topics

Reconciling Subledger Details

Reconciling General Ledger Details

Reconciliation Reports

Reconciling Subledger Details

Reconcile the subledger internally before posting to promote a smoother transfer process from Oracle Receivables to the general ledger. This pre-posting activity also minimizes the amount of manual journal entries that might later be required in the general ledger, thus ensuring that you maintain adequate supporting detail in the subledger for future audit purposes.

Receivables provides a comprehensive set of reports to help reconcile outstanding customer balances, transactions, receipts, and account balances. Before posting to the general ledger, use these reports to research transactions and receipts and the different accounts that they affect, for a given period:

1. Use the AR Reconciliation report to compare transactional data against accounting data.

2. Optionally run the Potential Reconciling Items report to view suggested journal items that might potentially post to incorrect GL account types.

3. Run the Journal Entries report to confirm that the actual GL accounts are correct.

   The Journal Entries report shows the transaction and receipt numbers that contribute to a particular GL account. Run this report using the Detail by Account parameter to review the details that make up your general ledger journal entries. This report selects all transactions that will be posted to the general ledger (where associated transaction type has Post to GL set to Yes).

   Note: The Journal Entries report can generate multiple reports. The 'Detail by Account' version of this report is probably most useful for reconciliation purposes.

4. Run the Aging - 7 Buckets - By Account or the Aging - 4 Buckets report to view beginning and ending customer balances. See: Aging Reports.

5. For a more detailed look at the period's activity, run the registers and journal reports.

   Use this table to see which registers and journals to run for which type of accounting data.

   Accounting Data	Accounting Report	Related Transaction Report
   Beginning balance	Not applicable	Aging - 7 Buckets - By Account or Aging - 4 Buckets
   Transactions accounting data	Sales Journal by Account (for account type of Receivables)	Transaction Register (for postable items)
   Adjustments accounting data	Adjustments Journal	Adjustment Register
   Not applicable	Not applicable	Invoice Exception Report (for non-postable items)
   Unapplied receipts accounting data	Unapplied Receipts Journal	Unapplied and Unresolved Receipts Register
   Applied receipts accounting data	Applied Receipts Journal	Applied Receipts Register
   Not applicable	On-Account Credit Memo Gain and Loss Journal	Not applicable
   Ending balance	Not applicable	Aging - 7 Buckets - By Account or Aging - 4 Buckets

   See: Reconciliation Reports.

   The AR Reconciliation report uses the following formula to ensure your period activity matches your receivables aging ending balance:

        Beginning Balance
   +    Transactions
   +/-  Adjustments
   -    Invoice Exceptions
   -    Applied Receipts
   -    Unapplied Receipts 
   +/-  Credit Memo Gain/Loss
   =    Ending Balance
   

After identifying and correcting in Receivables those items that did not reconcile, run the Submit Accounting program to initiate the transfer of Receivables data into the general ledger. See: Posting.

After posting, you are ready to reconcile the posted data. See: Reconciling General Ledger Details.

The following illustration describes the above internal reconciliation process.

Related Topics

Reconciling Receipts

Reconciling General Ledger Details

Reconciling Receivables

Receipt Journal

Sales Journal by Customer

Reconciling Receipts

This section describes how to use register and journal reports to reconcile receipts according to the receipt life cycle (confirmed, remitted, cleared), from a cash perspective. This is different from reconciling receipts from a customer balance perspective, which is discussed in Reconciling Subledger Details.

This type of reconciliation, which looks at both trade and miscellaneous receipts, does not employ the AR Reconciliation report. Instead, use the reports described in this table.

Accounting Data	Accounting Report	Related Transaction Report
total receipts (trade plus miscellaneous)	Receipt Journal	Receipt Register

1. Periodically check that Receivables receipts balance by running the Receipt Journal report and the Receipt Register for the same GL Date range.

   • Use the Receipt Journal to view information about receipts that appear in your Journal Entries report. Use the Receipt Register to review a list of receipts for the date range that you specify.

   • The total of the Receipt Journal should equal the total of all receipts in the Receipt Register. These reports display information about both invoice-related and miscellaneous receipts.

   Submit the two reports from either the Print Accounting Reports or Submit Requests window. Select the same GL Dates for the two reports and choose a Report Mode of 'Transaction' to run the Receipt Journal. Transaction mode gives you full details of all the accounts debited or credited during the receipt creation, remittance, and clearance processes. The alternative, 'Balance' mode, gives details of the final account balance only.

2. Run the Other Receipt Applications report to view details about receipt activity that do not impact customer open receivables.

   Run this report to view details about activities such as receipt write-offs and credit card refund activities. (The credit memo associated with a credit card refund affects the customer open receivable balance and is displayed on the Transaction Register.)

Note: You can also use Oracle Cash Management to reconcile your deposits with a bank statement. See: Reconciling Bank Receipts Using Oracle Cash Management.

Related Topics

Receipt Journal

Receipt Register

Reconciling General Ledger Details

Reconciling Receivables

Reconciliation Reports

Reconciling General Ledger Details

After you internally reconcile Oracle Receivables data (see: Reconciling Subledger Details) and post to the general ledger, complete the external reconciliation process. The external reconciliation process includes two main steps:

1. Confirm that what was sent from Receivables matches what was posted in Oracle General Ledger.

   Posting from Receivables operates through Oracle Subledger Accounting, and consists of two stages: General Ledger transfer and posting.

   Run the Create Accounting program to extract transaction and receipt data from Receivables, create final accounting in Subledger Accounting, and then transfer the accounting into Oracle General Ledger and post the journal entries. Receivables provides reporting tools to track and reconcile the posting process.

   See: Reconciling the General Ledger Transfer Process.

2. Confirm that all journals posted to the correct GL accounts.

   See: Verifying GL Accounts.

Reconciling the General Ledger Transfer Process

Follow these recommended reconciling steps:

1. The Create Accounting program produces the Subledger Accounting Program report that shows you the subledger journal entries created for successful accounting events. Compare this report to the Journal Entries report (run in Posted status mode) and verify that they match. Use the same General Ledger date ranges for the Journal Entries report and the Create Accounting program.

   See: Oracle Subledger Accounting Program Report, Oracle Subledger Accounting Implementation Guide.

2. When reconciling the Journal Entries report with the Subledger Accounting Program report, review the total untransferred items that appear on the report as well.

   If some transactions cannot successfully post to the general ledger due to invalid GL accounts, then make corrections, and rerun draft accounting.

3. Once transactions and receipts have been transferred to Oracle General Ledger, they are considered posted within the Receivables subledger.

Reconciling the Journal Import Process

Journal Import lets you create detail or summary journal entries in Oracle General Ledger. Choose the Detail option to see the transaction detail in your General Ledger. In this case, the program creates one journal line for each transaction. You can see this information when you run the Unposted Journals report from the General Ledger, or online using the Account Inquiry window in the General Ledger. Choose the Summary option if you do not want the invoice detail in your General Ledger and simply want the debits and credits summarized by account. In this case you will see one journal line for each accounting flexfield, per currency, instead of one journal line per invoice line. See: Posting.

Follow these recommended reconciling steps:

1. Journal Import produces an execution report that shows you the total debits and credits for the journals it created. These totals should match the totals on the Posting Execution report.

   Note: Journal import is run by Group ID, which is equivalent to the post control ID from the General Ledger Transfer program execution report.

2. To see your journals, run the Unposted Journals report from General Ledger. The grand totals on this report should match the Journal Import Execution report. Confirm transfer dates with journal dates, in case multiple transfers occurred.

   Note: If you choose the Detail option when you run Journal Import, the invoice and customer numbers appear in the description of your journal lines so you can easily see the invoices that affect each account.

3. Once you have run the Oracle General Ledger Post Journals program, view posted journal entries by running the General Journals report (submitted for posted journals). The grand totals on this report should match the totals on the Journal Import Execution report. This allows a direct comparison of what was transferred by Receivables to what is posted in the general ledger. See: General Journals Report - Posted Journals, Oracle General Ledger User's Guide.

Report Options

Be sure to use the same General Ledger Date ranges and accounting periods when running these reports:

• Submit the above reconciliation reports from the Print Accounting Reports or the Submit Requests window.

• Submit the Posted and Unposted Journals reports from Oracle General Ledger.

Verifying GL Accounts

Run the AR to GL Reconciliation report to verify that all Receivables journal entries posted to the correct GL accounts.

Note: If the GL account you are reviewing has had postings from other journal sources, such as Oracle Payables, be sure to account for these postings when reconciling Receivables with General Ledger. Postings from non-Receivables journal sources, summarized on the AR to GL Reconciliation report, might explain balance discrepancies between Receivables and General Ledger.

After making corrections where necessary, the reconciliation process is complete.

The following illustration describes the external reconciliation process.

Related Topics

Posting

Reconciling Receivables

Reconciliation Reports

Using Cash Basis Accounting

Receivables supports two methods of accounting: Cash Basis and Accrual. Depending on your business needs, you can set your Accounting Method to either Accrual or Cash Basis in the System Options window.

Cash Basis accounting recognizes revenue and expense when cash is actually spent or received. For example, revenue from sale of goods is recognized when payment is received from the customer, not when an invoice is created.

The Accrual accounting method recognizes revenue when it is earned and expenses when they are incurred. In the above example, revenue from sale of goods is recognized when the invoice is created.

If you choose cash basis as your accounting method, but actually sell goods to customers on credit, Receivables provides a system to keep track of your receivables without affecting your financial accounts.

Related Topics

Accrual vs. Cash Basis Accounting

Journal Entries

Preparing Receivables

Defining Receivables System Options, Oracle Receivables Implementation Guide

Accounting for Transactions (Accrual method)

Accrual vs. Cash Basis Accounting

Receivables handles transactions differently depending on the method of accounting you use. This table outlines major differences between accrual and cash basis accounting.

Accrual Accounting	Cash Basis Accounting
Creation of transactions such as invoices, debit memos, deposits and chargebacks affect the account balances immediately.	There is no effect on the account balances until payment is received to close the transactions.
Accounting Rules may be used to recognize revenue across different periods.	Accounting Rules are redundant as revenue will be recognized only when payment is received.
Receipts can be reversed using the Standard Reversal or Debit memo reversal.	Receipts can be reversed using the Standard Reversal only. Debit Memo reversal is not permitted.
Automatic receipts, such as Direct Debits, affect the cash balance only when the receipts are cleared.	Automatic receipts affect the cash balance on the maturity date, if the GL date = maturity date or on the GL date, if the GL date is after the maturity date.
Deposits and Guarantees both affect on-account balances in Receivables.	Guarantees do not affect on-account balances since there is no exchange of cash. In the case of deposits, the cash collected on deposits will be posted to the revenue account of the deposit instead of that of the invoice against the deposit. Use the Other Application report to view all invoices against deposits.

Adjustments (Cash Basis Accounting)

When you create an adjustment that has the same sign as that of the related transaction, the adjustment amount goes to a separate adjustment account, instead of increasing the balance of the original revenue account.

Consider an example of an invoice created for $1000, followed by an adjustment for $100. The full amount of $1100 is paid off. The following journal entry in the table below is created when cash is received:

Account	Debit	Credit
Cash	$1100
Revenue		$1000
Adjustment		$100

You have to set up an adjustment account (which is the same as the revenue account) if you want the adjustment to hit the original revenue account. In this case the journal entry would be as follows in this table:

Account	Debit	Credit
Cash	$1100
Revenue		$1000 (Original amount)
Revenue		$100 (Adjustment)

In case of multiple line invoices, Receivables creates a separate account to record the full adjustment. Consider an example in the table below:

Account	Debit	Credit
Cash	$1100
Line #1 Revenue		$800
Line #2 Revenue		$200
Adjustment		$100

If you want to prorate the adjustment across the two revenue accounts, you will have to specifically enter two adjustments of $80 and $20 each to hit the two different revenue accounts. In this scenario, the journal entry would be as follows in the table below:

Account	Debit	Credit
Cash	$1100
Line #1 Revenue		$800 (Original amount)
Line #1 Revenue		$80 (Adjustment)
Line #2 Revenue		$200 (Original amount)
Line #2 Revenue		$20 (Adjustment)

If you make an adjustment that has an opposite sign to the transaction it is adjusting, Receivables does not record the adjustment in a separate account. Instead, Receivables subtracts the adjustment from the Revenue account.

Consider an example of an invoice for $2000. If you make an adjustment of -$200 to it, there will be only one journal entry at the time of receipt of cash, as described in this table:

Account	Debit	Credit
Cash	$1800
Revenue		$1800

The adjustment is not recorded anywhere, it is taken into account by reducing the revenue by the $200.

Chargebacks

When a partial payment is received against an invoice, and you create a chargeback for the remaining amount due, the following journal entry is created, as described in this table:

Account	Debit	Credit
Cash	$800
Revenue (invoice)		$800

No entry will be created when a chargeback is created for the balance $200. However, when cash is received against this chargeback, the following journal entry is created, as described in this table:

Account	Debit	Credit
Cash	$200
Chargeback Adjustment		$200

Credit Memos and On-Account Credits

Regular credit memos will not be posted, as no cash is exchanged. Therefore, if you use credit memos, ensure that the accounts on the credit memo are the same as those on the invoices associated with the credit memos. You can achieve this by setting your profile option AR: Use Invoice Accounting For Credit Memos to Yes.

An on-account credit will be posted when it is applied to an invoice or combined with a cash receipt.

Consider the journal entries created in the following instances:

An on-account credit is issued. No journal entry is created.

The on-account credit is applied to an invoice for $100.

This table shows the journal entries that are created:

Account	Debit	Credit
Revenue (on-account credit)	$100
Revenue (invoice)		$100

Instead of applying the on-account credit memo to an invoice, the user combines it with a cash receipt of $200.

This table shows the journal entries that are created:

Account	Debit	Credit
Cash	$200
Unapplied Cash		$200
Revenue (on-account credit)	$100
Unapplied Cash		$100

By applying the on-account credit to a cash receipt, the available unapplied cash balance is increased from $200 to $300. The user applies the $300 unapplied cash balance to an invoice.

This table shows the journal entries that are created:

Account	Debit	Credit
Unapplied Cash	$300
Revenue (invoice)		$300

Related Topics

Default Accounting for Transactions (Accrual method)

Journal Entries

Preparing Receivables

Journal Entries

Review the following table to understand how account balances are affected in the two methods of accounting: Cash Basis and Accrual.

Action	Accrual	Cash Basis
Deposit is recorded	DR......Receivables (Dep) CR.....Unearned Revenue	No accounting effect
Invoice is created	DR.....Receivables (Inv) CR.....Revenue	No accounting effect
Deposit is applied to an invoice	DR.....Unearned Revenue CR.....Receivables (Inv)	No accounting effect
Invoice is adjusted to write off bad debt	DR.....Bad Debt CR.....Receivables	No accounting effect
Payment is received from customer against an invoice	DR.....Cash CR.....Receivables	DR........Cash CR........Revenue
Credit memo is created against an invoice	DR.....Revenue CR.....Receivables	No accounting effect

Note: The only time a journal entry is created is when cash is actually received. The revenue account is credited at this time. The intermediate receivables account is never debited or credited in cash basis accounting. The net effect remains the same in both cases (for example, when a transaction is closed, cash is debited, and revenue is credited).

Related Topics

Accrual vs. Cash Basis Accounting

Preparing Receivables

To prepare Receivables for Cash Basis accounting, perform the following setup steps.

Define your Accounting Method

Select Cash Basis as your accounting method in the System Options window.

Set up an Unallocated Revenue Account

Set up an Unallocated Revenue Account in the System Options window. This account will be credited when you overapply a cash receipt to an invoice with an outstanding balance equal to zero.

Consider the following example:

You have an invoice with 2 invoice lines which total zero.

Invoice Line #1 is for $100

Invoice Line #2 is for -$100

The transaction type allows overapplication, and you receive a payment for $50 against this invoice.

The payment should be prorated across the invoice lines, and the revenue accounts on the 2 invoice lines should be credited by (50*100)/0 and (50 * (-100))/0. However since dividing by zero is not possible, Receivables cannot determine the amounts to be prorated. In such cases Receivables uses the Unallocated Revenue Account to credit the entire amount. Thus the journal entry created will be as follows in the table below:

Account	Debit	Credit
Cash	$50
Unallocated Revenue		$50

You will have to reconcile the balance of the Unallocated Revenue Account with the revenue accounts on the invoice lines by manually creating adjustments.

Set up your Transaction Types

Be aware of the following when creating transaction types to be used with Cash Basis accounting:

• If you set 'Open Receivable' to No, the transactions will never be posted. If you do not create a receivable, cash will never be collected, and therefore revenue will never be recorded.

• Cash Basis method of accounting does not permit you to set 'Open Receivable' to Yes and 'Post To GL' to No. Whenever cash is received (because Open Receivable is Yes), revenue will be recognized.

• Creation Signs must be either positive or negative for all transactions. They cannot be of type 'Any Sign'.

Make GL Transfer and Journal Entry Report Incompatible

If you are using Cash Basis accounting, the GL Transfer program and the Journal Entry report are incompatible with each other and must be run alone (two instances of the program cannot run simultaneously). For Accrual accounting this is not the case. The programs are installed to work in an Accrual Accounting environment.

Execute the following script to tell the concurrent manager that these two programs are incompatible with each other and must be run alone:

 $ cd $AR_TOP/admin/sql
 $ sqlplus <AOL username>/<AOL password>
 SQL> @arsedpcf.sql

Related Topics

Using Cash Basis Accounting

Viewing Accounting Lines in Receivables

When you query a invoice, payment, or adjustment in Oracle Receivables, you can choose to view the detail accounting lines for the queried transaction in the form of a balanced accounting entry (i.e., debits equal credits). You can also choose to view the detail accounting as t-accounts. Use these features to see how a transaction affects the account balances in your general ledger.

To view accounting lines:

1. Query the invoice, payment, or adjustment for which you want to view accounting lines.

   Note: Transactions include invoices, debit/credit memos, chargebacks, deposits, and guarantees. Receipts include cash or miscellaneous receipts.

2. Choose View Accounting from the Tools menu.

   The View Invoice Accounting, View Payment Accounting, or View Adjustment Accounting window appears, depending on whether you queried an invoice, payment, or adjustment.

   See: View Accounting Windows.

3. (Optional) If your organization uses Multiple Reporting Currencies, choose the Alternate Currency button to view the accounting using an alternate currency. For example, if you are viewing the accounting in your primary functional currency (e.g., BEF), you can switch to EUR (reporting functional currency).

   From the poplist that appears after you choose the Alternate Currency button, choose the ledger whose transactions you want to view. The View Invoice Accounting, View Payment Accounting, or View Adjustment Accounting window changes to reflect amounts in the appropriate currency for the chosen ledger.

4. (Optional) To view the accounting detail as t-accounts, choose the T-Accounts button.

   See: T-Accounts, Oracle General Ledger User's Guide.

View Accounting Windows

The first time you open the View Invoice Accounting, View Payment Accounting, or View Adjustment Accounting windows, the following information will be displayed for the detailed accounting lines:

Column Name	Transaction	Receipt	Adjustment
Account	X	X	X
Applied Date		X
Credit	X	X	X
Curr Conversion Rate	X	X	X
Debit	X	X	X
Deposit Date		X
Detail Line Num	X
Entered Credit	X	X	X
Entered Curr	X	X	X
Entered Debit	X	X	X
Item	X
Item Description	X
Line Type	X	X	X
Quantity	X
Reversal Date		X
Tax Code	X	X	X
Tax Rate	X
Trans Line Num	X
Trans Line Type	X
Trans Num		X
Unit Price	X
UOM	X

When you select a detailed accounting line, Oracle Receivables displays the following information at the bottom of the related View Accounting window:

For Transactions: Account Description, Accounting Rule, Comments, Accounting Date, Transferred to GL

For Receipts: Account Description, Transaction Num, Comments, Accounting Date, Transferred to GL

For Adjustments: Account Description, Transaction Num, Comments, Accounting Date, Transferred to GL

Customizing the View Accounting Windows

The View Invoice Accounting, View Payment Accounting, and View Adjustment Accounting windows are folders. You can easily customize the information that is displayed in the windows.

See: Customizing the Presentation of Data in a Folder, Oracle Applications User's Guide.

When customizing the View Accounting windows, you can hide the columns that normally appear in the windows and you can choose to display any additional columns that are available.

Following is a list of all the hidden columns that you can choose to display:

Column Name	Transaction	Receipt	Adjustment
Account Description	X	X	X
Accounting Date	X	X	X
Accounting Rule	X
Activity Name		X	X
Adjustment Class			X
Adjustment Creation Type			X
Adjustment Date			X
Adjustment Num			X
Adjustment Type			X
Applied to Invoice Curr	X
Applied to Invoice Date	X
Applied to Invoice Line Num	X
Applied to Invoice Line Type	X
Applied to Invoice Num	X
Bank Account		X
Cash Receipt Date			X
Cash Receipt Num			X
Chargeback Num			X
Comments	X	X	X
Curr Conversion Date	X	X	X
Curr Conversion Type	X	X	X
Customer	X	X	X
Customer Num	X	X	X
Customer Site	X	X	X
Distribution Set		X
Document Seq Name		X	X
Document Seq Num	X	X	X
Document Seq Type	X
Entered Taxable Credit		X	X
Entered Taxable Debit		X	X
Line Reference	X	X	X
Receipt Method		X
Receipt Date		X
Reversal Comments		X
Sales Order Num	X
Sales Rep	X
Tax Exemption Num	X
Taxable Credit		X	X
Taxable Debit		X	X
Transaction Class	X
Transaction Date	X	X	X
Transaction Line Num		X
Transaction Line Type		X
Transaction Num	X		X
Transaction Type	X
Transferred to GL	X	X	X

Related Topics

Drilling Down to Oracle Receivables from Oracle General Ledger

Drilling Down to Oracle Receivables from Oracle General Ledger

From General Ledger, you can drill down to subledger details from the Account Inquiry, Enter Journals, or Journal Entry Inquiry windows for journals that have specific journal sources assigned to them. For example, if a journal source is Receivables, you can drill down to the transaction details in Oracle Receivables.

Depending on the nature of the originating Receivables transaction, drilling down from General Ledger opens the Payables Invoice Accounting, Payables Payment Accounting, or Receivables Adjustment Accounting window.

The first time you open one of these windows, the following information will be displayed:

Column Name	Transaction	Receipt	Adjustment
Account	X	X
Adjustment Class			X
Adjustment Date			X
Adjustment Num			X
Applied Date		X
Bank Account		X
Credit	X	X	X
Curr Conversion Rate	X	X	X
Customer	X	X	X
Debit	X	X	X
Deposit Date		X
Detail Line Num	X
Entered Credit	X	X	X
Entered Curr	X	X	X
Entered Debit	X	X	X
Item	X
Item Description	X
Line Type	X	X	X
Receipt Method		X
Quantity	X
Receipt Date		X
Receipt Num		X
Reversal Date		X
Tax Code	X	X	X
Tax Rate	X
Transaction Date	X
Transaction Line Num	X
Transaction Line Type	X
Transaction Num	X	X
Transaction Type	X
Unit Price	X
UOM	X

When you select a detailed accounting line, Oracle Receivables displays the following information at the bottom of the related window:

For Transactions: Transaction Class, Accounting Rule, Document Seq Num, Comments, Transaction Source, Accounting Date

For Receipts: Transaction Curr, Transaction Num, Document Seq Num, Comments, Receipt Curr, Accounting Date

For Adjustments: Adjustment Class, Transaction Num, Comments, Document Sequence, Adjustment Type, Accounting Date

Customizing the Drilldown Windows

The drilldown windows are folders. You can easily customize the information that is displayed in the windows.

See: Customizing the Presentation of Data in a Folder, Oracle Applications User's Guide.

When customizing the drilldown windows, you can hide the columns that normally appear in the windows and you can choose to display any additional columns that are available.

Following is a list of all the hidden columns that you can choose to display:

Column Name	Transaction	Receipt	Adjustment
Account			X
Account Description	X	X	X
Accounting Date	X	X	X
Accounting Rule	X
Activity Name			X
Adjustment Creation Type			X
Adjustment Type			X
Applied Date	X
Applied to Invoice Curr	X
Applied to Invoice Date	X
Applied to Invoice Line Num	X
Applied to Invoice Line Type	X
Applied to Invoice Num	X
Bill to Customer Name			X
Cash Receipt Date			X
Cash Receipt Num			X
Chargeback Num			X
Comments	X	X	X
Curr Conversion Date	X	X	X
Curr Conversion Type	X	X	X
Customer Num	X	X	X
Customer Site	X	X	X
Distribution Set		X
Document Seq Name	X	X	X
Document Seq Num	X	X	X
Entered Taxable Credit		X	X
Entered Taxable Debit		X	X
Line Reference	X	X	X
Receipt Class		X
Receipt Curr		X
Reversal Comments		X
Reversal Curr		X
Sales Order Num	X
Sales Rep	X
Tax Exemption Num	X
Taxable Credit		X	X
Taxable Debit		X	X
Transaction Class	X
Transaction Date		X	X
Transaction Line Num		X
Transaction Line Type		X
Transaction Num			X
Transaction Source	X
Transferred to GL	X	X	X

Drilling Down Further

From the Payables Invoice Accounting, Payables Payment Accounting, or Receivables Adjustment Accounting window, you can drill down even further to view detail transactions or you can choose to view the underlying transaction accounting.

To drill down to detail transactions or to view transaction accounting:

1. From the Payables Invoice Accounting, Payables Payment Accounting, or Receivables Adjustment Accounting window, select a detail accounting line.

2. Choose the Show Transaction button to view detail transactions.

3. Choose the Show Transaction Accounting button to view the transaction accounting.

Related Topics

Viewing Accounting Lines

Drilling Down to Subledger Detail, Oracle General Ledger User's Guide

T-Accounts, Oracle General Ledger User's Guide

Viewing MRC Details for a Transaction

If you use Multiple Reporting Currencies (MRC) functionality, and if you are using a responsibility associated with your primary functional currency, then you can use the View Currency Details window to see, in a single window, transaction amounts in your primary functional currency and in all the reporting ledger currencies. If the transaction currency is different from your primary functional currency, then the amounts are also displayed in the transaction currency.

The window also displays currency conversion details such as the rate, rate date, and rate type.

For a transaction, the window displays:

• Transaction header information

• Conversion details

• Transaction information. For each transaction, you see the total amount, plus the amounts of any receipts, credit memos, adjustments, discounts, or bills receivable, converted to each currency.

For a receipt, the window displays:

• Receipt header information

• Conversion details

• A list of receipt applications. For each application, you see the amount that was applied to the receipt. You see this amount in each currency. You can drill down from each invoice to the invoice currency detail.

To open the View Currency Details window, use a responsibility associated with your primary functional currency. Select a transaction in one of the following windows, then either choose the View Currency Details option from the Tools menu, or choose the View Currency Details icon in the toolbar.

• Transactions

• Transactions Summary

• Balances

• Receipts

• Receipts Summary

  Note: You must save a transaction before you can open the View Currency Details window for it.

Default Accounting for Transactions

This essay describes the default accounting entries created when you enter transactions in Receivables using the Accrual method of accounting.

Receivables creates default accounts for revenue, receivable, freight, tax, unearned revenue, unbilled receivable, late charges, and AutoInvoice clearing (suspense) accounts using the information specified in your AutoAccounting structure.

You then submit the Submit Accounting program to actually create accounting entries in Oracle Subledger Accounting. Receivables predefines setup in Oracle Subledger Accounting so that the Submit Accounting program accepts the default accounts that AutoAccounting derives without change. See: Accounting in Receivables.

You can optionally define your own accounting rules in Subledger Accounting to create accounting that meets your business requirements. See: Oracle Subledger Accounting Implementation Guide.

Note: This section does not include examples of accounting for tax on discounts, adjustments, miscellaneous receipts, and cash applications. For more information, see: Oracle E-Business Tax User Guide and Oracle E-Business Tax Implementation Guide.

Invoices

When you enter a regular invoice through the Transactions window, Receivables creates the following journal entry:

DR Receivables
   CR Revenue
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)

If you enter an invoice with a Bill in Arrears invoicing rule with a three month fixed duration accounting rule, Receivables creates the following journal entries:

In the first period of the rule:

DR Unbilled Receivables
   CR Revenue

In the second period of the rule:

DR Unbilled Receivables
   CR Revenue

In the third and final period of the rule:

DR Unbilled Receivables
   CR Revenue
DR Receivables
   CR Unbilled Receivables
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)

If you enter an invoice with a Bill in Advance invoicing rule, Receivables creates the following journal entries:

In the first period of the rule:

DR Receivables
   CR Unearned Revenue
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)
DR Unearned Revenue
   CR Revenue

In all periods of the rule for the portion that is recognized.

DR Unearned Revenue
   CR Revenue

Credit Memos

When you credit an invoice, debit memo, or chargeback through the Credit Transactions window, Receivables creates the following journal entry:

DR Revenue 
DR Tax (if you credit tax) 
DR Freight (if you credit freight) 
   CR Receivables (Credit Memo)
DR Receivables (Credit Memo)
   CR Receivables (Invoice)

When you credit a commitment, Receivables creates the following journal entries:

DR Revenue
   CR Receivables

When you enter a credit memo against an installment, Receivables lets you choose between the following methods: LIFO, FIFO, and Prorate. When you enter a credit memo against an invoice with invoicing and accounting rules, Receivables lets you choose between the following methods: LIFO, Prorate, and Unit. See: Crediting Transactions.

If the profile option AR: Use Invoice Accounting for Credit Memos is set to Yes, Receivables credits the accounts of the original transaction. If this profile option is set to No, Receivables uses AutoAccounting to determine the Freight, Receivables, Revenue, and Tax accounts. Receivables uses the account information for on-account credits that you specified in your AutoAccounting structure to create your journal entries.

Receivables lets you update accounting information for your credit memo after it has posted to your general ledger. Receivables keeps the original accounting information as an audit trail while it creates an offsetting entry and the new entry.

Commitments

Deposits

When you enter a deposit, Receivables creates the following journal entry:

DR Receivables (Deposit)
   CR Offset Account

Use the AR: Deposit Offset Account Source profile option to determine how Receivables derives the Offset Account to credit for this deposit. For more information, see: Overview of Receivables User Profile Options, Oracle Receivables Implementation Guide.

When you enter an invoice against this deposit, Receivables creates the following journal entries:

DR Receivables (Invoice)
   CR Revenue
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)
DR Offset Account (such as Unearned Revenue)
   CR Receivables (Invoice)

When you apply an invoice to a deposit, Receivables creates a receivable adjustment against the invoice. Receivables uses the account information that you specified in your AutoAccounting structure to create these entries.

When cash is received against this deposit, Receivables creates the following journal entry:

DR Cash
   CR Receivables (Deposit)

Guarantees

When you enter a guarantee, Receivables creates the following journal entry:

DR Receivables
   CR Revenue

Receivables uses the Receivable Account and Revenue Account fields on this guarantee's transaction type to obtain the accounting flexfields for the Unbilled Receivables and Unearned Revenue accounts, respectively. See: Transaction Types, Oracle Receivables Implementation Guide.

When you enter an invoice against this guarantee, Receivables creates the following journal entry:

DR Receivables (Invoice)
   CR Revenue
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)
DR Revenue
   CR Receivables

When you apply an invoice to a guarantee, Receivables creates a receivable adjustment against the guarantee. Receivables uses the account information you specified in your AutoAccounting structure to create these entries.

When cash is received against this guarantee, Receivables creates the following journal entry:

DR Cash
   CR Receivables (Invoice)

Receipts

When you enter a receipt, Receivables creates the following journal entries:

DR Cash
   CR Receivables

When you fully apply a receipt to an invoice, Receivables creates the following journal entry:

DR Cash
DR Unapplied Cash
   CR Unapplied Cash
   CR Receivables

Note: These examples assume that the receipt has a Remittance Method of No Remittance and a Clearance Method of Directly.

When you enter an unidentified receipt, Receivables creates the following journal entry:

DR Cash
   CR Unidentified

When you enter an on-account receipt, Receivables creates the following journal entry:

DR Cash
   CR Unapplied
DR Unapplied
   CR On-Account

When your receipt includes a discount, Receivables creates the following journal entry:

DR Receivables
   CR Revenue
DR Cash
   CR Receivables
DR Earned/Unearned Discount
   CR Receivables

Receivables uses the default Cash, Unapplied, Unidentified, On-Account, Unearned, and Earned accounts that you specified in the Remittance Banks window for this receipt class.

When you enter a receipt and combine it with an on-account credit (which increases the balance of the receipt), Receivables creates the following journal entry:

DR Cash
   CR Unapplied Cash

To close the receivable on the credit memo and increase the unapplied cash balance, Receivables creates the following journal entry:

DR Receivables
   CR Unapplied Cash

When you enter a receipt and combine it with a negative adjustment, Receivables creates the following journal entries:

DR Cash
   CR Receivables (Invoice)
DR Write-Off
   CR Receivables (Invoice)

You set up a Write-Off account when defining your Receivables Activity.

When you enter a receipt and combine it with a positive adjustment, Receivables creates the following journal entries:

DR Cash
   CR Receivables (Invoice)
DR Receivables (Invoice)
   CR Write-Off

When you write off the unapplied amount on a receipt, Receivables creates the following journal entries:

DR Unapplied Cash
   CR Write-off

When you enter a receipt and combine it with a Chargeback, Receivables creates the following journal entries:

DR Cash
   CR Receivables (Invoice)
DR Receivables (Chargeback)
   CR Chargeback (Activity)
DR Chargeback (Activity) 
   CR Receivables (Invoice)

You set up a Chargeback account when defining your Receivables Activity.

To move funds between receipts, you can apply one receipt to another open receipt (also called netting receipts). For example, you can move funds from Receipt 1 to Receipt 2 by opening Receipt 2 in the Applications window, and selecting Receipt 1 in the Apply To field.

See: Receipt-to-Receipt Applications.

Following the example above, Receivables creates these journal entries:

DR Unapplied Cash (Receipt 1)
   CR Netting (Receipt 1)
DR Netting (Receipt 2)
   CR Unapplied Cash (Receipt 2)

After this receipt-to-receipt application completes, Receipt 2 gains additional funds that you can then apply to a debit item.

You set up a Netting account when defining your Receivables Activity.

Important: When netting receipts, both receipts must be in the same currency.

If both receipts are in a foreign currency, however, then you could have an exchange gain or loss when you net the receipts. The exchange gain or loss is realized on the main receipt (Receipt 2) at the time of receipt application (netting).

If you later adjust the exchange rate on Receipt 1 or 2, then Receivables:

• Rolls back all accounting for both receipts.

• Re-creates the accounting, including the netting application, using the adjusted exchange rate.

• Recalculates the exchange gain or loss on whichever receipt is open in the Applications window.

Remittances

When you create a receipt that requires remittance to your bank, Receivables debits the Confirmation account instead of Cash. An example of a receipt requiring remittance would be a check before it was cashed. Receivables creates the following journal entry when you enter such a receipt:

DR Confirmation
   CR Receivables 

You can then remit the receipt to your remittance bank using one of the two remittance methods: Standard or Factoring. If you remit your receipt using the standard method of remittance, Receivables creates the following journal entry:

DR Remittance
   CR Confirmation

When you clear the receipt, Receivables creates the following journal entry:

DR Cash
DR Bank Charges
   CR Remittance 

If you remit your receipt using the factoring remittance method, Receivables creates the following journal entry:

DR Factor
   CR Confirmation 

When you clear the receipt, Receivables creates a short-term liability for receipts that mature at a future date. The factoring process let you receive cash before the maturity date, and assumes that you are liable for the receipt amount until the customer pays the balance on the maturity date. When you receive payment, Receivables creates the following journal entry:

DR Cash
DR Bank Charges
   CR Short-Term Debt

On the maturity date, Receivables reverses the short term liability and creates the following journal entry:

DR Short-Term Debt
   CR Factor

Adjustments

When you enter a negative adjustment against an invoice, Receivables creates the following journal entry:

DR Write-Off
   CR Receivables (Invoice)

When you enter a positive adjustment against an invoice, Receivables creates the following journal entry:

DR Receivables (Invoice)
   CR Write-Off

Debit Memos

When you enter a debit memo in the Transactions window, Receivables creates the following journal entries:

DR Receivables
   CR Revenue (if you enter line amounts)
   CR Tax (if you charge tax)
   CR Freight (if you charge freight)
DR Receivables
   CR Late Charges

On-Account Credits

When you enter an on-account credit in the Applications window, Receivables creates the following journal entry:

DR Revenue (if you credit line amounts)
DR Tax (if you credit tax)
DR Freight (if you credit freight)
   CR Receivables (On-account Credit)

Receivables uses the Freight, Receivable, Revenue, and Tax accounts that you specified in your AutoAccounting structure to create these entries.

Once the on-account credit is applied to an invoice, the following journal entry is created:

DR Receivables (On-account Credit)
   CR Receivables (Invoice)

Credit Card Refunds

Creating a credit card refund

When you unapply a receipt and reapply the receipt to a credit card refund, Receivables creates these journal entries:

DR Receivables
   CR Unapplied
DR Unapplied
   CR Receivable Activity (Clearing Account)

After you apply the receipt to a credit card refund, Receivables automatically creates a negative miscellaneous receipt in the amount of the refund and creates this journal entry:

DR Receivable Activity (Clearing Account)
   CR Cash

Reversing a credit card refund

When you reverse a credit card refund, either by reversing the negative miscellaneous receipt or by unapplying the credit card refund activity, Receivables creates this journal entry for the negative miscellaneous receipt:

DR Cash
   CR Receivable Activity (Clearing Account)

and Receivables creates this journal entry for the original payment receipt:

DR Receivables Activity (Clearing Account)
   CR Unapplied

Claims

Creating an invoice related claim

When you record an invoice related short payment as a claim in the Applications window, Receivables creates the standard accounting entries for the invoice and for the receipt application. There are no additional accounting entries for the invoice related claim.

Creating a non-invoice related claim

When you record a non-invoice related short payment or over payment as a claim investigation application in the Applications window, Receivables creates these journal entries:

DR Claim Investigation
   CR Unapplied Cash

Receivables derives the accounting flexfield for the claim investigation application from the receivable activity that you assigned in the Applications window.

Related Topics

About Remittances

Credit Card Refunds

Defining Receivables System Options, Oracle Receivables Implementation Guide

Transaction Types, Oracle Receivables Implementation Guide

AutoAccounting, Oracle Receivables Implementation Guide

Receivables Activities, Oracle Receivables Implementation Guide

Receipt Classes, Oracle Receivables Implementation Guide

Using Cash Basis Accounting

Working with Claims

Technical Perspective: Transactions

This essay describes the key tables and columns Receivables uses to store your accounts receivable transactions.

Introduction

Following is a brief description of the Receivables tables discussed in this essay. For each table, it provides a detailed description of the important columns and identifies the primary key of each table. Additionally, this section establishes a set of assumptions to consider while discussing how Receivables stores specific transactions. You should use this section as a reference guide to the rest of the essay.

Receivables uses the following tables to store your accounts receivable transactions:

RA_CUSTOMER_TRX table

• CUSTOMER_TRX_ID column

• TRX_NUMBER column

• BILL_TO_CUSTOMER_ID column

• TRX_DATE column

The RA_CUSTOMER_TRX table stores invoice, debit memo, commitment and credit memo header information. Each of these transactions is stored as a unique record, based on the primary key, customer_trx_id. The transaction number, transaction date and billing customer are stored in the trx_number, trx_date and bill_to_customer_id columns, respectively.

Additional information stored in this table includes ship-to customer, document sequence number, currency code and a transaction complete flag. The transaction type for the invoice is stored in the RA_CUST_TRX_TYPES table, but can be referenced via the foreign key cust_trx_type_id.

RA_CUSTOMER_TRX_LINES table

• CUSTOMER_TRX_LINE_ID column

• CUSTOMER_TRX_ID column

• LINK_TO_CUST_TRX_LINE_ID column

• LINE_TYPE column

• EXTENDED_AMOUNT column

The RA_CUSTOMER_TRX_LINES table stores invoice, debit memo, commitment and credit memo line level information. Each transaction line is stored as a unique record, based on the primary key, customer_trx_line_id column. The customer_trx_id column is a foreign key to the RA_CUSTOMER_TRX table. The line_type column identifies the type of data contained in the record. Valid line types are CHARGES, FREIGHT, LINE and TAX. Any record with a line type of TAX or FREIGHT refers to the original invoice line via the link_to_cust_trx_line_id column, except for header freight transactions. The total amount for each transaction line is stored in the column extended_amount.

RA_CUST_TRX_LINE_SALESREPS table

• CUST_TRX_LINE_SALESREP_ID column

• SALES_REP_ID column

• CUSTOMER_TRX_LINE_ID column

• REVENUE_AMOUNT_SPLIT column

• NON_REVENUE_AMOUNT_SPLIT column

• PREV_CUST_TRX_LINE_SALESREP_ID column

RA_CUST_TRX_LINE_SALESREPS stores sales credit assignments for invoice lines. Each assignment is stored as a unique record, based on the primary key, cust_trx_line_salesrep_id. If you base your accounting distributions on sales credits, the sales credit assignments in this table map to the RA_CUST_TRX_LINE_GL_DIST table. The sales_rep_id column identifies the salesperson receiving the credit for this transaction. The customer_trx_line_id column is a foreign key to the RA_CUSTOMER_TRX_LINES table.

The revenue_amount_split column stores the amount of the invoice line assigned to this salesperson. The non_revenue_amount_split column stores the amount of the non-header freight and tax lines assigned to this salesperson. If the sales credit were derived based on a percentage of the transaction line rather than a specific amount, the columns revenue_percent_split and non_revenue_percent_split would store the percentages of the transaction lines assigned to this salesperson. The prev_cust_trx_line_salesrep_id column references another sales credit assignment to which the current record is being applied.

RA_CUST_TRX_LINE_GL_DIST table

• CUST_TRX_LINE_GL_DIST_ID column

• CODE_COMBINATION_ID column

• CUSTOMER_TRX_LINE_ID column

• ACCOUNT_CLASS column

• AMOUNT column

RA_CUST_TRX_LINE_GL_DIST stores the accounting distribution for invoice, debit memo, commitment, and credit memo transactions. Each distribution is stored as a unique record, based on the primary key, cust_trx_line_gl_dist_id. The customer_trx_line_id column is a foreign key to the RA_CUSTOMER_TRX_LINES table. The account_class column describes the account type, while the code_combination_id column identifies the general ledger account. Valid account classes are CHARGES, FREIGHT, REC, REV, SUSPENSE, TAX, UNBILL and UNEARN. The account_class, REC, represents the receivable account distribution. The amount column for REC records is equal to the sum of all invoice lines. Therefore, there is no link to RA_CUSTOMER_TRX_LINES and the column customer_trx_line_id is null for these records. The REC record is linked to the table, RA_CUSTOMER_TRX, via the customer_trx_id column. For all other account classes, credits are represented by positive numbers and debits are represented by negative numbers.

AR_PAYMENT_SCHEDULES table

• PAYMENT_SCHEDULE_ID column

• AMOUNT_DUE_ORIGINAL column

• AMOUNT_DUE_REMAINING column

• CUSTOMER_TRX_ID column

• CASH_RECEIPT_ID column

• TRX_NUMBER column

• STATUS column

• AMOUNT_APPLIED column

• CLASS column

AR_PAYMENT_SCHEDULES stores customer balance information at the transaction level. Each transaction's balance is stored as a unique record, based on the primary key, payment_schedule_id. The class column identifies the transaction type and determines which columns Receivables updates when a transaction is stored. For billing transactions, the AR_PAYMENT_SCHEDULES table joins the RA_CUSTOMER_TRX table via the customer_trx_id column and stores NULL in the cash_receipt_id column. For payment transactions, the AR_PAYMENT_SCHEDULES table joins the AR_CASH_RECEIPTS table via the cash_receipt_id column and stores NULL in the customer_trx_id column.

The table below illustrates the tables that Receivables updates for billing and payment transactions.

TRANSACTION	CLASS	FOREIGN KEY	TABLE
Invoices	INV	customer_trx_id	RA_CUSTOMER_TRX
Debit Memos	DM	customer_trx_id	RA_CUSTOMER_TRX
Credit Memos	CM	customer_trx_id	RA_CUSTOMER_TRX
Deposits	DEP	customer_trx_id	RA_CUSTOMER_TRX
Guarantees	GUAR	customer_trx_id	RA_CUSTOMER_TRX
Chargebacks	CB	customer_trx_id	RA_CUSTOMER_TRX
Receipts	PMT	cash_receipts_id	AR_CASH_RECEIPTS

The status column identifies whether the transaction is open or closed, while the trx_number column stores the transaction number. The amount_applied column stores the sum of all transactions applied to the balance of the selected transaction. The amount_due_original column equals either the sum of the extended_amount column in the RA_CUSTOMER_TRX_LINES table for the given customer_trx_id or the sum of the amount column in the AR_CASH_RECEIPTS table for the given cash_receipts_id. The amount_due_remaining column represents the balance for the selected transaction.

For the amount_due_original and amount_due_remaining columns debit items, such as invoices, are stored as positive numbers and credit items, such as credit memos and payments, are stored as negative numbers. The current customer balance is reflected by the sum of the amount_due_remaining column for all confirmed payment schedules for a given customer.

AR_ADJUSTMENTS table

• ADJUSTMENT_ID column

• AMOUNT column

• CUSTOMER_TRX_ID column

• TYPE column

• PAYMENT_SCHEDULE_ID column

• CODE_COMBINATION_ID column

AR_ADJUSTMENTS stores information about invoice adjustments. Each adjustment is stored as a unique record, based on the primary key, adjustment_id. The amount column stores the amount of the adjustment. Receivables uses the customer_trx_id and payment_schedule_id to link the adjustment to the adjusted transaction and to update the amount_due_remaining and amount_adjusted columns of the adjusted transaction's payment schedule in the AR_PAYMENT_SCHEDULES table. The type column stores a description of the transaction to which the adjustment applies. Valid types include:

• Charges Adjustments

• Freight Adjustments

• Invoice Adjustments

• Line Adjustments

• Tax Adjustments

The code_combination_id column stores the accounting distribution associated with the adjustment transaction.

AR_RECEIVABLE_APPLICATIONS table

• RECEIVABLE_APPLICATION_ID column

• AMOUNT_APPLIED column

• STATUS column

• PAYMENT_SCHEDULE_ID column

• CODE_COMBINATION_ID column

• CASH_RECEIPT_ID column

• APPLIED_PAYMENT_SCHEDULE_ID column

• APPLIED_CUSTOMER_TRX_ID column

AR_RECEIVABLE_APPLICATIONS stores account distributions for receipt and credit memo applications and maps the application transaction to the applied transaction. Each accounting distribution is stored as a unique record, based on the primary key, receivable_application_id. The payment_schedule_id column links the receipt or credit memo to its payment schedule in the AR_PAYMENT_SCHEDULES table. The cash_receipt_id column stores the receipt id of payment transactions, while the cust_trx_id column, which is not shown, stores the transaction id for credit memo transactions. The applied_payment_schedule_id and applied_customer_trx_id columns reference the transaction to which this record applies.

The status column describes the state of the application transaction. For credit memos, the status will always be APP to identify the credit memo as applied. For receipt transactions, valid status values are APP, UNAPP, UNID, REV, NSF, and STOP. The code_combination_id column stores the general ledger account for the application transaction, based on the status. The amount_applied column stores the amount of the receipt or credit memo as a positive value.

Note: For cash basis accounting, Receivables uses the table AR_CASH_BASIS_DISTRIBUTIONS to store account distribution information. This table shows the distribution to revenue accounts of a given receipt based on the application of the receipt.

AR_CREDIT_MEMO_AMOUNTS table

• CREDIT_MEMO_AMOUNT_ID column

• CUSTOMER_TRX_LINE_ID column

• GL_DATE column

• AMOUNT column

AR_CREDIT_MEMO_AMOUNTS stores the GL dates and amounts for credit memos to use when they are applied to invoices with rules. Each credit memo application date is stored as a unique record, based on the primary key, credit_memo_amount_id. The customer_trx_line_id references the transaction line to which this credit memo applies. The gl_date column stores the date the credit memo should be applied to the invoice and the amount column stores the amount to apply.

AR_CASH_RECEIPTS table

• CASH_RECEIPT_ID column

• AMOUNT column

• STATUS column

• RECEIPT_NUMBER column

• TYPE column

AR_CASH_RECEIPTS stores a unique record for each receipt, based on the primary key, cash_receipt_id. The status column describes the state of the receipt in relation to customer invoices and balances. Valid status values are:

• UNID - The receipt customer is unidentified and no customer balance has been updated.

• UNAPP - The receipt customer has been identified, but the receipt has not been entirely applied to a specific invoice or been placed on account.

• APP - The entire amount of the receipt has been placed on account or applied to specific customer invoices.

• REV - The receipt has been reversed.

• NSF - The receipt has been reversed due to insufficient funds.

• STOP - The receipt has been reversed by a stop payment.

The type column identifies the receipt as either CASH or MISC to indicate whether the receipt is a customer payment or a miscellaneous receipt (not related to a receivable activity). The amount column stores the net amount of the receipt, while the receipt_number column stores the receipt_number.

AR_CASH_RECEIPT_HISTORY table

• CASH_RECEIPT_HISTORY_ID column

• AMOUNT column

• STATUS column

AR_CASH_RECEIPT_HISTORY stores the current status and history of a receipt. Each status change is stored as a unique transaction, based on the primary key, cash_receipt_history_id. The status column describes which step of the receipt's life cycle the receipt has reached. Valid status values are:

• APPROVED - This is only valid for automatic receipts and signifies the receipt has been approved for automatic creation. These record types are never postable.

• CONFIRMED - This is only valid for automatic receipts and signifies the receipt has been confirmed by the customer.

• REMITTED - This is valid for both manual and automatic receipts and signifies the receipt has been remitted.

• CLEARED - This is valid for both manual and automatic receipts and signifies the receipt has been cleared.

• REVERSED - This is valid for both manual and automatic receipts and signifies the receipt has been reversed.

As the receipt moves through its life cycle, Receivables inserts a new record into AR_CASH_RECEIPTS_HISTORY with the current_record_flag column set to 'Y'. Receivables also updates the previous record related to this receipt, by setting the current_record_flag to NULL and by setting the reversal_gl_date. The amount column stores the amount of the receipt. The cash_receipts_id column links AR_CASH_RECEIPTS_HISTORY to AR_CASH_RECEIPTS.

AR_MISC_CASH_DISTRIBUTIONS table

• MISC_CASH_DISTRIBUTION_ID column

• CASH_RECEIPT_ID column

• CODE_COMBINATION_ID column

AR_MISC_CASH_DISTRIBUTIONS stores the accounting distribution for miscellaneous cash receipts. Each distribution is stored as a unique record, based on the primary key, misc_cash_distribution_id. The distributions are linked to the receipt by the column cash_receipt_id. The code_combination_id column stores the general ledger account assigned to this receipt.

Assumptions

To simplify the discussion of how Receivables stores specific transactions, this essay uses the following assumptions:

• All transactions are postable to the general ledger, are included in agings, and occur in the same accounting period. Therefore, there will not be any installment transactions or split term invoices.

• No invoicing rules will be applied to any of the billing transactions.

• No accounting rules will be applied to any of the billing transactions.

• Credit memo transactions will not use a credit method for invoices with rules or for split term invoices.

• Payment schedules will not allow discounts and all due dates will be 30 days after the date of the transaction.

• Late charges will not be calculated on overdue items.

• Examples involving sales credit assignments will be expressly identified.

Related Topics

Invoices

Debit Memos

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Credit Memos

On-Account Credit Memos

Unapplied Receipts

Applied Receipts

Reverse Receipts

Miscellaneous Receipts

Chargebacks

About Adjustments

Invoices

When you enter an invoice either through the Transaction window or through the AutoInvoice program, Receivables uses the following tables to store your invoice information:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_PAYMENT_SCHEDULES

Consider a sample invoice:

Invoice Number: I-101

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

Item                  Amount      Tax   Total Amount
10 chairs @ $200      $2,000     $160         $2,160
10 tables @ $300      $3,000     $240         $3,240
       Subtotal: $5,400
Freight Charges: $1,000
          Total: $6,400

RA_CUSTOMER_TRX

Invoice number I-101 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date
101467	I-101	ABC Inc	22-May-94

RA_CUSTOMER_TRX_LINES

Invoice number I-101 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount
100	101467		LINE	2000
101	101467	100	TAX	160
102	101467		LINE	3000
103	101467	102	TAX	240
104	101467		FREIGHT	1000

Since the example invoice had freight at the header-level, it is not linked to any line and the column, link_to_cust_trx_line_id is null.

RA_CUST_TRX_LINE_SALESREPS

Invoice number I-101 is stored in this table as follows:

cust_trx_line_salesrep_id	sales_rep_id	customer_trx_line_id	revenue_amount_split	non_revenue_amount_split	prev_cust_trx_line_salesrep_id
140195	1492	100	1000	0	NULL
140196	1525	100	1000	0	NULL
140197	1492	101	0	80	NULL
140198	1525	101	0	80	NULL
140199	1624	102	3000	0	NULL
140200	1624	103	0	240	NULL
140201	1492	104	0	200	NULL
140202	1525	104	0	200	NULL
140203	1624	104	0	600	NULL

The revenue and non-revenue amounts associated with the first line item of the invoice are split between salesperson 1492 and salesperson 1525. Salesperson 1624 gets the complete sales credit for the second line item of the invoice, while all three share the credit for the header level freight.

RA_CUST_TRX_LINE_GL_DIST

Invoice number I-101 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
10866	01-1200-1000-3000		REC	64000
10867	01-8100-1000-3000	100	REV	2000
10868	01-4100-1000-3000	101	TAX	160
10869	01-8200-1000-3000	102	REV	3000
10870	01-4200-1000-3000	103	TAX	240
10871	01-4400-1000-3000	104	FREIGHT	1000

If you enter an invoice with rules (for example, Bill in Advance), the account distributions are not built when the invoice is initially created. Instead, RA_CUST_TRX_LINE_GL_DIST stores an account set, which represents how the actual distribution rows should be created and what percentage of the actual distribution should be allocated to each account. Account sets can be identified by a 'Y' in the account_set_flag column. The actual distribution records are built when the Revenue Recognition program is run.

AR_PAYMENT_SCHEDULES

Invoice number I-101 is stored in this table as follows:

payment_schedule_ id	amount_due_original	amount_due_remaining	customer_trx_id	cash_receipt_ id	trx_number	status	amount_applied	class
30191	6400	6400	101467	NULL	I-101	OP	NULL	INV

The example invoice has a status of OP (open) and an amount_applied of NULL because no payment has been applied against it. Once payment is received in full, the status will change to CL (closed), the amount_applied will be 6400 and the amount_due_remaining will be zero.

Related Topics

Debit Memos

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Chargebacks

About Adjustments

Debit Memos

Receivables handles debit memos the same as invoices, except that it sets the class of the payment schedule to DM instead of INV. For more information, see: Invoices.

Related Topics

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Credit Memos

Commitments

Receivables uses the following tables to store your commitment information:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_PAYMENT_SCHEDULES

Consider a sample guarantee:

Guarantee Number: G-101

Bill-To: ABC Inc

Guarantee Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

Guarantee number G-101 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date
122341	G-101	ABC Inc	20-May-94

RA_CUSTOMER_TRX_LINES

Guarantee number G-101 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount
108	122341		LINE	500

One record is inserted into the RA_CUSTOMER_TRX_LINES table with a line_type of 'LINE'. The extended_amount column will store the amount of the commitment. If there had been a sales credit for this commitment, records relating to the sales credit would be inserted in RA_CUST_TRX_LINE_SALESREPS, linked via the column customer_trx_line_id.

RA_CUST_TRX_LINE_GL_DIST

Guarantee number G-101 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
12345	01-1100-1000-3000		REC	500
12346	01-6200-1000-3000	108	REV	500

Two records are inserted into the RA_CUST_TRX_LINE_GL_DIST table. One contains the (unbilled) receivable account, which is linked to the record created in ra_customer_trx via the customer_trx_id. The second contains the (unearned) revenue account, which is linked to the record created in ra_customer_trx_lines via the customer_trx_line_id.

AR_PAYMENT_SCHEDULES

Guarantee number G-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	cash_receipt_id	trx_number	status	amount_applied	class
81194	500	500	122341	NULL	G-101	OP	NULL	GUAR

A record is created in AR_PAYMENT_SCHEDULES with class set to either DEP or GUAR depending on whether the commitment is a deposit or a guarantee. The amount_due_original and amount_due_remaining will initially be equal to the amount on the commitment.

Related Topics

Invoice Against a Deposit

Invoice Against a Guarantee

Invoice Against a Deposit

Receivables uses the following tables to store your invoice and deposit information:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_PAYMENT_SCHEDULES

• AR_ADJUSTMENTS

Consider a sample invoice:

Invoice Number: I-102

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

Invoice Line	Amount	Tax	Total Amount
1 Table @ $1000	1000.00	100.00	$1100.00

with a sample deposit:

Deposit Number: D-101

Bill-To: ABC Inc

Deposit Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date
10895	I-102	ABC Inc	22-May-94

RA_CUSTOMER_TRX_LINES

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_ trx_line_id	line_type	extended_amount
110	10895		LINE	1000
111	10895	110	TAX	100

If there had been a sales credit for this invoice, records relating to the sales credit would be inserted in the table RA_CUST_TRX_LINE_SALESREPS, linked via the column customer_trx_line_id.

RA_CUST_TRX_LINE_GL_DIST

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
111213	01-1200-1000-3000		REC	1100
111214	01-8100-1000-3000	110	REV	1000
111215	01-4100-1000-3000	111	TAX	100

AR_PAYMENT_SCHEDULES

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	cash_receipt_id	trx_number	status	amount_applied	class
302301	1100	1100	10895	NULL	I-102	OP	NULL	INV

The payment schedule for the invoice originally shows an amount_due_remaining of 1100.

AR_ADJUSTMENTS

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

adjustment_id	amount	customer_trx_id	type	payment_schedule_id	code_combination_id
45678	-500	10895	INVOICE	302301	01-6200-1000-3000

When the invoice is applied to the deposit, Receivables inserts a record into AR_ADJUSTMENTS to record an adjustment against the invoice. The amount column equals the inverse of the amount_due_remaining from the AR_PAYMENT_SCHEDULES table for the deposit or the total value of the invoice lines, whichever is smaller. Receivables uses the customer_trx_id to link the adjustment to the invoice. The payment_schedule_id column links the adjustment to the invoice payment schedule in the table, AR_PAYMENT_SCHEDULES.

The code_combination_id column stores the unearned revenue account of the deposit. Receivables will use this account to reverse the unearned revenue distribution, originally created by the deposit, and will use the receivable account of the invoice to reduce the invoice balance.

AR_PAYMENT_SCHEDULES

Invoice I-102 applied against deposit D-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_adjusted
302301	1100	600	10895	I-102	OP	NULL	INV	-500

The invoice payment schedule record in AR_PAYMENT_SCHEDULES is updated to reflect the adjustment of the deposit. The amount_due_remaining column is reduced by 500 and the amount_adjusted column is -500.

Receivables does not update the payment schedule record of the deposit in AR_PAYMENT_SCHEDULES when an invoice is applied to the deposit. The payment schedule of the deposit will be updated as adjustments and receipts are applied to this independent billing.

Related Topics

Invoice Against a Guarantee

Invoice Against a Guarantee

Receivables uses the following tables to store your invoice and guarantee information:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_PAYMENT_SCHEDULES

• AR_ADJUSTMENTS

Consider a sample invoice:

Invoice Number: I-103

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

Invoice Line	Amount	Tax	Total Amount
1 Table @ $1000	1000.00	100.00	$1100.00

with a sample guarantee:

Guarantee Number: G-102

Bill-To: ABC Inc

Deposit Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date
110120	I-103	ABC Inc	22-May-94

RA_CUSTOMER_TRX_LINES

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount
120	110120		LINE	1000
121	110120	120	TAX	100

If there had been a sales credit for this invoice, records relating to the revenue credit would be inserted in the table RA_CUST_TRX_LINE_SALESREPS, linked via the column customer_trx_line_id.

RA_CUST_TRX_LINE_GL_DIST

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
200101	01-1200-1000-3000		REC	1100
200102	01-8100-1000-3000	120	REV	1000
200103	01-4100-1000-3000	121	TAX	100

AR_PAYMENT_SCHEDULES

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

payment_ schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	cash_receipt_id	trx_number	status	amount_applied	class
401100	1100	1100	110120	NULL	I-103	OP	NULL	INV

The payment schedule for the invoice originally shows an amount_due_remaining of 1100.

AR_ADJUSTMENTS

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

adjustment_id	amount	customer_trx_id	type	payment_schedule_id	code_combination_id
56789	-500	110120	INVOICE	302302	01-6200-1000-3000

When the invoice is applied to the guarantee, Receivables inserts a record into AR_ADJUSTMENTS to record an adjustment against the invoice. The amount column equals the inverse of the amount_due_remaining from the AR_PAYMENT_SCHEDULES table for the guarantee or the total value of the invoice lines, whichever is smaller. Receivables uses the customer_trx_id and payment_schedule_id to link the adjustment to the guarantee payment schedule in the AR_PAYMENT_SCHEDULES table.

The code_combination_id column stores the unearned revenue account of the guarantee. Receivables will use this account to reverse the unearned revenue distribution, originally created by the guarantee, and will use the unbilled receivable account, originally created by the guarantee, to reverse the unbilled receivable balance.

AR_PAYMENT_SCHEDULES

Invoice I-103 applied against guarantee G-102 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_adjusted
302302	500	0	110120	G-102	CL	NULL	GUAR	-500

The payment schedule record of the guarantee is updated to reflect the application of the invoice against the guarantee. The amount_due_remaining column is zero and the amount_adjusted column becomes -500. The payment schedule record for the invoice will not be impacted by the adjustment.

Related Topics

Commitments

Invoice Against a Deposit

Credit Memos

When you enter a credit memo against an invoice, Receivables creates records in the following tables:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_PAYMENT_SCHEDULES

• AR_RECEIVABLE_APPLICATIONS

Consider a sample credit memo against line number 1 of invoice I-101:

Credit Memo Number: CM-101

Bill-To: ABC Inc

Credit Memo Date: 01-Jun-94

Credit Memo Amount: -1000

RA_CUSTOMER_TRX

Credit memo number CM-101 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date	previous_customer_ trx_id
123456	CM-101	ABC Inc	01-Jun-94	101467

The previous_customer_trx_id column references the original transaction you have credited.

RA_CUSTOMER_TRX_LINES

Credit memo number CM-101 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount	previous_customer_trx_id	previous_customer_trx_line_id
150	123456		LINE	-926	101467	100
151	123456	150	TAX	-74	101467	101

Based on the example credit memo, Receivables inserts two records into RA_CUSTOMER_TRX_LINES. The total value of the credit memo is prorated between the invoice and tax lines associated with line 1 of the original invoice. The previous_customer_trx_line_id column references the customer_trx_line_id of the original invoice you have credited.

RA_CUST_TRX_LINE_SALESREPS

Credit memo number CM-101 is stored in this table as follows:

cust_trx_line_salesrep_id	sales_rep_id	customer_trx_line_id	revenue_amount_split	non_revenue_amount_split	prev_cust_trx_line_salesrep_id
150205	1492	100	-463	0	140195
150206	1525	100	-463	0	140196
150207	1492	101	0	-37	140197
150208	1525	101	0	-37	140198

Assuming the credit memo only applied to the first line of the invoice, salesperson 1492 and salesperson 1525 will split the loss of the sales credit. The prev_cust_trx_line_salesrep_id column references the original sales credit from the original invoice.

RA_CUST_TRX_LINE_GL_DIST

Credit memo number CM-101 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
150160	01-1200-1000-3000		REC	-1000
150161	01-8100-1000-3000	150	REV	-926
150162	01-4100-1000-3000	151	TAX	-74

Because this is a credit memo, the revenue and tax accounts will be debited and the receivable will be credited.

AR_PAYMENT_SCHEDULES

Credit memo number CM-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_credited
400100	-1000	0	123456	CM-101	CL	-1000	CM	NULL

The class column of the credit memo payment schedule is CM. The example credit memo has a status of CL (closed) and the amount_applied column equals the amount of the credit memo, because the credit memo has been applied to an invoice. The amount_due_original column equals the amount of the credit memo, -1000. The amount_due_remaining is zero because the credit memo has been applied to an invoice.

AR_PAYMENT_SCHEDULES

Credit memo number CM-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_credited
30191	6400	5400	101467	I-101	OP	NULL	INV	-1000

Receivables updates the payment schedule of the invoice to reflect the application of the credit memo. The amount_due_remaining column is reduced by -1000 and the amount_credited column is -1000, the amount of the credit memo.

AR_RECEIVABLE_APPLICATIONS

Credit memo number CM-101 is stored in this table as follows:

receivable_application_id	amount_applied	status	payment_schedule_id	customer_trx_id	cash_receipt_ id	applied_payment_schedule_id	applied_customer_trx_id
400	1000	APP	400100	123456	NULL	30191	101467

Receivables uses the AR_RECEIVABLE_APPLICATIONS table to store the mapping of the credit memo to the invoice being credited. The payment_schedule_id and customer_trx_id columns contain the credit memo data, while the applied_payment_schedule_id and applied_customer_trx_id reference the original invoice. If the credit memo applies to an invoice with multiple payment schedules, a record is inserted into AR_RECEIVABLE_APPLICATIONS for each payment schedule of the invoice. The code_combination_id column, which is not shown, stores the receivable account of the invoice. However. when the transaction is posted to the general ledger it posts as two distributions. One entry is posted to the receivable account of the credit memo, as it is stored in the RA_CUST_TRX_LINE_GL_DIST table, and the other entry is posted to the receivable account of the invoice, as it is stored in the RA_CUST_TRX_LINE_GL_DIST table.

For a standard credit memo, the receivable account of the credit memo is debited, while the receivable account of the invoice is credited. Normally, the receivable accounts will be the same, but this process permits the flexibility of using a unique receivable account to record your credit memos.

Related Topics

On-Account Credit Memos

On-Account Credit Memos

When you enter an on-account credit without a specific invoice reference, Receivables creates records in the following tables:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST.

Consider a sample on-account credit applied to customer ABC Inc:

Transaction Number: OC-101

Bill-To: ABC Inc

Transaction Date: 05-Jun-94

Credit Amount: -1000

RA_CUSTOMER_TRX

On-Account Credit transaction number OC-101 is stored in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date	previous_customer_trx_id
660108	OC-101	ABC Inc	05-Jun-94	NULL

The previous_customer_trx_id column is NULL because the credit does not apply to a specific invoice.

RA_CUSTOMER_TRX_LINES

On-Account Credit transaction number OC-101 is stored in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount	previous_customer_trx_id	previous_customer_trx_line_id
170	660108		LINE	-1000

If there had been a sales credit for this invoice, records relating to the revenue credit would be inserted in RA_CUST_TRX_LINE_SALESREPS, linked via the column customer_trx_line_id.

For on-account credits Receivables inserts one record into RA_CUSTOMER_TRX_LINES. The total value of the credit is stored in the extended_amount column. The previous_customer_trx_line_id and previous_customer_trx_id columns are null because the credit does not apply to a specific invoice.

RA_CUST_TRX_LINE_GL_DIST

On-Account Credit transaction number OC-101 is stored in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
210220	01-1200-1000-3000		REC	-1000
210221	01-8100-1000-3000	170	REV	-1000

Because this is an on-account credit, the revenue account will be debited and the receivable will be credited.

Related Topics

Credit Memos

Unapplied Receipts

Receivables uses the following tables to store your receipt information:

• AR_CASH_RECEIPTS

• AR_CASH_RECEIPT_HISTORY

• AR_PAYMENT_SCHEDULES

• AR_RECEIVABLE_APPLICATIONS

Consider a sample receipt which is initially unapplied:

Receipt Number: R-101

Received From: ABC Inc

Transaction Date: 05-Jul-94

Receipt Amount: 4000

AR_CASH_RECEIPTS

Receipt number R-101 is stored in this table as follows:

credit_receipt_id	amount	status	receipt_number	type
338700	4000	UNAPP	R-101	CASH

AR_CASH_RECEIPT_HISTORY

Receipt number R-101 is stored in this table as follows:

cash_receipt_history_id	amount	status
457890	4000	CLEARED

AR_PAYMENT_SCHEDULES

Receipt number R-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	cash_receipt_id	customer_trx_id	trx_number	status	amount_applied	class
510555	-4000	-4000	338700	NULL	R-101	OP	0	PMT

The example receipt has a status of OP (open) and an amount_applied of NULL because the receipt has not been applied to a customer balance. The amount_due_original column equals the sum of the amount column in the AR_CASH_RECEIPTS table for the given cash_receipts_id. The class is PMT because this is a receipt related to a receivable activity. The amount_due_original and amount_due_remaining columns equal the inverse amount of the receipt.

AR_RECEIVABLE_APPLICATIONS

Receipt number R-101 is stored in this table as follows:

payment_schedule_id	amount_applied	status	payment_schedule_id	code_combination_id	cash_receipt_id	applied_payment_schedule_id	applied_customer_trx_id
408289	4000	UNAPP	400100	01-1100-1000	338700	NULL	NULL

The columns applied_payment_schedule_id and applied_customer_trx_id are NULL because the receipt has not been applied to a specific transaction. The amount_applied column equals the amount of the receipt. The code_combination_id column stores the general ledger account associated with unapplied cash receipts.

Related Topics

Applied Receipts

Reverse Receipts

Miscellaneous Receipts

Applied Receipts

Receivables uses the following tables to store your receipt information:

• AR_CASH_RECEIPTS, which stores one record for each receipt.

• AR_PAYMENT_SCHEDULES, which stores customer balance information at the transaction level.

• AR_RECEIVABLE_APPLICATIONS, which stores accounting entries for cash and credit memo applications.

Receivables supports both same currency and cross currency receipt applications. In the latter case, the receipt currency is different that the transaction currency.

Example 1 - Same Currency Receipt Application

Consider the sample receipt R-101, which is now applied to customer invoice I-101 for 6400 USD:

Receipt Number: R-101

Received From: ABC Inc

Transaction Date: 05-Jul-97

Receipt Amount: 4000 USD

AR_CASH_RECEIPTS

Receipt number R-101 is stored in this table as follows:

credit_receipt_id	receipt_number	amount	status	type	currency	rate
1521	R-101	4000	UNAPP	CASH	USD	NULL

After you apply the receipt, Receivables updates the status column from UNAPP to APP. If the receipt were only partially applied, the status would remain UNAPP.

AR_PAYMENT_SCHEDULES

Receipt number R-101 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	cash_receipt_id	customer_trx_id	trx_number	status	amount_applied	class	curr
2211	6400	2400	NULL	1422	I-101	OP	4000	INV	USD
2225	-4000	0	1521		R-101	CL	-4000	PMT	USD

The payment schedule of invoice I-101 has a class of INV, while the payment schedule of receipt R-101 has a class of PMT. The payment schedule record of the receipt is updated to reduce the amount_due_remaining column by the amount applied. Since the entire amount is applied, the amount_due_remaining is zero. The status of the receipt is changed to CL, and the amount_applied is -4000.

Note: If the cash receipt is not confirmed in the AR_CASH_RECEIPT_HISTORY table, the applications of that receipt are not reflected in the payment schedule of the transaction the receipt is applied against.

Receivables updates the payment schedule record of the invoice to reduce the amount_due_remaining by the amount of the applied receipt. The status is still OP because the entire balance has not been paid. Receivables updates the amount_applied to reflect the amount applied to the invoice.

AR_RECEIVABLE_APPLICATIONS

Receipt number R-101 is stored in this table as follows:

receivable_application_id	status	trx_number	amount_applied	code_combination_id
3132	UNAPP	NULL	4000	01-1100-1000
3134	UNAPP	NULL	- 4000	01-1200-1100
3135	APP	I-101	4000	01-1200-1100

Receivables inserts three records into AR_RECEIVABLE_APPLICATIONS. The first record, with a status of UNAPP, records the original unapplied receipt. The second record, with a status of UNAPP, offsets the original unapplied receipt. The third record, with a status of APP, stores the applied receipt information, including a reference to the applied invoice, via the trx_number column.

The code_combination_id column stores the general ledger account for this receipt, based on the status of the receipt. For the UNAPP record, the code_combination_id represents the general ledger account associated with unapplied receipts. For the APP record, the code_combination_id is the receivable account associated with the invoice transaction to which this receipt is applied.

Example 2 - Same Currency Receipt Application

Consider the sample receipt R-102, which, according to your customer's remittance advice, is to fully pay invoice I-102, using a cross currency rate of 1 CND = 0.729355 EUR.

• Receipt Number: R-102

  • Received From: ABC Inc.

  • Transaction Date: 5-JUL-97

  • Receipt Amount: 100 EUR

  • Exchange Rate: 1 EUR = .860956 USD

• Invoice Number: I-102

  • Transaction Date: 05-JUN-97

  • Invoice Amount:

  • Exchange Rate: 1 CND = .666667 USD

AR_CASH_RECEIPTS

Receipt number R-102 is stored in this table as follows:

credit_receipt_id	receipt_number	amount	status	type	currency	rate
1520	R-102	100	APP	CASH	EUR	.865956

When you apply the entire receipt, Receivables updates the status column from UNAPP to APP. If the receipt were only partially applied, the status would remain UNAPP.

AR_PAYMENT_SCHEDULES

Receipt number R-102 is stored in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	cash_receipt_id	customer_trx_id	trx_number	status	amount_applied	class	curr
2212	52.5	0		1423	I-102	CL	52.5	INV	CND
2224	-100	0	1520		R-102	CL	-100	PMT	EUR

The payment schedule of the invoice has a class of INV, while the payment schedule of the receipt has a class of PMT. The payment schedule record of the receipt is updated to reduce the amount_due_remaining column by the amount applied. Since the entire amount is applied, the amount_due_remaining is zero. The status of the receipt is changed to CL, and the amount_applied is -4000.

Note: If the cash receipt is not confirmed in the AR_CASH_RECEIPT_HISTORY table, the applications of that receipt are not reflected in the payment schedule of the transaction the receipt is applied against.

Receivables updates the payment schedule record of the invoice to reduce the amount_due_remaining by the amount of the applied receipt. The status is still OP because the entire balance has not been paid. Receivables updates the amount_applied to reflect the amount applied to the invoice.

AR_RECEIVABLE_APPLICATIONS

Receipt number R-102 is stored in this table as follows:

receivable_application_id	status	trx_number	amt_applied	amount_applied_from	trx_to_rcpt_rate	acct_amt_applied_to	acct_amt_applied_from	code_combination_id
3142	UNAPP	NULL	100				33.33	01-1100-1000
3134	UNAPP	NULL	-100	- 100		-33.33	-33.33	01-1200-1100
3135	APP	I-102	52.5	100	1.9048	35	33.33	01-1200-1000

Again, Receivables inserts three records into AR_RECEIVABLE_APPLICATIONS. The first record, with a status of UNAPP, records the original unapplied receipt. The second record, with a status of UNAPP, offsets the original unapplied receipt. The third record, with a status of APP, stores the applied receipt information, including a reference to the applied invoice, via the trx_number column.

The code_combination_id column stores the general ledger account for this receipt, based on the status of the receipt. For the UNAPP record, the code_combination_id represents the general ledger account associated with unapplied receipts. For the APP record, the code_combination_id is the receivable account associated with the invoice transaction to which this receipt is applied.

Related Topics

Commitments

Credit Memos

Unapplied Receipts

Reverse Receipts

Miscellaneous Receipts

Reverse Receipts

Receivables uses the following tables to store your receipt information:

• AR_CASH_RECEIPTS

• AR_CASH_RECEIPT_HISTORY

• AR_PAYMENT_SCHEDULES

• AR_RECEIVABLE_APPLICATIONS

If receipt R-101 was not an actual receipt, we could enter a reverse receipt transaction to cancel the receipt.

AR_CASH_RECEIPTS

The reverse receipt is represented in this table as follows:

credit_receipt_id	amount	status	receipt_number	type
338700	4000	REV	R-101	CASH

Receivables updates the status column of the original receipt from APP, applied, to REV, reversed.

AR_CASH_RECEIPT_HISTORY

The reverse receipt is represented in this table as follows:

cash_receipt_history_id	amount	status
545352	4000	REVERSED

A new record, which is not postable, will be inserted into AR_CASH_RECEIPT_HISTORY to record the reverse receipt. Additionally, the current_record_flag of the original cash receipt record will be updated to null, while the reverse_gl_date column of the original receipt record will be set.

AR_PAYMENT_SCHEDULES

The reverse receipt is represented in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	cash_receipt_id	customer_trx_id	trx_number	status	amount_applied	class
510555	-4000	0	338700	NULL	R-101	CL	0	PMT
30191	6400	6400	NULL	101467	I-101	OP	0	INV

The payment schedule of the invoice has a class of INV, while the payment schedule of the receipt has a class of PMT. Because the receipt has been reversed, the amount_due_remaining and amount_applied columns are zero and the status column is CL, closed.

Receivables updates the payment schedule record of the invoice to increase the amount_due_remaining by the amount of the reverse receipt. The status is still OP because the entire balance has not been paid. The amount_applied column is zero because no transactions have been applied to the invoice.

AR_RECEIVABLE_APPLICATIONS

The reverse receipt is represented in this table as follows:

receivable_application_id	amount_applied	status	payment_schedule_id	code_combination_id	cash_receipt_id	applied_payment_schedule_id	applied_customer_trx_id
408292	-4000	APP	400100	01-1200-1100	338700	30191	101467
408293	4000	UNAPP	400100	01-1100-1000	338700	NULL	NULL
408294	-4000	UNAPP	400100	01-1100-1000	338700	NULL	NULL

Receivables inserts three records into AR_RECEIVABLE_APPLICATIONS. The first record, with a status of APP, offsets the original application of the receipt, including a reference to the applied invoice, via the applied_payment_schedule_id and applied_customer_trx_id columns. The second and third records, with a status of UNAPP, offset the original unapplied transactions. The code_combination_id for the APP record is the receivable account associated with the invoice to which this receipt was originally applied. The code_combination_id for the two UNAPP records is the general ledger account associated with unapplied receipts.

Related Topics

Applied Receipts

Unapplied Receipts

Miscellaneous Receipts

Miscellaneous Receipts

Receivables uses the following tables to store your receipt information:

• AR_CASH_RECEIPTS

• AR_CASH_RECEIPT_HISTORY

• AR_MISC_CASH_DISTRIBUTIONS

Consider a sample miscellaneous receipt:

Receipt Number: R-102

Received From: Stock Broker

Transaction Date: 07-Jul-94

Receipt Amount: 500

AR_CASH_RECEIPTS

Receipt number R-102 is stored in this table as follows:

cash_receipt_id	amount	status	receipt_number	type
345678	500	APP	R-102	MISC

For miscellaneous receipts, Receivables uses a status of APP. The type column is MISC for receipts not related to a receivable activity. The amount column stores the net amount of the receipt, while the receipt_number column stores the receipt number.

AR_CASH_RECEIPT_HISTORY

Receipt number R-102 is stored in this table as follows:

cash_receipt_history_id	amount	status
467890	500	CLEARED

The only valid status values for a miscellaneous receipt are REMITTED, CLEARED, and REVERSED.

AR_MISC_CASH_DISTRIBUTIONS

Receipt number R-102 is stored in this table as follows:

misc_cash_distribution_id	cash_receipt_id	code_combination_id	amount
101789	345678	01-1190-1000-3000	250
101790	345678	01-1195-1000-3000	250

The code_combination_id stores the general ledger account associated with miscellaneous receipts. Each receipt may have multiple account distributions. The sum of the distributions for a given receipt will equal the amount of the receipt.

Related Topics

Unapplied Receipts

Applied Receipts

Chargebacks

Adjustments

Chargebacks

You create chargebacks to decrease the balance of an invoice and to create another debit item for the same amount. Receivables handles chargebacks the same as invoices, but also creates an adjustment to decrease the balance of the invoice.

Receivables uses the following tables to store your chargeback information:

• RA_CUSTOMER_TRX

• RA_CUSTOMER_TRX_LINES

• RA_CUST_TRX_LINE_GL_DIST

• AR_ADJUSTMENTS

• AR_PAYMENT_SCHEDULES

Consider the invoice I-101 created in the first example of this essay. You receive a payment for 2000 on June 1, 1994, and decide to create a chargeback, CB-101, for the balance of the invoice, 4400.

RA_CUSTOMER_TRX

This transaction is represented in this table as follows:

customer_trx_id	trx_number	bill_to_customer_id	trx_date
765432	CB-101	ABC Inc	01-Jun-94

RA_CUSTOMER_TRX_LINES

This transaction is represented in this table as follows:

customer_trx_line_id	customer_trx_id	link_to_cust_trx_line_id	line_type	extended_amount
711	765432		CB	4400

Receivables creates one record in RA_CUSTOMER_TRX_LINES for the chargeback with a line_type of 'CB' and the extended_amount equal to the balance of the invoice.

There is no impact to the RA_CUST_TRX_LINE_SALESREPS.

RA_CUST_TRX_LINE_GL_DIST

This transaction is represented in this table as follows:

cust_trx_line_gl_dist_id	code_combination_id	customer_trx_line_id	account_class	amount
660116	01-1200-1000-3000	NULL	REC	4400
660117	01-8100-1000-3000	711	REV	4400

Receivables inserts two records into the RA_CUST_TRX_LINE_GL_DIST table. The code_combination_id of the REC record stores the receivable account distribution for the chargeback. The code_combination_id of the REV record stores the revenue account distribution for the chargeback.

AR_ADJUSTMENTS

This transaction is represented in this table as follows:

adjustment_id	amount	customer_trx_id	type	payment_schedule_id	code_combination_id
57931	-4400	101467	INVOICE	30191	01-8100-1000-3000

When the chargeback is created, Receivables inserts a record into AR_ADJUSTMENTS to record an adjustment against the invoice. The amount column equals the inverse of the amount_due_remaining on the invoice payment schedule in the AR_PAYMENT_SCHEDULES table. The customer_trx_id and the payment_schedule_id columns reference the original invoice.

For chargebacks, the type column is always INVOICE. The code_combination_id column stores the revenue account of the chargeback. This transaction will offset the REV distribution from the RA_CUST_TRX_LINE_GL_DIST table. To link this adjustment with the chargeback, the chargeback_customer_trx_id column, which is not shown, stores the customer_trx_id of the chargeback.

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_adjusted
565785	4400	4400	765432	CB-101	OP	NULL	CB	NULL

The class column, CB, identifies this payment schedule as a chargeback. The example chargeback has a status of OP (open) and an amount_applied of NULL because no payment has been applied against it. The amount_due_original and amount_due_remaining columns equal the amount of the chargeback.

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_adjusted
30191	6400	0	101467	I-101	CL	2000	INV	-4400

Receivables updates the invoice payment schedule in the AR_PAYMENT_SCHEDULES by reducing the amount_due_remaining column to zero, to reflect the application of the chargeback to the invoice. The amount_adjusted column equals the amount of the chargeback and the status column is changed to closed (CL).

Related Topics

Adjustments

Adjustments

You can create adjustments to increase or decrease invoice balances. You can make adjustments to invoices, lines, tax or freight. Receivables uses the following tables to store your adjustment information:

• AR_ADJUSTMENTS

• AR_PAYMENT_SCHEDULES

For example, adjust invoice number I-104 to write off the remaining balance of 2400.

AR_ADJUSTMENTS

This transaction is represented in this table as follows:

adjustment_id	amount	customer_trx_id	type	payment_schedule_id	code_combination_id
987654	-2400	899143	INVOICE	646566	01-5100-3000-1000

Receivables inserts a record into AR_ADJUSTMENTS to record adjustment details such as the amount, the type of adjustment, the customer_trx_id and the payment_schedule_id of the invoice you want to adjust. The amount column equals the amount of the adjustment. The code_combination_id column stores the general ledger distribution for the adjustment transaction.

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

payment_schedule_id	amount_due_original	amount_due_remaining	customer_trx_id	trx_number	status	amount_applied	class	amount_adjusted
646566	6400	0	899143	I-104	CL	4000	INV	-2400

Receivables updates the payment schedule record of the invoice in AR_PAYMENT_SCHEDULES, by adjusting the amount_due_remaining to zero, changing the status to CL, and changing the amount_adjusted to -2400.

Related Topics

Chargebacks

About Adjustments