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.
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
Navigate to the Open/Close Accounting Periods window.
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.
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
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.
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 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
Multi Fund Accounts Receivables Receipt Examples
Adjusting Multi-Fund Accounts Receivable Invoice Examples
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.
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 |
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 |
This table describes the event classes and types that Receivables predefines for the Adjustments event entity.
Event Class | Event Types |
---|---|
Adjustment | Adjustment Created |
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 |
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.
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.
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.
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.
AutoAccounting always lets you override the default Accounting Flexfields.
Related Topics
AutoAccounting, Oracle Receivables Implementation Guide
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
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
AutoAccounting, Oracle Receivables Implementation Guide
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
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.
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.
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
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 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
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.
To internally reconcile your outstanding account balances before submitting the Create Accounting program, use standard Oracle Receivables reports. For more information, see: Reconciling Receivables.
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.
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
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:
Internal reconciliation: Reconcile the period's operational activity with Receivables accounting data, before posting to the general ledger.
External reconciliation: After posting, reconcile subledger details with the general ledger.
Related Topics
Reconciling General Ledger 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:
Use the AR Reconciliation report to compare transactional data against accounting data.
Optionally run the Potential Reconciling Items report to view suggested journal items that might potentially post to incorrect GL account types.
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.
Run the Aging - 7 Buckets - By Account or the Aging - 4 Buckets report to view beginning and ending customer balances. See: Aging Reports.
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 General Ledger Details
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 |
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.
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
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:
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.
Confirm that all journals posted to the correct GL accounts.
See: Verifying GL Accounts.
Follow these recommended reconciling steps:
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.
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.
Once transactions and receipts have been transferred to Oracle General Ledger, they are considered posted within the Receivables subledger.
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:
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.
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.
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.
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.
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
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
Defining Receivables System Options, Oracle Receivables Implementation Guide
Accounting for Transactions (Accrual method)
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. |
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.
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 |
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)
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
To prepare Receivables for Cash Basis accounting, perform the following setup steps.
Select Cash Basis as your accounting method in the System Options window.
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.
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'.
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
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.
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.
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.
(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.
(Optional) To view the accounting detail as t-accounts, choose the T-Accounts button.
See: T-Accounts, Oracle General Ledger User's Guide.
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
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
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
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 |
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.
From the Payables Invoice Accounting, Payables Payment Accounting, or Receivables Adjustment Accounting window, select a detail accounting line.
Choose the Show Transaction button to view detail transactions.
Choose the Show Transaction Accounting button to view the transaction accounting.
Related Topics
Drilling Down to Subledger Detail, Oracle General Ledger User's Guide
T-Accounts, Oracle General Ledger User's Guide
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.
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.
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
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.
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)
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)
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.
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
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
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
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)
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
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
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.
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
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
This essay describes the key tables and columns Receivables uses to store your accounts receivable transactions.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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 |
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.
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.
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.
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
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
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
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 |
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.
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.
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
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
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 |
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.
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 |
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.
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.
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
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
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 |
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.
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 |
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
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
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 |
Receipt number R-101 is stored in this table as follows:
cash_receipt_history_id | amount | status |
---|---|---|
457890 | 4000 | CLEARED |
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.
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
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.
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
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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
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
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.
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.
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
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.
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 |
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.
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.
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.
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.
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
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.
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.
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