Skip Headers

Oracle Receivables User Guide
Release 12.1
Part Number E13522-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Accounting for Receivables

Opening and Closing Accounting Periods

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

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

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

Period Status

An accounting period can have one of the following statuses:

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

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

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

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

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

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

Open: Transaction entry and posting are allowed.

Prerequisites

To open or close an accounting period:

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

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

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

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

Related Topics

Entering Transactions

Accounting in Receivables

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

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

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

Leveraging this accounting architecture, Receivables lets you:

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

How Does Accounting in Receivables Work?

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

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

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

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

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

Related Topics

Oracle Subledger Accounting Implementation Guide

Multi-Fund Accounts Receivable

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

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

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

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

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

Related Topics

Multi-Fund Accounts Receivable Balancing and Accounting Method Example

Cash Receipts in Multi-Fund Accounts Receivable Model

Credit Memo Examples

Multi Fund Accounts Receivables Receipt Examples

Adjusting Multi-Fund Accounts Receivable Invoice Examples

Receivables Accounting Event Model

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

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

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

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

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

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

Transactions Event Entity

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

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

Receipts Event Entity

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

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

Adjustments Event Entity

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

Event Class Event Types
Adjustment Adjustment Created

Bills Receivable Event Entity

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

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

Using AutoAccounting

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

When you run AutoAccounting, Receivables:

AutoAccounting and Oracle Subledger Accounting

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

Automatic Accounting Flexfield Creation

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

User Definable Structure

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

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

User Changeable Defaults

AutoAccounting always lets you override the default Accounting Flexfields.

Related Topics

AutoAccounting Structure

How to Use AutoAccounting

AutoAccounting, Oracle Receivables Implementation Guide

Defining AutoAccounting - Overview

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

Related Topics

Using AutoAccounting

AutoAccounting Structure

AutoAccounting Structure

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

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

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

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

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

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

Related Topics

How to Use AutoAccounting

AutoAccounting, Oracle Receivables Implementation Guide

How to Use AutoAccounting

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

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

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

Example 1

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

Using AutoAccounting to Create Flexfield Segments

the picture is described in the document text

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

the picture is described in the document text

Creating Accounting in Receivables

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

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

Submitting the Submit Accounting Program

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

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

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

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

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

Prerequisites

Related Topics

Viewing Accounting Lines

Using Oracle Subledger Accounting Inquiries

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

Related Topics

Accounting Events Inquiry, Oracle Subledger Accounting Implementation Guide

Subledger Journal Entry Headers Inquiry, Oracle Subledger Accounting Implementation Guide

Subledger Journal Entry Lines Inquiry, Oracle Subledger Accounting Implementation Guide

Oracle Subledger Accounting Reports

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

Related Topics

Subledger Accounting Reports Overview, Oracle Subledger Accounting Implementation Guide

Open Account Balances Listing, Oracle Subledger Accounting Implementation Guide

Posting

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

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

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

Reconcile Customer Balances

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

Posting Detail

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

Posting Reports

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

Related Topics

Reconciling Receivables

Reconciling Receivables

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

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

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

    See: Reconciling Subledger Details.

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

    See: Reconciling General Ledger Details.

Related Topics

Reconciling Subledger Details

Reconciling General Ledger Details

Reconciliation Reports

Reconciling Subledger Details

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

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

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

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

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

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

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

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

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

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

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

    See: Reconciliation Reports.

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

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

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

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

The following illustration describes the above internal reconciliation process.

the picture is described in the document text

Related Topics

Reconciling Receipts

Reconciling General Ledger Details

Reconciling Receivables

Receipt Journal

Sales Journal by Customer

Reconciling Receipts

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

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

Accounting Data Accounting Report Related Transaction Report
total receipts (trade plus miscellaneous) Receipt Journal Receipt Register
  1. Periodically check that Receivables receipts balance by running the Receipt Journal report and the Receipt Register for the same GL Date range.

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

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

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

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

Related Topics

Receipt Journal

Receipt Register

Reconciling General Ledger Details

Reconciling Receivables

Reconciliation Reports

Reconciling General Ledger Details

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

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

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

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

    See: Reconciling the General Ledger Transfer Process.

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

    See: Verifying GL Accounts.

Reconciling the General Ledger Transfer Process

Follow these recommended reconciling steps:

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

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

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

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

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

Reconciling the Journal Import Process

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

Follow these recommended reconciling steps:

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

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

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

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

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

Report Options

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

Verifying GL Accounts

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

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

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

The following illustration describes the external reconciliation process.

the picture is described in the document text

Related Topics

Posting

Reconciling Receivables

Reconciliation Reports

Using Cash Basis Accounting

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

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

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

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

Related Topics

Accrual vs. Cash Basis Accounting

Journal Entries

Preparing Receivables

Defining Receivables System Options, Oracle Receivables Implementation Guide

Accounting for Transactions (Accrual method)

Accrual vs. Cash Basis Accounting

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

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

Adjustments (Cash Basis Accounting)

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

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

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

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

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

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

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

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

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

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

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

Account Debit Credit
Cash $1800  
Revenue   $1800

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

Chargebacks

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

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

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

Account Debit Credit
Cash $200  
Chargeback Adjustment   $200

Credit Memos and On-Account Credits

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

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

Consider the journal entries created in the following instances:

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

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

This table shows the journal entries that are created:

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

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

This table shows the journal entries that are created:

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

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

This table shows the journal entries that are created:

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

Related Topics

Default Accounting for Transactions (Accrual method)

Journal Entries

Preparing Receivables

Journal Entries

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

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

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

Related Topics

Accrual vs. Cash Basis Accounting

Preparing Receivables

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

Define your Accounting Method

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

Set up an Unallocated Revenue Account

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

Consider the following example:

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

Invoice Line #1 is for $100

Invoice Line #2 is for -$100

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

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

Account Debit Credit
Cash $50  
Unallocated Revenue   $50

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

Set up your Transaction Types

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

Make GL Transfer and Journal Entry Report Incompatible

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

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

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

Related Topics

Using Cash Basis Accounting

Viewing Accounting Lines in Receivables

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

To view accounting lines:

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

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

  2. Choose View Accounting from the Tools menu.

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

    See: View Accounting Windows.

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

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

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

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

View Accounting Windows

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

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

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

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

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

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

Customizing the View Accounting Windows

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

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

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

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

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

Related Topics

Drilling Down to Oracle Receivables from Oracle General Ledger

Drilling Down to Oracle Receivables from Oracle General Ledger

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

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

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

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

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

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

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

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

Customizing the Drilldown Windows

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

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

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

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

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

Drilling Down Further

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

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

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

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

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

Related Topics

Viewing Accounting Lines

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

T-Accounts, Oracle General Ledger User's Guide

Viewing MRC Details for a Transaction

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

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

For a transaction, the window displays:

For a receipt, the window displays:

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.

Default Accounting for Transactions

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

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

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

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

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

Invoices

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

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

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

In the first period of the rule:

DR Unbilled Receivables
   CR Revenue

In the second period of the rule:

DR Unbilled Receivables
   CR Revenue

In the third and final period of the rule:

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

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

In the first period of the rule:

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

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

DR Unearned Revenue
   CR Revenue

Credit Memos

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

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

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

DR Revenue
   CR Receivables

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

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

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

Commitments

Deposits

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

DR Receivables (Deposit)
   CR Offset Account

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

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

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

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

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

DR Cash
   CR Receivables (Deposit)

Guarantees

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

DR Receivables
   CR Revenue

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

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

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

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

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

DR Cash
   CR Receivables (Invoice)

Receipts

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

DR Cash
   CR Receivables

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

DR Cash
DR Unapplied Cash
   CR Unapplied Cash
   CR Receivables

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

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

DR Cash
   CR Unidentified

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

DR Cash
   CR Unapplied
DR Unapplied
   CR On-Account

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

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

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

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

DR Cash
   CR Unapplied Cash

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

DR Receivables
   CR Unapplied Cash

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

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

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

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

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

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

DR Unapplied Cash
   CR Write-off

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

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

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

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

See: Receipt-to-Receipt Applications.

Following the example above, Receivables creates these journal entries:

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

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

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

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

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

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

Remittances

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

DR Confirmation
   CR Receivables 

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

DR Remittance
   CR Confirmation

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

DR Cash
DR Bank Charges
   CR Remittance 

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

DR Factor
   CR Confirmation 

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

DR Cash
DR Bank Charges
   CR Short-Term Debt

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

DR Short-Term Debt
   CR Factor

Adjustments

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

DR Write-Off
   CR Receivables (Invoice)

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

DR Receivables (Invoice)
   CR Write-Off

Debit Memos

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

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

On-Account Credits

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

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

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

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

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

Credit Card Refunds

Creating a credit card refund

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

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

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

DR Receivable Activity (Clearing Account)
   CR Cash

Reversing a credit card refund

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

DR Cash
   CR Receivable Activity (Clearing Account)

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

DR Receivables Activity (Clearing Account)
   CR Unapplied

Claims

Creating an invoice related claim

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

Creating a non-invoice related claim

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

DR Claim Investigation
   CR Unapplied Cash

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

Related Topics

About Remittances

Credit Card Refunds

Defining Receivables System Options, Oracle Receivables Implementation Guide

Transaction Types, Oracle Receivables Implementation Guide

AutoAccounting, Oracle Receivables Implementation Guide

Receivables Activities, Oracle Receivables Implementation Guide

Receipt Classes, Oracle Receivables Implementation Guide

Using Cash Basis Accounting

Working with Claims

Technical Perspective: Transactions

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

Introduction

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

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

RA_CUSTOMER_TRX table

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

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

RA_CUSTOMER_TRX_LINES table

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

RA_CUST_TRX_LINE_SALESREPS table

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

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

RA_CUST_TRX_LINE_GL_DIST table

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

AR_PAYMENT_SCHEDULES table

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

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

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

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

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

AR_ADJUSTMENTS table

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:

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

AR_RECEIVABLE_APPLICATIONS table

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

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

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

AR_CREDIT_MEMO_AMOUNTS table

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

AR_CASH_RECEIPTS table

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:

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

AR_CASH_RECEIPT_HISTORY table

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:

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

AR_MISC_CASH_DISTRIBUTIONS table

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

Assumptions

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

Related Topics

Invoices

Debit Memos

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Credit Memos

On-Account Credit Memos

Unapplied Receipts

Applied Receipts

Reverse Receipts

Miscellaneous Receipts

Chargebacks

About Adjustments

Invoices

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

Consider a sample invoice:

Invoice Number: I-101

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

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

RA_CUSTOMER_TRX

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

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

RA_CUSTOMER_TRX_LINES

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

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

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

RA_CUST_TRX_LINE_SALESREPS

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

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

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

RA_CUST_TRX_LINE_GL_DIST

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

Related Topics

Debit Memos

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Chargebacks

About Adjustments

Debit Memos

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

Related Topics

Commitments

Invoice Against a Deposit

Invoice Against a Guarantee

Credit Memos

Commitments

Receivables uses the following tables to store your commitment information:

Consider a sample guarantee:

Guarantee Number: G-101

Bill-To: ABC Inc

Guarantee Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

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

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

RA_CUSTOMER_TRX_LINES

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

customer_trx_line_id customer_trx_id link_to_cust_trx_line_id line_type extended_amount
108 122341   LINE 500

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

RA_CUST_TRX_LINE_GL_DIST

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

Related Topics

Invoice Against a Deposit

Invoice Against a Guarantee

Invoice Against a Deposit

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

Consider a sample invoice:

Invoice Number: I-102

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

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

with a sample deposit:

Deposit Number: D-101

Bill-To: ABC Inc

Deposit Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

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

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

RA_CUSTOMER_TRX_LINES

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

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

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

RA_CUST_TRX_LINE_GL_DIST

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

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

AR_PAYMENT_SCHEDULES

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

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

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

AR_ADJUSTMENTS

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

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

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

Related Topics

Invoice Against a Guarantee

Invoice Against a Guarantee

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

Consider a sample invoice:

Invoice Number: I-103

Bill-To: ABC Inc

Invoice Date: 22-May-94

Invoice Lines:

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

with a sample guarantee:

Guarantee Number: G-102

Bill-To: ABC Inc

Deposit Date: 20-May-94

Amount: $500

RA_CUSTOMER_TRX

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

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

RA_CUSTOMER_TRX_LINES

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

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

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

RA_CUST_TRX_LINE_GL_DIST

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

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

AR_PAYMENT_SCHEDULES

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

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

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

AR_ADJUSTMENTS

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

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

Related Topics

Commitments

Invoice Against a Deposit

Credit Memos

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

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

Credit Memo Number: CM-101

Bill-To: ABC Inc

Credit Memo Date: 01-Jun-94

Credit Memo Amount: -1000

RA_CUSTOMER_TRX

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

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

The previous_customer_trx_id column references the original transaction you have credited.

RA_CUSTOMER_TRX_LINES

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

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

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

RA_CUST_TRX_LINE_SALESREPS

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

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

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

RA_CUST_TRX_LINE_GL_DIST

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

AR_RECEIVABLE_APPLICATIONS

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

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

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

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

Related Topics

On-Account Credit Memos

On-Account Credit Memos

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

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

Transaction Number: OC-101

Bill-To: ABC Inc

Transaction Date: 05-Jun-94

Credit Amount: -1000

RA_CUSTOMER_TRX

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

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

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

RA_CUSTOMER_TRX_LINES

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

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

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

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

RA_CUST_TRX_LINE_GL_DIST

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

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

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

Related Topics

Credit Memos

Unapplied Receipts

Receivables uses the following tables to store your receipt information:

Consider a sample receipt which is initially unapplied:

Receipt Number: R-101

Received From: ABC Inc

Transaction Date: 05-Jul-94

Receipt Amount: 4000

AR_CASH_RECEIPTS

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

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

AR_CASH_RECEIPT_HISTORY

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

cash_receipt_history_id amount status
457890 4000 CLEARED

AR_PAYMENT_SCHEDULES

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

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

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

AR_RECEIVABLE_APPLICATIONS

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

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

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

Related Topics

Applied Receipts

Reverse Receipts

Miscellaneous Receipts

Applied Receipts

Receivables uses the following tables to store your receipt information:

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

Example 1 - Same Currency Receipt Application

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

Receipt Number: R-101

Received From: ABC Inc

Transaction Date: 05-Jul-97

Receipt Amount: 4000 USD

AR_CASH_RECEIPTS

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

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

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

AR_RECEIVABLE_APPLICATIONS

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

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

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

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

Example 2 - Same Currency Receipt Application

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

AR_CASH_RECEIPTS

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

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

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

AR_PAYMENT_SCHEDULES

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

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

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

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

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

AR_RECEIVABLE_APPLICATIONS

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

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

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

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

Related Topics

Commitments

Credit Memos

Unapplied Receipts

Reverse Receipts

Miscellaneous Receipts

Reverse Receipts

Receivables uses the following tables to store your receipt information:

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

AR_CASH_RECEIPTS

The reverse receipt is represented in this table as follows:

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

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

AR_CASH_RECEIPT_HISTORY

The reverse receipt is represented in this table as follows:

cash_receipt_history_id amount status
545352 4000 REVERSED

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

AR_PAYMENT_SCHEDULES

The reverse receipt is represented in this table as follows:

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

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

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

AR_RECEIVABLE_APPLICATIONS

The reverse receipt is represented in this table as follows:

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

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

Related Topics

Applied Receipts

Unapplied Receipts

Miscellaneous Receipts

Miscellaneous Receipts

Receivables uses the following tables to store your receipt information:

Consider a sample miscellaneous receipt:

Receipt Number: R-102

Received From: Stock Broker

Transaction Date: 07-Jul-94

Receipt Amount: 500

AR_CASH_RECEIPTS

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

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

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

AR_CASH_RECEIPT_HISTORY

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

cash_receipt_history_id amount status
467890 500 CLEARED

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

AR_MISC_CASH_DISTRIBUTIONS

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

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

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

Related Topics

Unapplied Receipts

Applied Receipts

Chargebacks

Adjustments

Chargebacks

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

Receivables uses the following tables to store your chargeback information:

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

RA_CUSTOMER_TRX

This transaction is represented in this table as follows:

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

RA_CUSTOMER_TRX_LINES

This transaction is represented in this table as follows:

customer_trx_line_id customer_trx_id link_to_cust_trx_line_id line_type extended_amount
711 765432   CB 4400

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

There is no impact to the RA_CUST_TRX_LINE_SALESREPS.

RA_CUST_TRX_LINE_GL_DIST

This transaction is represented in this table as follows:

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

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

AR_ADJUSTMENTS

This transaction is represented in this table as follows:

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

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

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

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

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

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

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

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

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

Related Topics

Adjustments

Adjustments

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

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

AR_ADJUSTMENTS

This transaction is represented in this table as follows:

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

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

AR_PAYMENT_SCHEDULES

This transaction is represented in this table as follows:

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

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

Related Topics

Chargebacks

About Adjustments