4Define Customer Payments

This chapter contains the following:

Create a Shared Service Model in Receivables
Application Rule Sets
Receipt Classes and Methods
Lockbox
Transmission Formats for Lockbox
AutoMatch Rule Sets
Application Exception Rule Sets
Customer Paying Relationships
FAQs for Receipt Sources

Create a Shared Service Model in Receivables

Use service provider relationships to create a shared service model in Receivables to centralize the processing of customer payments.

In the shared service model, you define one servicing business unit for customer payments. You then create a service provider relationship between this servicing business unit and one or more client billing business units.

Note: All business units must belong to the same ledger.

Once you define this relationship, the servicing business unit can receive and process payments for all of its client billing business units. The shared service model for centralized customer payment processing supports all receipt creation methods in Receivables:

Manual receipts.
Receipts uploaded using a spreadsheet.
Lockbox receipts.
Automatic receipts.

Receivables provides additional functionality for cross-business unit receipt processing, to facilitate the processing of customer payments:

Allow a billing business unit outside the service provider relationship to have payments for its transactions processed by any other business unit in the same ledger.
Allow an individual receipt to be applied to transactions of any business unit in the same ledger.

Perform these procedures to manage shared services in Receivables:

Define Customer Payments Service Providers
Define Receivables System Options for Cross-Business Unit Receipt Processing
Enable a Receipt for Cross-Business Unit Processing

Define Customer Payments Service Providers

Perform the steps in this procedure to define a servicing business unit and client billing business units.

Create a servicing business unit and client business units.
Assign the appropriate business functions to each business unit:
1. Open the Assign Business Functions page for the servicing business unit.
2. Assign business functions to the servicing business unit. At a minimum, you must assign the servicing business unit the Customer Payments business function.
3. Save your work.
4. Open the Assign Business Functions page for the first client business unit.
5. Assign business functions to the client business unit. At a minimum, you must assign the client business unit the Billing and Revenue Management business function.
6. Save your work.
7. Repeat steps 4 to 6 for each client business unit.
Assign the servicing business unit to each client business unit:
1. From the Manage Service Provider Relationships task, open the Manage Service Providers page for the first client business unit.
2. In the Customer Payments Service Providers section, click the Add icon.
3. In the Search and Select window, select the servicing business unit.
4. Save your work.
5. Repeat steps 1 to 4 for each client business unit.

Define Receivables System Options for Cross-Business Unit Receipt Processing

Perform the steps in this procedure to allow a billing business unit outside the service provider relationship to have payments for its transactions processed by any other business unit in the same ledger.

From the Manage Receivables System Options task, open the Edit System Options page for the business unit that you want.
Navigate to the Billing and Revenue tabbed region.
Enable the Allow any business unit to process receipts option.
Save your work.

This business unit can now have payments for its transactions processed by any other business unit in the same ledger.

Enable a Receipt for Cross-Business Unit Processing

Perform the steps in this procedure to apply an individual receipt to one or more transactions belonging to any business unit in the same ledger.

Use the Create Receipt page to create a new receipt or the Edit Receipt page to open an unapplied receipt.
In the Application tabbed section, click the Add Open Receivables button.
In the Add Open Receivables window, enable the Include transactions from all business units option.
Search for and select the transactions that you want to apply to the receipt. You can select transactions from any business unit in the same ledger.
Click the Add button and then the Done button.
If necessary, update the figure in the Applied Amount field for each applicable transaction.
Click the Save button to apply the receipt to the selected transactions.

Application Rule Sets

Rules of the Application Rule Set

When you apply a receipt or credit memo to a transaction, the application rule set determines how Receivables reduces the open balance of the line, tax, freight, and late charge amounts on a transaction.

Receivables uses the application rule set assigned to the transaction type to process payment applications. If no application rule set is assigned to the transaction type, then the application rule set assigned to Receivables system options is used.

You can arrange the order of the line types and application rules in an application rule set according to your needs. Each line type must appear in an application rule set, and appear only once. The Overapplication rule is always last in the sequence.

Line First - Tax After Rule

The Line First - Tax After rule first applies the payment to open line amounts, and then applies the remaining amount to the associated tax.

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

Freight
Late charges

After the payment is fully applied, if there is still a remaining receipt amount this amount is managed by the Overapplication rule.

Line and Tax Prorate

The Line and Tax Prorate rule applies a proportionate amount of the payment to open line and tax amounts for each line.

Freight
Late charges

After the payment is fully applied, if there is still a remaining receipt amount this amount is managed by the Overapplication rule.

Prorate All

The Prorate All rule applies a proportionate amount of the payment to each open amount associated with a debit item (that is, 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

After the payment is fully applied, if there is still a remaining receipt amount this amount is managed by the Overapplication rule.

Overapplication Rule

The Overapplication rule is always the last rule in an application rule set. This rule manages any remaining receipt amount after the open balance of all transaction lines has been reduced to zero.

If the transaction type for the debit item allows overapplication, Receivables applies the remaining amount to transaction lines, making the balance due negative. If the transaction type for the debit item does not allow overapplication, you can either place the remaining amount on-account or leave it unapplied.

Note: Lockbox uses the AutoCash rule set rather than the application rule set to determine how to apply a remaining amount.

Related Topics

Examples of Using Application Rules

These examples show how each application rule in an application rule set applies a payment to a transaction.

Invoice 123 contains these details:

Field	Value
Line	$1000
Tax	$140
Freight	$200
Total	$1340

Your customer remits a partial payment of $1040 for this invoice. This table shows how Receivables applies the payment using each of the three application rules:

Application Rule	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.28	127.72	0
Prorate All	1040	776.12	108.66	155.22

This table shows the calculations used by each application rule:

Application Rule	Calculations
Line First - Tax After	Apply payment to open line amount. Apply any remaining amount to tax.
Line and Tax Prorate	(1040/1140) * 1000 = 912.28 (Receipt Amount / Total Line and Tax) * Line Amount = Line Amount Applied (1040/1140) * 140 = 127.72 (Receipt Amount / Total Line and Tax) * Open Tax Amount = Tax Amount Applied
Prorate All	(1040/1340) x 1000 = 776.12 (Receipt Amount / Invoice Total) * Open Line Amount = Line Amount Applied (1040/1340) x 140 = 108.66 (Receipt Amount / Invoice Total) * Open Tax Amount = Tax Amount Applied (1040/1340) x 200 = 155.22 (Receipt Amount / Invoice Total) x Open Freight Amount = Freight Amount Applied

Line First - Tax After

The Line First - Tax After rule 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.

This table compares each line type before and after you apply an amount using the Line First - Tax After rule:

Transaction Amount	Remaining Amount	Line Items	Line Items Remaining	Tax	Tax Remaining	Freight	Freight Remaining
$1340	$300	$1000	$0	$140	$100	$200	$200

Line and Tax Prorate

The Line and Tax Prorate rule 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.

This table compares each line type before and after you apply an amount using the Line and Tax Prorate rule:

Transaction Amount	Remaining Amount	Line Items	Line Items Remaining	Tax	Tax Remaining	Freight	Freight Remaining
$1340	$300	$1000	$87.72	$140	$12.28	$200	$200

This table shows the calculations used to arrive at the proportionate amounts:

Item	Calculations
Line Items	1000 - 912.28 = 87.72 Amount Line Items - Line Amount Applied = Open Line Amount
Tax	140 - 127.72 = 12.28 Tax Original - Tax Amount Applied = Open Tax Amount

Line Items

1000 - 912.28 = 87.72

Amount Line Items - Line Amount Applied = Open Line Amount

Tax

140 - 127.72 = 12.28

Tax Original - Tax Amount Applied = Open Tax Amount

Prorate All

The Prorate All rule applies a proportionate amount of the receipt to the line, tax, and freight for this transaction.

This table compares each line type before and after you apply an amount using the Prorate All rule:

Transaction Amount	Remaining Amount	Line Items	Line Items Remaining	Tax	Tax Remaining	Freight	Freight Remaining
$1340	$300	$1000	$223.88	$140	$31.34	$200	$44.78

This table shows the calculations used to arrive at the proportionate amounts:

Item	Calculations
Line Items	1000 - 776.12 = 223.88 Amount Line Items - Line Amount Applied = Open Line Amount
Tax	140 - 108.66 = 31.34 Tax Original - Tax Amount Applied = Open Tax Amount
Freight	200 - 155.22 = 44.78 Freight Original - Freight Amount Applied = Open Freight Amount

Line Items

1000 - 776.12 = 223.88

Amount Line Items - Line Amount Applied = Open Line Amount

Tax

140 - 108.66 = 31.34

Tax Original - Tax Amount Applied = Open Tax Amount

Freight

200 - 155.22 = 44.78

Freight Original - Freight Amount Applied = Open Freight Amount

Example of Using Application Rules with Transactions with Mixed Sign Balances

This example shows how the Prorate All application rule is used to apply a payment to a transaction that has mixed sign balances. In a transaction with mixed sign balances, the charges that make up the transaction have a combination of positive and negative signs.

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 (that is, it is 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 applies any remaining amounts according to the Overapplication rule assigned to the application rule set.

Prorate All with Mixed Sign Balances

Invoice 101 contains these details:

Field	Value
Line	<$100>
Tax	$100
Freight	$30
Late Charges	$10

Assume that you are using the Prorate All application rule. Your customer remits a receipt of $100. Receivables prorates the positive receipt amount among the positive tax, freight, and late charges amounts. The line amount of <$100> is not affected.

This table shows the new balance of Invoice 101 after the receipt application:

Field	Value
Line	<$100>
Tax	$28.56
Freight	$8.58
Late Charges	$2.86

This table compares each line type for this invoice before and after you apply the payment using the Prorate All rule:

Line Items	Line Items Remaining	Tax	Tax Remaining	Freight	Freight Remaining	Late Charges	Late Charges Remaining
<$100>	<$100>	$100	$28.56	$30	$8.58	$10.00	$2.86

This table shows the amount applied to each line type:

Total Amount Applied	Line Amount Applied	Tax Amount Applied	Freight Amount Applied	Late Charges Amount Applied
100	0	71.44	21.42	7.14

This table shows the calculations used by the Prorate All application rule:

Item	Calculations
Tax	100 - (21.42 + 7.14) = 71.44
Freight	(30 * 100) / 140 = 21.42
Late Charges	3(10.00 * 100) / 140 = 7.14

FAQs for Application Rule Sets

What's the tax treatment?

The Tax Treatment option on the application rule set determines how to reduce the tax amount in relation to the line amount when a payment is applied.

The tax treatment options are:

Prorate: Proportionately reduce the net amount of the line and associated tax amounts.
Before: First reduce the open tax amount, then apply any remaining amount to the line.
After: Reduce the open line amount, then apply any remaining amount to the associated tax.

How can I use the rounding correction?

You assign a rounding correction to one of the line types (Line, Freight, or Charges) belonging to an application rule set. When an amount is prorated across more than one line type, the application rule set uses the line type you indicate to account for the rounding adjustment. The line amount of the designated line type is adjusted accordingly to account for any rounding corrections within the application rule set.

Receipt Classes and Methods

Remittance Methods and Clearance Methods

Define a remittance method and clearance method for each receipt class. These settings determine the remittance and clearing behavior for receipts with a given receipt class.

Standard: Use the remittance account for automatic receipts assigned to a receipt method with this receipt class.
Factoring: Use the factoring account for automatic receipts assigned to a receipt method with this receipt class.
Standard and Factoring: Receivables selects receipts assigned to this receipt class for remittance regardless of the batch remittance method. In this case, you can specify either of these remittance methods when creating your remittance batches.
No Remittance: For Manual receipts only. Remittance is not required for manual receipts assigned to this receipt class.

Clearance Methods

Use the clearance method to require receipts created using a receipt method assigned to this receipt class to be reconciled before posting them to the general ledger cash account.

Directly

This method is for receipts that you don't expect to be remitted to the bank and subsequently cleared.

It is assumed that these receipts are cleared at the time of receipt entry and require no further processing.

By Automatic Clearing

Use this method to clear receipts using the Clear Receipts Automatically program.

Note: You can also clear receipts using this method in Cash Management.

By Matching

Use this method to clear receipts manually in Cash Management.

Related Topics

Guidelines for Defining Automatic Receipt Methods

Define the attributes of an automatic receipt method to determine how automatic receipts are processed against selected transactions.

Review these guidelines when defining the attributes of automatic receipt methods:

Receipts Inherit Transaction Numbers
ISO Direct Debit
Number of Receipts Rule
Receipt Maturity Date Rule
Automatic Print Template
Lead Days
Customer Payment Method

Receipts Inherit Transaction Numbers

If you are using One per Invoice as the Number of Receipts Rule, you can enable the Receipts inherit transaction numbers option to ensure that the automatic receipt number is always the same as the transaction number to which it is applied. Enabling this option helps track automatic receipts.

Note: Do not enable this option if you are using document sequencing with automatic receipts.

ISO Direct Debit

Enable the ISO direct debit option to create automatic receipts that automatically debit a customer bank account according to the standards of ISO 20022 direct debit.

Enabling this option assumes that you have created a debit authorization agreement with your customers for ISO 20022 direct debit.

Number of Receipts Rule

The Number of Receipts Rule determines the way in which the automatic receipt process creates and applies receipts against transactions.

Note: If you enable the ISO direct debit option, the Number of Receipts Rule is disabled. ISO 20022 direct debit creates one receipt for the prearranged debit amount from your customer and transfers this amount to the remittance bank account defined in the automatic receipt method.

Select one of these rules:

One per Customer: Create one receipt for each customer.
One per Customer Due Date: Create one receipt for each customer and due date. This option creates several payments for a customer if the invoices of the customer have several due dates.
One per Invoice: Create one receipt for each invoice.
One per Site: Create one receipt for each customer site.
One per Site Due Date: Create one receipt for each customer site and due date.

Note: The Number of Receipts Rule assumes an additional grouping by payment instrument. For example, if you use the One per Customer rule, and two invoices belonging to the same customer are to be paid from different bank accounts, the automatic receipt process creates two receipts, one for each bank account number.

Receipt Maturity Date Rule

Use the Receipt Maturity Date Rule to pay invoices that have different due dates with a single receipt.

Select Earliest to use the earliest due date of all of the invoices that the receipt covers as the receipt maturity date. Select Latest to use the latest due date of all of the invoices that the receipt covers as the receipt maturity date.

When you remit a receipt, Receivables uses the maturity date to determine when to transfer funds from the customer bank account to your remittance bank account.

Automatic Print Template

Enter the automatic print template to use for transmissions using this receipt method.

Receivables provides one standard receipt print template to format the output of payment selection and creation programs when you create the receipt document. To use a different receipt print template, you must copy and modify this standard receipt print template.

Lead Days

The number of lead days is the number of days before the invoice due date that an invoice can be selected for application by the automatic receipt process using this receipt method.

This option is useful, for example, when customer approval is required. You can set the value to the number of days normally required to receive customer approval.

Customer Payment Method

Select the funds capture payment method that the customer will use to remit payment for automatic receipts using this receipt method.

Note: If you enable the ISO direct debit option, Bank Account Transfer is the only payment method available.

Oracle Payments provides predefined funds capture payment methods, but you can define your own.

Related Topics

Fund Transfer Error Handling on Automatic Receipts

Define fund transfer error handling on automatic receipt methods to manage error correction during automatic receipt processing.

You define fund transfer error handling to automatically correct errors encountered either during credit card authorization or payment capture, or during bank account transfer.

You set up error handling in the Fund Transfer Error Handling section of the Automatic Processing tab of the Create or Edit Receipt Class and Methods page, for the applicable automatic receipt methods.

Note: Credit card services are currently not available in Oracle Cloud implementations.

Mapping Third-Party Error Codes

To define fund transfer error handling for a given automatic receipt method, you map the error codes from a third-party credit card provider or financial institution to the corrective actions in Receivables for each category of transaction.

When an error occurs during payment processing of automatic receipts with the specified receipt method, Receivables applies the corrective action that corresponds to the given third-party error code.

Map each error code to a corresponding action for each category of transaction. This table indicates the corrective actions available for each category:

Category	Available Actions
Invoice, Debit Memo, Credit Memo	Clear Payment Information, Retry
Receipt	Retry, Reverse Receipt
Refund	Retry, Reverse Receipt

Mapping Error Codes: Example

You map a credit card provider error code of GW-0062 to the Invoice category and the Retry action.

When credit card authorization fails and the credit card provider returns the error code of GW-0062 for multiple transactions, then Receivables automatically deletes this error code on these failed transactions. These transactions then become available for inclusion in the next automatic receipt batch.

Remittance Bank Accounts on Receipt Methods

Define remittance bank account information for each receipt method assigned to a receipt class. Remittance bank account information includes the general ledger accounts to use when you enter or apply receipts.

Remittance Bank Accounts and Receipt Currencies

If you remit receipts in one currency only, you can enter more than one remittance bank account for a receipt method, but you must mark one account as the primary bank account for the receipt method.

If you remit receipts in more than one currency for a receipt method, then you must enter at least one remittance bank account per currency and mark one account per currency as primary.

During receipt entry and processing, Receivables uses the primary bank account as the default remittance bank account for the receipt. You can accept this value or enter any other bank account defined for the receipt method that is in the same currency as the receipt.

Factored Receipts

If the receipt class of the receipt method allows factoring, you can specify the number of Risk Elimination Days for factored receipts for a given bank account.

When you factor receipts, Receivables creates a short term debt to account for risk in case of customer default. When you clear or risk eliminate these receipts, the debt is cleared after the receipt maturity date plus the number of risk elimination days that you enter.

Related Topics

Considerations When You Create Accounts

FAQs for Receipt Classes and Methods

What creation method should a receipt class have?

Use an Automatic creation method to use the automatic receipt process to create a batch of receipts from selected transactions. For automatic receipts, Payments is responsible for the funds capture process. Use a Manual creation method for receipts either entered manually or imported using lockbox.

What's the relationship between the receipt class and receipt methods?

The receipt methods assigned to a receipt class account for receipt entries and applications. They also determine the customer remittance bank information.

The receipt class determines the processing steps that are required for receipts. These steps include automatic or manual creation, the remittance method, the bank clearance method, and whether receipts require confirmation by the customer.

What legal entity is assigned to a receipt?

Legal entities are linked to remittance and internal bank accounts. The receipt method determines which remittance bank account, and therefore which legal entity, is assigned to a receipt.

All receipts inherit the legal entity from the bank account, and all refunds inherit the legal entity of the original receipt.

You can perform receipt applications across legal entities, if the receipt and the transactions to which it is applied are in the same business unit. Receipt applications and receipt clearing across legal entities is recorded in the subledger as intercompany accounting.

Lockbox

MATCHING1_DATE - MATCHING8_DATE

For matching dates.

Destination

RESOLVED_MATCHING_NUMBER1-8

For resolved matching numbers.

Program determines the numbers.

Destination

RESOLVED_MATCHING1_DATE - RESOLVED_MATCHING8_DATE

For resolved matching dates.

Program determines the dates.

Destination

MATCH_RESOLVED_USING

For a match resolved.

Program determines the value.

Validation

Destination

Receipt Application using the Match Receipts By Rule

During lockbox and manual receipt processing, Receivables uses the settings of the Match Receipts By rule to identify the document type to use to match receipts to transactions when customer information is not available.

Document Types for Receipt Matching

The following six document types are used to match receipts to transactions. During receipt processing, Receivables searches for one of these document types in this order:

Transaction number
Sales order number
Purchase order number
Balance forward billing number
Shipping reference
Contract number

Selection of the Match Receipts By Rule

When Receivables finds a document type with the same number as the current search to match the receipt with a transaction, the process checks the locations where Match Receipts By rules are enabled in this order:

Customer bill-to site
Customer
Lockbox (for lockbox processing)
System options

Receivables looks for a rule that matches the document type of the number in the current search, and stops when a value is found. For example, if Receivables finds a matching transaction number in the first search, it checks the customer site for the Match Receipts By rule. If the rule is set to Transaction, Receivables matches the receipt with this transaction and applies the receipt.

If the Match Receipts By rule at the customer site is a document type other than Transaction, Receivables searches for a number that matches this document type.

If there are no values assigned at the customer site or customer level:

For lockbox processing, Receivables uses either the Match Receipts By rule assigned to the lockbox or, if the Use match criteria to determine customer option is enabled, the entire document type hierarchy.
For manual receipt processing, Receivables uses the Match Receipts By settings on the Receivables system options record assigned to the business unit.

If Receivables can't find a match after searching each document type, the process applies the receipt using the AutoCash rule set defined for the customer.

If the AutoCash rule set is unable to apply the receipt, Receivables assigns the receipt a status of Unapplied. You must then manually apply the receipt.

Examples of Matching Rules

Here are two examples of using matching rules.

Example 1: During lockbox processing, a receipt record indicates that a receipt should be applied to open debit item 12345. Receivables first searches for a transaction (invoice, debit memo, chargeback) with this number. Receivables finds an invoice with this number, so the process checks the value of the Match Receipts By parameter at the customer site. The Match Receipts By rule is null for this customer site, so Receivables checks the setting in the customer profile. Match Receipts By is set to Transaction in the customer profile, so Receivables matches and applies the receipt to the invoice.

Example 2: Using the same receipt record information as Example 1, assume that Receivables fails to find a transaction with the number 12345. The process then searches for a sales order with this number. Receivables can't find a sales order with this number, so it now searches for and finds a purchase order with number 12345. Receivables then checks the Match Receipts By rule at the customer site. The Match Receipts By rule is null for this customer site, so Receivables checks the setting in the customer profile. The rule is also null in the customer profile, so Receivables checks the rule for the lockbox. The Match Receipts By rule is set to Purchase Order Number for this lockbox, so the process matches the receipt with this purchase order and applies the receipt to the transaction.

Related Topics

FAQs for Lockbox

Why can't I find a receipt source in the lockbox?

Receipt sources are created and assigned to a particular business unit. Lockboxes are created and assigned to a particular lockbox set. The receipt sources available for use with a given lockbox are limited to the receipt sources created and assigned to the business units that belong to the lockbox set.

To define a receipt source for use with lockbox, use these settings:

Set Receipt Source Type to Manual.
Provide both a default Receipt Method and a default Bank Account.
Set Batch Numbering to Automatic.

How can I calculate the lockbox batch size?

Use the Batch Size field to enter the number of receipts to assign to each receipt batch during lockbox processing. For example, if you have 991 receipts, and you set the batch size to 10, the lockbox process creates 99 batches with 10 receipts and one batch with one receipt.

If you do not want the lockbox process to separate your lockbox submission into multiple receipt batches, complete these steps:

Enter a number that is larger than the number of receipts in the lockbox transmission for this lockbox.
Enable the Complete batches only option when you submit your lockbox transmission.

How can I use the accounting date source?

The value in the lockbox Accounting Date Source field determines the accounting date to apply to the receipts in the lockbox.

The accounting date source values for lockbox processing are:

Constant Date: Use the accounting date that you enter in the lockbox transmission.

If you do not enter an accounting date, the lockbox process does not validate your data.
Deposit Date: Use the deposit date that you enter in the lockbox transmission. This is the date that your remittance bank deposits your receipts.

If you do not enter a deposit date, the lockbox process displays an error and prompts for a deposit date to submit the lockbox.
Import Date: Use the date you import receipts.

How does AutoApply manage invalid transaction numbers?

If lockbox uses AutoApply, then the lockbox process attempts to match customers to receipts and receipts to transactions based on your setup.

If lockbox cannot fully apply a receipt due to invalid transaction numbers, then it manages the additional amounts according to the Post Partial Amount as Unapplied option. Receipts are applied to valid transactions, and the remaining receipt amounts are marked as Unapplied.

Transmission Formats for Lockbox

How Lockbox File Transmissions Are Validated

The first step in lockbox processing is validating the data imported from your bank file using the lockbox file transmission.

The lockbox process validates the data that you receive from the bank to ensure that:

the entire file was received.
there are no duplicate receipts within a batch.
the customers and transactions are valid.

Lockbox also validates that all data is compatible with Receivables by ensuring that the columns in the AR_PAYMENTS_INTERFACE_ALL table reference the appropriate values and columns in Receivables.

Settings That Affect Lockbox Validation

Lockbox checks for duplicate receipts and transactions.

Duplicate receipts have the same receipt number, amount, currency, and customer account number. Lockbox doesn't allow duplicate receipts within the same receipt source for the same customer. This is the same validation Receivables performs when you manually enter receipts.

Transaction numbers are only required to be unique within a receipt source. A customer can have duplicate transaction numbers as long as they belong to different receipt sources. However, lockbox can't automatically apply a payment to these transactions.

If a customer has more than one transaction in the lockbox transmission with the same number, then lockbox can't determine to which transaction to apply the payment. In this case, the receipt is either left as Unapplied (if the customer account number or MICR number is provided) or Unidentified (if the customer account number or MICR number is not provided).

You can manually apply the receipt according to the transaction recommendations that Receivables presents according to your implementation.

How a Lockbox Transmission Is Validated

When you import a bank file, lockbox completes the following validations:

Transmission Level Validations
Lockbox Level Validations
Batch Level Validations
Receipt Level Validations
Overflow Level Validations
Customer Validations
Currency Validation

Transmission Level Validations

Lockbox validates the lockbox transmission to ensure that transmission information corresponds to the transmission format. The following attributes are validated:

Transmission format contains receipt records.
Either the lockbox number is part of the transmission format, or you specify the lockbox number when you submit the lockbox.
Accounting date is in an open accounting period.
Total transmission record count and amount that you supply must match the actual receipt count and amount that is determined by lockbox. If the transmission format includes the transmission header or trailer, lockbox counts all records in this transmission. The validated count includes all receipts and detail records transferred to the interim table.
Origination number is valid, if it is provided.

Lockbox Level Validations

Lockbox validates the lockbox records to ensure that lockbox information corresponds to the transmission format. The following attributes are validated:

If the transmission format includes the transmission header or trailer, ensure that the lockbox number is included and is valid.
Lockbox batch count is correct, if it is provided.
Lockbox amount is correct, if it is provided.
Lockbox record count is correct, if it is provided.
Origination number is valid, if it is provided.
No duplicate lockbox numbers.

Batch Level Validations

Lockbox validates the batch records to ensure that batch information corresponds to the transmission format. The following attributes are validated:

Batch name exists on batch records.
Batch name is unique within the transmission.
Batch amount is correct.
Batch record count is correct.
Lockbox number exists on batch records, if this number is part of the transmission format.

Receipt Level Validations

Lockbox validates the receipt records to ensure that receipt information corresponds to the transmission format. The following attributes are validated:

Remittance amount is specified.
Check number is specified.
Item number is specified and is unique within a batch, a lockbox, or the transmission, depending on the transmission format.
Lockbox number is specified (if this number is not part of the lockbox header or trailer of the transmission format) and batches are not imported.
Batch name is specified, if either batch headers or trailers are part of the transmission format.
Account number is specified, if transit routing number is part of the transmission format.
Invoice1-8 are either valid or left blank.
Installment1-8 are either valid installment numbers or are left blank.
Invoice, debit memo, credit memo, on-account credit, or chargeback number derived from the matching number doesn't belong to a receipt.
Transaction number is entered where an application amount is specified.
Sum of all of the Amount Applied columns for a receipt doesn't exceed the remittance amount.
Customer account number is valid.
Customer account number and MICR number both reference the same customer, if both are provided.
Receipt date is specified.
Receipt method is valid.
Currency is valid.

Overflow Level Validations

Lockbox validates the overflow records to ensure that overflow information corresponds to the transmission format. The following attributes are validated:

Batch name is specified, if either batch headers or trailers are part of the transmission format.
Lockbox number is specified, if either the batch header or trailer is not specified and the transmission format includes the lockbox number.
Item number is specified and matches a receipt record.
Overflow indicator is specified, unless it is the last overflow record.
Overflow sequence is specified.
Invoice1-8 are either valid or are left blank.
Installment1-8 are either valid installment numbers or are left blank.
Transaction number derived is entered where an application amount is specified.

Note: For Receipt and Overflow validations of Invoice1-8: If you are using matching numbers and a receipt record indicates that multiple transactions are to be paid by this receipt, lockbox assumes that all of the transactions are the same document type, such as invoices, sales orders, or purchase orders.

For example, if the first 2 transactions are invoices, lockbox successfully matches them with this receipt. However, if the next transaction is not an invoice, lockbox either imports the remaining receipt amount as Unidentified or rejects the entire receipt, depending on the lockbox definition.

If lockbox imports the remaining receipt amount as Unapplied, then Receivables retains the invalid matching numbers.

Customer Validations

Lockbox can either validate customer data based on the following attributes or mark the receipt as Unidentified if no match is found:

Customer account number is valid.
MICR number is valid.
Bill-to customer is from a matched invoice, if matching is enabled.

Currency Validation

Receivables lets you process receipts in multiple currencies. If you pass the currency, conversion type, and receipt date, lockbox attempts to determine the conversion rate. If lockbox is unable to determine the conversion rate, the receipt will fail validation.

Related Topics

Lockbox Standard Receipt Import Process

Lockbox Transmission Formats

Lockbox receipt processing makes use of transmission formats, also called control files (.ctl), to specify how the data in a bank file is organized for import into the Receivables interface tables.

The control files are based on industry standards that are used by many banks for transferring lockbox receipts.

During Lockbox receipt processing:

The Load Interface File for Import process identifies the control file to use based on the prefix of the bank file name. For example, because the file Arlockboximportbai2_mmddyyyy.dat begins with arlockboximportbai2, the process uses this transmission format.
The Lockbox validation process uses the structure of the transmission format to ensure that data is transferred from the bank file to the tables correctly.

BAI (arlockboximportbai.ctl): Original format created by the Bank Administration Institute.
BAI 2.0 (arlockboximportbai2.ctl): Updated format created by the Bank Administration Institute.
BAI2 Extended (arlockboximportextbai2.ctl): Updated format that provides some extended field lengths.
ORA_BAI2-EXTENDED_GENERIC (arlockboximportgenbai2.ctl): Updated format similar to the BAI2 Extended format with field lengths similar to database table field lengths holding comparable data.
EDI823 (arlockboximportedi823.ctl): Format used in an Electronic Data Interchange (EDI) environment.
Receivables Standard Receipt Import (FBDI) (arlockboximportc.ctl): Format similar to Cloud FBDI process control files. These files provide a comma-delimited data file with a corresponding macro-enabled spreadsheet template.
Zengin Format for Japan (ORA_ZENGIN_LOCKBOX) (arlockboximportzenginr.ctl): Format that identifies Japanese customers using the alternate payer name.

Lockbox Transmission Format Record Types

Enter the record types to include in a lockbox transmission format. Use the Identifier column to uniquely identify each record type.

Your bank file might not contain all of these record types. You should define your transmission format to only include the record types you actually use.

Batch Header: A Batch Header marks the beginning of a specific batch. Batch Headers usually contain information such as batch number, deposit date, and lockbox number.
Batch Trailer: A Batch Trailer marks the end of a specific batch. Batch Trailers usually contain information such as batch number, lockbox number, batch record count, and batch amount.
Lockbox Header: A Lockbox Header marks the beginning of a specific lockbox. Lockbox Headers usually contain information such as destination account and origination number.
Lockbox Trailer: A Lockbox Trailer marks the end of a specific lockbox. Lockbox Trailers usually contain information such as lockbox number, deposit date, lockbox amount, and lockbox record count.
Overflow Receipt: An Overflow Payment usually contains invoice information for a specific payment, such as batch number; item number; sequence number; overflow indicator; invoice, debit memo, or chargeback number; and debit item amounts. Receivables combines the overflow and payment records to create a logical record to submit payment applications.
Receipt: A Receipt usually contains payment information such as MICR number, batch number, item number, check number, and remittance amount.
Service Header: Service Header records contain general information about the transmission.
Transmission Header: A Transmission Header marks the beginning of a specific data file. Transmission Headers usually contain information such as destination account, origination number, deposit date, and deposit time.
Transmission Trailer: A Transmission Trailer marks the end of a specific data file. Transmission Trailers usually contain information such as total record count.

Lockbox Transmission Format Field Types

Enter the lockbox transmission field types to use to identify the characteristics of each lockbox transmission record type.

You specify the size, order, and format of each transmission record. The lockbox transmission program only validates the fields that you define in your transmission format. The transmission format must be fully compatible with how you organize data in your lockbox file.

Account: Your customer bank account. The bank account number and the transit routing number make up your customer MICR number.
Alternate Name: The alternate name for this customer.
Amount Applied 1 to 8: The amount applied to each invoice, debit memo, or chargeback. Each payment or overflow payment record can accommodate up to eight debit item numbers. For cross-currency applications, this is the amount to apply in the transaction currency.
Amount Applied From 1 to 8: Used for cross-currency receipt applications, this is the amount applied to each transaction in the receipt currency. Each payment or overflow payment record can accommodate up to eight debit item numbers.
Attribute 1 to 15: Use attributes to enter descriptive flexfield segments. Attributes can only be assigned to payment records.
Bank Transaction Code: A code defined for each account that is used by your bank to uniquely identify the kind of transaction in a bank statement (for example, debit, credit, void). This is also used by Cash Management to determine the receipt effective date.
Batch Amount: The total receipt batch amount for a specific bank batch.
Batch Name: The name of the batch for a specific bank batch.
Batch Record Count: The total number of payment records in a specific bank batch. The total number of all batch record counts equals the Lockbox Record Count. This doesn't include overflow payments, headers, or trailers.
Billing Location: Your bank transmits the billing location of the payment. You must only specify the field name and the field positions that the billing location occupies in the transmitted data file.
Comment: Any comments you want to associate with this transmission.
Conversion Rate: The conversion rate associated with this payment, if you are using lockbox to import foreign currency receipts.
Conversion Type: The conversion type used to convert a foreign currency receipt to the ledger currency.
Currency: The currency of the payment. For cross-currency payments, you can also enter the Invoice Currency. If you don't enter a value in this field, lockbox derives the currency from the information that is provided in the Amount Applied 1 to 8 and Amount Applied From 1 to 8 fields.
Customer Bank Branch Name: The name of the customer bank branch.
Customer Bank Name: The name of the customer bank.
Customer Number: The identification number of the customer who submitted a payment.
Customer Reason 1 to 8: The customer reason why a payment shows a discrepancy.
Customer Reference 1 to 8: Customer comments about this payment.
Deposit Date: The date the bank receives and deposits the customer payment.
Deposit Time: The time the bank receives and deposits the customer payment.
Destination Account: Your business bank account. Your business may have more than one bank account.
Effective Date: The date on which the bank determines a customer balance to apply interest (used by Cash Management).
Invoice 1 to 8: The invoices, debit memos, and chargebacks to which you apply your payment. Each payment or overflow payment record can accommodate up to eight debit item numbers.
Invoice 1 to 8 Installment: The installment number for this invoice.
Invoice Currency 1 to 8: The currency of the transaction. This field is used for cross-currency receipt applications. This field is optional.
Item Number: A sequence number that your bank assigns to a specific payment. This number associates an invoice with a receipt.
Lockbox Amount: The total payment amount in a specific lockbox.
Lockbox Batch Count: The total number of bank batches in a specific lockbox.
Lockbox Number: The identification number for a specific lockbox.
Lockbox Record Count: The number of payment records in a specific lockbox. This doesn't include overflow payments, headers, or trailers.
Matching Date 1-8: The dates to use to match receipts with transactions, if you are using the Match on Corresponding Date option for this lockbox.
Origination: The bank origination number provided by your bank. This number uniquely identifies the bank branch that sends you lockbox information.
Overflow Indicator: Indicates whether there are any additional overflow records for this payment.
Overflow Sequence: A sequence number that your bank assigns to each overflow payment.
Receipt Method: The receipt method associated with this lockbox.
Payment Number: The identification number of a payment. For example, a check number.
Receipt Date: The date your customer made a payment.
Record Identifier: A number that identifies the kind of transmission record.
Remittance Amount: The amount of a payment.
Remittance Bank Branch Name: The name of the bank branch from which this payment originated.
Remittance Bank Name: The name of the bank from which this payment originated.
Status: The status of this payment.
Total Record Count: The total number of transmission records in a bank file. This includes headers, trailers, payments, and overflow records.
Trans to Receipt Rate 1 to 8: The conversion rate used to convert the receipt amount from the receipt currency to the transaction currency. This field is used for cross-currency receipt applications, when the receipt and transaction currencies don't have a fixed rate. If the currencies have a fixed rate, this field is optional (in this case, lockbox derives the rate to use).
Transit Routing Number: The number that uniquely identifies your customer bank. The transit routing number and the customer bank account number make up the customer MICR number.
Transmission Amount: The total amount of payments for a bank file.

FAQs for Transmission Formats for Lockbox

Can I reformat the transmission amount?

Yes, by using the Format Amount field setting. If you set this field to Yes, lockbox rounds the format amount to the same degree of precision and the same number of decimal places as your ledger currency.

For example, if your ledger currency is USD (precision = 2) and you set this option to Yes, a value of 50000 in the bank data file is formatted as 500.00. If you set the option to No, then this value is not formatted and would appear as 50000.

What's an overflow record?

An overflow record stores additional receipt information that can't fit on the receipt record. This is typically additional invoice numbers and the amount of the receipt to apply to each invoice.

Each overflow record must have a receipt record as a parent. If there are multiple overflow records for a receipt record, each overflow record is assigned an overflow sequence.

AutoMatch Rule Sets

How AutoMatch Recommendations Are Calculated

During receipt processing, Receivables applies receipts to transactions based on the transaction information provided. In cases where the transaction information provided doesn't exactly match the transaction numbers on record, the AutoApply process attempts to find as close a match as possible and either apply the receipt to the transaction automatically or present one or more transactions as recommendations for manual receipt application.

In like manner, during lockbox processing it may happen that a lockbox contains incomplete or inaccurate customer information. The AutoApply process attempts to match a customer to a receipt and present one or more customers as recommendations for the receipt.

The AutoMatch rule set provides information that is used by the AutoApply process to complete the process of applying receipts to transactions. The settings in the AutoMatch rule set provide these recommendations:

Customer recommendations: The matching process recommends customers for lockbox receipts that have invalid customer information.
Transaction recommendations: The matching process recommends one or more transactions for receipt application for both lockbox and manual receipts.

Settings That Affect AutoMatch Recommendations

Recommendations are based on matching threshold levels defined in the AutoMatch rule set. These threshold settings determine the percentage level necessary to consider a customer or transaction for receipt recommendation:

Customer Recommendation Threshold: The qualifying percentage necessary to add customer information to a receipt. If the calculated score for a customer account number is above this threshold, then the AutoApply process adds this customer information to the receipt.
Minimum Match Threshold: The qualifying percentage necessary to recommend a transaction for receipt application. If the calculated score for one or more transactions is above this threshold, the AutoApply process recommends the transactions for receipt application, in order of the highest percentage match.

Note: The minimum match threshold must be less than the customer recommendation threshold and the combined weighted threshold.
Combined Weighted Threshold: The qualifying percentage necessary for the AutoApply process to apply a receipt to a transaction automatically. This percentage is the sum of the qualifying percentages defined for the supplied customer information, transaction information, and actual transaction amount that is considered for receipt matching.
Days of Closed Invoices Threshold: Determines which closed transactions to include in the AutoMatch process. All transactions that were closed on or before the number of days provided as the threshold value are considered for application or recommendation.

How AutoMatch Recommendations Are Calculated

The threshold qualifying percentages defined in the AutoMatch rule set are compared to the resulting scores of each customer account number or transaction number that is analyzed by the matching process.

The matching process derives a recommendation in this way:

If applicable, remove characters and spaces from the number as defined by the AutoMatch rule set string handling.
Apply the formula (Levenshtein algorithm) to the resulting string to obtain the score. This formula is:
```
1 - (number of changes required to make the recommended string match the provided string / length of the larger string)
```
Compare the resulting score to the applicable threshold.

AutoMatch Recommendation: Example

The transaction number 10010 is provided by lockbox for a receipt application. This number doesn't exist, but Receivables finds the number AR10001. The recommendation for this number is calculated in this way:

The AutoMatch rule set string handling settings indicate that the first two characters are to be removed from a string under consideration.

Receivables removes AR, leaving the number 10001.
It will take one transposition for 10001 to match 10010. Therefore, the score for this match is (1 - 1/5) = 80%.
The 80% score exceeds the Combined Weighted Threshold value of 70%, so the receipt is automatically applied to transaction AR10001.

Related Topics

AutoMatch Combined Weighted Thresholds

When you define an AutoMatch rule set, use the weighted threshold fields to qualify the percentage necessary to allow for an automatic receipt application. This qualifying percentage considers the importance, or weight, that the AutoApply process should give to the three main components of a transaction: customer information, transaction information, and transaction amount.

How You Use the Combined Weighted Thresholds

Enter the weight, as a percentage, that the AutoApply process should give to the successful matching of customer, transaction, and amount information, when considering a transaction for automatic receipt application.

The total of the three percentages must equal 100. In most cases, you would not give equal weight to each component of a transaction. That is, you would not enter 33, 33, 34 as the three weighted values. In order for AutoApply to apply a receipt to a transaction automatically, the weighted thresholds you enter should reflect your standard business practices.

Enter these weighted thresholds:

Customer Weight: Enter the weight to give to matching the customer information on the transaction.
Transaction Weight: Enter the weight to give to identifying the correct transaction, either by correct matching or by the Match Receipts By rule document reference.
Amount Weight: Enter the weight to give to matching the open balance amount. Because the parts of a transaction amount can play a part in this decision, you can use the Amount Weight Exceptions section to provide additional granularity to the open balance amount considered.

The AutoApply process calculates the percentage score for each match between customer, transaction, and amount. It then derives a final score for each weighted threshold as a percentage of the weighted threshold values, and adds these results to obtain a final score. This final score is then compared against the combined weighted threshold value.

For example, you enter these weighted threshold values:

Weight	Value
Combined Weighted Threshold	75%
Customer	20%
Transaction	70%
Amount	10%

During lockbox processing, a transaction is presented for receipt application with these details:

Customer account number: 1001
Transaction number: 10010
Amount due remaining : 127
Amount after discount: 120.65
Tax remaining: 20
Freight Remaining: 7
Unearned Discount: 6.35

Lockbox presents a receipt for application with these details:

Customer account number: 1005
Reference number: 1001
Reference amount: 120.65

AutoApply performs these calculations:

Customer match: The match between account number 1001 and 1005 has a calculated score of 75% [(1-1/4)*100]. Since the customer weighted threshold value is 20%, this provides a final score of 15%.
Transaction match: The transaction match has a calculated score of 80% [(1-1/5)*100]. Since the transaction weighted threshold value is 70%, this provides a final score of 56%.
Amount match: The transaction amount match is 100%. Since the amount weighted threshold value is 10%, this provides a final score of 10%.

The sum of the three final scores is 81%, which is greater than the Combined Weighted Threshold value of 75%. Therefore, AutoApply automatically applies the receipt to the transaction.

Note: If the score were below the Combined Weighted Threshold value but above the Minimum Match Threshold value, then AutoApply would generate recommendations for user review. If the score were below the Minimum Match Threshold value, then AutoApply would not generate recommendations.

AutoMatch Amount Weight Exceptions

When you define an AutoMatch rule set, the values you enter in the Amount Weight Exceptions section qualify the meaning of the open balance amount that is considered by the Amount Weight threshold.

How You Use Amount Weight Exceptions

Enter threshold percentages to qualify the weight to give to different portions of the open balance amount on a transaction.

Enter these amount weight exception thresholds:

Net of Tax Weight: Enter the weight to give to the total transaction amount net of tax but including freight.
Net of Tax and Freight Weight: Enter the weight to give to the total transaction amount net of tax and freight.
Net of Freight Weight: Enter the weight to give to the total transaction amount net of freight but including tax.
Unearned Discount Weight: Enter the weight to give to transaction amounts that include an unearned discount.

If an exact match exists between the receipt amount and transaction amount, AutoApply uses the Amount Weight threshold value without reference to the amount weight exceptions.

If an exact match doesn't exist between the receipt amount and transaction amount, AutoApply looks for the best match among all of the amount weight exceptions to derive a percentage score.

For example, you enter these amount weight exception threshold values:

Weight	Value
Net of Tax Weight	70%
Net of Tax and Freight Weight	70%
Net of Freight Weight	80%
Unearned Discount Weight	60%

During lockbox processing, a transaction is presented for receipt application with these details:

Customer account number: 1001
Amount due remaining: 127
Amount after discount: 120.65
Tax remaining: 20
Freight Remaining: 7
Unearned Discount: 6.35

Lockbox presents a receipt for application with these details:

Customer account number: 1005
Reference amount: 120

Because no exact match exists between the transaction amount and the receipt amount, AutoApply looks for the closest match among the amount weight exceptions to derive an amount weight. There is an exact match between the receipt amount and the transaction amount net of freight (127 - 7 = 120). AutoApply therefore uses the Net of Freight Weight threshold value of 80% as the calculated score for the Amount Weight threshold.

How AutoMatch String Handling Works

The String Handling section of the Create and Edit AutoMatch Rule Set pages provides rules that assist in the search for transaction matches against the Match Receipts By document type reference used by AutoApply.

The rules indicate what part of a string to remove in order to compare the resulting stripped number against the matching numbers provided during receipt processing. Matching recommendations for the string are processed according to the weighted threshold values of the AutoMatch rule set.

You can define rules for transaction strings and remittance strings.

Settings That Affect String Handling

Use the string handling settings to indicate what part of a string to remove before string comparison. This is typically an alphanumeric prefix or suffix, or a string of zeros used to pad numbers to equal length.

Enter these settings:

String Location: Indicate whether to remove characters and digits from the Front or Back of the string.
String Value: Indicate the type of characters and digits to remove: Zero, Empty Spaces, or Any. Any includes zeros, spaces, and any character, digit, or special character.
Number of Characters: Indicate the number of places to remove.

How String Handling Is Used

If the string handling settings for a transaction number are:

String Location: Front.
String Value: Any.
Number of Characters: 5.

Then the string ABC: 10044 is converted to 10044. The string handling process removed the first 5 characters from the string: the alphanumeric characters ABC, the colon (:), and the space.

If the string handling settings for a transaction number are:

String Location: Back.
String Value: Zero.
Number of Characters: 3.

Then the string:

ABC: 10044000 is converted to ABC: 10044.
985660000 is converted to 985660.
985660000000003 is not processed. This is because AutoApply looks for zeros at the end of the string but finds a number instead.

Application Exception Rule Sets

Application Exception Rule Conditions and Actions

Use the Exception Rules section of the Create Receivables Application Exception Rule Set page to indicate how to process each overpayment and underpayment condition.

Each exception rule consists of:

A condition.
The amount and percentage that applies to the condition.
The action to take when the condition arises.

The Action field contains the Receivables activities that you have defined for Adjustment, Receipt Write-off, or Refund. The underpayment or overpayment amount is accounted for in the general ledger accounts belonging to the applicable Receivables activity.

The User Review Required option indicates whether the action is processed automatically or requires manual review and approval.

For example, the exception rule:

Over Payment >= 100 Refund

means that if a receipt application overpays a transaction by $100 or more, then the customer should receive a refund.

The exception rule:

Under Payment < 5 Write-off

means that if a receipt application results in an underpayment of less than $5, then the remaining amount can be written off.

You can use the Percent field with the Amount field to further refine the scope of a condition. If you use both fields, then both conditions must be met in order to apply the rule.

For example, the exception rule:

Under Payment < 5 5% Write-off

means that if a receipt application results in an underpayment that is both less than $5 and also less than 5% of the open balance, then the remaining amount can be written off. In this case, if a $10 open balance has a $4 underpayment, then this exception rule doesn't apply, because $4 is 40% of the open balance. If the $4 underpayment were for an open balance of $100, then the rule does apply, because $4 is 4% of the open balance.

Related Topics

FAQs for Application Exception Rule Sets

When do I use an application exception rule set?

Use an application exception rule set to manage remaining amounts after lockbox processing.

After lockbox processes and applies receipts, the AutoApply process uses the application exception rule set to determine how to manage over and under payments:

If there is an overpayment, the application exception rule indicates whether to refund the amount to the customer, place the amount on account, write off the amount, or leave the amount unapplied.
If there is an underpayment, the application exception rule indicates whether to allow write off of the remaining open balance amount on the transaction.

What's the difference between the AutoMatch rule set and the application exception rule set?

During lockbox processing, the AutoMatch rule set provides recommendations for matching receipts to transactions based on the transaction information provided. The AutoApply process attempts to match receipts to transactions and either apply receipts automatically or present for manual processing transaction recommendations for receipt application.

If the AutoApply process can apply the receipt to all of the transaction references automatically, then it uses the details of the application exception rule set to refund overpayment to the customer, if there is one, or process underpayment according to the exception rules.

If AutoApply can't apply the receipt to all of the transaction references automatically, then the remaining transaction recommendations are presented, if available, for manual processing and the application exception rule set is not used.

Note: If a receipt doesn't have a transaction reference, the application exception rule set for overpayments is not used.

Customer Paying Relationships

Customer Hierarchies and Paying Relationships

The customer hierarchy describes the structure of an enterprise or portion of an enterprise. Enterprise structures are defined and maintained in the FND_HIER tables. There are three predefined hierarchies: Customer hierarchy, Trading Community party hierarchy, and Duns and Bradstreet hierarchy.

You assign a paying relationship to a hierarchy to indicate how the parties in the hierarchy are able to manage each other's customer payments. There are two paying relationships:

Pay Any: Any party within the relationship can pay for the accounts of any other party within the relationship.
Pay Below: A parent-child relationship, whereby each party can pay for its own transactions and the transactions of all parties that are lower in the hierarchy (children, grandchildren, and so on).

This figure describes the customer hierarchy in Acme Corporation:

This figure illustrates a sample customer hierarchy,
with Acme Worldwide first in the hierarchy, then Acme USA and Acme
Japan as two equal branches of Acme Worldwide, and finally Acme West
as a branch of Acme USA.

Pay Any Paying Relationship

If this Acme Corporation hierarchy is assigned a Pay Any paying relationship, then:

Acme Worldwide can pay for Acme USA, Acme Japan, and Acme West.
Acme USA can pay for Acme Worldwide, Acme Japan, and Acme West.
Acme Japan can pay for Acme Worldwide, Acme USA, and Acme West.
Acme West can pay for Acme Worldwide, Acme USA, and Acme Japan.

Pay Below Paying Relationship

If this Acme Corporation hierarchy is assigned a Pay Below paying relationship, then:

Acme Worldwide can pay for Acme USA, Acme Japan, Acme West, and its own transactions.
Acme USA can pay for Acme West and its own transactions.
Acme Japan can pay for its own transactions.

Related Topics

How You Manage Hierarchies

FAQs for Customer Paying Relationships

What's the difference between an account relationship and a paying relationship?

An account relationship is a flat relationship between two customer accounts only. In an account relationship, either one account can pay for the transactions of another account (one-way) or both accounts can pay for the transactions of each other (reciprocal).

A paying relationship makes use of a hierarchical structure within an enterprise to allow all corresponding accounts and transactions that are associated with one party to be accessible to other parties in the structure. In a paying relationship either one account can pay for the transactions of accounts lower in the hierarchy (Pay Below) or all accounts anywhere in the hierarchy can pay for the transactions of any other party (Pay Any).

What happens if a customer hierarchy type is deactivated?

Then the active paying relationship assignments for this hierarchy are no longer valid. You must enter an end date for each related paying relationship assignment that is on or before the date the customer hierarchy type was deactivated.

FAQs for Receipt Sources

How does automatic batch numbering work?

The automatic receipt and remittance processes assign a number to an automatic receipt or remittance batch by adding +1 to the previous batch number. When you define the Automatic Receipts receipt source, enter a number in the Batch Number Starts After field as the starting point from which to increment the next automatic receipt batch number.

For example, to number automatic receipt batches starting with 1000, enter the number 999. The automatic receipt process adds +1 to each subsequent number as new batches are created.

Where are receipt sources used?

You only use receipt sources with receipt batches and remittance batches. This includes automatic receipt batches, lockbox receipts, and receipts created using a spreadsheet.

The Automatic Receipts receipt source is used automatically by the automatic receipt and remittance processes. You don't need to enter this receipt source.