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

Receipts

Entering Receipts

Use the Receipts window to enter new or query existing receipts.

You can enter two types of receipts in Receivables:

You can enter receipts and apply them to transactions in either Open or Future accounting periods. You can also create chargebacks or adjustments against these transactions.

You can apply receipts to invoices, debit memos, deposits, on-account credits, and chargebacks. You can partially or fully apply a receipt to a single debit item or to several debit items.

You can also apply receipts to other open receipts. See: Receipt-to-Receipt Applications.

If you are using Oracle Trade Management, then you can place your customers' overpayments and short payments into claim investigation while the claim is being researched. See: Applying Receipts and Working with Claims.

If you do not specify a customer for a receipt, the receipt is unidentified. In this case, the receipt amount appears in the Unidentified field in the Receipts window (Balances region). You cannot apply an unidentified receipt.

Note: You can view the detail accounting lines for an existing receipt in the form of a balanced accounting entry (i.e., debits equal credits) by choosing View Accounting from the Tools menu. You can also choose to view the detail accounting as t-accounts.

See: Viewing Accounting Lines.

Note: If you are using Multiple Reporting Currencies (MRC) functionality, then you can use the View Currency Details window to view receipt amounts in both your primary and MRC reporting currencies.

See: Viewing MRC Details for a Transaction.

Viewing the Receipt History

Use the Receipt History window to view additional details about your saved receipts. This window displays a history of the receipt's statuses, as well as exchange rate adjustments. You can also view all application notes that were made to this receipt.

This window also includes Oracle Cash Management-related information. See: Receipts Field Reference.

From the Receipts window, click Receipt History.

See: Reviewing Receipts and Applications.

Receipt Status

A receipt can have one of the following statuses:

Approved: This receipt has been approved for automatic receipt creation. This status is only valid for automatic receipts.

Confirmed: For manually entered receipts, this status indicates the receipt belongs to a receipt class that requires remittance.

Remitted: This receipt has been remitted.

Cleared: The payment of this receipt was transferred to your bank account and the bank statement has been reconciled within Receivables.

Reversed: This receipt has been reversed. You can reverse a receipt when your customer stops payment on a receipt, if a receipt comes from an account with non-sufficient funds or if you want to re-enter and reapply it in Receivables.

Note: A receipt's state is different from its status. See: Receipts Field Reference.

Prerequisites

To manually enter a receipt:

  1. Navigate to the Receipts or Receipts Summary window.

  2. Enter a receipt method. Receivables uses the receipt method to determine the accounting and remittance bank accounts for this receipt.

    The selected receipt method automatically defaults the payment method and instrument number. Receipts paid by automatic methods use Oracle Payments to complete the funds capture process. See: Enabling the Funds Capture Process, Oracle Receivables Implementation Guide.

  3. Enter the receipt information, including receipt number, currency, receipt amount, GL date, and receipt date. The default GL date is the same as the batch GL date. If there is no batch information, the GL date is the same as the receipt date. The default receipt date is the current date, but you can change it. If the Receipt date is not in an open period, Receivables changes the GL date to the last date of the most recent open period. You can change the GL date, but it must be in an open or future period. If this receipt is part of a batch and you change the receipt date, Receivables does not automatically modify the GL date.

    Note: After you create the receipt, you cannot update the receipt or GL date. To make changes to these dates, either delete and recreate the receipt, or reverse the receipt.

    You can enter transactions in any currency defined in Oracle Receivables if you have at least one remittance bank account which has the Multiple Currencies Allowed check box selected. If no such bank account exists, you are limited to entering only those currencies in which bank accounts exist. (The currency of a multiple currency bank account must be the same as your functional currency.)

    If the currency for this receipt is different from your functional currency and you have not defined daily conversion rates, enter exchange rate information. See: Foreign Currency Transactions.

  4. Choose a receipt type of Standard.

  5. To help identify the customer for this receipt, enter a transaction number (optional). Receivables displays the customer associated with this transaction. If multiple customers have transactions with the number you entered, Receivables displays a window from which you can select a customer. If you enter a number here, Receivables defaults the number in the Applications window when you apply this receipt.

  6. If you did not enter a transaction number and the receipt is not unidentified, enter customer information for this receipt, including customer name or number and bill-to location. When you enter the customer, Receivables enters this customer's primary bill-to location, if one exists (you can change this value). If the system option Require Billing Location for Receipts is set to Yes, you must enter a bill-to location.

    Important: If you do not enter a bill-to location and the customer has no statement site, any unapplied or on-account receipt amounts will not appear on statements sent to this customer.

  7. If bank charges apply, then enter an amount for bank charges. Bank charges may apply if the receipt's creation status is 'Cleared' (the clearance method of the associated receipt class must be set to 'Directly'). See: Receipt Classes, Oracle Receivables Implementation Guide.

    Note: This field is available only if the AR: Create Bank Charges profile option is Yes.

  8. The receipt method that you previously selected automatically defaults the payment method and instrument number.

    Optionally choose Select Instrument to navigate to the Payment Instrument window. To choose this button, you must first select a receipt method. In the Payment Instrument window, you can select a different payment instrument, or create a new one. You can select any payment instrument that has been assigned to the defaulted payment method at the customer account or site level.

    Note: You cannot add a payment instrument if the receipt method is assigned to a receipt class whose creation method is Manual.

    The Payment Instrument window also displays payment instrument details. Oracle Payments populates these fields during the funds capture process.

    The fields in this window display differently depending on the payment method that is associated with the receipt method. For example:

    For both types of payment instruments, use the Payment Details page to indicate the priority level of each payment instrument, if multiple instruments exist, as well as the customer's notification preferences, such as by e-mail or fax.

    Note: You can also create payment instruments at the customer account or site level. See: Entering and Updating Account Payment Details and Entering and Updating Account Site Payment Details.

  9. The Payment Server Order Number (PSON) field is a display only field and is populated by Oracle Payments.

    This number is the order number used by Payments during the funds capture settlement process.

  10. Receivables derives the default remittance bank account from the receipt method you entered. You can accept this value or enter any bank account assigned to the receipt method if the bank account is in the same currency as that of the receipt or the bank account has the Multiple Currencies Allowed check box selected. Only bank accounts that are in your functional currency can accept multiple currency deposits. See: Manually Entering Automatic Receipts.

  11. If you are using manual document numbering, then open the More tabbed region and enter a unique document number.

    Otherwise, Receivables assigns this transaction a unique number when you save.

    See: Implementing Document Sequences, Oracle Receivables Implementation Guide.

  12. Enter the receipt deposit date (optional). The default is either the deposit date entered at the batch level or, if there is no batch information, the receipt date. The default receipt maturity date is the deposit date.

    Receivables uses the deposit date as the exchange date when the receipt currency is different from your functional currency. If you later change the deposit date, then Receivables also updates the exchange date.

  13. To prevent the receipt remittance bank from being automatically overridden during the remittance process, choose Don't Allow in the Override field (optional).

    If you choose Allow, Receivables can automatically change the receipt remittance bank to the remittance batch bank during the remittance process.

    See: Creating Remittance Batches.

  14. Save your work. If you entered a customer, the receipt amount appears in the Unapplied field in the Balances region. Otherwise, the entire receipt amount appears in the Unidentified field.

    To apply this receipt, see: Applying Receipts.

Related Topics

Receipts Field Reference

Entering Miscellaneous Receipts

Batching Receipts for Easy Entry and Retrieval

Creating Chargebacks and Adjustments

Reversing Receipts

Reapplying Receipts

Receipt Analysis - Days Late Report

Receipt Register

Unapplied and Unresolved Receipts Register

Receipts Field Reference

This section provides a brief description of some of the fields in the Receipts, Receipts Summary, Receipt Batches, and Receipt History windows.

Actual Count/Amount: The total number and amount of receipts in this batch. If you add receipts in different currencies to a batch, the total amount reflects the amount entered in all currencies, not just the batch currency. Receivables updates these fields when you add cash receipts to this batch.

Actual Value Date: (Receipt History window) The date when cash is withdrawn (for a payment) or deposited (for a receipt) in a bank account. Your bank usually provides this date on your bank statement. When you reconcile receipts with your bank statement in Oracle Cash Management, Receivables automatically updates this field with the bank statement line's value date.

Anticipated Value Date: (Receipt History window) The date you expect cash to be withdrawn (for a payment) or deposited (for a receipt) in your bank account. This field is optional. The bank uses this date to determine the available balance to apply interest calculations. This field is used by Oracle Cash Management's Cash Forecasting feature.

Application Notes: (Receipt History window) This field is used for receipts that are imported into Receivables via AutoLockbox.

If you select the Post Partial Amount as Unapplied box as one of your AutoLockbox options, then AutoLockbox can import a receipt into QuickCash with an unapplied amount even if any of the receipt's matching numbers are invalid. Receivables stores the invalid matching numbers in the Application Notes field.

This field, which you can update, holds a maximum of 2,000 characters.

You can display the Application Notes field in the Receipts Summary or QuickCash windows by choosing Show Field from the Folder menu.

Applied Count/Amount: The total number and amount of applied receipts in this batch. Receivables updates these fields when you apply cash receipts that are part of this batch.

Batch: The batch name associated with the lockbox transmission that created this batch. If the receipt status is Remitted, this is the name of the remittance batch. If the receipt status is Cleared, this is the name of the clearing batch. If the receipt status is Reversed, this field is null.

Cash Claims: The amount of non-invoice related claim investigation applications on the receipt.

Cash Claims Count/Amount: The total number and amount of non-invoice related claim investigation applications in this batch. Receivables updates these values when the claims that are part of this batch are settled.

Deposit Date: The deposit date for the receipt or receipt batch. This date defaults from the receipt or batch date. If you later change the receipt or batch date, then Receivables updates the deposit date accordingly, unless the deposit date has already been manually updated.

Difference Count/Amount: The difference between the Control and Actual receipt counts and amount for this batch. When you add cash receipts to this batch, Receivables updates the Actual, Difference, and Unapplied Count and Amount totals for this batch.

Discounts Unearned: The total discount that your customer did not earn, but you accepted. You decide whether your customers can take unearned discounts by setting the system option Allow Unearned Discounts to either Yes or No.

Instrument Number: This field is display only. Receivables defaults this value based on the receipt method. Your customers use payment instruments to pay you. For example, a payment instrument can be a credit card or a bank account. You can change the payment instrument by choosing Select Instrument, which opens the Payment Instrument window. From this window, choose Create/Update Instrument to update or create a payment instrument on the Payment Details page.

Line Number: (Receipt History window) Receivables enters a value for this field when you match receipts with bank statements in Oracle Cash Management.

Lockbox: The number of the Lockbox that created this batch.

Maturity Date: When you remit a receipt, Receivables uses the maturity date to determine when to transfer funds from your customer's bank to one of your remittance bank accounts.

Miscellaneous Count/Amount: Receivables updates these fields when you add miscellaneous receipts to this batch.

Name: The name of the Lockbox that created this batch.

On-Account Count/Amount: The total number and amount of on-account receipts in this batch. Receivables updates these values when you apply these receipts.

Partially Purged: This check box indicates whether some of the transactions in this batch have been deleted by the Archive Purge program. When transactions are partially purged, the Control Total section appears out of balance because the Actual Count and Amount fields no longer include the purged transactions.

Payment Method: This field is display only. Receivables defaults this value based on the receipt method.

Posted Date: The date this receipt posted to your general ledger. A receipt can be posted to your GL both when it is Remitted and when it is Cleared.

Postmark Date: The postmark date for the receipt.

Prepayments Count/Amount: The total number and amount of prepayment receipts in this batch. A prepayment receipt is not included in the Applied Count/Amount totals until the Automatic Receipts program applies the prepayment receipt to a prepaid invoice.

Prepayments: The total amount of prepayment receipts.

Receipt Class: You can assign a receipt class to a receipt source. Receivables derives the default receipt class from the Receipt Source for this batch. When you define a receipt class in the Receipt Classes window, you specify whether to create remittances for receipts with this class and whether you want to track when they clear after running the Automatic Clearing program.

Remittance Method: (Receipt Batches Summary window) A read-only field that indicates the remittance method of the batch in which this receipt is included. If the receipt is not included in a remittance batch, this field is null.

Returned Count/Amount: The total number and amount of receipts in this batch that you reversed using a Reversal Category of either 'NSF' or 'Stop'.

Reversed Count/Amount: The total number and amount of receipts in this batch that you reversed using a Reversal Category of 'Reverse'.

State: (Receipts Summary window) Possible receipt states are Applied, Unapplied, Unidentified, Non-Sufficient Funds, Stopped Payment, and Reversal-User Error. You cannot apply receipts with a state of Non-Sufficient Funds, Stopped Payment, or Reversal-User Error.

Statement Date: (Receipt History window) Receivables enters a value for this field when you match receipts with bank statements in Oracle Cash Management.

Statement Number: (Receipt History window) Receivables enters a value for this field when you match receipts with bank statements in Oracle Cash Management.

Tax Code: This field is used to report VAT in Germany. For more information, see "German VAT for On-Account Receipts Report" in the Oracle Financials for Europe User Guide.

(Identify By) Trans Number: The transaction number that identifies this receipt.

Unapplied: The amount of this receipt in your functional currency that has not been applied to a transaction.

Unapplied Count/Amount: The total number and amount of unapplied and partially applied receipts in this batch. Receivables updates these fields when you apply cash receipts that are part of this batch.

Unidentified Count/Amount: The total number and amount of unidentified receipts in this batch. Unidentified receipts are those for which you have not entered a customer.

Related Topics

Applying Receipts

Batching Receipts for Easy Entry and Retrieval

Applying Receipts

Use the Applications window to apply your receipts or on-account credits. You can apply receipts to any type of transaction except guarantees and standard credit memos. You can apply all or part of a receipt or on-account credit to a single debit item or to several debit items. For example, your customer may send a single check to pay all of one invoice and part of another invoice. Or, a customer may have an on-account credit he will expect you to use with his receipt to close an open debit item.

You can apply receipts to an entire transaction and prorate the receipt amount across all transaction lines. Or, you can apply receipts to specific transaction lines. See: Applying Receipts in Detail.

You can apply a receipt to an unrelated customer's debit items if the system option Allow Payment of Unrelated Invoices is set to Yes. You can apply a receipt to a related customer's debit items if the Related Customers check box is checked. You cannot apply an unidentified receipt; you must specify the customer who remitted the receipt before you can apply it to a transaction.

You can also combine on-account credits with a customer's receipts to increase the amount you can apply to debit items, leave partial receipt amounts unapplied, or place an amount on-account.

Note: On-account credits (credit memos) are different from on-account cash on a receipt. See: Creating On-Account Credit Memos.

If you leave partial receipt amounts unapplied or if a receipt underpays an invoice, then you can write off the receipt. See: Writing Off Receipts.

You can even apply receipts against other open receipts. See: Receipt-to-Receipt Applications.

You can apply receipts in the same foreign currency as your transactions. Enter foreign currency exchange rate information using predefined exchange rates, or enter your own rate. When you post a foreign currency receipt application to the general ledger, Receivables records a realized gain or loss amount. See: Foreign Currency Transactions.

If you have set up Receivables to use cross currency receipts, you can apply a receipt in one currency to one or more transactions in different currencies. See: Applying Cross Currency Receipts.

To validate the application amount, Receivables uses the transaction type of the debit item to which you are applying the receipt. See: Transaction Types, Oracle Receivables Implementation Guide.

Receivables uses the Application Rule Set assigned to this debit item's transaction type to determine how to reduce the open line, tax, freight, and late charge amounts. If there is no application rule set assigned to this item's transaction type, Receivables uses the application rule set in the System Options window. See: Receivables Application Rule Sets.

Using Oracle Trade Management to Track Claims

If you are using Trade Management, then you can create a claim for invoice-related short payments in the Applications window. When you create a claim for an invoice, Receivables places the invoice in dispute until the claim is resolved.

For individual receipt over payments or short payments that are not related to any invoice, you can create a claim using the Claim Investigation application type. You can create multiple claim investigation applications per receipt.

Claims that you create in the Applications window are then automatically passed to Trade Management for tracking and further research. See: Working with Claims.

Receipt-to-Receipt Applications

You can net receipts in Receivables. To net receipts, you apply a receipt against another open receipt, and then apply the resulting unapplied receipt balance to a transaction.

Open receipts include receipts that have:

You can also apply one receipt against another receipt that has an open claim investigation application. A claim investigation application results from either a noninvoice-related deduction or an overpayment. See: Working with Claims.

Note: Receivables automatically updates Trade Management when you make a receipt application against a second receipt that has an open claim investigation.

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

You can also net a QuickCash receipt against multiple open receipts. See: QuickCash.

Prerequisites

Applying a Receipt

To apply a receipt to several transactions:

  1. Navigate to the Receipts window.

  2. Query or enter the receipt to apply. See: Entering Receipts.

  3. If the receipt is unidentified, enter the name or number of the customer who remitted this receipt.

  4. Choose Search and Apply.

  5. Specify the transactions to which you want to apply this receipt by entering transaction selection criteria. For example, enter a range of transaction types, transaction numbers, due dates, transaction dates, balances, or PO numbers. Leave a field blank if you do not want to limit the search to transactions matching that criteria.

    Note: If the Show Billing Number system option check box is selected, then Receivables displays two transaction Numbers fields. You can enter a balance forward bill number in the first field, or use the second field to enter a transaction number.

    Note: If you want to include closed invoices in your query, then you must check the Show Closed Invoices check box from the Tools menu.

  6. Specify how to order selected transactions by entering Sort Criteria (optional). You can mark transactions by Balance Due, Due Date, Invoice Date, or Invoice Number and in Ascending or Descending order. For example, to order items with the largest balances first, choose Balance Due, Descending.

    Tip: Use sort criteria to ensure that the transactions you want to pay first are listed first in the Applications window.

  7. Specify which types of transactions to include in your query by checking or unchecking the appropriate check boxes.

    Note: If a customer location is specified in the Location field, then Receivables ignores this check box and selects only the specified customer's transactions for receipt application.

    Note: If you check the Disputed Transactions box, then you must also indicate the classes of disputed transactions that you want to include in this query.

    Use the AR: Default Open Receipts for Application profile option, Oracle Receivables Implementation Guide to always include open receipts.

  8. Enter an Apply Date (optional). If the receipt date is later than the current date, the default is the receipt date; otherwise the default is the current date. Receivables uses this date as the application date for all transactions included in this application.

  9. To view the transactions matching your selection criteria without marking them for application, choose Preview. This lets you choose to which transactions you want to apply this receipt (see next step).

    To automatically mark the transactions matching your selection criteria for application, choose Apply. Receivables selects each item for application in the order queried until the full amount of the receipt is applied. Marked transactions will be paid in full with any discounts automatically taken.

  10. If you chose Preview, select transactions for application by checking the Apply check box. Receivables enters the Amount Applied and updates the Unapplied Amount of the receipt and the Balance Due for each transaction.

    Note: If applying this receipt against an open receipt, then skip to the next step.

    The default amount applied can be either the open amount of the transaction or the unapplied amount of the receipt, but you can change it (for example, if you want to apply this receipt to more than one transaction). Use the AR: Always Default Transaction Balance for Applications profile option, Oracle Receivables Implementation Guide to control how Receivables defaults the applied amount.

    If you chose Apply, you can either accept how Receivables has marked each transaction for application, or modify this information. Unchecking the Apply check box resets the balance due for that transaction and increases the unapplied amount of the receipt. You can update the Amount Applied, select a different transaction, or leave the receipt partially unapplied.

    Note: The default Discount Taken is the amount of earned discounts available for this application, but you can change it. If the system option Allow Unearned Discounts is set to Yes, you can apply these discounts here. Receivables skips this field if this transaction is a credit memo. See: Discounts.

  11. If applying this receipt against an open receipt, then the amount applied defaults to the greater of either:

  12. To place any remaining amount on account, use the down arrow to insert a new record, then enter 'On Account' in the Apply To field. The default amount is the unapplied amount of the receipt, but you can change it.

  13. If you are using Trade Management, then you can create an invoice-related claim for any short payment, or a noninvoice-related claim for any overpayment.

    See: Manually Applying Receipts.

  14. When you are satisfied with this receipt application, save your work. Receivables updates your customer's account balances.

Manually Applying Receipts

To manually apply a receipt to one or more transactions:

  1. Navigate to the Receipts window.

  2. Enter or query the receipt to apply. See: Entering Receipts.

  3. If the receipt is unidentified, enter the name or number of the customer who remitted this receipt.

  4. Choose Apply.

  5. In the Apply To field, from the list of values, select the transaction to which you want to apply this receipt.

    Note: If you want to include closed invoices in the list of values, then you must first check the Show Closed Invoices check box from the Tools menu.

    Receivables enters the Amount Applied for this receipt and updates the Unapplied Amount of the receipt and the Balance Due for this transaction. If the system option Allow Payment of Unrelated Invoices is set to Yes, you can apply this receipt to an unrelated customer's transactions.

    The default amount applied can be either the open amount of the transaction or the unapplied amount of the receipt, but you can change it (for example, if you want to apply this receipt to more than one transaction). Use the AR: Always Default Transaction Balance for Applications profile option, Oracle Receivables Implementation Guide to control how Receivables defaults the applied amount.

    Note: The default Discount is the amount of earned discounts available for this application, but you can change it. If the system option Allow Unearned Discounts is Yes, you can apply these discounts here. Receivables skips this field if this transaction is a credit memo. See: Discounts.

  6. To apply this receipt against specific transaction lines, choose Apply in Detail.

    See: Applying Receipts in Detail.

  7. You can apply this receipt against open receipts, as well. See: Receipt-to-Receipt Applications.

    Note: To include open receipts in the list of values:

    If applying this receipt against an open receipt, then the amount applied defaults to the greater of either:

  8. To apply this receipt to another transaction or open receipt, repeat steps 5 and 6.

  9. To place an amount on account, enter 'On Account' in the Apply To field. The default amount is the unapplied amount of the receipt, but you can change it.

    Receivables marks any portion of this receipt that you do not apply or place on-account as 'Unapplied'.

  10. If you are using Trade Management, then complete this step. If not, then skip to the next step.

    Receivables integrates with Trade Management to let you record, research, and resolve your customers' short payments and over payments on their receipts. These payment discrepancies are called claims.

    You can place any short payment or over payment into claim investigation when entering a receipt in the Applications window. When you save the application, the claim is automatically sent to Trade Management, which then populates the Application Reference field with the claim number.

    Use the down arrow to insert a new record, then enter either an invoice related or non-invoice related claim:

  11. When you are satisfied with this receipt application, save your work. Receivables updates your customer's account balances.

Related Topics

Applying Receipts in Detail

Applications Field Reference

Chargebacks and Adjustments

Reapplying Receipts

Reviewing Receipts and Applications

Applying On-Account Credit Memos

Unapplying Cash when Crediting a Transaction

Applied Receipts Register

Unapplied and Unresolved Receipts Register

Deposited Cash Report - Applied Detail/Open Detail Reports

Applying Receipts in Detail

During receipt application, you can allocate cash against an entire transaction. Or, use Oracle Receivables' line-level cash application functionality to apply cash against specific transaction lines, according to your customer's remittance advice. For example, if your customer received only Item A, but not Item B, then you can apply your customer's payment to Item A. Later, after your customer receives Item B and remits payment, you can apply the payment to Item B.

Receivables lets you apply receipts in these ways:

Note: Line-level cash application functionality is available only for invoices, debit memos, and chargebacks with line details. You cannot apply receipts in detail to all other transactions, including invoices with installments.

The line-level cash application functionality does not use application rule sets, because you make application decisions according to your customer's remittance advice.

You can update existing line-level cash applications. For example, after applying a receipt against an entire transaction, you later learn that the customer only wanted to partially pay the transaction. In this case, you can unapply the original receipt application and reapply the receipt to specific transaction lines. See: Reapplying Receipts.

You can also unapply line-level cash applications and reapply a receipt against an entire transaction. In this case, Receivables automatically removes all existing line-level cash applications, before applying cash at the transaction level.

After applying a partial payment against a specific transaction line, you can later apply a second payment against the remaining balance of the transaction. Receivables prorates the second receipt amount across all remaining transaction lines.

Applying Receipts in Detail

Prerequisites:

  1. If necessary, modify the AR: Always Default Transaction Balance for Applications profile option.

    See: Overview of Receivables User Profile Options, Oracle Receivables Implementation Guide.

  2. Optionally modify the various system options that control discounts. For example, set the Allow Unearned Discounts or Discount on Partial Payment system options.

    See: Miscellaneous System Options, Oracle Receivables Implementation Guide.

  3. Optionally modify the discount options for your customer profile classes. For example, enable discounts for a customer profile class, and set the number of discount grace days.

    See: Customer Profile Class and Customer Account Profiles Field Reference, Oracle Receivables Implementation Guide.

To apply receipts in detail:

  1. Navigate to the Receipts window.

  2. Enter or query the receipt to apply. See: Entering Receipts.

  3. Choose Apply.

  4. In the Apply To field, from the list of values, select the transaction to which you want to apply this receipt.

  5. Choose Apply in Detail to navigate to the Detailed Applications window.

    Important: You cannot apply receipts in detail to invoices from Release 11i, if activity already exists on those invoices. Examples of invoice activity include credit memos, deposits, guarantees, or adjustments.

    The Detailed Applications window includes four regions:

  6. In the Application Tree region, select the application level for this receipt. Your selection controls which transaction details are made available for application in the Detailed Applications region.

    Receivables automatically calculates earned discounts. You must manually enter unearned discounts.

  7. When you are satisfied with all applications, save your work. Receivables updates your customer's account balances.

Related Topics

Applying Receipts

Reapplying Receipts

Reviewing Receipts and Applications

Applications Field Reference

This section provides a brief description of some of the fields in the Applications window.

Activity: The receivable activity for this application. Receivables uses the receivable activity to derive the accounting for this application. You cannot enter an activity when applying receipts to transaction numbers.

Allocated Receipt Amount: The amount of the receipt to apply in the receipt currency. This field is used for cross currency receipt applications.

Amount Applied: The amount of the receipt to apply in the transaction currency. This field is used for cross currency receipt applications.

Application Reference Number: If you are using Oracle Trade Management, then the Reference Number is the claim number.

If this application line was made to a refund activity, such as Credit Card Refund, then this column holds the miscellaneous receipt number that was created to generate the customer refund. See: Credit Card Refunds.

If this application line was made to the Prepayment application type, then this column indicates the number of the transaction, such as the order number, that generated this prepayment.

Application Reference Reason: Select a reason for this claim (both short payments and overpayments) from the list of values in this field. This field is used for integration with Trade Management only.

You can also use this field to indicate why you are performing any manual receipt activities.

Application Reference Type: To create a claim, select Trade Management Claim from the list of values in this field.

If this application line was made to a refund activity, such as Credit Card Refund, then Receivables populates this field with Miscellaneous Receipt.

If this application line was made to the Prepayment application type, then this column indicates where the prepayment originated, such as from Order Management.

Apply Date: The apply date to assign to this receipt application. If the receipt date is later than the current date, the default is the receipt date; otherwise the default is the current date. You cannot change this date after you save this application.

Apply To: The identification number of the transaction to which you want to apply this receipt. You can enter receipt applications against items that have GL dates in future accounting periods. When you use the list of values to select the transaction to which to apply this receipt, Receivables displays one choice for each installment of an invoice.

You can enter a balance forward bill number and Receivables will find all the transactions that are associated with this balance forward bill. You can then apply payment to the individual invoices within the balance forward bill. The total balance of the balance forward bill is thus reduced by the amount of the payment. See: Balance Forward Billing.

You can also apply receipts against other open receipts. See: Receipt-to-Receipt Applications.

The Apply To list of values also displays other types of applications that you can make in this window:

Cash Claims: The amount of the receipt that you have placed in claim investigation.

This total represents only noninvoice-related claims, which Receivables views as open cash. Noninvoice-related claims are similar to unapplied or on-account cash; further action is required on the receipt before this receipt is fully applied. These action points are thus represented in the same area of the Applications window.

For invoice-related claims, however, further action is required on the transaction. The Cash Claims total, therefore, does not include open invoice-related claims.

This field is for users of Trade Management only.

See: Working with Claims.

Customer Reason: The customer's reason for a payment disrepancy.

This column is a hidden folder field, and is used by Trade Management.

Customer Reference: Customer-supplied information, if AutoLockbox determines that the transaction number is invalid.

This column is a hidden folder field, and is used by Trade Management.

GL Date: The date on which to post this application to your general ledger. The default is the current date, the receipt GL date, or the invoice GL date, whichever is latest. If the default GL date is in a closed or future period, Receivables uses the first date of the most recent open period. Receivables lets you enter multiple applications for a single receipt that have different GL dates. The GL date of this application cannot be earlier than the GL date of the receipt or the GL date of the invoice.

Installment: The installment number of this transaction.

Line: The line that you enter is for reference only. Receivables does not update the remaining amount due for a line when you apply a receipt against it.

When you apply a receipt against an invoice and specify one of its lines for the application, Receivables updates the balance due for the entire invoice by the amount of the receipt application.

Or, apply receipts to specific transaction lines by choosing Apply in Detail. See: Applying Receipts in Detail.

On Account: The amount of the receipt that you have placed On Account. When you place an amount On Account, Receivables automatically updates the Unapplied and On Account fields.

Original Transaction Reference: The number of the document that this receipt amount was originally applied to.

For example, if this application line was applied to a transaction, but was later unapplied and reapplied to a special refund activity, then this column holds the original transaction number. See: Credit Card Refunds.

Receivables automatically populates this column with a nonupdatable value.

Original Transaction Reference Type: The type of the document that this receipt amount was originally applied to.

Prepayments: The amount of the prepayment application.

Reference Reason: The claim reason, translated from the customer's original reason into the deploying company's reason code (used by Trade Management).

Transaction Code: Transaction codes are typically used by U.S. federal government customers to produce both proprietary and budgetary accounting entries for a given transaction. This feature is available only in public sector installations.

Managing Prepayment Receipts

Oracle Receivables integrates with any feeder system, such as Oracle Order Management, to let you record prepayments from customers before the delivery of goods or services.

This section describes how the process works.

What is a prepayment?

A prepayment is payment in advance of the delivery of goods or services.

Receivables creates prepayments as receipts before the related invoices are created. Later, a business event from your feeder system triggers the invoicing process in Receivables, and an AutoInvoice postprocess matches the prepaid receipts to their related invoices.

See: Prepayments Process Flow.

The creation of prepayment receipts and the subsequent application to matching prepaid invoices is a process that occurs without user intervention.

Note: You cannot manually create prepayments in Receivables. Instead, your feeder system initiates the creation of prepayments in Receivables.

Your customers can use any of these Oracle Payments payment methods to make a prepayment:

Your customers can use more than one of the above payment methods for a single prepayment. Receivables creates one prepayment receipt for each payment method.

When are prepayments required?

You can create and track prepayments in Receivables. However, your unique business requirements dictate whether or not you require a prepayment. Your enterprise must implement specific business practices to determine which orders require prepayments.

For example, you might require customers to prepay all orders for consulting services. Or, you might require a down payment for any order over $1,000.

Prepayments Process Flow

  1. When you determine that a prepayment is required, you record the payment information in your feeder system, and the information is passed to Oracle Receivables.

  2. A public API creates a prepayment receipt in Receivables, and processes the receipt using the payment information provided.

    Receivables immediately applies all prepayment receipts against the Prepayment application type, and records accounting according to a special prepayment receivables activity.

    Receivables reserves these receipts for subsequent reapplication to the invoice or invoices that are eventually generated for the order.

  3. When the order is later sent to Receivables for invoicing, AutoInvoice creates an invoice that is marked as prepaid.

    Additionally, AutoInvoice initiates a postprocess matching program to identify any open prepaid invoices and search for matching prepayment receipts. When a match is found, the program unapplies the receipt from the Prepayment application type and reapplies the receipt to the corresponding invoice.

    Reapplication of the receipt against the appropriate invoice occurs without any user intervention.

  4. You can review your prepayment receipts history:

Related Topics

Managing Prepayment Receipts

Managing Your Customers' Prepayments

Reapplying Receipts

Setting Up Prepayments

Prerequisites

To set up prepayments:

  1. Define a prepayment receivables activity. See: Receivables Activities, Oracle Receivables Implementation Guide.

  2. Define receipt methods. See: Receipt Methods, Oracle Receivables Implementation Guide.

  3. Set the Sequential Numbering profile option to Always Used or Partially Used. Next, define an automatic document sequence, or use an existing sequence, and assign it to the document category that Receivables automatically created for the receipt methods you defined in the previous step. See: Setting Up Document Sequences, Oracle Receivables Implementation Guide.

  4. (Optional) Define a prepayment payment term. See: Payment Terms, Oracle Receivables Implementation Guide.

    Tip: Optionally set the number of days to zero if you are defining a prepayment payment term.

    Note: The prepayment payment term does not require the capture of funds in advance of invoicing or the delivery of prepaid goods or services. Establish specific business practices at your enterprise if you want to capture these funds in advance.

Related Topics

Prepayments Process Flow

Managing Your Customers' Prepayments

Managing Your Customers' Prepayments

You can easily modify or cancel prepayments while maintaining a strict accounting and audit trail for orders that you process. You can:

Related Topics

Managing Prepayment Receipts

Prepayments Process Flow

Cross Currency Receipts

When your customer remits payment for an invoice, debit memo, or chargeback, the receipt is usually in the same currency as the transaction. However, there may be times when your customer remits payment in a currency that is different than the currency of the open debit item. For these occasions, Receivables lets you create cross currency receipt applications to let you fully or partially process the payment.

For example, you create Invoice 101 in Canadian dollars (CAD) but your customer sends a receipt in euro (EUR) as payment. Using the remittance information provided by your customer, you can either fully or partially apply this receipt to Invoice 101. Receivables automatically calculates the open balance on the invoice (if any) and the foreign exchange gain or loss (FXGL) for this application.

You can apply receipts to transactions using any currency defined in Oracle General Ledger.

Note: You can also apply a receipt with an on-account credit to open debit items in different currencies. See: Applying a receipt with an on-account credit memo.

Calculating the Foreign Currency Exchange Gain or Loss

Because of fluctuating exchange rates between currencies, cross currency applications must be evaluated to determine their effect within Receivables and the corresponding accounting entries created in your general ledger. With each cross currency application, you can incur either a foreign exchange gain or loss (FXGL).

When you apply a receipt to a transaction that is in a different currency, Receivables first determines the transaction and the receipt amounts in your functional currency. Receivables then compares these amounts to determine the foreign exchange gain or loss for this application. If the result is positive, you will incur a foreign currency exchange gain for this application; if the result is negative, you will incur a foreign exchange loss.

Note: As with same currency receipt applications, Receivables accounts for your FXGL using the Realized Gains and Realized Losses accounts that you defined in the System Options window.

Receivables calculates the FXGL using the following formula:

Receipt Amount (as of the receipt date) - Invoice Amount (as of the invoice date) = Foreign Exchange Gain or <Loss> *

* Receivables calculates each amount in your functional currency.

Using the fields in the Applications window, this formula can be also represented as shown below:

Allocated Receipt Amount Base - Amount Applied Base = FXGL

See: Applying Cross Currency Receipts - Examples.

Euro Validation

In accordance with the laws of the European Monetary Union, from January 1, 1999 to December 31, 2001, certain former European currencies were considered National Currency Units of the euro currency, and had a fixed-rate relationship with the euro. Receivables supports currencies that are fixed-rate denominations of the euro.

Because the National Currency Units of the euro had fixed, predefined exchange rates, the Applications window can enter some default values when you create applications for NCU transactions.

For example, currencies within Country A and Country B are euro-denominated and are defined as such in the general ledger. You issue an invoice in NCU A, then later apply a receipt to that invoice in NCU B. Because the rate for these NCUs is fixed, you only need to enter either the amount applied or the allocated receipt amount in the Applications window. When you do this, Receivables automatically calculates and displays a default value for the other amount.

This example supports the following situations in which your customer provides either:

or

Viewing Discounts on a Cross Currency Receipt Application

When you apply a receipt to multiple transactions that are in different currencies, Receivables does not display the total discount amount in the Receipts window. This is because Receivables always calculates discounts in the currency of the transaction.

Since there are multiple transactions with multiple currencies involved in this type of application, the total discount cannot be expressed in a single currency. Therefore, you can only view the discount for each application separately in the Applications window.

To do this, perform the following:

Accounting Entries in Multiple Currencies

When you enter a receipt or a transaction that is not in your functional currency, Receivables requires that you enter the applicable exchange rate in the Exchange Rates pop up window. This lets Receivables account for amounts in both your functional currency and the currency of the transaction.

For more information, see: Foreign Currency Transactions.

Customer Remittance Information

When applying cross currency receipts, your customer needs to provide you with the following remittance information:

Note: Alternatively, your customer can provide the exchange rate used to convert the transaction currency to the receipt currency (this could be a previously agreed upon rate). If your customer provides this exchange rate, Receivables automatically calculates the Allocated Receipt Amount. For information on how the cross currency rate field and the Allocated Receipt Amount are mutually exclusive, see: Applying Cross Currency Receipts - Examples.

Related Topics

Setting Up Cross Currency Receipts

Applying Cross Currency Receipts - Examples

Applying Cross Currency Receipts

Setting Up Cross Currency Receipts

To set up Receivables to use cross currency receipts, perform the following steps.

Step 1 Define Cross Currency Rounding Account

Define a Cross Currency Rounding Account in the System Options window. Receivables uses this account to record any rounding error amounts created during a cross currency receipt application for currencies that have a fixed rate relationship.

Step 2 Define a Suspense Account in Oracle General Ledger

When you create a cross currency receipt application, the resulting accounting entry includes several currencies: the receipt currency, the functional currency, and the accounting or functional currency. Receivables ensures that the proper FXGL is calculated so that the entry balances in your functional currency. The entry, however, does not balance in the entered currency (see the entry created in Example 1 in which a EUR receipt is applied to a CAD invoice). See: Applying Cross Currency Receipts - Examples.

When Receivables posts these multi-currency journal entries, Oracle General Ledger separates the entries by currency before balancing them. Next, General Ledger creates one entry to a clearing account so that each journal entry will balance in the entered currency. A clearing account is called a 'Suspense Account' in Oracle General Ledger.

Note: The entry to the clearing account will always be zero in your functional currency as the journal already balances in functional currency.

Important: You do not need to enable suspense accounting for your ledger to apply cross currency receipts in Receivables. You only need to define a suspense account for journal entries created by your cross currency receipt applications.

The Oracle General Ledger Journal Import Program identifies all journals with a category of 'Cross Currency' that are imported from the source 'Receivables'. Receivables creates multi-currency entries each time you apply a receipt in one currency to a transaction in a different currency.

For each of these entries, Oracle General Ledger does the following:

When defining a Suspense Account for your ledger, enter a Source of 'Receivables' and a Category of 'Cross Currency.' See: Defining Suspense Accounts, Oracle General Ledger Implementation Guide.

Step 3 Define Journals: Display Inverse Rate Profile Option

The profile option Journals: Display Inverse Rate lets you determine how you enter and display conversion rates in the Exchange Rate window. When you create a cross currency application, the field 'Cross Currency Rate' in the Applications window displays a value independent of this setting. This field will always display a value in accordance with the following:

Transaction Amount * Cross Currency Rate = Receipt Amount

Receivables will always use multiplication as the operation to convert the transaction currency to the receipt currency. In Example 1 Receivables multiplies the Amount Applied (90 CAD) by the cross currency rate (0.7111111) to calculate the Allocated Receipt Amount (64 EUR). See: Profile Options in Oracle General Ledger., Oracle Receivables Implementation Guide

Related Topics

Applying Cross Currency Receipts - Examples

Applying Cross Currency Receipts

Applying Cross Currency Receipts - Examples

This section provides two examples of cross currency receipt applications. The first example shows how you can apply a receipt in one currency to an invoice in a different currency and the calculations Receivables performs during each step. In this example, both the invoice and receipt currencies are different from your functional currency.

The second example shows how you can apply a receipt to several invoices, each in a different currency.

Note: The Applications window is a folder form, which means you can choose the fields you want to see and the order in which they appear. The examples below show one possible way to set up the Applications window to help you create cross currency receipt applications; your implementation may be different. For more information about folders, see: Customizing the Layout of a Folder, Oracle Applications User's Guide.

Example 1

This example shows how you can apply a receipt in euro (EUR) to an invoice in Canadian dollars (CAD). For this example, assume that your functional currency is US dollars (USD), and that there is no tax, freight, or applicable discount.

Step 1: Create a Transaction

On JAN-01 you create Invoice 101 for 100 Canadian dollars (CAD). The corporate exchange rate on JAN-01 is 1 USD = 1.5 CAD. Receivables uses this rate to calculate the amount of the invoice in your functional currency to be 66.67 USD (100 / 1.5 = 66.67).

Receivables creates corresponding journal entries for this amount in both the invoice and your functional currency, as illustrated in this table:

Account Debit Credit
Accounts Receivable 100 CAD [66.67 USD]  
Sales   100 CAD [66.67 USD]

Step 2: Enter and Apply Receipt

On JAN-31, you receive payment of 64 EUR for Invoice 101. Your customer informs you that the entire amount (64 EUR) is a partial payment of 90 CAD for Invoice 101. The corporate exchange rate on JAN-31 is 1 USD = 1.13 EUR. When you enter the receipt information, Receivables uses this rate to calculate a receipt amount in your functional currency of 56.64 USD (64 / 1.13 = 56.64).

You choose Apply, then enter '101' in the Apply To field. Receivables enters the balance due in your functional currency (Balance Due Base) and the invoice currency (Balance Due).

The Applications window now appears as shown in the table below (see Note above):

Apply To Balance Due Base Balance Due Amount Applied Amount Applied Base Cross Currency Rate Allocated Receipt Amount Allocated Receipt Amount Base Exchange Gain/Loss
101 66.67 100.00            

Following your customer's remittance information, you enter a new value of 90 in the Amount Applied field. Receivables automatically calculates the amount applied in your functional currency (Amount Applied Base) and updates the balance due in your functional currency (Balance Due Base) and the invoice currency (Balance Due).

The Applications window now appears as shown in the table below:

Apply To Balance Due Base Balance Due Amount Applied Amount Applied Base Cross Currency Rate Allocated Receipt Amount Allocated Receipt Amount Base Exchange Gain/Loss
101 6.67 10.00 90.00 60.00        

Calculations

Next, you enter the amount of the receipt to apply to this invoice (64 EUR) in the Allocated Receipt Amount field. Receivables uses this amount to determine the Cross Currency Rate of 0.7111111 (64/90). Receivables then determines the Allocated Receipt Amount Base (in your functional currency) of 56.64 USD, using the exchange rate as of the receipt date (see Example Summary below). Finally, Receivables calculates an Exchange Loss of 3.36 USD.

The Applications window now appears as shown in the table below:

Apply To Balance Due Base Balance Due Amount Applied Amount Applied Base Cross Currency Rate Allocated Receipt Amount Allocated Receipt Amount Base Exchange Gain/Loss
101 6.67 10.00 90.00 60.00 0.7111111 64.00 56.64 <3.36>

Calculations

When you save this application, Receivables creates the accounting entries as illustrated in this table:

Account Debit Credit
Cash 64 EUR [56.64 USD]  
Foreign Exchange Loss 3.36 USD  
Accounts Receivable   90 CAD 60 USD]

Example Summary

The table below summarizes each step in this example and the corresponding calculations that Receivables performs.

Action Exchange Rate Calculation
You create Invoice 101 for 100 CAD. 1 USD = 1.5 CAD
(exchange rate on invoice date)
100 CAD / 1.5 = 66.67 USD
You enter receipt for 64 EUR. Receivables calculates amount in functional currency. 1 USD = 1.13317 EUR
(exchange rate on receipt date)
64 EUR / 1.13 = 56.64 USD
You enter 90 CAD in Amount Applied field. Receivables calculates Amount Applied in your functional currency. 1 USD = 1.5 CAD 90 CAD / 1.5 = 60 USD
You choose to apply the entire 64 EUR receipt to Invoice 101. Receivables calculates the cross currency exchange rate from this value. 0.7111111
(cross currency rate derived by Receivables)
64 EUR / 90 CAD = 0.7111111
Receivables calculates Allocated Receipt Amount in your functional currency. 1 USD = 1.13 EUR
(as of JAN-31, receipt date)
64.00 / 1.13 = 56.64
Receivables calculates Foreign Exchange Gain or Loss. (NA) 57.48 USD - 60 USD = <3.36> USD

Example 2: Applying a Receipt to Several Invoices in Different Currencies

Using the same procedure described in the previous example, you can apply a receipt in one currency to several transactions, each in a different currency.

Applying a Cross Currency Receipt

the picture is described in the document text

As in Example 1, to apply a receipt to several transactions in different currencies, your customer must provide detailed remittance information.

For example, your customer remits a Receipt 1234 for 300 EUR and includes the information as described in this table:

Invoice Num Date Invoice Balance Paid Amount Rate to EUR EUR Remitted
101 1-JAN 100 CAD 90 CAD .725298 65.28
102 2-JAN 100 USD 100 USD 1.15989 115.99
103 4-JAN 8000 JPY 8000 JPY .0086927 69.54

Note: In this example, your customer's remittance advice included rate information for each invoice. This is an alternative to requiring that your customer provide the Allocated Receipt Amount for each invoice. Receivables automatically calculates the Allocated Receipt Amount for each application when you enter the Cross Currency Rate.

After you enter and apply the receipt according to your customer's remittance information, the Applications window appears as shown in the table below:

Apply To Balance Due Base Balance Due Amount Applied Amount Applied Base Cross Currency Rate Allocated Receipt Amount Allocated Receipt Amount Base Exchange Gain/Loss
101 6.67 10.00 90.00 60.00 .725298 65.28 57.14 (2.86)
102 0.00 0.00 100.00 100.00 1.15989 115.99 99.12 (0.88)
103 0.00 0.00 500.00 96.15 .0086927 69.54 94.61 1.54
On Account           49.22 6.27  

Tip: You can also use the Receivables Search and Apply feature to automatically select transactions for cross currency receipt application. For more information, see: Automatically Selecting Invoices for Cross Currency Receipt Application.

Using the Cross Currency Exchange Gain/Loss Report

Receivables lets you review detailed information about your cross currency settlements. The Cross Currency Exchange Gain/Loss report lets you analyze each cross currency receipt application for a customer, customer site, receipt date range and receipt currency. This report is useful when you need a record of the cross currency rates used in your cross currency receipt applications.

The Cross Currency Exchange Gain/Loss report provides much of the same information as the Applications window during cross currency receipt application. In addition, this report provides a 'Rate Reconciliation' section that shows what the foreign exchange gain/loss for an application would have been if you had used the cross currency rate maintained in Oracle General Ledger. This information lets you analyze any significant discrepancies in the FXGL that can result from cross currency receipt applications.

To illustrate the Rate Reconciliation section of the report, consider Example 1 in this section where the cross currency rate used (in accordance with the remittance information) in the application was 0.7111111. The Rate Reconciliation section of Cross Currency Exchange Gain/Loss report will default the system's Corporate rate, for example, between CAD and EUR on 31-Jan of 0.726556. Based on this rate, it would have taken 65.39 EUR to close 90 CAD (where 90 CAD x 0.726556 = 65.39 EUR) of the customer's balance. In this case, you would have experienced a loss of 0.61 USD instead of the realized loss of 2.86 USD (refer to Example 1).

The report shows that the variance between the foreign exchange loss you actually experienced and the loss you would have experienced is 2.25 (2.86 - 0.61). This detailed information may be necessary to determine whether the cross currency rate used by your customer was appropriate. See: Cross Currency Exchange Gain/Loss Report.

Related Topics

Creating On-Account Credit Memos

Entering Receipts

Foreign Currency Transactions

Applying Cross Currency Receipts

Applying Cross Currency Receipts

Use the Applications window to manually apply receipts that are in one currency to one or more transactions in different currencies. For example, you can apply a USD receipt to one invoice denominated in euros (EUR) and another in Canadian dollars (CAD). You can apply receipts to invoices, debit memos, and chargebacks.

You can apply a receipt to an unrelated customer's debit items if the system option Allow Payment of Unrelated Invoices is set to Yes.

To apply cross currency receipts, define a Suspense Account for your ledger. See: Setting Up Cross Currency Receipts.

Tip: To help you manage cross currency receipt applications, we recommend that you set up the Applications window to display the fields shown in the section Applying Cross Currency Receipts - Examples. Since the Applications window is a folder form, you can choose which fields to display and in what order they will appear. For example, to include the Balance Due field in the window, choose Show Field from the Folder pulldown menu, then choose Balance Due from the list of available fields. Receivables will insert the field at the cursor's current location. You can also reposition fields by choosing Move Left or Move Right from the Folder menu.

When you post a cross currency receipt application to the General Ledger, Receivables records a realized gain or loss amount. A realized gain or loss occurs when the exchange rate changes between the invoice date and the receipt date. See: Calculating the Foreign Currency Exchange Gain or Loss.

You can also use the Search and Apply window to automatically select a range of invoices for cross currency receipt application. See: Automatically Selecting Invoices for Cross Currency Receipt Application.

Use the Cross Currency Exchange Gain/Loss Report to review your cross currency receipt applications and the foreign exchange gain or loss for each. See: Cross Currency Exchange Gain/Loss Report.

Prerequisites

To manually apply a receipt to one or more transactions in a different currency:

  1. Navigate to the Receipts window.

  2. Enter or query the receipt to apply. See: Entering Receipts.

  3. If the receipt is unidentified, enter the Customer or Customer Number who remitted this receipt.

  4. Choose Apply.

  5. Select the transaction to which you want to apply this receipt from the list of values. Receivables displays the balance due in both the invoice currency (Balance Due) and your functional currency (Balance Due Base).

  6. Enter the amount to apply to this transaction (based on your customer's remittance information) in the Amount Applied field. Receivables performs the following:

  7. Enter either the Cross Currency Rate used to convert the transaction amount to the receipt amount or the Allocated Receipt Amount. If you enter the Cross Currency Rate, Receivables calculates the Allocated Receipt Amount, and vice versa.

    Receivables calculates the Exchange Gain/Loss for this application.

  8. To apply this receipt to another transaction, repeat steps 5-7.

    Note: The default Discount is the amount of earned discounts available for this application, but you can change it. If the system option Allow Unearned Discounts is set to Yes, you can apply these discounts here. Receivables skips this field if this transaction is a credit memo. See: Discounts.

  9. To place any remaining amount on account, create a separate application and enter 'On Account' in the Apply To field. The default amount is the unapplied amount of the receipt, but you can change it.

  10. When you are satisfied with this receipt application, save your work. Receivables updates your customer's account balances.

Automatically Selecting Invoices for Cross Currency Receipt Application

You can use the Search and Apply window to automatically select transactions for cross currency receipt application. Use this window to select transactions for application by entering selection criteria, such as a range of open balances, transaction types, or due dates.

If you have set up your system to use Cross Currency receipts, Receivables displays a Cross Currency check box in the Search and Apply window. Check this box to apply a receipt to transactions in different currencies.

If you set Cross Currency to Yes, then Receivables:

If you set Cross Currency to No, Receivables limits its search to transactions that are in the same currency as the receipt.

To automatically select transactions for cross currency receipt application:

  1. Navigate to the Receipts window.

  2. Query or enter the receipt to apply. See: Entering Receipts.

  3. If the receipt is unidentified, enter the name or number of the customer who remitted this receipt.

  4. Choose Search and Apply.

  5. Specify the invoices to which you want to apply this receipt by entering Transaction selection criteria. For example, enter a range of transaction Types, transaction Numbers, Due Dates, or Balances. Leave a field blank if you do not want to limit the search to transactions matching that criterion.

  6. Specify how to order selected transactions by entering Sort Criteria (optional). You can mark transactions by Balance Due, Due Date, Invoice Date, or Invoice Number and in Ascending or Descending order. For example, to order items with the largest balances first, choose Balance Due, Descending.

    Tip: Use sort criteria to ensure that the invoices you want to pay first are listed first in the Applications window.

  7. Specify the type of transactions to include for this receipt application. For example, check the Invoices, Debit Memos, and Disputed Transactions check boxes to include these transactions.

  8. Check the Cross Currency box. This lets you apply this receipt to transactions regardless of their currency.

  9. Enter an Apply Date. If the receipt date is later than the current date, the default is the receipt date; otherwise the default is the current date. Receivables uses this date as the application date for all invoices included in this application.

  10. Choose Preview.

  11. Select the invoices to which you want to apply this receipt. See: Applying Cross Currency Receipts.

    Note: The default Discount is the amount of earned discounts available for this application, but you can change it. If the system option Allow Unearned Discounts is set to Yes, you can apply these discounts here. Receivables skips this field if this transaction is a credit memo. See: Discounts.

  12. When you are satisfied with this receipt application, save your work. Receivables updates your customer's account balances.

Related Topics

Reviewing Receipts and Applications

Cross Currency Exchange Gain/Loss Report

Cross Currency Exchange Gain/Loss Report

Use this report to review detailed information about your cross currency settlements.

This information includes:

You can run this report from the Print Account Reports window.

Important: To run this report, you must set up Receivables to use cross currency settlements. See: Setting Up Cross Currency Receipts.

Report Parameters

Customer Name: To include only receipts for a specific customer in this report, enter a customer name. Leave this field blank to include receipts for all customers.

Location: If you entered a Customer, enter a customer site to include only receipts for that site (optional). Leave this field blank to include receipts for all of this customer's sites.

From Receipt Date: To include only specific receipts in this report, enter the receipt creation date from which you want to include receipts. Leave this field and the To Receipt Date field blank to include receipts in this report regardless of their creation date.

To Receipt Date: If you entered a From Receipt Date, enter the last date for which you want to include receipts in this report. Leave this field blank to include all receipts entered through today's date.

Receipt Currency: To include only receipts denominated in a specific currency in this report, enter a currency.

Exchange Rate Type: Enter the exchange rate type to use as the system cross currency rate in the Rate Reconciliation section of this report (optional). This parameter specifies the conversion rate used to convert the receipt currency to the transaction currency.

If you do note enter an Exchange Rate Type, the Rate Reconciliation section will not appear in this report. The Rate Reconciliation section lets you view the gain or loss that you would have incurred for this application if you had used the cross currency rate maintained in your general ledger instead of the rate used by your customer.

Report Headings

Customer: The name of the customer whose data this report includes. If you specified a customer in the report parameters, the report displays information for only this customer; otherwise, the report displays information for all customers.

Location: The customer site. If you specified a site in the report parameters, the report includes information for only this site; otherwise, the report displays information for all sites.

Receipt: The receipt number.

Date: The receipt creation date.

Amount: The amount of this receipt.

Receipt Currency: The currency of this receipt.

Rate Type: The rate type used to convert your receipt currency to the currency of the transaction. If you do not enter a Rate Type, the report does not include the Rate Reconciliation section.

Column Headings

Transaction Section

Transaction Number/Date/Currency: The number, creation date, and the entered currency for this transaction.

Amount Applied: The amount applied to this transaction in the transaction currency.

Amount Applied Base: The amount applied to this transaction converted to your functional currency on the date of the application.

Actual Application Section

Allocated Receipt Amount: The amount applied to this transaction in the receipt currency.

Allocated Receipt Amount - Base: The amount applied to this transaction converted to your functional currency on the date of the receipt.

Cross Currency Rate: The exchange rate used to apply the receipt to this transaction. This is the exchange rate as of the receipt date (for the selected rate type).

Exchange Gain/Loss: Measured in your functional currency, the exchange gain or loss incurred on this receipt application. These gains or losses arise from changes in the exchange rates between the receipt and the transaction currency. Receivables uses the following formula to calculate this amount:

Allocated Receipt Amount (Base) - Amount Applied (Base) = Exchange Gain or <Loss>

Rate Reconciliation Section

Important: If you did not enter a Rate Type in the report parameters, the report does not include this section.

Absolute Difference: The absolute difference between the exchange gain or loss in the Actual Application section and the Rate Reconciliation section. This is expressed as a positive number.

Allocated Receipt Amount: The portion of this receipt that was applied to the transaction in the receipt currency.

Allocated Receipt Amount - Base: The portion of this receipt that was applied to the transaction in your functional currency.

Exchange Gain/Loss: The gain or loss you would have incurred on this application if you had used the cross currency rate maintained in your general ledger (see System Cross Currency Rate, above).

System Cross Currency Rate: The exchange rate maintained in your general ledger (with the selected rate type) between the transaction and receipt currency on the receipt date.

Related Topics

Reviewing Receipt Applications

Applying On-Account Credit Memos

Receivables Application Rule Sets

Application Rule Sets determine the steps Receivables uses to apply partial payments and credit memos to your customer's open debit items, and how discounts affect the open balance for each type of associated charges.

Transactions usually consist of line items, tax, freight, and late charges, or a combination of these. Depending on your business needs, you can reduce each associated charge proportionately, close the outstanding tax amount first, or apply a payment to the line and tax amounts and use any remaining portion to reduce the freight and late charges.

Application Rule Sets let you specify how Receivables reduces the balance of your open debit items when you:

You can assign a rule set to each of your transaction types and enter a default rule set in the System Options window. Receivables uses the following hierarchy to determine which application rule set to use, stopping when one is found:

  1. Transaction Type

  2. System Options

Application Rule Sets

Receivables provides the following predefined Application Rule Sets. You can view these rule sets and create your own rule sets in the Application Rule Sets window.

For a detailed explanation of each of these rule sets, see: Application Rule Set Example.

Line First - Tax After

This rule set first applies the payment to the open line amount, and then applies the remaining amount to the associated tax. If the payment is greater than the sum of the line and tax, Receivables attempts to close each open item by applying the remaining amount in the following order, stopping when the payment has been fully applied:

  1. Freight

  2. Late charges

Any remaining receipt amount is applied using the Overapplication Rule. This is the default application rule set in the System Options window. See: Overapplication Rule.

Line and Tax Prorate

This rule set applies a proportionate amount of the payment to the open line and tax amount for each line. If the payment is greater than the sum of the open line and tax amounts, Receivables attempts to close each open item by applying the remaining amount in the following order, stopping when the payment has been fully applied:

  1. Freight

  2. Late charges

Any remaining receipt amount is applied using the Overapplication Rule. See: Overapplication Rule.

Prorate All

This rule set applies a proportionate amount of the payment to each open amount associated with a debit item (for example, any line, tax, freight, and late charge amounts for this item).

Receivables uses the following formula to determine the applied amount:

Applied Amount = open application line type amount / sum of application line types in rule details * Receipt Amount

Any remaining receipt amount is applied using the Overapplication Rule. See: Overapplication Rule.

Overapplication Rule

Each application rule set includes an Overapplication Rule by default. This rule applies any remaining receipt amount after the balance due for all charges has been reduced to zero. If the transaction type for the debit item has the Allow Overapplication check box set to Yes, Receivables applies the remaining amount to the lines, making the balance due negative. If the item's transaction type has Allow Overapplication set to No, you can either place the remaining amount on-account or leave it 'Unapplied'.

When using AutoLockbox, Receivables uses your AutoCash Rule Set to determine how to apply the remaining amount. See: AutoCash.

Application Rule Sets Example

This example shows how Receivables applies a payment using each predefined application rule set.

You have the following invoice:

Invoice #123

Your customer remits a partial payment of $1040 for this invoice. The table below shows how Receivables applies the payment using each of the three predefined application rule sets.

See: Calculations for Applying Payments Using Application Rules.

Application Rule Set Total Amount Applied Line Amount Applied Tax Amount Applied Freight Amount Applied
Line First - Tax After 1040 1000 40 0
Line and Tax Prorate 1040 912.281 127.722 0
Prorate All 1040 776.123 108.664 155.225

Calculations for Applying Payments Using Application Rules:

Line First - Tax After

First apply payment to open line amount; apply any remaining amount to tax.

Line and Tax Prorate

1(1040/1140) * 1000 = 912.28

(Receipt Amount / Total Line and Tax) * Line Amount = Line Amount Applied

2(1040/1140) * 140 = 127.72

(Receipt Amount / Total Line and Tax) * Open Tax Amount = Tax Amount Applied

Prorate All

3(1040/1340) x 1000 = 776.12

(Receipt Amount / Invoice Total) x Open Line Amount = Line Amount Applied

4(1040/1340) x 140 = 108.66

(Receipt Amount / Invoice Total) x Open Tax Amount = Tax Amount Applied

5(1040/1340) x 200 = 155.22

(Receipt Amount / Invoice Total) x Open Freight Amount = Freight Amount Applied

Line First - Tax After

As shown in the example above, this rule set first applies the payment to the line amount, reducing the balance due to zero. Receivables then applies the remaining amount ($40) to the tax charges, reducing the open tax amount to $100. Since the payment is not enough to close these items, the freight balance is not affected.

The table below compares each line type before and after you apply an amount using this rule.

App. Rule Set Amount Due Orig. Amount Due Remaining Line Items Orig. Line Items Remaining Tax Orig. Tax Remaining Freight Orig. Freight Remaining
Line First - Tax After 1340 300 1000 0 140 100 200 200

Line and Tax Prorate

This rule set applies a proportionate amount to the open line and tax charges. Since the amount applied is not enough to close these items, the freight balance is not affected.

The table below compares each line type before and after you apply an amount using this rule.

See: Calculations for Applying Payments Using the Line and Tax Prorate Application Rule.

App. Rule Set Amount Due Orig. Amount Due Remaining Line Items Orig. Line Items Remaining Tax Orig. Tax Remaining Freight Orig. Freight Remaining
Line and Tax Prorate 1340 300 1000 87.721 140 12.282 200 200

Calculations for Applying Payments Using the Line and Tax Prorate Application Rule:

11000 - 912.28 = 87.72

Amount Line Items - Line Amount Applied = Open Line Amount

2140 - 127.72 = 12.28

Tax Original - Tax Amount Applied = Open Tax Amount

Prorate All

This rule applies a proportionate amount of the receipt to the line, tax, and freight for this transaction. To see the formula Receivables uses to calculate the amount applied for each line type, refer to Prorate All.

The table below compares each line type before and after you apply an amount using this rule.

App. Rule Set Amount Due Orig. Amount Due Remaining Line Items Orig. Line Items Remaining Tax Orig. Tax Remaining Freight Orig. Freight Remaining
Prorate All 1340 300 1000 223.38 140 31.34 200 44.78

Transactions with Mixed Sign Balances

An additional consideration is the situation in which you apply a payment to a transaction that has mixed sign balances. 'Mixed sign balances' indicates that not all of the charges that make up a transaction have the same sign (positive or negative). In this case, the procedure Receivables uses to apply a payment is different than when applying to transaction amounts that are all positive or all negative (i.e. "same sign" balance).

When you apply a payment to a transaction that has mixed sign balances, Receivables applies the payment only to those amounts that have the same sign as the payment. For example, if the payment is for a positive amount (i.e. not a credit memo), Receivables only reduces the charges that have a positive balance; any negative balances are not affected.

As with transactions having a same sign balance, Receivables will apply any remaining amounts according to the overapplication rule assigned to your Application Rule Set.

Consider the following example:

Invoice #101

Assume that you are using the Application Rule 'Prorate All.' Your customer remits a receipt of $100, and you apply this amount to invoice 101. Receivables prorates the amount among the tax, freight, and charges, because, like the receipt, these amounts are positive. The Line amount (-100) is not affected.

The new invoice balance is shown below:

Invoice #101

The table below compares each line type for this invoice before and after you apply the payment.

App. Rule Set Line Items Orig. Line Items Remaining Tax Orig. Tax Remaining Freight Orig. Freight Remaining Charges Orig. Charges Remaining
Prorate All <100> <100> 100 28.56 30 8.58 10.00 2.86

The amount applied to each line type and the calculations Receivables performs are shown in the table below.

See: Calculations for Applying Payments Using the Prorate All Application Rule.

Total Amount Applied Line Amount Applied Tax Amount Applied Freight Amount Applied Charges Amount Applied
100 0 71.441 21.422 7.143

Calculations for Applying Payments Using the Prorate All Application Rule:

1100 - (21.42 + 7.14) = 71.44

2(30 * 100) / 140 = 21.42

3(10.00 * 100) / 140 = 7.14

Related Topics

Application Rule Sets, Oracle Receivables Implementation Guide

Defining Receivables System Options, Oracle Receivables Implementation Guide

Chargebacks and Adjustments

Receivables lets you create adjustments and chargebacks against transactions to which you are applying a receipt.

Use chargebacks to create a new debit item for your customer when closing an existing debit item. For example, your customer sends payment of $75 for a $100 invoice. You can apply the receipt to the invoice, then create a chargeback for the balance due.

If you use Oracle Trade Management, then you can create chargebacks against receipts when resolving cash claim investigations. You can use the Receipt Applications window to create a chargeback against a receipt. Or, Trade Management users can create chargebacks against transactions and receipts without any intervention required by a Receivables user. See: Working with Claims.

Chargebacks and Adjustments against Transactions

You can create multiple chargebacks and adjustments against each transaction, for positive or negative amounts.

Receivables lets you enter a chargeback against a credit memo or an on-account credit if they have a positive balance.

Receivables uses the transaction type of the transaction you are adjusting to validate the adjustment or chargeback amount. If the transaction type does not allow overapplication, you cannot enter an amount that would reverse the sign of the balance of the debit item. Chargebacks and adjustments do not follow the natural application rules; this lets you adjust transactions in either direction, regardless of the Natural Application flag. For more information, see: Transaction Types, Oracle Receivables Implementation Guide.

If the profile option AR: Cash - Allow Actions is set to No, the Chargebacks and Adjustments buttons are not available in the Applications window.

Chargebacks against Receipts

If you use Trade Management to track your customers' short payments and over payments (claims) on receipts, then the claims that you create in Receivables are automatically passed to Trade Management for claim tracking, analysis, and resolution. If a chargeback is required to resolve a claim, then the chargeback is created directly in Trade Management:

Alternatively, you can manually create a chargeback against a receipt in the Receipt Applications window in Receivables.

Both the chargeback application on the receipt and the actual chargeback transaction are created in the currency of the receipt. In the event of an exchange rate adjustment, Receivables calculates a foreign exchange gain or loss on the receipt for the functional difference between the chargeback transaction and the chargeback application.

For other resolution options, see: Working with Claims.

Creating a Chargeback

Receivables requires that you automatically number your chargebacks. The base number for your chargeback numbering sequences is determined when you install Oracle Receivables. See: Transaction Batch Sources, Oracle Receivables Implementation Guide.

Prerequisites

To create a chargeback against a transaction:

  1. Navigate to the Receipts window.

  2. Query or enter the receipt. See: Entering Receipts.

  3. Choose Apply.

  4. Select or enter the Transaction to which you want to apply this receipt. See: Applying Receipts.

  5. Choose the Chargebacks button.

  6. Enter the transaction Type and the Amount of this chargeback. The default chargeback amount is the remaining amount of the transaction. Receivables displays the new remaining amount in the Balance Due field. You can enter an amount greater than the balance due only if the Allow Overapplication option for this transaction type is Yes. For more information, see: Transaction Types, Oracle Receivables Implementation Guide.

  7. If document numbering is enabled and the document sequence associated with this receipt is Manual, enter a Document Number for this chargeback. If the sequence type is Automatic, Receivables assigns a document number when you save.

  8. Enter the Account for this chargeback. The transaction type provides the default account, but you can change it.

  9. Enter the Due Date for this chargeback. The default due date is the value of the Chargeback Due Date parameter in the System Options window. For example: Current Date, Deposit Date, Open Invoice Due Date, or Receipt Date.

  10. Open the More tabbed region, then enter a Reason for creating this chargeback and any Comments (optional). You can define additional chargeback reasons in the Receivables Lookups window. See: Defining Receivables Lookups, Oracle Receivables Implementation Guide.

    Note: See: Applications Field Reference for a description of the Transaction Code field.

  11. Save your work. Receivables uses the chargeback batch source to automatically number your chargeback and assigns the default payment term 'IMMEDIATE.'

    Note: You can view the payment term, GL date, and other information about this chargeback in the Transactions window. To do this, perform a query using the chargeback number.

To create a chargeback against a receipt:

Note: If you have Trade Management installed, then the Trade Management user, not the Receivables user, will create these transactions to resolve invalid non-invoice related claims.

  1. Navigate to the Receipts window.

  2. Query or enter the receipt. See: Entering Receipts.

  3. Choose Apply.

  4. Select or enter the claim investigation application for which you want to create the chargeback. See: Applying Receipts.

    Note: After entering a claim investigation application, you must first save the application record before you can enter a chargeback against it.

  5. Choose the Chargebacks button.

  6. Enter the transaction type of this chargeback. The default chargeback amount is for the full amount of the claim, and cannot be changed.

  7. If document numbering is enabled and the document sequence associated with this receipt is Manual, enter a document number for this chargeback. If the sequence type is Automatic, Receivables assigns a document number when you save.

  8. Enter the account for this chargeback. The transaction type provides the default account, but you can change it.

  9. Enter the due date for this chargeback. The default due date is the value of the Chargeback Due Date parameter in the System Options window. For example: Current Date, Deposit Date, Open Invoice Due Date, or Receipt Date.

  10. Enter a reason for creating this chargeback and any comments (optional). You can define additional chargeback reasons in the Receivables Lookups window. See: Defining Receivables Lookups, Oracle Receivables Implementation Guide.

    Note: See: Applications Field Reference for a description of the Transaction Code field.

  11. Save your work.

    Receivables uses the chargeback batch source to automatically number your chargeback and assigns the default payment term 'IMMEDIATE.'

    In the Applications window, Receivables automatically unapplies the claim investigation application and reapplies the claim amount to a chargeback with an activity of Chargeback Adjustment.

    Note: You can view the payment term, GL date, and other information about this chargeback in the Transactions window. To do this, perform a query using the chargeback number.

Creating an Adjustment

Create adjustments to increase or decrease the balance due for an invoice, debit memo, chargeback, or commitment. For example, you apply a receipt to an invoice, but there is still an open balance of two dollars. You can create an adjustment to write off the remaining amount and close the debit item.

Note: If you create an adjustment during a receipt application (for example, to write off a small remaining amount) and then unapply the application later, Receivables reverses the adjustment and assigns it a status of 'Adjustment Reversal.'

Prerequisites

To create an adjustment:

  1. Navigate to the Receipts window.

  2. Enter or query the receipt. See: Entering Receipts.

  3. Choose Apply.

  4. Select or enter the Transaction to which you want to apply the receipt. See: Applying Receipts.

  5. Choose Adjustments.

    Note: You can view the detail accounting lines for an adjustment in the form of a balanced accounting entry (i.e., debits equal credits) by choosing View Accounting from the Tools menu. You can also choose to view the detail accounting as t-accounts.

    See: Viewing Accounting Lines.

  6. Enter an Activity Name and choose the Type of adjustment you are creating. Valid adjustment types include Invoice, Charges, Freight, and Tax.

  7. Enter the Amount of this adjustment. If you specify 'Invoice' as your adjustment type, Receivables requires that the amount of your adjustment be at least enough to close the item you are adjusting, and displays this value in the Amount field. If the amount of this adjustment is outside your approval limits, Receivables sets the status of the adjustment to Pending Approval when you save (unapproved adjustments do not update the balance due for an item).

    Important: You can enter an amount greater than the balance due only if the transaction type's Allow Overapplication option is set to Yes. For more information, see: Transaction Types, Oracle Receivables Implementation Guide.

  8. Enter the GL Date for this adjustment (optional). The default is the later of either the transaction GL date or the current date. However, if this date is not in an open or future-enterable period, the default GL Date is the last date of the most recent open period. The GL date must be later than or equal to the GL date of the debit item you are adjusting and must be in an open or future-enterable period.

  9. Enter the Adjustment Date (optional). The default is the current date, but you can change it.

  10. Open the Account IDs tabbed region, then enter the GL Account for this adjustment (optional). The activity name provides the default GL account, but you can change it.

  11. If you are using manual document numbering, enter a unique Document Number for this adjustment. If you are using automatic document numbering, Receivables assigns a document number when you save. See: Implementing Document Sequences, Oracle Receivables Implementation Guide.

  12. Open the Comments tabbed region, then enter a Reason for creating this adjustment. Receivables prints your reasons on the Adjustment Register.

    Note: An adjustment reason is optional unless you set the AR: Require Adjustment Reason profile option to Yes. See: Overview of Receivables User Profile Options, Oracle Receivables Implementation Guide.

  13. Update the Status of this adjustment (optional). If this adjustment is within your user approval limits, you can choose any status. If you are reviewing a previously approved adjustment, Receivables skips this field.

  14. Save your work. Receivables generates a unique number for this adjustment.

Related Topics

About Adjustments

Foreign Currency Transactions

Transaction Types, Oracle Receivables Implementation Guide

Adjustment Register

Entering Miscellaneous Receipts

Non-invoice related transactions such as investment and interest income are known as miscellaneous receipts in Receivables. Use the Receipts or Receipts Summary window to enter your miscellaneous receipts.

You can enter miscellaneous receipts in any currency defined in the system if you have at least one remittance bank account which has the Multiple Currencies Allowed check box selected. If no such bank account exists, you can only enter receipts in the same currency in which bank accounts exist.

Receivables uses distribution sets that you define to account for miscellaneous receipts. See: Distribution Sets, Oracle Receivables Implementation Guide.

Prerequisites

To enter a miscellaneous receipt:

  1. Navigate to the Receipts window.

  2. Enter receipt information, including Receipt Method, Receipt Number, Currency, Receipt Amount, and GL Date.

    See also: Entering Receipts.

  3. Choose a Receipt Type of Miscellaneous.

  4. Enter a Reference Type for this transaction (optional).

  5. If you entered a Reference Type, enter the corresponding Reference Number, or choose from the list of values. This table illustrates some examples:

    Reference Type Reference Number
    Payment Check Number
    Payment Batch Payment Batch Name
    Receipt Receipt Number
    Remittance Remittance Batch Name

    If your Reference Type is Payment, the list of values lets you choose from checks recorded in Oracle Payables that are written from the same bank account as the remittance account you entered for this transaction.

    If your Reference Type is Payment Batch, the list of values lets you choose from payment batches created in Oracle Payables that have the same bank account as this transaction.

    If your Reference Type is Receipt, the list of values lets you choose from receipts in Receivables that have the same bank account as this transaction.

    If your Reference Type is Remittance, the list of values lets you choose from Receivables remittance batches that have the same bank account as this transaction.

  6. In the Paid By region, specify from where this payment originated (optional). This field is for informational purposes only.

  7. Enter an activity, or choose one from the list of values.

    The Receivables activity determines the default distribution set and accounting for this transaction.

    You can enter any Receivables activity with a Miscellaneous Cash type except an activity that was previously set up with a location-based tax code. You cannot enter a location-based tax code because you cannot enter ship-to information in the Receipts window.

    Note: If your tax method is VAT and you calculate tax on miscellaneous receipts, the Receivables Activity also determines the tax code and tax rate for this transaction.

    Note: To create a miscellaneous receipt with a negative amount, you must confirm that the receivables activity with the Miscellaneous Cash activity type has a liability tax code with a tax type of Input. See: Receivables Activities, Oracle Receivables Implementation Guide

  8. If you want to change the tax code for this transaction, enter a Tax Code (optional). You can enter any predefined tax code with a type of Sales or VAT.

    Important: You can change the default Tax Rate and Tax Amount if the tax code is an ad hoc tax code and the profile option Tax Allow Ad Hoc Tax Changes is set to Yes. Otherwise, these fields are for display only.

  9. Modify the remittance Bank Account (optional).

  10. If you are using manual document numbering, then open the More tabbed region and enter a unique Document Number.

  11. Modify the Deposit Date (optional).

  12. To review or update the general ledger account information for this transaction, choose Distributions.

    Note: If your tax method is VAT and you calculate tax on miscellaneous receipts, the Distributions window displays the tax code and tax amount for this transaction.

Related Topics

Miscellaneous Receipts Register

Entering Receipts

Reversing Receipts

Receivables lets you reverse a receipt when your customer stops payment on a receipt or if a receipt comes from an account with insufficient funds. You can also reverse a receipt if you want to re-enter and reapply it in Receivables.

You can reverse these types of receipts:

Receivables lets you create two types of receipt reversals:

To view a list of reversed receipts, see: Reversed Receipts Report.

Note: After you reverse a receipt, you cannot update any of the receipt's attributes.

Standard Reversals

When you create a standard reversal, Receivables automatically creates reversal journal entries for your general ledger and reopens all of the debit and credit items that were closed with the original receipt.

You can create a standard reversal for a receipt that has applied transactions that are related to chargebacks, provided that there is no activity against the chargeback and the chargeback has not been posted to the general ledger. If the chargeback has been posted to the general ledger, then you must create a debit memo reversal (see below).

If you create a standard reversal for a receipt that you have applied, then Receivables reverses any adjustments or chargebacks that you created, as long as you have not posted these adjustments to your general ledger.

Debit Memo Reversals

Debit memo reversals are used when you need to reverse a receipt, but you want to maintain the link between the billing activity and the payment. When you create a debit memo reversal, Receivables reverses the receipt, but does not update any of the receipt activity that is associated with the original receipt.

A debit memo reversal is different from a standard reversal because, instead of reopening the debit and credit items that were closed with the original receipt, Receivables creates one new receivable in the amount of the net of the closed debit and credit transactions. As a result, the reversed receipt shows the transaction as still applied.

You create a debit memo reversal by checking the Debit Memo Reversal check box in the Reverse window when you reverse a receipt. Do not check the Calculate check box on the transaction type for the debit memo reversal, because the tax was already accounted for on the original invoice. See: Transaction Types, Oracle Receivables Implementation Guide.

You must create a debit memo reversal if:

When you create a debit memo for a receipt reversal, Receivables generates the line item from the predefined memo line. Receivables creates this line on the debit memo: Debit memo for reversal of payment &PAYMENT_NUMBER&, where &PAYMENT_NUMBER& represents the original receipt number.

The accounting for a debit memo reversal is automatically created, but Receivables does not use AutoAccounting as it does for a standard debit memo. See: Accounting for Debit Memo Reversals.

In addition, when you save the reversal, Receivables assigns a unique transaction number to the new debit memo. If the receipt that you are reversing uses a receipt method with the Debit Memo Inherit Receipt Number option set to Yes, then you can control whether the debit memo has the same transaction number as the original receipt. If the Debit Memo Inherit Receipt Number option is set to No, then Receivables uses the DM Reversal transaction source to determine the numbering for the debit memo reversal.

See: Receipt Methods, Oracle Receivables Implementation Guide for more information about the Debit Memo Inherit Receipt Number option. See: Transaction Batch Sources, Oracle Receivables Implementation Guide for more information on transaction numbering.

Accounting for Debit Memo Reversals

When you create a debit memo reversal, Receivables creates the accounting entries on the new debit memo transaction, rather than on the original receipt. This ensures that you do not make duplicate entries, and eliminates the need for a clearing account.

For a regular debit memo, AutoAccounting creates both the revenue and receivable accounts. But, for a debit memo reversal, AutoAccounting does not create the accounting entries on the new debit item. Instead, the receivable account defaults from the transaction type. The revenue account defaults from the cash account on the receipt. The GL cash account that defaults depends on the status of the receipt at the time when you create the debit memo reversal. For example, if the receipt was remitted, then the GL cash account is the same as the remitted account that is assigned to the receipt method of this receipt. See: Default Accounting for Transactions.

Receivables creates these two entries:

  1. The first entry decreases the cash account.

    Receivables already recognized revenue with the original invoice. To avoid overstating the cash and revenue accounts, Receivables does not create an additional entry to revenue. Instead, Receivables assigns the cash account to the revenue line on the debit memo.

  2. The second entry creates the new receivable.

    When you applied the original receipt, Receivables closed the invoices and their associated receivables. You must establish a new receivable, therefore, because you want to track this new debit item.

    The receivable account defaults from the receivable account that was assigned to the predefined debit memo reversal transaction type.

To reverse a receipt:

Prerequisites

To reverse a receipt:

  1. Navigate to the Receipts window.

  2. Query the receipt to reverse.

    Note: You can view the detail accounting lines for a receipt by choosing View Accounting from the Tools menu.

    See: Viewing Accounting Lines.

  3. To review the applications for this receipt, choose Apply.

    To review the distributions for a miscellaneous receipt, choose the Distributions button.

  4. Choose the Reverse button.

  5. In the Date field, enter the date of this receipt reversal and the date to post this reversal to your general ledger. The default for the reversal and GL dates is the current date.

    Receivables verifies that the GL date you enter for this reversal is in an open period. However, if the current date is not in an open period, then the default is the last date of the most recent open period.

    You can change the reversal and GL dates, but the reversal date must be on or after the deposit date of the original receipt, and the reversal GL Date cannot be before the receipt GL Date or the reversal date.

  6. In the Category field, enter the category for this reversal. Valid categories include Non-Sufficient Funds, Reverse Payment, and Stop Payment.

    Note: Use the Reverse Payment category when the receipt has been incorrectly entered and you wish to re-enter it. Oracle Cash Management does not reconcile receipts that are reversed with this category, because this category is reserved for entry errors only.

    If you are reversing a credit card refund miscellaneous receipt, then the Credit Card Refund Reversal category defaults into this field.

    Note: The Credit Card Refund Reversal category displays only during credit card refund reversals.

  7. In the Reason field, enter a reason for this receipt reversal. Typical reasons include Insufficient Funds, Account Closed, Wrong Amount, Wrong Customer, and Uncollectable.

  8. To create a standard reversal, choose the Reverse button.

  9. To create a debit memo reversal:

    1. Check the Debit Memo Reversal check box, then enter a transaction type for this reversal in the Type field.

    2. In the Account field, enter the account for this new receivable. The debit memo transaction type provides the default value for this field, but you can change it.

    3. If you are using manual document numbering, enter a unique document number for this reversal in the Document Num field. Otherwise, Receivables assigns a number when you choose Reverse. See: Implementing Document Sequences, Oracle Receivables Implementation Guide.

    4. Choose the Reverse button.

Related Topics

Standard Memo Lines, Oracle Receivables Implementation Guide

Transaction Types, Oracle Receivables Implementation Guide

Reversed Receipts Report

Entering Receipts

Applying Receipts

Creating Chargebacks and Adjustments

Entering Miscellaneous Receipts

Reapplying Receipts

You can reapply receipts that you previously applied in error before or after posting these items to your general ledger. You can reapply both automatic and manually entered receipts.

When you reapply a receipt, you first 'unapply' the original receipt applications; this reopens each transaction or transaction line that was previously closed by the receipt. However, you cannot unapply a receipt that has adjustments associated with it unless you first readjust the transaction to its original amount. In addition, you cannot unapply a transaction if there is a chargeback against it and the chargeback has any activities against it (for example, another receipt or credit memo).

You can unapply a receipt that was applied to another open receipt, provided that neither receipt is drawn negative by the unapplication. See: Receipt-to-Receipt Applications.

Prerequisites

To reapply a receipt:

  1. Navigate to the Receipts window.

  2. Query the receipt to reapply.

    Note: To include open receipts in the list of values, check the Include Open Receipts box from the Tools menu, or set the AR: Default Open Receipts for Application profile option to Yes.

  3. Select the receipt, then choose Apply.

  4. Reverse applications by unchecking the Apply check box next to each transaction.

    Or, if you applied this receipt at the transaction line level, then choose Apply in Detail and deselect the transaction lines that you want to unapply.

    Receivables changes the Applied Amount for each transaction or transaction line to zero, and increases the Unapplied Amount of the receipt.

    Receivables enters a Reversal GL Date date for each transaction or transaction line that you reopen. The Reversal GL Date is the date to post this reapplication to your general ledger. This date is the same as either the GL date of the original application or, if the original application's GL date is in a closed period, the current date. If the current date is not open, the default is the last date of the most recent open period.

  5. Apply this receipt to a different transaction or transaction line. See: Applying Receipts or Applying Receipts in Detail.

  6. Save your work. Receivables creates reversing journal entries for each application that you reopened.

Related Topics

Entering Receipts

Applying Receipts

Applying Receipts in Detail

Chargebacks and Adjustments

Reversing Receipts

Reviewing Receipts and Applications

Reviewing Receipts and Applications

You can review the applications for a receipt from the Receipts, Receipts Summary, or Applications window. In the Receipts window, use the Balances region to view the amount applied, unapplied, placed on-account or in claim investigation, any earned or unearned discounts, and the original amount of a receipt. In the Applications window, you can review all of the debit and credit items to which you have applied this receipt, or you can view only specific debit or credit items by executing a query.

You can also view summarized information about your receipts in the Receipt History window. The Receipt History window lists changes made to a receipt during its lifetime, including dates when the receipt was remitted, approved, confirmed, or reversed, and when each receipt state posted to your general ledger. You can also view the receipt amount at each phase and any functional currency gains or losses resulting from exchange rate adjustments. See: Foreign Currency Transactions.

You can view all activities against a receipt in the Activities window. Use this window to view each activity, its application date and amount, and status. You can also use the Activities window to view all activities against existing receipt applications (applied transactions).

You can view the total entered and functional amounts of your receipts in the Sums of Receipt Amounts window. The Sums of Receipt Amounts window displays the currency, count, entered amounts, and functional amounts of selected receipts.

Prerequisites

To review receipt applications:

  1. Navigate to the Receipts or Receipts Summary window.

  2. Query the receipt to view.

    The application summary fields are displayed in the Balances region of the Receipts window.

    Note: You can also view these totals from the Receipts Summary window by placing your cursor in the window, choosing Show Field from the Folder menu, and then selecting the field to view (for example, Applied Amount or Discounts Earned).

    Note: You can view the detail accounting lines for a receipt in the form of a balanced accounting entry (i.e., debits equal credits) by choosing View Accounting from the Tools menu. You can also choose to view the detail accounting as t-accounts.

    See: Viewing Accounting Lines.

  3. To review the specific applications for a cash receipt, choose Apply. To review the distributions for a miscellaneous receipt, choose Distributions.

    Tip: To view only specific transactions in the Applications window, select Enter from the Query menu, enter the Customer Number, Transaction Number, or Amount Applied, then choose Run from the Query menu.

To view the history of a receipt:

  1. Navigate to the Receipts or the Receipts Summary window.

  2. Query the receipt.

  3. Choose Receipt History from the Tools menu.

To view a receipt's activities:

  1. Navigate to the Receipts or the Receipts Summary window.

  2. Query the receipt.

  3. Choose Activities from the Actions menu.

    The Activities window displays all activity, both current and historical.

To view only current activities for a receipt, choose Apply. In the Applications window, you can view all current receipt application activities.

To view activities against existing receipt applications:

  1. Navigate to the Receipts or the Receipts Summary window.

  2. Query the receipt.

  3. Choose Apply.

  4. Select an applied transaction on the receipt, then choose Activities from the Actions menu.

    The Activities window displays all activity, both current and historical, against the transaction that you applied this receipt to. This lets you see if any other payments were made to the selected transaction.

To view the total amount of selected receipts:

  1. Navigate to the Receipts Summary window.

  2. Query the receipts.

  3. Select the receipt to view.

    To select more than one receipt, press and hold the Control key while selecting receipts.

    To select a range of receipts, select a receipt, press and hold the Shift key, then select another receipt.

  4. Choose Receipt Totals from the Tools menu. Receivables displays the total entered and functional amount of the receipt(s) you selected in the Sums of Receipt Amounts window.

To review information about a reversed receipt:

  1. Navigate to the Receipts window.

  2. Query the receipt.

  3. Open the More tabbed region.

Related Topics

Applying Receipts

Receipt Analysis - Days Late Report

Batching Receipts for Easy Entry and Retrieval

Use the Receipt Batches window to create receipt batches or to query existing batches. Batching receipts lets you:

You can add duplicate receipts to a batch. Duplicate receipts are receipts that have the same number, amount, and customer information.

You can post a receipt batch to your general ledger regardless of its status. You can delete a receipt batch only if it does not contain any receipts.

If you are remitting receipts, see: Creating Remittance Batches.

Receivables lets you add receipts denominated in different currencies to a batch. However, the total in the Receipt Batches window reflects amounts entered in all currencies, not the batch currency. For example, if there are two receipts in a batch, one for 400 USD and one for 200 EUR, the total amount for this batch is 600, regardless of the batch currency.

Note: You can specify how many spaces are available to the right of the decimal point when displaying numbers representing different currencies using the profile option Currency:Mixed Currency Precision. See: Profile Options in Oracle Application Object Library, Oracle Receivables Implementation Guide.

Important: The GUI versions of Oracle Receivables let you enter receipts both individually and as part of a batch. Previous versions (i.e. character mode) required that you either entered receipts as part of a batch or entered them individually (in the latter case, you could not create batches at all). As a result, if you are using Receivables in character mode, you can only query receipts that were entered in the GUI version if they are part of a batch.

Batch Statuses

A batch has a status that indicates whether it is complete. Receivables automatically updates the status of a receipt batch when you add new or apply existing receipts in the batch. A batch can have one of the following statuses:

New: This is a new batch that does not yet contain any receipts.

Out of Balance: The actual count and amount of receipts in this batch do not equal the control count and amount.

Open: The actual count and amount equal your control count and amount. However, you have one or more receipts that are unidentified or unapplied.

Closed: The actual count and amount match the control count and amount and there are no receipts that are either unidentified or unapplied.

To create a batch of receipts:

Prerequisites

  1. Navigate to the Receipt Batches or the Receipt Batches Summary window.

  2. Choose a Batch Type of Manual Regular.

  3. Enter a Batch Source. If you have defined the profile option AR: Receipt Batch Source, Receivables uses this as the default batch source, but you can change it. The batch source determines default attributes for receipts within this batch, including receipt method, receipt class, and whether receipt numbers are assigned automatically.

    Receivables uses the receipt method to determine the accounting and remittance bank accounts for this receipt. The receipt class determines the processing steps for this receipt.

    Note: If a user has access to multiple organizations, Receivables does not default the receipt batch source in Receipt Batches and Receipt Batches Summary windows.

  4. Enter a unique Batch Name. If Automatic Batch Numbering for the batch source you entered is Yes, Receivables assigns a batch name when you save.

    Tip: If you use good naming conventions for your batches, you can easily find a batch or individual receipts within a batch for review.

  5. If the currency for this batch is different from your functional currency, enter the Currency and exchange rate information. See: Foreign Currency Transactions.

    Note: Receivables uses the batch currency as the default for each receipt that you add to this batch. However, you can add receipts to a batch that are in different currencies.

  6. Enter the Batch, GL, and Deposit Dates for this batch (optional). The default batch and deposit date is the current date, but you can enter a different date. The default batch GL date is the last day of the most recent open period. You can change this date, but it must be in an open or future enterable period. The batch GL date provides the default GL date for each receipt in this batch.

    Receivables uses the deposit date as the exchange date when the receipt currency is different from your functional currency. If you later change the deposit date, then Receivables also updates the exchange date.

  7. Enter the Receipt Class, Receipt Method, and Bank Name for this batch. The batch source provides default values, but you can change them.

    Note: You can only enter receipt methods assigned to this receipt class. You can enter any bank account assigned to the receipt method if the account is in the same currency as the receipt, or the Receipt Multi-Currency flag for this remittance bank is set to Yes.

  8. Enter the total number and amount of receipts that you want to add to this batch in the Control Count and Control Amount fields.

  9. To add receipts to this batch, choose Receipts. Receivables saves your batch information. See: Entering Receipts.

    When you add receipts to this batch or apply, unapply, reverse, or adjust receipts that are part of this batch, Receivables updates the batch totals. See: Receipts Field Reference.

Related Topics

Receipts Field Reference

QuickCash

Post QuickCash

Notes Receivable

Receivables lets you enter and track future-dated payments. These types of payments can either be a future dated check or a formal document called a promissory note. A promissory note is a formal, printed document in which the issuer promises to a pay a specific amount on a specific date to another party (the note holder). The date that payment is due is called the note maturity date. Promissory notes are guaranteed by the bank that issues the note.

When a promissory note is created, the issuer specifies the amount due, the maturity date, and the bank branch from which the holder can receive the payment. When the note reaches its maturity date, the holder submits it to their bank. The bank then submits the note to a clearing institution, which transfers the payment from the issuer's bank to the holder's bank.

Notes issued by the customer can also be returned to the supplier prior to the maturity date if, for example, the note had been issued as a deposit, advance payment, or as payment for existing customer invoices.

When a promissory note or future dated check is received as payment for goods or services, it is called a Note Receivable.

Note Status

Use the Notes Receivable reports to review note statuses. A note can have one of the following statuses:

Confirmed: Receivables assigns this status when you create a new note receivable.

Return: This note was returned to the issuer on or before the note maturity date. Receivables assigns this status when you reverse a note and the reversal date is on or before the note maturity date. You can return a note by creating a standard reversal in the Reverse Receipts window. You can also create a debit memo reversal for a returned note.

Delinquent: This remitted note reached its maturity date, but funds were not available. Receivables assigns this status if you reverse a remitted note by creating a debit memo reversal and the reversal date is after the maturity date. You can reverse a note in the Receipts window.

Repurchase: This factored note reached its maturity date, but funds were not paid to the factoring bank (the note is delinquent). Receivables assigns this status if you reverse a factored note by creating a debit memo reversal and the reversal date is after the maturity date. You can reverse a note in the Receipts window.

Exchange: This is a new note that you applied to the debit memo that was created when you reversed a delinquent, returned, or repurchased note. For example, you create a debit memo reversal for a delinquent note that had been applied to a transaction. Then, you create a new note (with a new maturity date, note number and optional interest charges) and apply it to the new debit memo. You can reverse a note and create a new note receivable in the Receipts window.

Mature: This note has reached its maturity date. A note can be remitted or factored when it reaches maturity.

Note Activities

Following are valid note activities in Receivables:

Deposit: Similar to a bill of exchange, the note holder can submit the cash receipt to the issuer's bank for collection. The note issuer's bank is credited on the note maturity date.

Exchange: You can replace a delinquent note with a new note. You specify a new maturity date and note number, and can add interest to the amount of the new note. This is also called Renewing a note. You can create a note receivable in the Receipts window.

Factor: You can factor a note with your bank prior to the note maturity date. A factored note is one that you sign over to your bank in exchange for cash. Similar to a receipt, you can choose to factor a note receivable by assigning it to a receipt class that has a remittance method of Factoring or Standard and Factoring. Factored notes are subject to bank discounting (factoring) fees. See: Factoring Remittances and Automatic Clearing for Receipts.

Remit: Similar to a receipt, you can remit a note receivable as payment for goods or services. You can remit a note receivable in the Remittances window. See: About Remittances.

Return: You can return a note to the issuer on or before the note maturity date. These notes may have been received as an advance payment or as payment for an invoice. You can return a note by reversing it in the Receipts window. See: Reversing Receipts.

The figure below shows the possible note activities within Receivables.

Processing Notes Receivable

the picture is described in the document text

To see a text description of this graphic, see: Text Description of the Processing Notes Receivable Graphic.

Related Topics

Setting Up Notes Receivable

Clearing Notes Receivable

Reversing a Note Receivable

Accounting for Notes Receivable

Setting Up Notes Receivable

Complete the following steps in the order shown to set up your system to create notes receivable.

Step 1 Define Banks and Bank Accounts

Define the banks and bank accounts you use to remit your payments. You can define as many banks and bank accounts as you want, but each bank account must refer to one currency. Receivables requires that you enter a cash account for each bank account.

See: Bank Account Model Overview, Oracle Cash Management User Guide.

Step 2 Define Receipt Classes

Define a receipt class to use with your notes receivable. Indicate that this receipt class will be used for notes receivable by setting Notes Receivable to Yes. You define Receipt Classes in the Receipt Classes window. See: Receipt Classes, Oracle Receivables Implementation Guide.

Additionally, use the following settings for your Notes Receivables receipt class:

Creation Method: Manual

Remittance Method: Standard, Factoring, or Standard and Factoring

Clearance Method: Automatic Clearing or Matching

Step 3 Assign Receipt Methods and Remittance Banks

Assign a receipt method to your note receivable receipt class. Set the number of Lead Days (clearing days) to zero so the cash account can be debited on the note maturity date. Lead Days represent the number of days after the maturity date that funds can be transferred from the issuer's bank account to the note holder's bank account when the receipt is cleared.

The Notes Receivable account should be cleared on the note maturity date. To do this when you assign a remittance bank to this receipt method, assign your Confirmation, Remittance, and Factoring accounts to your Notes Receivable account. Additionally, you should assign your Notes Factored account to the Short Term Debt account. The Short Term Debt account will be used for delinquent notes.

For more information, see: Receipt Methods, Oracle Receivables Implementation Guide and Assigning Remittance Banks, Oracle Receivables Implementation Guide.

Related Topics

Creating a Note Receivable

Creating a Note Receivable

Create notes receivable to record future-dated payments in Receivables. With this type of payment, funds are transferred from the note issuer's bank to the note holder's bank on the note maturity date.

You can only enter notes receivable manually using the Receipts window, you cannot create notes using the Receivables Automatic Receipts feature.

To create a note receivable:

  1. Navigate to the Receipts window.

  2. Enter the Receipt Method that you assigned to your Notes Receivable Receipt Class.

  3. Enter basic information for this note including note Number, Currency, Amount, and GL Date.

    See also: Entering Receipts.

  4. Enter the maturity date.

    The default Maturity Date is the same as the deposit date. The Maturity Date is the date that funds will be transferred from the note issuer's bank to the note holder's bank.

  5. Choose a Receipt Type of Standard.

  6. If the system option Require Billing Location for Receipts is set to Yes, enter a bill-to Location.

  7. If bank charges apply, then enter an amount for Bank Charges.

  8. Modify the remittance Bank Account (optional).

  9. If you are using manual document numbering, then open the More tabbed region and enter a unique Document Number.

  10. Enter the note Deposit Date.

    The default deposit date is today's date. You can change the deposit date, but for a note receivable, the deposit date should not precede the Receipt Date (note date).

  11. Optionally use the Override field to prevent the receipt Remittance bank from being automatically overridden during the remittance process.

  12. In the Notes Receivable region, enter the following information:

    Issuer Name: (optional) The name of the person who issued this note. The note issuer does not need to be defined in Receivables.

    Issue Date: The Date you are issuing this note. The default is today's date, but you can change it.

    Issuer Bank Name: Enter the bank from which this note was issued, or select a bank from the list of values.

    Issuer Bank Branch: Enter the bank branch from which this note was issued, or select a branch from the list of values.

  13. Save your work. Receivables assigns this note a status of Confirmed.

Related Topics

Reversing a Note Receivable

Clearing Notes Receivable

Notes Receivable Report

Notes Receivable

Clearing Notes Receivable

Run the Receivables Automatic Clearing program to clear your notes receivable. This program clears the receivable account and the appropriate contra account, depending on whether the note was factored or deposited in your bank.

Although funds are credited to the note holder's bank account on the note maturity date, funds are usually not available until the fund transfer and clearing is complete. The number of days after the maturity date when funds are actually deposited in the note holder's bank account varies depending on the issuer's bank and the remittance bank. If the issuer bank and the remittance bank is the same (intra-bank dealing), the number of clearing days is zero; otherwise, the number of clearing days may vary. In either case, for Receivables to create accounting entries on the maturity date, the Lead Days (clearing days) for the receipt method must be set to 0. See: Setting Up Notes Receivable.

When you clear a note receivable, the Automatic Clearing program updates its status to Matured.

Related Topics

Automatic Clearing for Receipts

Accounting for Notes Receivable

Notes Receivable Report

Reversing a Note Receivable

You can reverse a note receivable in the Reverse Receipts window. You can reverse a note if it is delinquent, the note issuer has stopped payment, or if you want to return it to the issuer before the note maturity date. If a note is delinquent (for example, funds are not available on the note maturity date), you can either exchange or repurchase the note. To repurchase a note receivable, create a debit memo reversal.

When you create a debit memo reversal for a note receivable that was remitted, Receivables changes the note status to Delinquent.

When you create a debit memo reversal, Receivables does not update any of the receipt activity associated with the original receipt. The new debit memo reversal is actually a new receivable that replaces the item closed by the original note.

The procedure for reversing a note receivable is the same as for a cash receipt. This is true for both standard and debit memo reversals.

To return a note before its maturity date:

  1. Navigate to the Reverse Receipts window.

  2. Query the note to return.

  3. Specify a Reversal Date that is on or before the note maturity date.

  4. Create either a standard or debit memo reversal for this note. See: Reversing Receipts.

  5. Save your work. Receivables assigns this note a status of Return.

To repurchase a delinquent, factored note:

  1. Navigate to the Reverse Receipts window.

  2. Query the note to repurchase.

  3. Specify a Reversal Date that is after the note maturity date.

  4. Create a debit memo reversal for this note. See: Reversing Receipts.

  5. Save your work. Receivables assigns this note a status of Repurchase.

To reverse a delinquent, remitted note:

  1. Navigate to the Reverse Receipts window.

  2. Query the delinquent note.

  3. Specify a Reversal Date that is after the note maturity date.

  4. Create a debit memo reversal for this note. See: Reversing Receipts.

  5. Save your work. Receivables assigns this note a status of Delinquent.

To exchange a note receivable:

  1. Navigate to the Receipts window.

  2. Enter a new note receivable. See: Creating a Note Receivable.

  3. Apply the new note to the debit memo that was created when the note was returned, delinquent, or repurchased. Receivables assigns this note a status of Exchange.

Related Topics

Notes Receivable Report

Reversed Notes Receivable Report

Accounting for Notes Receivable

This table compares the accounting entries that Receivables creates for a regular receipt and a note receivable.

Cash Receipt Note Receivable
Create Receipt Requiring Remittance
DR Confirmation
CR Receivables
Create Note Requiring Remittance
DR Notes Receivable
CR Receivables
Standard Remittance
DR Remittance
CR Confirmation
Factored Remittance
DR Factor
CR Confirmation
Standard Remittance
DR Notes Receivable
CR Notes Receivable
Factored Remittance
DR Factor
CR Confirmation
Clear
DR Cash
DR Bank Charges
CR Short Term Debt
Clear Factored Note (prior to maturity date)
DR Cash
DR Bank Charges
CR Short Term Debt
Maturity Date
DR Short Term Debt
CR Factor
Maturity Date
DR Cash
CR Notes Receivable
Risk Eliminate
DR Short Term Debt
CR Factor
Risk Eliminate
DR Short Term Debt
CR Factor

Related Topics

Notes Receivable Report

Reversed Notes Receivable Report

Notes Receivable Report

The Notes Receivable Report lets you view general information about your notes receivable.

This report only includes notes that have the following status:

The Notes Receivable report does not include notes that have a status of Returned, Delinquent, or Repurchased.

Report Parameters

Currency: Enter the currency of the notes to include in this report. Leave this field blank to include all notes, regardless of their currency.

Customer Name Low/High: To include only notes that belong to a specific customer or customers, enter a range of customer names. Leave this field blank to include notes for all customers, or enter the same customer in both fields to report on only one customer.

Customer Number Low/High: To include only notes that belong to a specific customer or customers, enter a range of customer numbers. Leave this field blank to include notes for all customers, or enter the same customer number in both fields to report on only one customer.

End Maturity Date: If you entered a Start Maturity Date, enter an end date to include only notes with maturity dates within this range in your report.

Order By: Choose the method you want to use to sort information for this report. Choose Maturity Date, Customer, or Remittance Bank. This parameter is required.

Remittance Bank: To include only notes for a specific bank, enter a remittance bank.

Remittance Bank Account: To include only notes for a specific bank account, enter a remittance bank account (optional).

Start Maturity Date/End Maturity Date: To include only notes within a range of maturity dates, enter a range of dates here. Leave this field blank to include all notes, regardless of their maturity date.

Status: To include only notes with a specific status in your report, enter a status. Choose one of the following: Exchange, Matured, Open, or Remitted. Leave this field blank to include all notes, regardless of their status.

Report Headings

Currency: The currency of notes included in this report (if you specified a currency in the report parameters).

From (Maturity date) To (Maturity Date): The maturity date range of notes included in this report (if you specified a range in the report parameters).

Order By: The option you chose to sort information in this report.

Column Headings

Customer Name: The name of the customer for whom you created these notes.

Customer Site: The bill-to site for this customer.

Issuer Name/Issuer Bank Name: The name and bank of the note issuer.

Issue Date/Maturity Date: The date this note was issued and the note maturity date.

Note Number/Exchanged Note: The note number and the note that replaces it (if you exchanged this note).

Note Status: The status of this note.

Note Amount: The amount of this note.

Remittance Bank: The remittance bank for this note.

Remittance Bank Account: The remittance bank account for this note.

Row Headings

Total for Site: The total amount of notes for the customer site.

Total for Customer: The total amount of notes for the customer.

Report Total: The total amount of notes included in this report.

Reversed Notes Receivable Report

The Reversed Notes Receivable report lets you view information about your reversed notes receivable.

This report only includes notes that have the following statuses:

This report also includes notes that were created and then applied to a debit memo reversal. These notes have a status of Exchange.

Report Parameters

Currency: Enter the currency of the notes to include in this report. Leave this field blank to include all notes, regardless of their currency.

Customer Name: To include only notes that belong to a specific customer, enter a customer name. Leave this field blank to include notes for all customers.

Order By: Choose the method you want to use to sort information for this report. Choose Customer or Remittance Bank. This parameter is required.

Report Non-Exchanged Notes: Indicate whether you want to include notes for which a debit memo reversal was created but a new note has not yet been applied in this report. Choose either Yes or No.

Start Maturity Date/End Maturity Date: To include only notes within a range of maturity dates, enter a range of dates here. Leave this field blank to include all notes, regardless of their maturity date.

Start Reversal Date/End Reversal Date: To include only notes within a range of reversal dates, enter a range of dates here. Leave this field blank to include all notes, regardless of their reversal date.

Status: To include only notes with a specific status in your report, enter a status. Choose one of the following: Open, Exchange, Remitted, Factored, or Matured. Leave this field blank to include all notes, regardless of their status.

Report Headings

Currency: The currency of notes included in this report (if you specified a currency in the report parameters).

From (Maturity date) To (Maturity Date): The maturity date range of notes included in this report (if you specified a range in the report parameters).

Order By: The option you chose to sort information in this report.

Column Headings

Customer Name/Customer Site: The name and bill-to site of the customer for whom you created these notes.

Debit Memo/Exchange Note: If this note was exchanged, this column displays the debit memo number and the number of the note that you applied to this debit memo.

Issuer Name/Issuer Bank Name: The name and bank of the note issuer.

Issue Date/Maturity: The date this note was issued and the note maturity date.

Note Amount: The amount of this note.

Note Number: The note number.

Note Status: The status of this note.

Row Headings

Total for Site: The total amount of notes for this customer site.

Total for Customer: The total amount of notes for this customer.

Total for Receipt Method: The total amount of notes for this receipt method.

Report Total: The total amount of notes included in this report.

Using AutoLockbox

AutoLockbox (or Lockbox) is a service that commercial banks offer corporate customers to enable them to outsource their accounts receivable payment processing. An AutoLockbox operation can process millions of transactions a month.

AutoLockbox eliminates manual data entry by automatically processing receipts that are sent directly to your bank. You specify how you want this information transmitted and Receivables ensures that the data is valid before creating QuickCash receipt batches. You can automatically identify the customer who remitted the receipt and optionally use AutoCash rules to determine how to apply the receipts to your customer's outstanding debit items.

If you are using Oracle Trade Management, then during AutoLockbox and Post QuickCash processing, Receivables can automatically prepare eligible remittance lines for claim creation in Trade Management. See: How AutoLockbox Creates Claims.

You can also use AutoLockbox for historical data conversion. For example, you can use AutoLockbox to transfer receipts from your previous accounting system into Receivables. AutoLockbox ensures that the receipts are accurate and valid before transferring them into Receivables.

AutoLockbox is a three step process:

  1. Import: During this step, AutoLockbox reads and formats the data from your bank file into the AutoLockbox table using an SQL *Loader script.

  2. Validation: The validation program checks data in the AutoLockbox tables for compatibility with Receivables. Once validated, the data is transferred into QuickCash tables. At this point, you can optionally query your receipts in the QuickCash window and change how they will be applied before submitting the final step, Post QuickCash.

  3. Post QuickCash: This step applies the receipts and updates your customer's balances. See: Post QuickCash.

These steps can be submitted individually or at the same time from the submit Lockbox Processing window. After you run Post QuickCash, Receivables treats the receipts like any other receipts; you can reverse and reapply them and apply any unapplied, unidentified, or on-account amounts.

Note: AutoLockbox cannot process receipts that are not related to invoices. Process non-invoice related receipts, such as investment income, through the Receipts window using a receipt type of Miscellaneous.

Import

During the import step, Lockbox uses an SQL*Loader control file to import receipt information contained in the bank file into the AR_PAYMENTS_INTERFACE_ALL table. AutoLockbox uses the transmission format you specify in the Submit Lockbox Processing window to ensure that data is correctly transferred from the bank file into the AR_PAYMENTS_INTERFACE_ALL table. Transmission formats contain information such as the customer number, bank account number, the amount of each receipt to apply, and transaction numbers to which to apply each receipt. You can define your own transmission format or use one of two formats that Receivables provides. See: Transmission Formats, Oracle Receivables Implementation Guide.

Important: For SQL*Loader to load your bank file properly, each logical record that your bank sends to you must end with a carriage return; otherwise, SQL*Loader displays an error message when you submit AutoLockbox.

Validation

During the validation step, AutoLockbox ensures that no duplicate entries exist, the customer and receipt information is valid, the amount to apply does not exceed the receipt amount, and that columns in the AR_PAYMENTS_INTERFACE_ALL table reference the correct values and columns in Receivables. If the receipt and transaction currencies are different, AutoLockbox also requires specific application information and must be able to determine the exchange rate between the two currencies. See: Using AutoLockbox to Process Cross Currency Receipts.

Lockbox transfers the receipts that pass validation to the AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL interim tables in Receivables. Receipts that fail validation remain in the AR_PAYMENTS_INTERFACE table until you manually correct errors using the Maintain Transmission Data window. You can then resubmit just the validation step for these receipts using the Submit Lockbox Processing window. After a receipt is successfully imported into Receivables, you can apply, reverse, remit, or place it on account, just like a manually entered receipt. If you did not run Post QuickCash when you submitted AutoLockbox, you can review each receipt and optionally update their application information in the QuickCash window. See: AutoLockbox Validation.

Post QuickCash

When you submit Post QuickCash, the program tries to apply each receipt based on the information contained in the AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL tables. To be able to apply a receipt to a transaction, Post QuickCash must be able to determine the following:

The following illustration shows how receipt data from your bank file is imported into Receivables tables. The illustration also shows that Receivables generates the Import section when you submit the import step of AutoLockbox, and generates the Validation section when you submit the validation step of AutoLockbox. See Lockbox Execution Report. Receivables automatically generates the Post QuickCash Execution Report each time you submit Post QuickCash or AutoLockbox. See: Post QuickCash Execution Report.

Importing Data from your Bank File

the picture is described in the document text

Related Topics

How AutoLockbox Identifies Customers for a Receipt

How AutoLockbox Applies Receipts

How AutoLockbox Creates Claims

Running AutoLockbox

Commonly Asked Questions

Lockbox Interface Table and Column Descriptions, Oracle Receivables Reference Guide

AutoCash

AutoLockbox Validation

Receivables validates the data you receive from the bank to ensure that the entire file was received, there are no duplicate receipts within a batch, and that customers and invoices are valid.

AutoLockbox also validates all of your data for compatibility with Receivables. AutoLockbox validates your data by ensuring that the columns in AR_PAYMENTS_INTERFACE_ALL reference the appropriate values and columns in Receivables.

Duplicate receipts have the same receipt number, amount, currency, and customer number. AutoLockbox does not allow duplicate receipts within the same batch source for the same customer. This is the same validation Receivables performs when you manually enter receipts using the Receipts window.

Note: If proper controls are not in place, it is possible to reimport and reapply receipts that AutoLockbox has already processed. We recommend that you establish standard operating procedures to ensure that users do not process the same bank file more than once using AutoLockbox.

Invoice numbers are only required to be unique within a batch source. A customer can have duplicate invoice numbers as long as they belong to different batch sources; however, AutoLockbox cannot automatically apply a payment to these invoices.

If a customer has more than one invoice in the system with the same number, then AutoLockbox cannot determine to which invoice to apply the payment. The receipt will either be left as Unapplied (if the customer number or MICR number is provided) or Unidentified (if the customer number or MICR number is not provided).

However, you can manually apply a receipt(s) to these invoices in:

AutoLockbox completes the following validations:

Related Topics

Transmission Formats, Oracle Receivables Implementation Guide

Running AutoLockbox

Lockbox Execution Report

Commonly Asked Questions

How AutoLockbox Identifies Customers for a Receipt

AutoLockbox uses several methods to determine the customer for receipts that you import into Receivables. Depending upon your transmission format and how you set up your system, AutoLockbox can validate your customer data based on the following attributes or, if no match is found, import the receipt and assign it a status of Unidentified.

Customer Number

If you provide a customer number for receipts that you import through AutoLockbox, Receivables will try to apply the receipts using whatever application information is provided in your transmission format.

MICR Number

The MICR (Magnetic Ink Character Recognition) number that appears on each receipt relates your customer to a bank. Lockbox only uses MICR numbers to associate a customer with a receipt if both of the following are true:

An MICR number consists of two segments. The first segment is the transit routing number that is part of your Lockbox transmission format; this identifies the bank from which your customer draws their check. The second segment identifies your customer's account at that bank. Enter the transit routing number in the Bank Branch Number of the Banks window. Enter the customer account number in the Bank Account Number field of the Bank Accounts window.

Note: If a receipt is imported with a new MICR number, but AutoLockbox was able to identify the customer using another method, Receivables stores the new number for future reference.

AutoAssociate

If the customer cannot be identified from either the MICR number or the customer number (for example, if the transmission does not include this information), you can use AutoAssociate to determine the customer using matching numbers. A matching number can be a transaction number, balance forward bill number, sales order number, purchase order number or another, custom defined number. Your customer's remittance advice in the bank file must include matching numbers for Receivables to identify the customer using this method.

To use AutoAssociate:

If the MICR number or customer number is not included with a receipt record and AutoAssociate is set to No, Lockbox imports the receipt and assigns it a status of Unidentified. You can use the Receipts or Applications window to assign customers to unidentified receipts.

The AutoLockbox validation program will identify a customer for a receipt using the matching number only if all of the transactions listed to be paid by this receipt are associated with the same customer.

You can use the validation section of the Lockbox Processing Report to examine transactions that AutoLockbox could not apply to because the customer could not be uniquely identified. See: Lockbox Execution Report.

The table below shows examples of three separate AutoLockbox transmissions that include duplicate invoice numbers. Assume that in each transmission, AutoAssociate is set to Yes, the remitting customer is Customer ABC, and the receipt information includes the invoice number but not the customer name:

Receipt Information Invoice Number - Customer Identify Customer? Apply Receipt?
Invoice 101 101 - Customer ABC
102 - Customer ABC
Yes Yes
Invoice 101 101 - Customer ABC
101 - Customer ABC
Yes No
Invoice 101 101 - Customer ABC
101 - Customer XYZ (related to Customer ABC)
Yes Yes
Invoice 101 101 - Customer ABC
101 - Customer XYZ
No No

In the second example, Lockbox is able to identify the receipt because the invoices belong to the same customer. However, since the invoices have the same number, Lockbox cannot determine to which invoice to apply the receipt, so the receipt is left 'Unapplied'.

Note: Depending on your setup, Lockbox might create a claim for an unmatched remittance.

See: How AutoLockbox Creates Claims.

In the third example, Customer XYZ is related to Customer ABC and there are two invoices with the same invoice number. In this case, Lockbox will apply the receipt to the invoice that belongs to the remitting customer (Customer ABC) if the receipt record includes the customer or MICR number; otherwise, Lockbox assigns the receipt a status of Unidentified.

In the last example, two invoices with the same number exist for two different customers. Lockbox does not validate the receipt because it cannot determine how to apply the receipt. You can review receipts that failed the validation step in the Lockbox Execution Report. See: Lockbox Execution Report.

Associate Receipts with Billing Locations

Receivables also lets you track receipts for each of your customer's billing locations. To use this feature, you must include a billing location in your transmission format and ensure that the system option Require Billing Location for Receipts is set to Yes. Additionally, if you set this system option to Yes, Post QuickCash will create unidentified receipts for payments that do not have billing locations. If Require Billing Location for Receipts is Yes at the system options level, you should also set this option to Yes when defining your Lockboxes; otherwise, Receivables displays an error when you submit AutoLockbox. For more information, see: Miscellaneous System Options, Oracle Receivables Implementation Guide.

Related Topics

How AutoLockbox Applies Receipts

How AutoLockbox Creates Claims

Commonly Asked Questions

Receipts Without Sites Report

Lockboxes, Oracle Receivables Implementation Guide

How AutoLockbox Applies Receipts

Receivables applies the receipts in a Lockbox transmission when you submit Post QuickCash. You can either submit Post QuickCash when you run Lockbox or as a separate step after importing and validating your receipts. Post QuickCash updates your customer's balance using the information provided in your Lockbox transmission.

To successfully apply a receipt, AutoLockbox must know the name or number of the remitting customer and to which transaction(s) each receipt should be applied. If the Lockbox transmission includes both the customer name or number and the transaction(s) to which each receipt should be applied, AutoLockbox uses this information to apply the receipts during Post QuickCash. If customer information is not provided, you can set up your Lockbox to use matching rules to identify the remitting customer and partially or fully apply each receipt.

A Lockbox transmission usually includes matching numbers. These are most often transaction numbers, but they can also be other types of numbers, such as a purchase order or sales order number. To use matching rules, you need to specify a Match Receipts By method and set the AutoAssociate parameter to Yes when defining your Lockbox. The Match Receipts By method determines which type of number to search for during the validation step. When it finds a match, AutoLockbox identifies the customer using the information from the matched transaction and then applies the receipt during the final step, Post QuickCash.

If AutoLockbox cannot identify the customer or to which transaction to apply the receipt, it assigns the receipt a status of Unidentified.

If AutoLockbox identifies the customer for a receipt but cannot determine to which transaction this receipt should be applied, then AutoLockbox might create a claim, depending on your setup. See: How AutoLockbox Creates Claims.

If you did not define your lockbox to automatically create claims, or if you did but no remittance lines are eligible, then AutoLockbox applies the receipt using the AutoCash Rule Set defined for this customer.

AutoLockbox can also import and apply cross currency receipts. See: Using AutoLockbox to Import and Apply Cross Currency Receipts.

You can pay for another customer's invoices through AutoLockbox if you have set up a relationship between these customers or the system option Allow Payment of Unrelated Invoices is Yes for this Lockbox submission. The paying customer should be identified by a customer or MICR number on the receipt record. Otherwise, if you are using AutoAssociate when applying Customer A's receipt to Customer B's invoice, the receipt will be identified as paid by Customer B. Additionally, all invoices listed to be paid by one receipt must belong to the same customer; otherwise, Lockbox imports the receipts as 'Unapplied'.

If the Allow Payment of Unrelated Invoices option is No in the System Options window or for this Lockbox submission, you need to set up a relationship between the customers before you can make applications in this way. See: Defining and Updating Account Relationships.

You can also set up a party paying relationship. See: Using Party Paying Relationships.

Note: When applying a receipt to an invoice through AutoLockbox, AutoLockbox does not realize discounts. This is an operation of the Post QuickCash program..If the customer's credit profile and payment terms are set to Allow Discounts, Post QuickCash will automatically take the discount. The discount taken will also depend on how you set the Allow Unearned Discounts and Discount on Partial Payment system options. The discount can be manually overridden in the Receipts window.

Matching Rules

If the customer number or MICR number is not included in your transmission but AutoAssociate is set to Yes, AutoLockbox will try to identify the customer and to which transaction(s) each receipt should be applied based on whatever type of number is provided.

AutoLockbox always searches for the type of matching number in the following order:

  1. Transaction Number

  2. Sales Order Number

  3. Purchase Order Number

  4. Balance Forward Bill Number

  5. Other, user defined number

If the matched number is a sales order number, AutoLockbox searches for the first invoice that belongs to this order. Then, when you run Post QuickCash, the program will apply the receipt to that invoice.

If the matched number is a purchase order number, AutoLockbox searches for a reference number that refers to this purchase order. Then, when you run Post QuickCash, the program will apply the receipt to that invoice.

If the matched number is a balance forward bill number, AutoLockbox will be able to identify the customer and Post QuickCash will apply the receipt to the transactions included on the balance forward bill using the AutoCash rule Clear Past Due Invoices Grouped by Payment Term.

If the matched number is determined using a custom matching rule, Lockbox uses the rule that you specify to determine how to apply this receipt. See: Implementing a Custom Matching Rule.

Match Receipts By Option

When it finds an item with the same number and type as the current search, AutoLockbox checks the following locations for the Match Receipts By parameter, stopping when a value is found:

  1. Customer Bill-to Site

  2. Customer

  3. Lockbox

The setting of the Match Receipts By parameter must be the same as the current search for AutoLockbox to match a receipt with an open item.

For example, if AutoLockbox finds a matching transaction number in the first search, it checks the customer site for the Match Receipts By parameter. If the parameter is set to Transaction, AutoLockbox matches the receipt with this transaction and applies the receipt when you run Post QuickCash. If the setting at the customer site is a value other than Transaction, AutoLockbox searches for the next type of matching number (in this example, a sales order number). If the setting at the customer site is null, AutoLockbox checks the next location for the value of the Match By Receipts parameter (in this example, the customer profile).

Refer to the examples and the illustration below for more information.

Matching Rules Examples

Example 1: A receipt record indicates that a receipt should be applied to open debit item 12345. AutoLockbox first searches for a transaction (invoice, debit memo, chargeback) with this number. AutoLockbox finds an invoice with this number, so it checks the value of the Match Receipts By parameter at this customer's site. The Match Receipts By parameter is null for this customer's site, so AutoLockbox checks the setting in the customer's profile. Match Receipts By is set to Transaction in the customer's profile, so AutoLockbox matches the receipt with this invoice and will apply it to this transaction when you run Post QuickCash.

Example 2: Using the same receipt record information as Example 1, assume that AutoLockbox fails to find a transaction with the number 12345. The second time the program searches for a sales order with this number. AutoLockbox does not find a sales order with this number, so it now searches for a purchase order that has the number 12345. AutoLockbox finds purchase order 12345 in this transmission, so it checks the Match Receipts By parameter at the customer's site. The parameter is null at the customer's site, so the program checks the customer's profile. The parameter is also null in the customer's profile, so AutoLockbox checks the parameter for this Lockbox. The Match Receipts By parameter is set to Purchase Order Number for this Lockbox, so the program matches the receipt with this purchase order and will apply it to this transaction when you run Post QuickCash.

If AutoLockbox cannot find a match after searching for each type of number in the sequence, it applies the receipt using the AutoCash rule set defined for this customer. See: AutoCash Rules.

If the AutoCash rule set is unable to apply the receipt, AutoLockbox assigns it a status of Unapplied. You must then manually apply the receipt in the QuickCash or Applications window.

Note: Depending on your setup, Lockbox might create a claim for an unmatched remittance.

See: How AutoLockbox Creates Claims.

Match on Corresponding Date

The Match on Corresponding Date option for your Lockbox determines whether AutoLockbox should also check the transaction date before matching receipts with transactions. For example, if the matching number is a sales order number and Match on Corresponding Date is set to Always, the sales order date must be the same as the date specified in your receipt record for Lockbox to apply the receipt. See: Lockboxes, Oracle Receivables Implementation Guide.

AutoCash Rules

Post QuickCash uses AutoCash rules to apply any identified receipts that could not be applied using matching rules. To use AutoCash rules to apply receipts imported using Lockbox, be sure that you:

If you submit Post QuickCash as a separate step, you can review each unapplied receipt in the QuickCash window. Receivables displays 'AutoCash Rule' in the Application Type field to indicate that it will be using AutoCash rules to apply your receipts when you run Post QuickCash.

Overapplying Invoices

To allow overapplication using AutoLockbox, set the profile option AR: Allow Overapplication in Lockbox to Yes. If this profile option is set to Yes and the transaction type of the debit item allows overapplication, AutoLockbox applies the receipt and, if the payment exceeds the balance due, changes the sign of the debit item.

For example, AR: Allow Overapplication in Lockbox is set to Yes and Post QuickCash applies a $50 payment to a $25 invoice. If the transaction type allows overapplication, Post QuickCash applies the entire amount and the invoice balance due changes to -$25. If the transaction type does not allow overapplication or the profile option is set to No, Post QuickCash applies $25 of the receipt (closing the invoice) and leaves the remaining amount unapplied.

Note: If the transaction type does not allow overapplication or the profile option is set to No, and you are using Oracle Trade Management to track and resolve claims, then Post QuickCash applies $25 of the receipt (closing the invoice) and creates a claim for the remaining amount.

See: How AutoLockbox Creates Claims.

Note: You cannot overapply a receipt to an open debit item using AutoCash rules.

Important: If the sign of your application is different from the sign of the balance due on your invoice, Post QuickCash does not apply the receipt. In this case, the entire receipt amount remains unapplied.

Applying Remaining Amounts

If part of a receipt is left unapplied, you can control whether it remains unapplied or if AutoLockbox applies it using AutoCash Rules. To apply remaining amounts in a Lockbox transmission using AutoCash Rules, specify a Remainder Rule Set in the remitting customer's profile class. To import receipts with remaining amounts as Unapplied, leave the Remainder Rule Set field blank. See: Assigning Profile Classes to Customers, Oracle Receivables Implementation Guide.

Application Rule Sets

Post QuickCash uses the Application Rule Set assigned to the debit item's transaction type to determine how to apply payments and how discounts affect the open balance of any associated charges (such as lines, freight, and tax). If no rule set is assigned to this item's transaction type, Post QuickCash uses the rule set defined in the System Options window. See: Receivables Application Rule Sets.

Receipt Status

Lockbox assigns a status to each receipt that you import into Receivables depending on the information included in your transmission:

Related Topics

How AutoLockbox Identifies Customers for a Receipt

How AutoLockbox Creates Claims

AutoCash

Automatic Receipts

Post QuickCash

AutoLockbox Validation

Commonly Asked Questions

Transmission Formats, Oracle Receivables Implementation Guide

Lockboxes, Oracle Receivables Implementation Guide

Importing and Applying Cross Currency Receipts

Implementing a Custom Matching Rule

Receivables supplies the packaged procedure arp_lockbox_hook.cursor_for_matching_rule which you can use to add your own custom matching rule with AutoLockbox. You can use this feature if, for example, you need to match matching numbers and dates passed to Lockbox with numbers and dates in your own custom tables (custom_table.custom_number and custom_table.custom_date) instead of or in addition to standard matching options. You can also use this feature to match with other numbers and dates in the existing Receivables tables.

This procedure expects a row in the AR_LOOKUPS table with lookup_type = ARLPLB_MATCHING_OPTION and valid values for other columns required for using a customized matching rule. The master program arp_process_lockbox will fetch that row and - if it finds it to be one of the non-standard (i.e. not built in core AR) rows - it will pass the control to this procedure with the corresponding lookup_code in your database. The procedure should return a string that Dynamic SQL can use to open and parse a cursor. You need to create this SQL string to replace the string named p_cursor_string (see example below).

Your string should have the following restrictions:

  1. You should only use the following bind variables:

    a. b_current_matching_number - This will get a value of a matching_number passed in the overflow or payment record.

    b. b_current_matching_date - This will get a value of a matching_date passed in the overflow or payment record.

    c. b_current_installment - This will get a value for the installment number (if any) passed in the overflow or payment record.

    d. b_customer_id - If the customer is identified using a customer number or an MICR number, the program will enforce that the matching_number is for the same customer (except if the value is 'Y' in b_pay_unrelated_customers).

    e. b_pay_unrelated_customers - When you submit AutoLockbox, the program prompts you to choose whether to allow payments for unrelated customers. This variable will get a value 'Y' or 'N' based on the value that you choose.

    f. b_lockbox_matching_option - The value of this variable will match to the value of ar_lookups.lookup_code. It is also stored in ar_customer_profiles.lockbox_matching_option and in ar_lockboxes.lockbox_matching_option.

    g. b_use_matching_date - This variable will be assigned a value NEVER, ALWAYS, or FOR_DUPLICATES, depending upon the value of the Match on Corresponding Date option for your lockbox (in ar_lockboxes).

  2. If you are customizing AutoLockbox using this procedure, be sure that this procedure returns a string that can create a valid cursor and that the SQL returns one and only one row (neither zero nor more than one).

  3. The program expects three return values from the SQL statement in the following order:

    1. Customer_Id (NUMBER(15))

    2. Invoice Number (VARCHAR2(20))

    3. Invoice Date (DATE)

  4. The program expects that the combination of invoice number and invoice date is unique in ar_payment_schedules.

  5. You do not have to use all the bind variables that are provided in your SQL statement. For example:

    p_cursor_string := 'select ct.customer_id, ct.trx_number, ct.trx_date ' ||
              'from custom_table ct ' ||
              'where ct.matching_number = :b_current_matching_number ' ||
              'and ct.matching_date = :b_current_matching_date 
              ';
  6. If the SQL statement does not match with the given matching number and matching date (optional), the statement must return the following:

    customer_id = -9999,
    trx_number = null,
    trx_date = null.
  7. If the statement matches to multiple customers but the same trx numbers, it must return customer_id = -7777. The procedure will ignore trx_number and trx_date in this case.

    Note: The program calling this procedure does not expect it to return any errors because the definition of a cursor is a one-time procedure and, if done carefully, should not error.

    Below is the packaged procedure arp_lockbox_hook.cursor_for_matching_rule that Receivables provides:

    ---------------------------------------------------------*/
    PROCEDURE CURSOR_FOR_MATCHING_RULE(p_matching_option IN VARCHAR2,p_cursor_string OUT VARCHAR2) IS
    BEGIN
    arp_util.debug('arp_lockbox_hook.cursor_for_matching_rule()+');
    p_cursor_string := 'select -9999, NULL, NULL from dual';
    arp_util.debug('arp_lockbox_hook.cursor_for_matching_rule()+');
    RETURN;
    END cursor_for_matching_rule;
    END arp_lockbox_hook;
    COMMIT;
    EXIT;
    

    For more information about setting up Lockbox to use a custom matching rule, refer to the files $AR_TOP/admin/sql/ARRLBHKS.pls and $AR_TOP/admin/sql/ARRLBHKB.pls.

How AutoLockbox Creates Claims

You can track your customers' overpayments and short payments as claims.

AutoLockbox can initiate claim creation for eligible remittances. Claim creation, along with claim tracking and resolution, actually occurs in Oracle Trade Management. See: Working with Claims.

You can initiate claim creation:

This section describes automatic claim creation via AutoLockbox.

Prerequisites

Unmatched Remittance Lines

Your claims system options indicate the type of unmatched remittance lines, positive or negative, that AutoLockbox creates claims for.

If an unmatched remittance line is eligible for claim creation, then AutoLockbox creates a noninvoice-related claim by applying the remittance line against the Claim Investigation application type. Trade Management receives the claim when you run Post QuickCash. See: QuickCash.

Note: Unapplied receipt balances are not considered unmatched, and therefore do not cause claim creation.

For each claim, AutoLockbox copies the following items to the claim investigation line:

If the remittance line is not eligible for claim creation, then AutoLockbox handles the receipt according to the lockbox setting for Invalid Transaction Number Handling. See: Lockboxes, Oracle Receivables Implementation Guide.

Unmatched cross currency remittance lines

When evaluating an unmatched remittance line for claim creation, AutoLockbox always assumes that the currency of the line matches that of the receipt header.

Matched Remittance Lines

Your claims system options also indicate whether or not AutoLockbox should create claims for matched remittance lines.

You can set up your system so that AutoLockbox considers all matched remittance lines for possible claim creation. Or, you can choose to exclude short payments of credit memos from consideration.

AutoLockbox evaluates matched remittance lines for claim creation by reviewing each remittance line's matched transaction. AutoLockbox creates a claim if:

Natural Application

Natural application refers to the type of application, either positive or negative, that brings a transaction's balance closer to zero. See: Transaction Types, Oracle Receivables Implementation Guide.

The AutoLockbox validation program confirms that imported remittance lines do not violate their matched transactions' Natural Application rule. If a violation does occur, then AutoLockbox reassigns the remittance line to the Claim Investigation application type.

For example, an invoice has a positive balance and is assigned a transaction type with the Natural Application Only box selected. You can apply only a negative application to this invoice.

If, however, AutoLockbox matches a remittance line to this invoice that actually increases the invoice balance, then the validation program will update the remittance line to a Claim Investigation application.

Note: AutoLockbox copies the original matched transaction number to the Application Notes for the receipt as well as to the Customer Reference column on the claim investigation line.

Overapplication

Overapplication occurs when you apply a $500 receipt, for example, to a $400 invoice. This application overapplies the invoice and reverses the invoice's sign (from positive to negative).

You can set the Allow Overapplication setting on a transaction type to disallow overapplication. See: Transaction Types, Oracle Receivables Implementation Guide.

If an application would violate its matched transaction's Allow Overapplication setting, then AutoLockbox marks the remittance line with an Overapplication Indicator. After you import receipts, you can optionally correct the overapplication in the QuickCash window before you run Post QuickCash.

If the overapplication violation still exists when you run Post QuickCash, then Post QuickCash fully applies the transaction, and creates a claim investigation line for the overpayment amount.

Note: If the AR: Allow Overapplication in Lockbox profile option is No, yet the Evaluate for Claims Eligibility box is selected, then AutoLockbox will allow remittance lines that overapply their matched transactions into QuickCash, but only for overapplication violations.

Related Topics

Using AutoLockbox

Working with Claims

Maintaining Lockbox Transmission Data

Importing and Applying Cross Currency Receipts

You can use AutoLockbox to import and apply receipts when the currencies of the receipt and the transaction are different. For example, your functional currency is the US dollar, and you create invoices for your customers in that currency. However, you have many international customers, so you need to accept payments in different currencies. AutoLockbox can import and apply cross currency receipts for each currency defined in your system.

You can also use AutoLockbox to import receipts and apply euro receipts to transactions denominated in former National Currency Units of the euro. AutoLockbox also supports euro to predecessor currency applications, and vice versa.

Floating and Fixed Rate Relationships

Currencies that have a "floating" relationship do not have an established exchange rate. Floating exchange rates change frequently and can vary considerably from one day to the next. The US dollar and the Japanese yen, for example, have a floating exchange rate. To apply a receipt when the receipt and transaction currencies are different and do not have a fixed relationship, AutoLockbox requires that application and exchange rate information be provided in your bank transmission file.

Currencies with a "fixed" relationship have an established, non-fluctuating exchange rate. For example, when EMU currencies were abolished and replaced by the euro in 1999, the former currencies were used as National Currency Units (NCU) of the euro. These NCUs had a fixed exchange rate with the euro until December 31, 2002 when they were abolished. To process euro and NCU transactions using AutoLockbox, you must define fixed exchange relationships using the official European Union fixed rates.

Defining Fixed Exchange Rate Relationships

Before using AutoLockbox to process euro receipts and transactions, you need to define a fixed rate relationship between the euro and each NCU in which you do business. You do not need to define fixed relationships between NCUs: Oracle's currency engine and the features that use it, such as AutoLockbox, fully support the concept of Triangulation during the euro transitional period. AutoLockbox uses fixed exchange rates for the following types of cross currency applications:

Transmission File Format - Required Values

AutoLockbox uses the following field types in the bank transmission file to apply cross currency receipts:

The formula AutoLockbox uses to apply a cross currency receipt is shown below:

Transaction Amount Applied * Exchange Rate = Receipt Amount Applied

If the receipt and transaction currencies have a fixed rate relationship, AutoLockbox can apply the receipt regardless of whether the bank file has only one or two of these values or all of them.

If the receipt and transaction currencies do not have a fixed rate relationship, AutoLockbox must either have the exchange rate or be able to determine it to apply the receipt. For example, the exchange rate is not included in the transmission file for two currencies that do not have a fixed rate. If the amount_applied and amount_applied_from are included, AutoLockbox can calculate the missing exchange rate. If the exchange rate and one of the other values is missing, AutoLockbox checks the setting of the Cross Currency Rate Type system option and either derives the rate (and the missing value) or rejects the receipt. See: Cross Currency Rate Type.

This table shows how AutoLockbox responds to different combinations of information provided in the bank transmission file.

Information Provided in Transmission File Action Result
Transaction Amount Applied, Receipt Amount Applied, and Exchange Rate Validate that all values are correct. If all values are correct, apply the receipt; otherwise, reject the application.
Transaction Amount Applied and Receipt Amount Applied Calculate the exchange rate to use or derive it from General Ledger. Apply the receipt.
(Fixed rate relationship) Exchange Rate, Transaction Amount Applied, or Receipt Amount Applied Calculate the missing value(s). Apply the receipt.
(No fixed rate relationship) Exchange Rate AND either the Transaction Amount Applied or the Receipt Amount Applied Calculate the missing value. Apply the receipt.
(Fixed rate relationship) Transaction Amount Applied OR the Receipt Amount Applied Derive fixed exchange rate and then calculate the missing value. Apply the receipt.
(No fixed rate relationship) Transaction Amount Applied OR the Receipt Amount Applied Check AR: Cross Currency Rate Type profile option. If rate is defined, use it to apply the receipt; otherwise, reject the receipt.

See: Transmission Formats, Oracle Receivables Implementation Guide.

Cross Currency Rate Type

The Cross Currency Rate Type system option determines the exchange rate type that AutoLockbox uses to apply cross currency receipts when all of the following are true:

If the Cross Currency Rate Type system option is not defined, then AutoLockbox rejects receipts matching this criteria.

To define a rate for this system option, see: Accounting System Options, Oracle Receivables Implementation Guide.

Cross Currency AutoLockbox Validation

If the transmission file includes the exchange rate and the amount to apply in both the receipt and transaction currencies, AutoLockbox ensures that the amounts are consistent before importing the receipt. If the amounts are not correct, AutoLockbox rejects the receipt.

AutoLockbox ensures that the following calculations are true:

 amount_applied * trans_to_receipt_rate = amount_applied_from
 amount_applied_from / trans_to_receipt_rate = amount_applied

Note: AutoLockbox also rejects duplicate receipts. AutoLockbox considers receipts to be duplicates if they have the same receipt number, amount, currency, and customer number. See: AutoLockbox Validation.

QuickCash Window

You can use the QuickCash window to enter cross currency receipts and application information. The QuickCash window displays the Amount Applied and Allocated Receipt Amount fields to help you apply cross currency receipts. You can apply both manually entered and imported cross currency receipts in the QuickCash window.

Like the Applications window, the QuickCash window provides defaulting logic to help you enter information and reduce manual errors. For more information, see: Applying Cross Currency Receipts - Examples and QuickCash.

Tip: Define the Cross Currency Rate Type system option. This system option determines the default exchange rate type that the QuickCash window uses when the receipt and transaction currency are different and the two currencies do not have a fixed rate relationship. See: Accounting System Options, Oracle Receivables Implementation Guide.

Rounding Remittance Amounts

The method your customer uses to sum payment amounts in the bank transmission file can effect whether AutoLockbox fully applies a cross currency receipt.

Consider the following example:

1 EUR = .860956 USD

Your customer has three invoices, each for 1000 EUR. The customer adds the invoice amounts and then converts the total to USD. The result is shown below:

 Transaction * Rate = Amount (in receipt currency)
 3,000.00 EUR * .860956 = 2,582.87 USD (rounded)

Although this method is mathematically correct, AutoLockbox calculates remittance amounts differently. AutoLockbox calculates remittance amounts using the following procedure:

  1. Convert each transaction to the receipt currency.

  2. Add the amounts in the receipt currency.

  3. Remit the sum as the amount_applied_from.

The result of this method (using the values from the previous example) is shown below:

 Transaction * Rate = Amount (in receipt currency)
 1,000.00 EUR * .860956 = 860.96 USD (rounded)
 1,000.00 EUR * .860956 = 860.96 USD (rounded)
 1,000.00 EUR * .860956 = 860.96 USD (rounded)
 Total = 2,582.88 USD

As you can see, the receipt amount (amount_applied_from) in the bank transmission file is 2582.87, but AutoLockbox calculates it as 2582.88. As a result of this discrepancy, AutoLockbox leaves .01 unapplied and one of the invoices remains open. To avoid situations like this, we recommend that you establish business procedures with your customers to ensure that remittance amounts are calculated using the same method as AutoLockbox.

Rounding Differences

Rounding differences are not uncommon when processing cross currency receipts between currencies. These errors occur because there are usually more decimal places defined for an exchange rate than for the standard precision for your functional currency. When a receipt amount is multiplied by an exchange rate and then rounded to match your standard precision, the result can be slightly different from the transaction amount specified in the transmission file.

Receivables records rounding errors in the Cross Currency Rounding Account. You define a Cross Currency Rounding Account in the System Options window. See: Accounting System Options, Oracle Receivables Implementation Guide.

Foreign Exchange Gains and Losses

Due to fluctuating exchange rates, it is possible to incur either a foreign exchange gain or loss whenever you apply a cross currency receipt. These gains and losses occur when the exchange rate between the two currencies changes after the invoice is created but before the receipt is applied. For more information, see: Calculating the Foreign Currency Exchange Gain or Loss.

Receivables records foreign exchange gains and losses in the Realized Gains and Realized Losses accounts. You define these accounts in the System Options window. See: Accounting System Options, Oracle Receivables Implementation Guide.

Related Topics

Transmission Formats, Oracle Receivables Implementation Guide

Alternate Name Receipt Matches Window

You can use the Submit Lockbox Processing window to import bank files that are in the Japanese Zengin format. Unlike some bank files, you cannot select import, validate, and post Zengin files in a single step. You need to import the data, match and confirm receipts with customers in the Lockbox Transmission Data window, and then return to the Submit Lockbox Processing window to validate and post the records. Receivables provides a sample control file called arzeng.ctl you can use to import bank files in the Zengin format. See: Transmission Formats, Oracle Receivables Implementation Guide.

When you match Zengin receipts with customer information, Receivables updates the Alternate Names table so it can automatically match receipts for these customers the next time you run AutoLockbox. The Alternate Name Matches window lets you remove this information from the Alternate Names table if, for example, this information is no longer valid.

Deleting information in this window only removes the record from the Alternate Names table; it does not delete the customer's name, number, or any other information from Receivables.

Note: The records in the Alternate Names table are not the same as the Alternate Name you can assign to a customer using the Customers window. The records in the Alternate Names table originate from the bank file you imported using AutoLockbox, and are simply alternative customer names often used by Japanese businesses.

For more information about the Alternate Name Receipt Matches window and importing Zengin format files using AutoLockbox, see: Using AutoLockbox, Oracle Financials for Asia/Pacific User Guide.

Related Topics

Using AutoLockbox

Lockbox Execution Report

AutoLockbox Field Reference

Commonly Asked Questions

When applying a receipt to an invoice through AutoLockbox, will the Post QuickCash program automatically take the discount?

AutoLockbox does not realize discounts. This is an operation of the Post QuickCash program.

If the customer's credit profile and payment terms are set to 'Allow Discounts', Post QuickCash will automatically take the discount. The discount taken will also depend on the system options Allow Unearned Discounts and Discount on Partial Payment. The discount can be manually overridden in the Receipts window.

Can you process non-invoice related receipts through AutoLockbox?

No. AutoLockbox is specifically for invoice related receipts. Non-invoice related receipts, such as investment income, must be processed through the Receipts window using a receipt type of Miscellaneous. See: Entering Miscellaneous Receipts.

Can one customer pay for another customer's invoices through AutoLockbox?

Yes, if you have set up a relationship between these customers or the system option Allow Payment of Unrelated Invoices is Yes for this Lockbox submission. The paying customer should be identified by a customer or MICR number on the receipt record. Otherwise, if you are using AutoAssociate when applying Customer A's receipt to Customer B's invoice, the receipt will be identified as paid by Customer B. Additionally, all invoices listed to be paid by one receipt must belong to the same customer; otherwise, Lockbox imports the receipts as 'Unapplied'.

If the Allow Payment of Unrelated Invoices option is No in the System Options window or for this Lockbox submission, you need to set up a relationship between the customers before you can make applications in this way. See: Defining and Updating Account Relationships.

You can also set up party paying relationships. See: Using Party Paying Relationships.

How could trimming cause my receipts to display as unidentified?

Receipts are identified by a customer number or MICR number being passed as part of the bank record. They can also be identified by the invoice number when AutoAssociate is used. If this information is supplied, and most of the receipts still show as unidentified, it is usually a problem with how the customer number, MICR number, or invoice number is being trimmed during validation. Trimming is done to remove blanks or zeros used to pad data fields from the bank's data file. Your Transmission Format determines how a field will be trimmed. You must specify whether the field is right or left justified, and then identify the trim character to be a zero or blank. If the field is right justified, the validation process trims the fill characters from the left until it reaches a non-fill character. If the field is left justified, the validation process trims the fill characters from the right until it reaches a non-fill character.

Here are some examples:

This table illustrates how trimming occurs with the settings Character Field, 10 characters long, Right Justified, Zero Filled:

Before Trimming After Trimming
1122000000 1122000000
1234067000 1234067000
0004560000 4560000

This table illustrates how trimming occurs with the settings Character Field, 10 characters long, Left Justified, Zero Filled:

Before Trimming After Trimming
1122000000 1122
1234067000 1234067
0004560000 000456

Incorrect trimming can cause a receipt to be unidentified because an incorrectly trimmed field will not match the corresponding database field during validation. For example, if the customer number should appear as 00842 after validation, but it appears as 842, it will not match customer number 00842 in Receivables. The trim specifications in the above example are "right justified and zero filled", because the leading zeros are being trimmed until a non-fill character (8) is encountered. To have the customer number appear as 00842 after validation you can modify the fill character to be "blank" and the leading zeros will not be trimmed.

When does AutoLockbox consider a receipt to be a duplicate?

Duplicate receipts have the same receipt number, amount, currency, and customer number. AutoLockbox does not allow duplicate receipts within the same batch source for the same customer. This is the same validation Receivables performs when you manually enter receipts using the Receipts window.

Note: If proper controls are not in place, it is possible to reimport and reapply receipts that AutoLockbox has already processed. We recommend that you establish standard operating procedures to ensure that users do not process the same bank file more than once using AutoLockbox.

When does AutoLockbox consider an invoice to be a duplicate?

Invoice numbers are only required to be unique within a batch source. A customer can have duplicate invoice numbers as long as they belong to different batch sources; however, AutoLockbox cannot automatically apply a payment to these invoices.

If a customer has more than one invoice with the same number within a Lockbox transmission, then AutoLockbox cannot determine to which invoice to apply the payment. The receipt will either be left as Unapplied (if the customer number or MICR number is provided) or Unidentified (if the customer number or MICR number is not provided).

However, you can manually apply a receipt(s) to these invoices in:

What causes an application to be invalid?

Sometimes the AutoLockbox Execution Report will show receipts rejected with error code 43281: Receipt has invalid applications. Your application is invalid if:

  1. The receivable item belongs to a customer that is not related to the customer who remitted the receipt and Allow Payment of Unrelated Invoices is set to No.

  2. The receivable item is not an invoice, a debit memo, a deposit, a credit memo, a chargeback, or an on-account credit.

  3. The receivable item is a duplicate or invalid for the customer.

  4. The receivable item has been selected for automatic receipt.

  5. The installment number or the receivable item is invalid.

AutoLockbox uses the same reasons to invalidate an application as the standard receipt entry windows.

How does AutoLockbox divide receipts into batches?

AutoLockbox uses four criteria for dividing receipts into batches. They are listed in order of precedence as follows:

1) A batch can only have one deposit date or GL date. So, if AutoLockbox encounters a change in the deposit date or the GL date, it will create a new receipt batch.

2) A batch can have only one batch name. So, if a new batch name is encountered, AutoLockbox will create a new receipt batch.

3) You can specify the maximum size of a batch in the Lockboxes window. If the number of receipts exceeds this maximum, AutoLockbox will create a new receipt batch.

4) The bank can provide batch records as part of the data file, which divide the receipts into batches.

A group of receipts will be processed as one batch if:

Related Topics

Running AutoLockbox

Running AutoLockbox

Run AutoLockbox to submit your lockbox transmission processes and transfer payment information from your bank files into Receivables. Submit AutoLockbox from the Submit Lockbox Processing window.

Use AutoLockbox to import your invoice-related receipts. You must process non-invoice related receipts (such as investment income) through the Receipts window using a receipt type of 'Miscellaneous.'

You can import, validate, and run AutoLockbox all in one step, or perform the steps separately using the same window. For example, you can import data into Receivables and review it before validating it within Receivables. Upon examination and approval, you can submit the validation step and Receivables will automatically validate your data and create QuickCash receipt batches.

Caution: When you receive your bank file, be sure to name the file and move it to the appropriate directory. You will need to specify the location of your bank file when you submit AutoLockbox. If you receive daily files from your bank, be careful not to overwrite the files from the previous day.

Caution: If proper controls are not in place, it is possible to reimport and reapply a receipt that AutoLockbox has already processed. We recommend that you establish standard operating procedures to ensure that users do not process the same bank file more than once using AutoLockbox.

Receivables uses SQL*Loader to load information from your bank files into AutoLockbox tables. For SQL*Loader to load your bank file properly, each logical record that your bank sends to you must end with a carriage return; otherwise, SQL*Loader displays an error message when you initiate AutoLockbox.

Important: If you are using the automatic receipts feature, AutoLockbox ignores all transactions in this transmission that are selected for automatic receipt (i.e. transactions assigned to a receipt class with an Automatic Creation Method).

If you are using Oracle Trade Management, then you can set up AutoLockbox to automatically initiate claim creation in Trade Management. See: How AutoLockbox Creates Claims.

Prerequisites

To run AutoLockbox:

  1. Navigate to the Submit Lockbox Processing window.

  2. If you are importing a new bank file, check the New Transmission check box, then enter a new Transmission Name. If you are resubmitting an existing lockbox transmission, you can select a name from the list of values.

  3. To import a new bank file into Receivables, check the Submit Import check box, then enter your bank file's Data File, Control File, and Transmission Format information. When you run the import step, Receivables automatically generates the import section of the Lockbox Execution Report.

    Important: You must enter the file extensions in the data file field. For example, /home/ar/lockbox/bofa9101.dat

  4. In the Alternate Name Search field, select Manual or Automatic if you are importing a bank file with a Japanese Zengin character set. Otherwise, select None.

    The default value is None.

  5. Optionally select a transaction code from the list of values in the Transaction Code field.

    Important: To view the Transaction Code field in the Submit Lockbox Processing window, enable the Enable Transaction Code profile option. See: Profile Options in Oracle General Ledger, Oracle Receivables Implementation Guide. Additionally, you must check the Submit Import check box to activate this field.

    Receivables uses the transaction code that you select as the default transaction code for all payment and application records included in this lockbox transmission. After the import phase, you can review and update each transaction code in the Lockbox Transmission Data window. See: Maintaining Lockbox Transmission Data.

    This feature is available only in public sector installations.

  6. To validate or revalidate imported data and create QuickCash receipt batches, perform the following:

    a. Check the Submit Validation check box.

    Important: If you check the Submit Validation check box, you can view only the transaction codes that fail validation in the Lockbox Transmission Data window. Therefore, if you want to review all the transaction codes in the Lockbox Transmission Data window, do not check the Submit Validation check box until after the transaction codes are reviewed.

    Transaction codes are available only in public sector installations.

    b. Enter the Lockbox Number to validate. If this is not a new transmission, the default lockbox number is the number used for the original step of this transmission. If you specified Lockbox Number as a value to be imported from the bank file when you defined your transmission format, or if the transmission format shows that a number already exists, Receivables skips this field. You must enter a lockbox number if Submit Validation is Yes and the lockbox number is not specified in your bank file.

    c. To apply receipts to transactions belonging to unrelated customers, check the Allow Payment of Unrelated Invoices check box.

    d. Enter the date to post the receipt and batch records in this lockbox transmission to your general ledger in the GL Date field. If you defined your GL Date as 'Constant Date' in the Lockboxes window, you must enter a GL Date; if you specified a GL Date of 'Deposit Date' or 'Import Date', Receivables uses this as the GL date.

    e. Enter a Report Format. When you submit the validation step, Receivables creates the Lockbox Processing Validation report. This report lets you review all records that pass and fail validation. Enter 'All' to include all records processed in this transmission. Enter 'Rejects Only' to include only records that failed validation. See: Lockbox Execution Report.

    Note: Use the Maintain Lockbox Transmission data window to review and edit records that fail validation. See: Maintaining Lockbox Transmission Data.

    f. To transfer only the lockbox batches in which all records pass the validation step to the QuickCash tables, check the Complete Batches Only check box. If you do not check this check box, Receivables will transfer any receipts within a batch that pass validation, even if others are rejected.

  7. If the Post Partial Amount as Unapplied box is checked, Lockbox will import a receipt that is listed to be applied to several invoices, even if one or more of the invoices are invalid and Lockbox could not apply to them. In this case, Lockbox transfers the receipt into QuickCash with an unapplied amount, and you can then manually apply payment to a valid invoice(s) using the Applications window.

    Note: When AutoLockbox imports a receipt with an unapplied amount into QuickCash, Receivables retains the invalid matching numbers in the Application Notes field in the Receipt History window. You can also display the Application Notes field in the Receipts Summary or QuickCash windows by choosing Show Field from the Folder menu.

    If the Reject Entire Receipt box is checked and AutoLockbox encounters an invalid transaction number, the receipt that Lockbox cannot fully apply will remain in the AR_PAYMENTS_INTERFACE_ALL table. In this case, you need to edit the invalid record(s) in the Lockbox Transmission Data window, then submit the Validation step again for the receipt.

  8. To apply receipts in this transmission and update your customer's receivable balance, check the Submit Post QuickCash box. Do not check this box if you want to review and edit your receipt batches in the QuickCash window before applying them to your customer's open debit items. See: Reviewing Receipts in a Lockbox Transmission.

    Note: You can also submit Post QuickCash from the Receipt Batches window. See: Post QuickCash.

  9. Save your work. Receivables displays the Request ID of your concurrent process and generates the Lockbox Execution report. See: Lockbox Execution Report.

    The request ID assigned when you first import a new bank file is associated with this lockbox transmission throughout all steps. Use this request ID to check the status of a transmission in the View Transmission History window.

Reviewing Receipts in a Lockbox Transmission

After you successfully import and validate your receipts using Lockbox, you can review them in the QuickCash window. Use the Transmission region in the Receipt Batches window to query all receipt batches that were included in one transmission and to update or delete any receipt information.

You can review Lockbox receipts before or after you run Post QuickCash. If you submitted Post QuickCash for this lockbox transmission, you can review these receipts only in the Receipts or the Adjustments window. See: Running AutoLockbox.

You can review receipts that failed the validation step in the Lockbox Transmission Data window. See: Maintaining Lockbox Transmission Data.

Note: Lockbox receipt batches have a Batch Type of Manual-Quick.

To review validated receipts in a lockbox transmission:

  1. Navigate to the Receipt Batches or the Receipt Batches Summary window.

  2. Query the batch. You can query by Transmission, Lockbox, or Batch Name.

  3. Choose Receipts.

Related Topics

Maintaining Lockbox Transmission Data

AutoLockbox Field Reference

Lockbox Execution Report

Using AutoLockbox

Commonly Asked Questions

AutoLockbox Field Reference

This section provides a brief description of some of the fields in the Submit Lockbox Processing, Lockbox Transmission Data, and Lockbox Control windows. To open the Lockbox Control window, navigate to the Lockbox Transmission Data window, then choose Control.

Alternate Name Search: (Submit Lockbox Processing window) Indicates whether you can transfer bank information in the Zengin file format into Receivables (Zengin is the standard file format for bank transfers in Japan). Instead of using a customer number or invoice number to identify which customer remitted payment, the Zengin format uses "alternate names" to match customers with receipts. An alternate name is usually the customer's phonetic name spelled with Japanese Kana characters. Your choices are:

Bank Origination Number: (Lockbox Control window) The bank origination number of the bank that transmitted this lockbox file. Receivables determines the Bank Origination number from the remittance bank account you entered in the Lockboxes window.

Control File: (Submit Lockbox Processing window) Receivables uses SQL *Loader to load information from your operating system files into the Receivables database. The control file is used by SQL *Loader to map the data in the bank file to tables and columns in the Oracle database. You need to create a control file for each bank file that uses a different transmission format. For SQL *Loader to load your bank file properly, each logical record that your bank sends to you must end with a carriage return. If each record does not end with a carriage return, SQL *Loader displays an error message when you submit AutoLockbox.

Tip: If you are using Receivables Multiple Organizations Support feature, we recommend that you create a different control file for each of your organizations. Each control file should populate the default org_id column for that organization in the ar_payments_interface table. Additionally, if your existing control files use the date format 'YY' for the year, we recommend that you change this to 'RR'.

Important: You must store the control file in your $AR_TOP/bin directory with an extension of .ctl. When you enter a control file name in the Submit Lockbox Processing window, you do not need to enter the path or the extension of the control file. For example, if your control file is in $AR_TOP/bin and is named bankabc.ctl, you just need to enter bankabc in the control file field to submit the file successfully.

Data File: (Submit Lockbox Processing window) The path name and the filename of the bank file you are transferring into Receivables. This is the file that contains payment data you receive from the bank. Receivables lets you store the file in any directory.

Destination Account: (Lockbox Control window) The bank account into which this receipt was deposited.

Item Number: (Lockbox Transmission Data window) The item number associated with this receipt. If you have multiple receipts in a batch, you might include this in your transmission format to order receipts in a batch.

Important: The item number is also used to associate an overflow record with the receipt record. Each overflow record must have the same item number as the parent receipt record.

Lockbox Batch Count: (Lockbox Control window) The total number of bank batches associated with this lockbox.

Lockbox Receipt Count: (Lockbox Control window) The total number of receipts associated with this lockbox. This count does not include overflow receipts, headers, or trailers.

Overflow Sequence: (Lockbox Transmission Data window) A type of bank file record that stores additional receipt information that could not fit on the receipt record. Each Overflow record must have a receipt record as a parent. Typically, an Overflow record will store additional invoice numbers and the amount of the receipt to apply to each invoice. If there are multiple overflow records for a receipt record, each overflow record will have an overflow sequence.

Record Count: (Lockbox Control window) The total number of records in this lockbox transmission.

Record Identifier: (Lockbox Transmission Data window) A record identifier consists of at most two characters which Receivables uses to identify each record type. For example, Receivables can identify a receipt record in BAI bank files because this record always starts with the character '6'. You define valid record identifiers in the Transmission Formats window.

Transaction Code: (Submit Lockbox Processing window) The transaction code that AutoLockbox uses as the default code for all payment and application records in a lockbox transmission. AutoLockbox uses transaction codes to manage receivables accounting in a manner that is consistent with federal regulations. This feature is available only in public sector installations.

After the bank file is imported, you can optionally update transaction codes in the Lockbox Transmission Data window.

Important: To view the Transaction Code field in the Submit Lockbox Processing window and in the Lockbox Transmission Data window, enable the Enable Transaction Code profile option. See: Profile Options in Oracle General Ledger, Oracle Receivables Implementation Guide.

Transmission Format: (Submit Lockbox Processing window) A transmission format defines what data your bank is sending in the bank file, and how that data is organized so Receivables can successfully import this data. You must work with your bank to determine the content of your transmission format. Your transmission format must match each bank control file that you create, so the number of control files that you use must correspond to the number of transmission formats that you define. Receivables provides several sample format files in the $AR_TOP/bin directory. You can modify these transmission formats or create new ones.

Related Topics

Using AutoLockbox

Running AutoLockbox

Lockbox Execution Report

Lockbox Execution Report

Receivables automatically generates the Lockbox Execution report each time you run AutoLockbox. This report is divided into two sections:

Import Section

Receivables generates the Import section when you submit the import step of AutoLockbox. If you use SQL*Loader as your import program, it always creates a .log file which can be found in the $AR_TOP/out directory. The .log file contains general information about the activity of your SQL* Loader run, including the reason that the record was not imported.

SQL*Loader also creates a .dis and .bad file in the same directory, if it has records to write to these files. The .bad file contains information about any records that were rejected due to formatting or Oracle errors, such as an invalid date. The .dis file contains discarded records that did not satisfy any of the WHEN clauses in your control file.

Receivables prints a line at the end of the Import section informing you of any rejected or discarded files.

Validation Section

Receivables generates the Validation section when you submit the validation step of AutoLockbox. Use this section of the Lockbox Processing Report to see the number of records that pass or fail validation. You can also see the total amount and number of receipts in each lockbox transmission.

For records that pass validation, Receivables automatically creates QuickCash receipt batches. You can review QuickCash receipt batches in the Receipt Batches window. If you checked the Submit Post QuickCash check box in the Submit Lockbox Processing window, Receivables posts these QuickCash receipt batches to your receivables accounts.

Use the Maintain Lockbox Transmission Data window to review and edit records that failed validation. See: Maintaining Lockbox Transmission Data.

Column Detail

Record Count Summary

Receivables displays the number of records for this transmission and their corresponding statuses.

Transmission

Receivables displays the Deposit date, Bank origination number, Deposit time, and the destination account as well as the following transmission information:

Lockbox Records

Receivables displays the lockbox record information for each record processed. The lockbox information includes the number of receipts in the lockbox that met the criteria for each category.

Batch Records

Receivables displays receipt batch information for each batch in this bank file if you include batches as part of your transmission format. Lockboxes may contain several receipt batches. Receipt batch information includes the receipt batch name, the total number of receipts in this receipt batch, the total receipt amount, currency, and the Deposit and GL date for this receipt batch.

Record Details

Receivables displays the details of each record and the status of that record. If you chose to run the validation report for Rejects Only, Receivables will display the records in error only along with one of the error statuses listed below. If you run the validation report for 'All' records, then records with success statuses will also be displayed.

Lockbox automatically transfers all of the receipt records that have a Success status to the QuickCash tables. If you set the Allow Partial Applications check box to Yes in the Submit Lockbox Processing window, Lockbox will also transfer records that do not have a Success status, but will not be able to apply them. You can apply these receipts manually in the Applications window. If you set the Allow Partial Applications check box to No, records in a batch must have a Success status before they can be transferred into the QuickCash tables.

Error Detail

Receivables lists all errors and their definitions by error number to help you identify the reason a record failed validation.

Related Topics

Running AutoLockbox

QuickCash

Commonly Asked Questions

Maintaining Lockbox Transmission Data

Use the Lockbox Transmission Data window to delete and edit transmission data imported into Receivables from your bank using Lockbox. You can correct your lockbox data in this window for receipts that fail validation, then resubmit the validation step to import these receipts.

Use the Lockbox Execution report to help you determine which transmission records you need to correct to ensure that your validation processes succeed.

If you are updating information, be sure to update only those fields that have data corresponding to the transmission format used to submit the import process.

Note: The Lockbox Transmission Data window is a Folder window. You can customize the appearance of this window by selecting options from the Folder menu. For example, you may choose to add the Alternate Name and Customer Name fields to your default folder.

Prerequisites

To maintain lockbox transmission data:

  1. Navigate to the Lockbox Transmission Data window.

  2. Enter or query the lockbox transmission. Within each transmission, Receivables displays the lockbox and batch records first, followed by the receipts and overflow records. The lockbox import program assigns a date to transmission records that you import into Receivables and displays transmissions by date when you query them in this window.

    The Lockbox Transmission Data window displays the following record types if they are contained in your data file: Service Header, Transmission Header; Lockbox Header; Batch Header; Receipt; Overflow Receipt; Batch Trailer; Lockbox Trailer; Transmission Trailer. You can modify any of the values in these records.

  3. To review error messages, place the cursor in the Status field, then choose Edit Field from the Edit menu. This field is set by the validation process.

  4. Enter Comments about this transmission (optional). Receivables transfers comments for batch header records to the Receipt Batch after you run Post QuickCash. Receivables transfers batch header comments if the batch header does not include comments. You can review and update comments about a batch in the Receipt Batches window.

  5. If the error is contained in the control, receipt, or application information, you can make changes to the invalid records by selecting the record, then choosing one of the following:

  6. Save your work.

  7. Resubmit the transmission for validation. See: Running AutoLockbox.

Related Topics

Using AutoLockbox

Lockbox Execution Report

Viewing Transmission History

Commonly Asked Questions

Viewing Transmission History

Receivables keeps track of each lockbox transmission you submit through the Submit Lockbox Processing window. Use the Lockbox Transmission History window to review information about your lockbox transmissions such as the origination date, the number and amount of records in a transmission, and the number and amount of receipts that passed the validation step.

To view individual records within a transmission, see: Maintaining Lockbox Transmission Data.

Transmission Status

A Lockbox transmission can have one of the following statuses:

New: This transmission has been imported into Receivables but has not yet been validated.

Out of Balance: One or more of the receipts in this transmission was rejected during validation.

Open: All of the receipts in this transmission have been successfully validated and transferred into Receivables. Post QuickCash has not yet processed these receipts.

Closed: All of the receipts in this transmission have been successfully processed by Post QuickCash. You can review these receipts in the Receipts window.

Prerequisites

To view lockbox transmission history:

  1. Navigate to the Lockbox Transmission History window.

  2. Query the lockbox transmission to view. The Control Count and Amount fields display the total number and amount of records in this lockbox transmission. The Validated Count and Amount fields display the total number and amount of receipts in this transmission that passed the validation step.

  3. Enter any Comments about this transmission (optional).

Related Topics

Using AutoLockbox

Running AutoLockbox

Commonly Asked Questions

QuickCash

Create a batch of QuickCash receipts when you need to enter and apply receipts quickly. The QuickCash window requires only minimal information for each receipt and application. QuickCash also provides an extra level of control for entering high volume receipts because it does not immediately affect your customer's account balance.

When you enter receipts and applications in a QuickCash batch or import them using AutoLockbox, Receivables stores the data in an interim table. You can then use the QuickCash window to review receipts and ensure that application information is correct.

Note: If a receipt that you imported contains invalid matching numbers and you selected the Lockbox option Post Partial Amount as Unapplied, then AutoLockbox imports the receipt with an unapplied amount into QuickCash. For your convenience, Receivables retains the invalid matching numbers in the Application Notes field in the QuickCash window. To view the Application Notes field, choose Show Field from the Folder menu.

You must batch QuickCash receipts. Receivables does not update the status, applied, on account, unapplied, and unidentified fields for your QuickCash batch until you save your work.

Important: You cannot add miscellaneous receipts to a QuickCash batch.

QuickCash lets you apply your receipts to one or many transactions, use AutoCash rules, place receipts on-account, or enter them as unidentified or unapplied. You can also apply receipts to transactions in different currencies.

You can also apply a QuickCash receipt against other open receipts. See: Applying a QuickCash Receipt to Multiple Transactions.

In addition, you can use the QuickCash window to:

After reviewing a QuickCash batch for accuracy, run Post QuickCash to update your customer's account balances.

After you run Post QuickCash, Receivables treats QuickCash receipts like any other receipts; you can reverse and reapply them and apply any unapplied, unidentified, or on-account amounts.

Note: If you do not identify the customer for a receipt, Receivables automatically assigns the receipt a status of Unidentified.

Bank Charges

The profile option AR: Create Bank Charges determines whether Receivables will consider bank charges and tolerance limits when applying receipts. When this profile option is set to Yes, both the Bank Charges and Tolerance Limit fields appear in the QuickCash window. However, whether you can enter values in these fields depends on the receipt's Application Type and creation status.

If you are applying a QuickCash receipt using an Application type other than 'AutoCash Rule' and the receipt creation status of the Receipt Class is 'Cleared,' Receivables lets you enter an amount in the Bank Charges field. (A receipt is created as Cleared if the Clearance Method of the receipt class is set to 'Directly.')

When applying QuickCash receipts using an Application Type of 'AutoCash Rule,' Receivables disables the Bank Charges field. For more information about how Receivables uses the Bank Charges and Tolerance Limit values to match receipts with invoices, see: AutoCash.

Entering Quick Receipts

Prerequisites

To create a batch of quick receipts:

  1. Navigate to the Receipt Batches window.

  2. To create a new batch, choose a Batch Type of Manual-Quick, then enter information for this batch. See: Batching Receipts for Easy Entry and Retrieval.

    To add receipts to an existing QuickCash batch, query the batch.

    Tip: To query a batch of receipts imported by AutoLockbox, query the transmission number or the Lockbox name in the Transmission region.

  3. Choose Receipts.

  4. Enter the Receipt Number, Receipt Date, and GL Date. The batch Deposit Date and GL Date provide the default Receipt and GL Dates, but you can change them. The receipt GL Date must be in an open or future-enterable period.

  5. Enter the receipt Currency (optional). The batch currency provides the default currency, but you can change it to any currency defined in the system if you have at least one remittance bank account with the Receipts Multi-Currency flag set to Yes. See: Foreign Currency Transactions.

  6. Enter the Net Amount of this receipt. If bank charges apply, enter the amount in the Bank Charges field. Receivables calculates the total amount as the sum of the net amount plus the bank charges.

  7. Specify how to apply the receipt by choosing one of the following Application Types:

    Auto Cash Rule: Apply receipts to this customer's transactions using AutoCash Rule Set defined for this customer's profile class. If this customer's profile class does not have an AutoCash rule Set assigned to it, Receivables uses the AutoCash Rule Set defined in the System Options window. See: AutoCash.

    Single: Apply this receipt to a single installment. If you choose this option, you must also enter the transaction number to which you want to apply this receipt.

    Multiple: Apply this receipt to multiple transactions or to multiple installments. You specify the transactions and installments to which you want to apply this receipt in the Applications window. See: Applying a QuickCash Receipt to Multiple Transactions.

    Note: (Optional) You can create claims when applying a QuickCash receipt using either the Single or Multiple application type. You can enter a customer reference and reason, if provided. Receivables passes this information to Oracle Trade Management when you run Post QuickCash.

    On-Account: Apply this receipt to a customer's account, but not to a specific transaction.

    Unapplied: Mark this amount as Unapplied if this receipt is not applied to any transactions.

    Unidentified: Mark this amount as Unidentified if this receipt is not associated with a customer.

    Claim Investigation: Create non-invoice related claim for this receipt. For use with Trade Management only.

    Note: (Optional) You can enter a customer reference and reason, if provided. Receivables passes this information to Trade Management when you run Post QuickCash.

  8. Enter the Customer Name, Number, and Bill-to Location for this receipt. When you enter the customer, Receivables enters this customer's primary bill-to location (if one exists), but you can change this value. If the system option Require Billing Location for Receipts is set to Yes, you must enter a bill-to location.

    Tip: If you need to apply a receipt to debit items, but you do not know the customer's name, instead of entering an Application Type, first enter one of the debit item numbers in the Apply To field. When you do this, Receivables displays the name of the customer associated with this transaction. Then, enter the appropriate application type.

    Important: If you do not enter a bill-to location and the customer has no statement site, any unapplied or on-account receipt amounts will not appear on statements sent to this customer.

  9. If you chose an Application Type of Single, enter a transaction number or select one from the list of values. Receivables enters the customer and remittance bank information for this transaction.

    If the transaction currency is different from the receipt currency, enter either the Amount Applied or Cross Currency Rate.

    Note: To apply an amount greater than the balance due, the transaction type of the open debit item must allow overapplication and the profile option AR: Allow Lockbox Overapplication must be set to Yes.

    If the transaction type does not allow overapplication and you try to overapply the transaction when Trade Management is installed, then QuickCash applies the balance due and creates a claim for the overapplication amount.

  10. Enter the Receipt Method if it did not default from the batch information, or if you changed the receipt currency. You can only select receipt methods that have remittance bank accounts assigned to them that have the same currency as the currency you specified for the receipt, or that have the Multiple Currencies Allowed check box selected.

  11. If you are using manual document numbering, enter a unique Document Number. Otherwise, Receivables assigns a unique number when you save. See: Implementing Document Sequences, Oracle Receivables Implementation Guide.

  12. Move to the next record and repeat the steps above for each receipt to add to this batch.

Applying a QuickCash Receipt to Multiple Transactions

You can apply a QuickCash receipt to several transactions by choosing an application type of 'Multiple.' You then select to which transactions you want to apply this receipt in the Applications window. Receivables does not actually update your customer's balance until you run Post QuickCash.

You can apply a receipt to a transaction even if the GL date is in a future accounting period or the transaction currency is different from the receipt currency. You can also apply a receipt to other customer's transactions if the system option Allow Payment of Unrelated Invoices is set to Yes.

You can also apply a QuickCash receipt against open receipts that are in the same currency. See: Receipt-to-Receipt Applications.

To apply a QuickCash receipt to several transactions:

  1. Navigate to the Receipt Batches window.

  2. Query or enter the QuickCash batch. See: Entering Quick Receipts.

  3. Choose Receipts.

  4. If this is a new batch, enter receipt information and choose an Application Type of Multiple. If the receipt currency is different from the batch currency, specify exchange rate information.

  5. Choose the Multiple button.

  6. Enter a transaction or open receipt, or select one from the list of values.

  7. Enter the amount of the receipt to apply to this transaction.

    Note: If applying this receipt against an open receipt, then skip to the next step.

    Use the AR: Always Default Transaction Balance for Applications profile option, Oracle Receivables Implementation Guide to control how Receivables defaults the applied amount.

    Note: To apply an amount greater than the balance due, the transaction type of the open debit item must allow overapplication and the profile option AR: Allow Lockbox Overapplication must be set to Yes.

    If the transaction type does not allow overapplication and Trade Management is installed, then QuickCash applies the balance due and creates a claim for the overapplication amount if you try to overapply the transaction.

    The default Discount is the earned discount amount available for this application, unless the system option Allow Unearned Discounts is set to Yes. In this case, the default discount is the amount that, along with the receipt amount applied, closes this item. However, the discount amount cannot be greater than the maximum discount allowed for the transaction (which is determined by the transaction's payment terms). If you do not want Receivables to calculate a discount, change the value of the Discount field to null (no value). See: Discounts.

    Note: Use the hidden field, Estimated Balance Due, to obtain a preview of the remaining balance due on a transaction after considering the current application line that Post QuickCash program might create upon submission. The values displayed in this column are estimates only, and do not convey:

  8. If applying this receipt against an open receipt, then the amount applied defaults to the greater of either:

  9. If the receipt and transaction currencies are different, enter either the Allocated Receipt Amount or the Cross Currency Rate. The Allocated Receipt Amount is the amount to apply in the receipt currency. If you enter the Allocated Receipt Amount, Receivables calculates the cross currency rate, and vice versa.

  10. Move to the next record and repeat the steps above for each transaction to which you want to apply this receipt.

Related Topics

Post QuickCash

Post QuickCash Execution Report

Receipts Field Reference

Post QuickCash

When you enter receipts in the QuickCash window or import them using AutoLockbox, Receivables stores them in interim tables. You can then use the QuickCash window to review each receipt and use the Applications window to ensure that the application information is correct. After you approve the receipts and their applications, run Post QuickCash to update your customer's account balances.

You can choose which QuickCash or Lockbox batches to review. For example, you may want to review only the receipts entered by your data entry clerks or the data files sent by your bank.

The following diagram summarizes how Post QuickCash transfers receipts and applications from interim tables into Receivables.

Post QuickCash

the picture is described in the document text

How Post QuickCash Applies Receipts

Closed Transactions

If you enter a receipt and fully apply it to an open invoice, Post QuickCash will process the receipt as well as the application. However, if you apply a receipt to an invoice that is closed by another application, Post QuickCash will only process the receipt. In this case, the receipt will be marked 'Unapplied'. You need to use the Applications window to manually apply these receipts.

AutoCash Rule Sets

Post QuickCash uses the AutoCash Rule Set assigned to the customer site or profile class to determine how to apply receipts. If an AutoCash Rule Set has not been assigned to the customer's site, Post QuickCash uses the rule set in the customer's profile class; if the customer's profile class does not have an AutoCash Rule Set, Post QuickCash uses the rule set in the System Options window. See: AutoCash.

If you use AutoCash rules to apply your receipt and all of the rules in your AutoCash Rule Set fail, Post QuickCash will apply the receipt using the Remaining Amount Rule Set that you specify for this customer's profile class. If you did not specify a Remaining Amount Rule Set for this customer's profile class, Receivables marks the remaining amount Unapplied. See: Defining Customer Profile Classes, Oracle Receivables Implementation Guide.

Bank Charges

If you set the system option AR: Create Bank Charges to Yes, Receivables will also consider bank charges and a tolerance limit when applying receipts. See: Matching Using Bank Charges and Tolerance Limit.

Receipts Without a Bill-to Location

If the system option 'Require Billing Location For Receipt' is set to Yes, Post QuickCash will not process receipts that do not have a bill-to location. Both the QuickCash window and AutoLockbox validate that receipts have a billing location if this option is set to Yes. However, the system option may change after the receipts have been entered but before Post QuickCash has been run, so Post QuickCash revalidates.

Application Rule Sets

Post QuickCash uses the Application Rule Set assigned to the debit item's transaction type to determine how to apply payments and how discounts affect the open balance for each type of associated charges. If no rule set is assigned to this item's transaction type, Post quickCash uses the rule set defined in the System Options window. See: Receivables Application Rule Sets.

Cross Currency Receipts

You can use Post QuickCash to apply a receipt when the receipt and transaction currencies are different. See: Importing and Applying Cross Currency Receipts.

Invoice-related and Noninvoice-related Claims

When you run Post QuickCash, qualified QuickCash application lines are passed to Oracle Trade Management for claim creation and management:

A claim number is passed back to Receivables after Trade Management creates the claim.

Receipt-to-Receipt Applications

You can net receipts by applying a QuickCash receipt against multiple open receipts. See: Receipt-to-Receipt Applications.

Related Topics

QuickCash

Running Post QuickCash

Post QuickCash Execution Report

Running Post QuickCash

Run Post QuickCash to update your customer's account balances for batches created either in the QuickCash window or using AutoLockbox. Run Post QuickCash after you approve your receipts and applications in the Receipts and Applications windows. Alternatively, you can choose to run Post QuickCash at the same time that you import and validate your LockBox receipt batch in the Submit Lockbox window. See: Running AutoLockbox.

You can select batches that contain on-account, unapplied, and unidentified receipts and you can submit a receipt batch for posting regardless of its status. Your batch will generally have a status of either Open or Out of Balance before submitting Post QuickCash. See: Batching Receipts for Easy Entry and Retrieval.

Post QuickCash sends qualified application lines to Oracle Trade Management for claim creation if you have properly set up your system. See: How AutoLockbox Creates Claims.

After you run Post QuickCash, you can fully or partially apply any unidentified, on-account, or unapplied amounts in the Receipts window. After you fully apply or place on-account each receipt in the batch, Receivables updates the batch status to Closed and changes the batch type to Manual-Regular (this is true for both manually entered batches and those created by AutoLockbox).

If the system option AR: Create Bank Charges is Yes, Receivables will also consider bank charges and a tolerance limit when applying receipts. See: Matching Using Bank Charges and Tolerance Limit.

Prerequisites

To run Post QuickCash from the Receipt Batches or Receipt Batches Summary window:

  1. Navigate to the Receipt Batches or the Receipt Batches Summary window.

  2. Query the batch to post.

    If you are in the Receipt Batches Summary window, query then select the batch to post.

    Tip: To review a batch of receipts imported by AutoLockbox, perform a query using the Lockbox or Transmission Name.

  3. To review receipts within this batch, choose Receipts. If a receipt's Application Type is 'Multiple,' you can review its application by choosing the Multiple button. If a receipt's Application Type is Single, Receivables displays the transaction to which this receipt will be applied in the Apply To field.

  4. To post this batch, choose Post QuickCash, then choose Yes to acknowledge the message. Receivables displays a Process Status number for this batch and creates the Post QuickCash Execution Report.

    The Process Status number represents the unique concurrent request ID assigned to this batch. You can use this number to check the status of your request in the Requests window.

To run Post QuickCash using the Submit Lockbox window:

  1. Navigate to the Submit Lockbox Processing window.

  2. Enter the lockbox Transmission Name or select a transmission from the list of values. See: Running AutoLockbox.

  3. Check the Submit Post QuickCash check box.

  4. Save your work. Receivables displays the Request ID of your concurrent process and creates the Post QuickCash Execution report. See: Post QuickCash Execution Report.

    The Request ID number represents the unique concurrent request ID assigned to each receipt batch. You can use this to check the status of your requests in the Requests window.

Related Topics

QuickCash

Post QuickCash Execution Report

Monitoring Requests, Oracle Applications User's Guide

Post QuickCash Execution Report

Receivables automatically generates this report each time you submit Post QuickCash or AutoLockbox. The report is printed in two sections. The first section contains detailed payment information for each receipt. The second section contains summary information for the receipt batch.

If another user selects the same batch before your request has completed, Receivables rejects the second request and the Post QuickCash Execution Report will display the message 'This batch has already been processed.'

If Post Batch uses other open amounts when applying a receipt (for example, a receipt, unapplied or on-account amount), Receivables marks that receipt with two asterisks (**) and prints the legend "Total applications from previous receipts" at the bottom of the report. This occurs when you are using either the 'Clear the Account' or 'Clear Past Due Invoices' AutoCash rule to apply receipts, since both of these rules consider all of a customer's open debit and credit items when applying receipts.

Detailed Section

Receivables prints the amount of the receipt that is applied to each transaction and the application type, such as partial application, on-account, or unidentified. This section also displays the remaining amount of the receipt.

Note: The report does not consider receipts that are not fully applied when adding the number of applied receipts in a batch. For example, you create a batch with two receipts, one for $100 and one for $75. Post QuickCash applies $50 of the $100 receipt but the other receipt is left unapplied. The execution report lists applied receipts as described in this table:

Count Percentage Amount Percentage
1 50 50 29

If you use AutoCash Rules, Receivables displays the abbreviated AutoCash Rule code for the AutoCash Rule used. The AutoCash Rule Legend at the end of the report lists the rules in more detail.

If you are using the AutoCash rule 'Clear the Account,' Receivables prints two asterisks (**) next to receipts that do not belong to this batch. Receivables includes all open credit and debit items when determining the customers open balance for the Clear the Account rule, so this may include partially applied or unapplied receipts on your customer account.

Summary Section

Receivables displays the status of this receipt batch. Statuses include Out of Balance and Closed. If the batch is out of balance, you can use the Difference Counts and Amounts to alert you to data entry problems.

Period information is displayed for the date you create the receipt batch, the batch GL date, and the batch deposit date.

In the Status Summary section, Receivables displays the total number, percentage, and amount of each receipt type included in this receipt batch.

In the Discounts section, Receivables displays the total amount of earned and unearned discounts taken for this receipt batch. See: Discounts.

In the Distribution section, Receivables displays the total amount of the receipts applied to line items, tax, freight, and receivables charges.

Important: If your batch contains receipts in different currencies, the totals in this report contain amounts in mixed currencies. For example, if the batch includes one receipt for 100 USD and another for 50 EUR, the total amount is 150.00.

Related Topics

QuickCash

Running Post QuickCash

AutoCash

The Post QuickCash program uses AutoCash rules to determine how to automatically apply your receipts. Receivables uses your customer's open balance along with the AutoCash rules to determine how to apply receipts and whether you allow partial payments to be applied to your customer's items. If Receivables is not able to apply or fully apply a receipt, you can specify whether the remaining amount is left as Unapplied or On-Account.

Receivables provides five AutoCash rules you can use to create your AutoCash rule sets. See: AutoCash Rules. When you define your AutoCash rule sets, you specify which rules to use and the sequence of these rules.

To determine which AutoCash Rule Set to use when applying receipts, Receivables uses the following hierarchy, stopping when one is found:

  1. Customer site

  2. Customer profile class

  3. System Options window

Note: AutoCash rules do not support cross-currency receipt applications.

Calculating Your Customer's Open Balance

For each AutoCash rule set, you can determine how Receivables calculates your customer's open balance. Receivables uses the values for each customer's profile class and the Open Balance Calculation region of the AutoCash Rule Sets window when calculating your customer's open balance. If the Discount parameter for this AutoCash Rules Set option is set to a value other than 'None', the Payment Terms and number of Discount Grace Days specified in this customer's profile class determine the discount amount for each transaction.

The system option Allow Unearned Discounts determines whether you can include earned and unearned discounts for this AutoCash Rule Set. Additionally, the Items in Dispute option for this AutoCash rule set determines whether items that are in dispute will be included when calculating your customer's open balance.

Automatic Matching Rules

Apply Partial Receipts

A partial receipt is a receipt that is less than the amount required to close the debit item to which it is applied. If you are using the Apply to the Oldest Invoice First rule, Receivables lets you determine if you want to be able to apply a partial payment to your customer's debit items. The Apply Partial Receipts option in the AutoCash Rule Sets window determines whether Receivables can apply a partial payment to an open debit item.

The options that Receivables uses to calculate your customer's open balance affect the meaning of partial payments. For example, you have the following situation:

Discounts = No

Apply Partial Receipts = No

Late Charges = Yes

Items in Dispute = No

Receipt = $100

Invoice #25 = $100

Late Charge for Invoice #25 = $10

In this example, Receivables will not be able to apply the $100 receipt to Invoice #25 because the total remaining amount on the invoice is $110 and Apply Partial Receipts is set to No. The status of the receipt amount will depend on the value you enter for the Remaining Remittance Amount.

Remaining Remittance Amount

If you are using the Apply to the Oldest Invoice First rule, Receivables lets you determine the status of any remaining remittance amounts. If Receivables cannot fully or partially apply a receipt using any of the AutoCash rules in your AutoCash Rule set, it will either mark the remaining amount 'Unapplied' or place it 'On Account.' You choose one of these options in the Remaining Remittance Amount field in the AutoCash Rule Sets window.

Matching Using Bank Charges and Tolerance Limit

If you have set up your system to use bank charges and a tolerance limit, Receivables will also consider these amounts if the current AutoCash rule does not find a match. If Receivables cannot find a match using bank charges or tolerance limit, it looks at the next rule in the sequence.

For Receivables to consider bank charges and tolerance limits, the following must be true:

Example

This example uses the AutoCash rule 'Match Payment with Invoice' to explain matching using bank charges and tolerance limit.

If it cannot match the receipt amount with an invoice, Receivables will attempt to match the sum of the receipt amount plus the bank charges to the invoices. If these amounts match, Receivables applies the receipt; otherwise, it will attempt to apply the sum of the receipt amount plus the tolerance limit to the invoice with the lowest value. If there are two or more invoices with equal amounts, Receivables will apply the receipt to the invoice with the oldest due date.

Consider the following example and the invoices in the table below:

Receipt = $980

Bank Charge = $3

Tolerance Limit = $20

Invoice Number Amount
701 $985
702 $990
703 $995

Receivables will attempt to exactly match the receipt amount with an invoice. After failing to do so, Receivables attempts to match the sum of the receipt plus the Bank Charge ($983) to the invoices. When this also fails, Receivables attempts to apply the sum of the receipt plus the Tolerance Limit ($1,000) to the invoice with the lowest amount (to minimize the bank charges incurred). In this example, Receivables will apply $985 to invoice #701, thereby incurring a $5 bank charge.

Receipt = $980

Inv. #701 = <$985>

Bank Charge: <$5>

AutoCash Rules

Receivables provides five AutoCash rules that you can use to create your AutoCash rule sets. When you run Post QuickCash to apply your customer's receipts, Receivables tries to use each AutoCash rule within an AutoCash rule set. If the first rule in the set does not find a match, Receivables uses the next rule in the sequence, and so on until it can apply the receipt.

Following are the AutoCash rules you can use:

If you have set up Receivables to use Bank Charges, each AutoCash rule (except Apply to the Oldest Invoice First) can also consider bank charges and tolerance limits when attempting to match payments with invoices.

See: Matching Using Bank Charges and Tolerance Limit.

Match Payment with Invoice

When using this rule, Receivables can only apply the receipt to a single invoice, debit memo, or chargeback if the receipt amount matches the amount of the debit item. If more than one debit item has an open amount that matches the receipt amount, Receivables applies the receipt to the item with the earliest due date. If more than one debit item exists with the same amount and due date, Receivables applies to the item with the lowest payment schedule id number (this is an internal, system-generated number).

Receivables uses the values you entered for the open balance calculation and the number of discount grace days you specified in this customer's profile class to determine the remaining amount due of the debit item. For example, you have the following situation:

Discounts = Earned Only

Late Charges = No

Receipt = $1800

Receipt Date = 14-JAN-93

Discount Grace Days = 5

This table shows the invoice details:

Invoice Num Invoice Amount Discount Payment Terms Invoice Date Due Date
600 $2000 $20 10% 10/Net 30 01-JAN-93 30-JAN-93

Since Late Charges is not enabled, Receivables subtracts the $20 late charges from the amount of the invoice, reducing the amount to $2000. The payment terms assigned to this invoice include a 10% discount if the invoice is paid within 10 days and our open balance calculation allows us to take earned discounts. Even though the invoice is paid after the 10 day period, Receivables adds the 5 discount grace days, making this invoice eligible for a 10% discount. The remaining amount due of this invoice on January 14 is $1800. Since the remaining amount due of the invoice matches the receipt amount, the receipt is applied. If no discount grace days were offered, Receivables would not be able to apply the receipt because the remaining amount of the invoice would be $2000.

Note: If this AutoCash rule fails and you have set up your system to use bank charges and a tolerance limit, Receivables will compare the receipt amount plus bank charges to the invoice. If this fails, Receivables will compare the receipt amount plus tolerance limit to the invoice. If it finds a match, Receivables applies the receipt; otherwise, it looks at the next AutoCash rule in the sequence. For more information, see: Matching Using Bank Charges and Tolerance Limit.

Clear the Account

When using this rule, Receivables can only apply the receipt if the receipt amount matches your customer's open balance. Receivables includes all open debit and credit items when calculating your customer's open balance. Open credit items include credit memos, on-account credits, and on-account and unapplied cash.

Receivables uses the options you specified for the open balance calculation and the number of discount grace days that you defined for this customer's profile class to determine your customer's open balance. For example, you have the following situation:

Late Charges = Yes

Items in Dispute = Yes

Receipt = $590

The table below shows this customer's activity:

Past Due Debits/Credits Invoice Amount Late Charges In Dispute
Invoice #45 $500 $40 Yes
Invoice #46 $300 $0 N/A
Credit Memo #100 $50 N/A N/A
Unapplied Cash $200 N/A N/A

Since Late Charges and Items in Dispute are enabled, the open balance for this customer is $590. Because the receipt amount matches your customer's open balance, the receipt can be applied.

Note: If this AutoCash rule fails and you have set up your system to use bank charges and a tolerance limit, Receivables will compare the receipt amount plus bank charges to your customer's open balance. If this fails, Receivables will compare the receipt amount plus tolerance limit to the your customer's open balance. If it finds a match, Receivables applies the receipt; otherwise, it looks at the next AutoCash rule in the sequence. For more information, see: Matching Using Bank Charges and Tolerance Limit.

Clear Past Due Invoices

When using this rule, Receivables can only apply a receipt if the receipt amount matches your customer's past due account balance. Receivables includes all open past due debit and credit items when calculating your customer's past due account balance.

A debit item is considered past due if the invoice due date is earlier than or equal to the receipt date of the receipt being applied to this invoice. For unapplied and on-account cash, Receivables uses the receipt date, and for credit memos and on-account credits Receivables uses the credit memo date to determine whether to include these amounts in the customer's account balance. For example, if you are trying to apply a receipt with a receipt date of 10-JAN-93, all unapplied and on-account cash as well as credit memos and on-account credits that have a transaction date (receipt date or credit memo date) on or earlier than 10-JAN-93 will be included when calculating this customer's account balance.

Receivables uses the options that you entered for the open balance calculation and the number of discount grace days that you specified for this customer's profile class to determine your customer's past due account balance. The values you choose for the Late Charges and Items in Dispute options may prevent a past due debit item from being closed, even if the receipt amount matches your customer's past due account balance. For example, you have the following situation:

Late Charges = No

Items in Dispute = No

Receipt = $420

The table below shows this customer's activity:

Past Due Debits/Credits Invoice Amount Late Charges In Dispute
Invoice #209 $300 $0 N/A
Invoice #89 $250 $0 Yes
Invoice #7 $120 $30 N/A

Since Late Charges and Items in Dispute are not enabled, Receivables does not include Invoice #89 ($250) or late charges for Invoice #7 ($30) when calculating this customer's past due account balance. Therefore, the past due account balance for this customer is $420. Because the receipt amount matches your customer's past due account balance, the receipt can be applied; however, Invoice #7 and #89 are still open, past due debit items.

Note: If this AutoCash rule fails and you have set up your system to use bank charges and a tolerance limit, Receivables will compare the receipt amount plus bank charges to your customer's past due account balance. If this fails, Receivables will compare the receipt amount plus tolerance limit to the past due account balance. If it finds a match, Receivables applies the receipt; otherwise, it looks at the next AutoCash rule in the sequence. For more information, see: Matching Using Bank Charges and Tolerance Limit.

Clear Past Due Invoices Grouped by Payment Term

When using this rule, Receivables can only apply a receipt if the receipt amount matches the sum of your customer's credit memos and past due invoices. This rule is similar to the Clear Past Due Invoices rule, but it first groups past due invoices by their payment term, and then uses the oldest transaction due date within the group as the group due date.

A debit item is considered past due if the invoice due date is earlier than the deposit date of the receipt being applied to this invoice. For credit memos, Receivables uses the credit memo date to determine whether to include these amounts in the customer's account balance. For example, if you are trying to apply a receipt with a receipt date of 10-JAN-93, credit memos that have a transaction date (credit memo date) on or earlier than 10-JAN-93 will be included. Credit memos do not have payment terms, so they are included in each group.

Receivables uses the options that you entered for the open balance calculation and the number of discount grace days that you specified for this customer's profile class to determine the sum of your customer's credit memos and past due invoices. The values you specify for the Late Charges and Items in Dispute options may prevent a past due debit item from being closed, even if the receipt amount matches the sum of your customer's credit memos and past due invoices.

Consider the following situation and activity in the table below:

Receipt = $900 on 25-JUN

Transaction Number Payment Term Due Invoice Amount
1 A 25-MAY $500
2 A 25-JUNE $200
3 A 25-JUNE $200
4 B 20-JUNE $900
5 C 25-MAY $905

Receivables will group these transactions as follows:

Group 1: Trans 1,2,3

Amount: $900

Group Due Date: 25-MAY

Group 2: Trans 4

Amount: $900

Group Due Date: 20-JUN

Group 3: Trans 5

Amount: $905

Group Due Date: 25-MAY

Since Groups 1 and 2 match the receipt amount, Receivables will select the group with the oldest due date (Group 1) and apply the receipt to those transactions.

Note: If this AutoCash rule fails and you have set up your system to use bank charges and a tolerance limit, Receivables will compare the receipt amount plus bank charges to the sum of your customer's credit memos and past due invoices for that payment term. If this fails, Receivables will compare the receipt amount plus tolerance limit to the group with the smallest sum of credit memos and past due invoices (if there are two or more groups with the same combined amount Receivables will select the group with the oldest due date). If it finds a match, Receivables applies the receipt; otherwise, it looks at the next AutoCash rule in the sequence. For more information, see: Matching Using Bank Charges and Tolerance Limit.

Apply to the Oldest Invoice First

When using this rule, Receivables applies receipts to your customer's debit and credit items starting with the item having the oldest due date. Receivables uses the values that you entered for the open balance calculation to determine your customer's oldest outstanding item.

For example, you have the following situation plus activity in the table below:

Apply Partial Receipts = Yes

Late Charges = No

Receipt = $200

Invoice Number Invoice Amount Late Charges Due Date
801 $0 $35 01-DEC-92
707 $450 $0 01-JAN-93

If you compare only the due dates for the two invoices, invoice #801 is the oldest invoice, but Receivables also checks the options that you entered for both your open balance calculation and automatic matching rule. Since Late Charges is not enabled, Receivables ignores invoice #801 (since the remaining amount only consists of late charges) and applies the $200 receipt to invoice #707.

If Apply Partial Receipts was set to No, Receivables would not be able to apply this receipt and would look at the next rule in the sequence.

Note: Matching using bank charges and a tolerance limit does not apply to this AutoCash rule.

Example

Assume that you have defined the following AutoCash rule set:

Open Balance Calculation

Automatic Matching Rules

Sequence of AutoCash Rules

  1. Match Payment with Invoice

  2. Clear The Account

  3. Apply To The Oldest Invoice First

A payment was entered for Global Freight Carriers for $600 through the QuickCash window with a deposit date of 10-DEC-92.

As illustrated in the table below, Global Freight Carriers has the following outstanding invoices, none of which are in dispute:

Number Amount Remaining Due Date Discount Date/Amount
123 $200 11-DEC-92 01-DEC-92/$20
124 $300 08-DEC-92 30-NOV-92/$30
125 $150 13-DEC-92 28-NOV-92/$15

Results:

Related Topics

AutoCash Rule Sets, Oracle Receivables Implementation Guide

Post QuickCash

AutoCash Rules Report

Discounts in Post QuickCash

Discounts

Receivables lets you give discounts to your customers when they pay for their debit items before a certain date. Discounts are determined by the payment terms you assign to your customers. You can also choose whether to allow discounts for partial payments and specify how you want Receivables to calculate the discount on your invoices.

Types of Discounts

Receivables lets you use the following types of discounts.

Earned and Unearned Discounts

Receivables lets you determine whether your customers can take earned and unearned discounts. An earned discount is a discount you give to a customer who pays on or before the discount date or within the discount grace period. For example, a customer may earn a 2% discount off the original invoice if payment is received within 10 days. The earned discount period is determined by the invoice date, apply date of the receipt, and any discount grace days.

Receivables also lets you choose whether to allow unearned discounts. Unearned discounts are discounts that you allow after the earned discount period has passed. If the discount is unearned, the default earned discount is zero and the maximum value of the unearned discount is dictated by the payment terms. If the discount is earned, the default discount is the amount of the earned discount. Receivables lets you override the discount amount during payment entry. You specify whether your customers can take unearned discounts in the System Options window. See: Miscellaneous System Options, Oracle Receivables Implementation Guide.

For more information, see: Determining the Discount Percent.

Discounts on Partial Payments

Receivables lets you choose whether to allow discounts when your customer remits partial payment for an open debit item. If you allow discounts on partial payments, Receivables prorates the amount of the discount based on the applied amount. You can control whether your customers can receive discounts for partial payments by setting the system option Discount on Partial Payment to Yes or No. See: Accounting System Options, Oracle Receivables Implementation Guide.

Tiered Discounts

When you define your payment terms, you can assign multiple discounts to each payment schedule. You might want to assign different discount percents based on different discount dates. For example, you might give your customers a 15% discount if they pay within 10 days after the invoice date, but only a 5% discount if they pay within 15 days.

Discount Options

The following options let you determine how Receivables calculates the discount amount.

Discount Grace Days

Grace days refer to the number of days after the discount term that your customer can take earned discounts. Your customer must have discounts specified in their payment terms before discount grace days can be used. If you use an AutoCash Rule Set to apply payments to a customer's open debit items, Receivables uses the number of Discount Grace Days that you specify for this customer's profile to determine this customer's open balance. See: Defining Customer Profile Classes, Oracle Receivables Implementation Guide and AutoCash.

Discount Basis

The discount basis option lets you specify how Receivables calculates discounts for your invoices. You enter a discount basis when creating your Payment Terms. You can also enter a default discount basis for your payment terms in the System Options window. See: Miscellaneous System Options, Oracle Receivables Implementation Guide.

You can choose one of the following options as your discount basis:

Invoice Amount: Calculate the discount amount based on the sum of the tax, freight charges, and line amounts of your invoices.

Lines Only: Calculate the discount amount based on only the line amounts of your invoices.

Lines, Freight Items and Tax: Calculate the discount amount based on the amount of line items, freight, and tax of your invoices, but not freight and charges at the invoice header level.

Lines and Tax, not Freight Items and Tax: Calculate the discount amount based on the line items and their tax amounts, but not the freight items and their tax lines, of your invoices.

Set Up Receivables to Calculate Discounts

Determining the Discount Percent

Earned Discounts

When determining the discount percent for earned discounts, Receivables uses the invoice date, discount grace days, and the apply date of the receipt to determine the discount percent for this payment term. For example, the invoice date is 01-DEC-93, the receipt is applied on 12-DEC-93, discount grace days = 5 and your payment term has the following discounts:

10% 10 days

7% 15 days

2% 20 days

Receivables uses 10% as your discount percent since the receipt was applied within 10 days (including grace days).

Unearned Discounts

When determining the discount percent for unearned discounts, Receivables uses the maximum discount allowed for this payment term. To allow unearned discounts, set Allow Unearned Discounts to Yes in the System Options window.

Formulas Used to Calculate Discounts

Maximum Discount

Use the following formula to determine the maximum discount amount:

Maximum Discount = Amount Due Original * Highest Discount Percent - Discount Taken

Earned Discounts and Partial Payments Allowed

If the receipt amount is more than the amount due remaining less the discount, Receivables uses the following formula to determine the earned discount:

Earned Discount = Amount Due Remaining * Discount Percent

If the receipt amount is either the same or less than the amount due remaining less the discount, Receivables uses the following formula to determine the earned discount:

Earned Discount = (Receipt Amount * Discount Percent) / 1 - Discount Percent

Unearned Discounts with Partial Payment Discounts Allowed

Receivables uses the following formula to determine unearned discounts if partial payments are allowed:

Unearned Discount = Maximum Discount - Earned Discount

Earned Discounts with Partial Payment Discounts Not Allowed

If the Allow Discount on Partial Payments check box for your payment terms is not checked, Receivables only takes discounts if the receipt amount closes the installment. Receivables uses the following formula to determine earned discounts if partial payment discounts are not allowed:

Earned Discount = Amount Due Original * Discount Percent

Unearned Discounts and Partial Payments Not Allowed

If the Allow Discount on Partial Payments check box for your payment terms is not checked, Receivables only takes discounts if the receipt amount closes the installment. Receivables uses the following formula to determine unearned discounts if partial payments are not allowed:

Unearned Discount = Amount Due Original * Maximum Discount Percent - Earned Discount

Discount on Lines Only

If the Discount Basis option for your payment term is set to Lines Only, Receivables does not take discounts on receipt amounts applied to tax, freight, or late charges and uses the following formula to determine the discount amount:

Line Percent = Discount Percent * (Sum of Lines + Sum of Line Adjustments - Sum of Line Credits / Amount Due Original + Sum of Adjustments - Sum of Credits)

Once you determine the discount line percent, use this as the discount percent in the formulas above.

Defaulting Discount Amounts

When you enter receipts manually, Receivables determines whether discounts are allowed based on the payment terms, discount grace days, system options, transaction date, and receipt apply date. If discounts are allowed, Receivables determines the amount of earned and unearned discounts and displays this information in the Discount field.

Review the example below to understand how Receivables displays discount information based on the apply date of the receipt. Assume that you are using the following information:

 Unearned Discounts = Yes
 Payment Terms: 10/10, 5/15, Net 30
 Discount Grace Days = 0
 Calculate Discount on Lines Only = No
 Allow Discount on Partial Payments = Yes

This table shows the discount details:

Percent Date On Lines Only On Partial Payments
5 17-DEC-93 NO YES
10 12-DEC-93 NO YES
 Invoice Details:
 Invoice #101
 Invoice Date = 02-DEC-93
 Due Date = 01-JAN-94
 Amount = $1100

The following table displays the default discount amounts based on different receipt application dates. You can also see the amount of earned and unearned discounts that your customers can take.

Receipt Apply Date Receipt Amount Default Discount Amount Message Line Earned Discount Allowed Unearned Discount Allowed
From 02-DEC-93 to 12-DEC-93 $990 $110 Discount Earned = 110, Total = 110 $110 None
After 17-DEC-93 $990 0
To take the unearned discount, you must update the amount in the Discount field.
Discount Earned = 0, Total = 110 None $110
From 02-DEC-93 to 12-DEC-93 $1000
$100 of the receipt is left as Unapplied.
$110 Discount Earned = 110, Total = 110 $110 None
From 13-DEC-93 to 17-DEC-93 $1000
$100 of the receipt is left as Unapplied.
$52.63
To take the unearned discount, you must update the amount in the Discount field.
Discount Earned = 52.63, Total = 110 $52.63 $57.37
After 17-DEC-93 $1000
$100 of the receipt is left as Unapplied.
0
To take the unearned discount, you must update the amount in the Discount field.
Discount Earned = 0, Total = 110 None $110

Determining the Default Amount to Apply

Receivables defaults applied receipt amounts into the receipt application windows.

The default amount applied is the remaining amount of the transaction, less any available discount. However, if the remaining amount of the receipt is less then the balance of the transaction, the default amount applied is the remaining amount of the receipt and Receivables takes the discount available on the transaction.

Discounts in Post QuickCash

AutoCash Rules

Receivables uses the discount values that you assigned to your AutoCash rule set along with the payment terms, discount grace days, system options, transaction date, and receipt apply date to determine whether to include discount amounts.

If you choose any of the AutoCash rules, Post QuickCash first takes into account the maximum discount available before trying to apply the receipt.

For example, you are using Apply to the Oldest Invoice First as your AutoCash rule and your oldest invoice is $1000. The payment term associated with this invoice allows a maximum discount of $100 and your receipt amount is $6000. Post QuickCash first applies the $100 discount, which reduces the remaining amount of the invoice to $900, and then applies $900 of the receipt to close the invoice. After the application, you are left with $5100 to apply to the next oldest invoice.

If you are using one of the matching rules, such as Match Payment with Invoice, the receipt must match the invoice after the discount is taken. For example, if you have an invoice for $1000 and a maximum discount of $200, your receipt must be $800 before Post QuickCash can apply it to the invoice. See: Post QuickCash.

When the Discount Amount Exceeds the Maximum Discount

When the discount amount exceeds the maximum discount, Receivables uses the maximum discount as the discount taken. Receivables uses the following formulas to determine the earned discount amount and the maximum discount:

Earned Discount = (Receipt Amount * Discount Percent) / 1 - Discount Percent

Maximum Discount = Discount Taken * Amount Due Original - Highest Discount

Related Topics

Defining Receivables System Options, Oracle Receivables Implementation Guide

Payment Terms, Oracle Receivables Implementation Guide

Entering Discount Information, Oracle Receivables Implementation Guide

AutoCash

Discount Projection Report

Profile Options, Oracle Receivables Implementation Guide

Writing Off Receipts

In Oracle Receivables, you can write off the following:

Unapplied Receipts

When you apply a receipt to debit items, a small unapplied amount may remain on the receipt. Receivables lets you write off unapplied receipt balances during or after receipt application.

With Receivables you can:

Underpayments on Receipts

When a receipt underpays an invoice by a small amount, you can manually write off the underpayment rather than bill your customer for the difference.

Reversal

To reverse the write off, you can unapply the original write-off application by unchecking the Apply check box in the Applications window for the write-off amount that you want to reverse.

Exchange Rates

When you write off a foreign currency receipt, Receivables uses the same exchange rate information from the original receipt for the write-off record.

When you adjust the exchange rate of a foreign currency receipt, Receivables reverses the write-off with the original exchange rate and then applies the new exchange rate to the write-off. Receivables reverses the write-off only if the converted amount does not exceed the system level write-off limit. If the converted amount exceeds the system level write-off limit, Receivables leaves the write-off amount as unapplied.

Creating Manual Receipt Write-Offs

The manual write-off process gives you the flexibility to write off both overpayments and underpayments when you enter and apply a receipt, or at any time.

You can enter multiple write-offs in the Applications window, provided that the total write-off amount does not fall outside the range of both your Receipt Write-off approval limits and system level write-off approval limits.

Prerequisites

To create a manual write-off:

  1. Navigate to the Receipts window.

  2. Enter the receipt information or query an existing receipt. See: Entering Receipts.

  3. Choose Apply.

  4. In the Apply To field, select Receipt Write-off.

  5. In the Amount Applied field, enter the amount to be written off. Receivables validates the value that you enter against your write-off approval limit.

  6. In the Activity field, select a receivables activity. You can select from all active receivables activities defined with the activity type of "Receipt Write-off."

Creating Automatic Receipt Write-Offs

Use the Automatic Receipt Write-off program to write off multiple receipts at once with minimum manual intervention to individual receipt records. When you submit the Automatic Receipt Write-off program, a concurrent program creates the write-offs and closes the receipts.

Important: Use the Automatic Receipt Write-off program to write off only unapplied amounts on receipts.

Use the Create Receipt Write-off window to submit the Automatic Receipt Write-off program. When you submit the program, you must select a receivables activity with an activity type of Receipt Write-off. The receivables activity tells Receivables which GL account to credit in the write-off process.

Note: Always use the Generate Report Only option to preview the receipts that you want to write-off before submitting the program. You can only reverse the write-off by manually unapplying each write-off from the Applications window.

Prerequisites

To create an automatic write-off:

  1. Navigate to the Create Receipt Write-off window.

  2. In the Selection region, enter the currency of the receipts to write off. The default value is your functional currency if the user level write-off limit has been defined for the functional currency. You can change the default value to another currency.

  3. Enter either an unapplied amount or unapplied amount percentage, or both. If you enter an unapplied amount, Receivables validates that the amount entered is within your receipt write-off approval limit.

  4. Use the remaining fields in the Selection region to enter additional selection criteria for the receipts that you want to write off.

  5. Navigate to the Parameters region.

  6. Choose a receivables activity. The receivables activity tells Receivables which GL account to credit for the write-off. This field is optional if you choose the Generate Report only option.

  7. Enter the apply date. The value that you enter in this field becomes the apply date of the write-off record for the receipt.

  8. Enter the GL Date. The value you enter in this field becomes the GL date of the write-off application.

  9. Enter optional comments. You can view the comments that you enter here from the Applications window after Receivables creates the write-off record.

  10. Navigate to the Options region.

  11. Select either the Generate Report Only or Create Write-off option.

Write-Off Process

Both the manual and automatic write-off processes initiate a concurrent program to process the write-off records. This program validates the data that you enter and selects the records to write off. The program then creates the accounting entries and updates the receipt balances.

Accounting Entries

See: Default Accounting for Transactions for an example of the accounting entries that Receivables creates when writing off unapplied receipts.

Create Receipt Write-off Field References

This section provides a brief description of the fields in the Create Receipt Write-off window.

Receipt Currency: The currency of the receipts that you want to write off. Only receipts with the same currency entered here are eligible for write-off.

Unapplied Amount: The maximum amount that you want to write off. Oracle Receivables selects receipts with unapplied amounts less than or equal to this value and that meet the other selection criteria.

Unapplied Amount Percent: The percentage of unapplied amount against the original receipt amount that you want to write off. For example, if you want to write off receipts with an unapplied balance of 5% or less of the original receipt amount, then enter 5 in the field.

Receipt Date (Optional): The date range for the receipts that you want to write off. Receivables selects receipt records that fall within the specified date range.

Receipt GL Date (Optional): The GL date range for the receipts that you want to write off. Receivables selects receipt records with a GL date that falls within the specified receipt GL date range.

Receipt Method (Optional): If you specify a receipt method, then Receivables selects receipt records with this specific receipt method.

Customer Name (Optional): The name of a specific customer whose unapplied receipts you want to write off. Receivables defaults the Customer Name when a valid customer number is entered in the Customer Number field.

Customer Number (Optional): The number of a specific customer whose unapplied receipts you want to write off. Receivables defaults the Customer Number when a valid customer name is entered in the Customer Name field.

Receipt Number (Optional): When you select a receipt number from the list of values, the Customer Name and Customer Number fields are defaulted according to the selected receipt number. If you specify the Receipt Method, Customer Number, or Customer Name, the list of values in the Receipt Number field filters the receipt numbers according to your selection criteria.

Activity: The selected receivables activity determines the GL account that Receivables credits for the write-off.

Apply Date: The value entered in this field becomes the apply date of the write-off record for the receipt.

GL Date: This date determines the GL date of the write-off record. The GL date defaults to the current date and, during the write-off process, is validated to make sure that it is in an Open or Future period. You can change this date.

Comments (Optional): Comments entered here can be viewed from the Applications window after the write-off record is created.

Generate Report Only: When this option is selected, Receivables generates a report that shows the receipts that will be processed using your selection criteria. No receipts are actually written off. This option gives you an opportunity to review the selected records and projected results, so that you can make changes if necessary.

Create Write-off: When this option is selected, the Automatic Receipt Write-off program is submitted.

Working with Claims

Your customers can communicate disputes with you in a number of ways. One option is via their remittances.

For example, on a receipt, a customer might include short payments (deductions) or over payments due to promotional deals, short shipments, damages, and so on. If the remittance advice does not supply you with supporting details, such as an on-account credit memo number or promotional code, then additional research may be required to determine if the discrepancies between the billed amount and the paid amount are warranted.

Receivables integrates with Oracle Trade Management to let you manage these discrepancies, or claims.

Create claims:

See: Creating Claims and How AutoLockbox Creates Claims.

When you create a claim in Receivables, Receivables automatically passes the claim to Trade Management for further research. Trade Management assigns a claim number and the claim investigation process can begin. After a claim's validity is determined, the claim can be resolved directly from Trade Management without any manual intervention by a Receivables user.

See: Resolving Claims.

In certain instances, however, claim resolution must occur directly in Receivables. In those cases, Trade Management sends settlement instructions to Receivables via Workflow notifications.

See: Claims Overview, Oracle Trade Management User Guide.

Creating Claims

Receivables can automatically initiate claim creation during AutoLockbox and Post QuickCash processing. See: Using AutoLockbox.

Additionally, you can create claims when manually entering receipts in the Applications window or in the QuickCash window. See: Applying Receipts and QuickCash.

You can also create claims directly in Trade Management. See: Claims Overview, Oracle Trade Management User Guide.

Claims can be either invoice related or non-invoice related:

Related Topics

Working with Claims

Accounting for Transactions

Resolving Claims

After research on a claim is completed and its validity determined, the claim can be resolved directly from Trade Management. In cases where a Trade Management user cannot resolve a claim directly, however, Workflow notifications alert you that the claim should be resolved in Receivables.

For example, see: Chargebacks and Adjustments.

To learn about settlement options in Trade Management, see: Claim Settlement Methods, Oracle Trade Management User Guide.

Resolving a split claim

Trade Management users have the flexibility to split an existing claim into two or more separate claims. A split claim might be required, for example, in the case of a partial claim resolution.

When a claim is split in Trade Management, however, claim information is not immediately updated in Receivables.

Claim information is automatically updated in Receivables when one of the claims is resolved directly from Trade Management.

See: Splitting a Claim, Oracle Trade Management User Guide.

Passing Claim Information from Oracle Trade Management

Trade Management users can create chargebacks to resolve invoice-related and noninvoice-related claims. See: Chargebacks and Adjustments.

Use the Receivables Transactions window to view these chargebacks. By default, Receivables populates the Reason field on the Reference Information tab with Invalid Claim. Or, complete the following setup steps to display the Trade Management claim reason for chargeback creation.

Note: Receivables displays the Trade Management claim reason on record when the chargeback was initially created. Subsequent changes to the claim reason in Trade Management are not reflected in Receivables.

To display the Trade Management claim reason:

  1. In Receivables, create the same invoice and adjustment reasons. For example, Invalid Promotion.

    Use both the Invoice Reason and Adustment Reason lookup types in the Oracle Receivables Lookups window. See: Transaction Lookups, Oracle Receivables Implementation Guide.

  2. In Trade Management, create claim reasons, and map them to the Receivables adjustment reasons that you already created.

    See: Claim Types and Reasons, Oracle Trade Management User Guide.

Related Topics

Claims Overview, Oracle Trade Management User Guide

Working with Claims

Crediting Transactions

Creating On-Account Credit Memos

Reapplying Receipts

Writing Off Receipts

Payables and Receivables Netting

The Payables and Receivables Netting feature enables the automatic netting of Payable and Receivable transactions within a business enterprise. You can predefine a netting agreement that incorporates the netting business rules and transaction criteria needed to run your tailored netting process. The netting process automatically creates the Payables payments and Receivables receipts required to clear a selected number of Payables and Receivables transactions.

You can view the receipts that the Netting process creates by querying the netted receipts in the Receipts workbench. To view additional details about the netting batch, select AP/AR Netting from the Actions menu.

Note: You cannot update netted receipts in the Receipts workbench.

General Ledger Setup Prerequisites

Cash Management Setup Prerequisites

Receivables Setup Prerequisites

Netting Agreements

A netting agreement controls how a group of trading partners net Payables and Receivables transactions. You can create a netting agreement for each group of trading partners that agrees to net transactions. Netting agreements include the business rules that define the types of transactions that may be selected for netting, and which suppliers and customers can be netted.

See: Netting Agreements, Oracle Payables User Guide.

Netting Process

The netting process includes the following steps:

See: Netting Batch Process, Oracle Payables User Guide.

Related Topics

Payables and Receivables Netting, Oracle Payables User Guide

Cash Application Work Queue

The Cash Application Work Queue list all items in the Work Queue of Cash Application Owner upon performing the search. This page displays all work items, which satisfy the search parameters given by you.

Navigate to Receipts > Cash Application Work Queue.

By default, the user login will be taken as the Cash Application Owner. You can select another owner from the list as a search parameter. The other search parameters are listed below:

Click Show More Options link to display the following search parameters. Click Hide More Options link to hide the following search parameters.

Click Go to display the work items. Click Clear to remove given parameters.

Work Queue Results

The results region displays the work items per the search parameters given. Use Show All or Hide All links to display the receipt details of the work items.

You can take the following actions on the displayed work items:

Update Work Items:

Click Update to open the Work Items Update page, which shows all the work items selected by you for modification.

The Work Items Update page will display all work items selected for modification. You can update the following fields:

Click Apply to save the changes or Cancel to return to the Cash Application Work Queue page.

Reassign Work Items:

Click Reassign to open the Reassign Work Items page for mass reassignment of selected work items to a desired Cash Application Owner.

Note: This button will be visible to only to Cash Application Managers having the necessary function assigned in the menu.

Select the New Cash Application Owner for the selected work items.

Click Apply to save the changes or Cancel to return to the Cash Application Work Queue page.

Export Work Items:

Click Export to export the displayed results to an Microsoft Excel worksheet.

Click Refresh to reload the Cash Application Work Queue.

Related Topics

Cash Application Owner Assignment, Oracle Receivables Implementation Guide