Oracle Fusion Applications Financials Implementation Guide II

21 Define Common Accounts Receivable
Configuration
This chapter contains the following:
Simple Configuration to Operate Receivables: Explained
Notes Mapping for Receivables: Explained
Define Receivables Activities
Define AutoCash Rule Sets
Define Approval Limits
FAQs for Distribution Sets
Simple Configuration to Operate Receivables:

Explained
You can create an operational Oracle Fusion Receivables environment with
seven configurations. The remaining configurations are either optional or
have predefined values.
If applicable, your Receivables configuration must include a plan to migrate
your customer information from your legacy system.
Receivables Configuration Tasks

There are seven configuration tasks necessary to create an operational
Receivables environment. Before you perform these tasks, you must ensure
that you have completed all of the required implementation tasks for Oracle
Fusion Financials.
Perform these seven tasks in the order indicated:
1. Set Receivables System Options
Set Receivables system options to customize your Receivables
environment. During Receivables setup, you specify your accounts,
customer and invoice parameters, and how the AutoInvoice and
Automatic Receipts programs operate.
2. Define Receivables Activities
Define receivables activities to default accounting information for the
activities you need, such as miscellaneous cash, discounts, late
charges, adjustments, and receipt write-off applications.
3. Define AutoAccounting Rules

Defining AutoAccounting is a required configuration task for processing
customer billing.
Define AutoAccounting to specify how you want Receivables to
determine the default general ledger accounts for transactions.
Receivables creates default accounts for revenue, receivable, freight,
tax, unearned revenue, unbilled receivables, late charges, and
AutoInvoice clearing (suspense) accounts using this information.
4. Define Receipt Classes and Methods
Defining receipt classes and receipt methods is a required
configuration task for processing customer payments.
Receipt classes determine the required processing steps for receipts to
which you assign receipt methods with this class. These steps include
confirmation, remittance, and clearance. Receipt methods specify
accounting for receipt entries and applications, determine customer
remittance bank account information, and configure automatic receipt
processing and fund transfer error handling.
5. Define Remit-to Addresses
Define remit-to addresses to let your customers know where to send
payment for open receivables. Receivables uses the addresses to
provide default remit-to information when you enter transactions.
You must provide a remit-to address to complete a transaction.
If you use AutoInvoice, but have not defined a remit-to address for a
particular customer site, AutoInvoice rejects all transactions for which
it could not determine a remit-to address.
6. Define Approval Limits
Define approval limits to determine whether a Receivables user can
approve adjustments or credit memo requests. You define approval
limits by document type, amount, reason code, and currency.
7. Define Statement Cycles
Define statement cycles to control when you create customer
statements. You assign statement cycles to customer profiles.
Notes Mapping for Receivables: Explained

The Notes common component portlet is available on all Oracle Fusion
Receivables transaction pages. You can create, view, update and delete
notes on transactions throughout the entire transaction cycle: incomplete,
complete, posted.
There are two types of Notes: Internal and Private. Internal notes are
available to all users. Private notes are available to authors only.
There are three configuration tasks to perform to use the Notes portlet on
Receivables transactions.
Notes Mapping Configuration Tasks

There are three configuration tasks for Notes mapping to Receivables.
Perform these tasks in the order indicated:
1. Manage Receivables Note Type
Define the lookups you need for the Note Type.
2. Manage Receivables Note Type Mapping
Use the CRM component to map the Note Type to the Receivables
Transaction object (AR_TRANSACTIONS).
This table displays the predefined note type mapping for Receivables:
MAPPING_TYPE_C
OBJECT_CODE ODE
MAPPED_LOOKUP_C
Descripti
ODE
Meaning on
AR_TRANSACTI ZMM_NOTE_TYPE
ON
MAINTAIN (default)
Maintain
AR_TRANSACTI ZMM_NOTE_TYPE
ON
AR_APPROVAL
Receivabl Receivabl
es Credit es credit
Maintain
Receivabl
es
transactio
ns
Memo
memo
Request request
Approval approval
note type
3. Manage Receivables Note Descriptive Flexfields
You can optionally define descriptive flesfields for Notes. You can use
Notes descriptive flexfields on Receivables transactions to capture
additional information for your business requirements.
Define Receivables Activities

Receivables Activity Types
Receivables activity types provide the default accounting information for
each corresponding activity that take place in Oracle Fusion Receivables.
Using Receivables Activity Types

Adjustment
You use activities of this type when creating adjustments. You must create at
least one activity of this type.
There are also three related activities that are reserved for internal use only:
Chargeback Adjustment
Adjustment Reversal
Chargeback Reversal
You must define general ledger accounts for the Chargeback Adjustment
activity before creating chargebacks.
When you reverse a receipt, if an adjustment or chargeback exists,
Receivables automatically generates off-setting adjustments using the
Adjustment Reversal and Chargeback Reversal activities.
Bank Error
You use activities of this type when entering miscellaneous receipts. You can
use this type of activity to help reconcile bank statements using Oracle
Fusion Cash Management.
Credit Card Chargeback
You use activities of this type when recording credit card chargebacks. You
must define a general ledger clearing account for the Credit Card
Chargeback activity that Receivables provides before recording credit card
chargebacks.
Receivables credits the clearing account when you apply a credit card
chargeback, and then debits the account after generating the negative
miscellaneous receipt. If you later determine the chargeback is invalid, then
Receivables debits the clearing account when you unapply the credit card
chargeback, and then credits the account after reversing the negative
miscellaneous receipt. Only one Credit Card Chargeback activity within a
business unit can be active at a time.
Credit Card Refund
You use activities of this type when processing refunds to customer credit
card accounts. This activity includes information about the general ledger
clearing account to use to clear credit card refunds. You must create at least
one activity of this type to process credit card refunds.
Earned Discount
You use activities of this type to adjust a transaction if payment is received
within the discount period, as determined by the payment terms on the
transaction.
Late Charges
You use activities of this type to define a late charge policy. You must define a
Late Charges activity if you record late charges as adjustments against
overdue transactions. If you assess penalties in addition to late charges, then
define a separate Late Charges activity for penalties.
Miscellaneous Cash
You use activities of this type when entering miscellaneous receipts. The
Miscellaneous Cash activity use a distribution set to automatically distribute
miscellaneous cash across various accounts. You must create at least one
activity of this type.
If the Tax Rate Code Source for this activity is Activity, then you must define
asset and liability tax rate codes to account for tax on miscellaneous receipts
and miscellaneous payments.
Payment Netting
You use activities of this type when applying a receipt against other open
receipts. You must define a general ledger clearing account to use when
offsetting one receipt against another receipt. Only one Payment Netting
activity within a business unit can be active at a time.
Prepayments
You use activities of this type when creating prepayment receipts. You must
define a general ledger account for prepayment receipts that use the
Prepayments activity. Only one Prepayments activity within a business unit
can be active at a time.
Receipt Write-of
You use activities of this type when writing off receipts. You must define the
general ledger account to credit when you write off an unapplied amount or
an underpayment on a receipt.
Refund
You use activities of this type to process automated non-credit card refunds.
You must define the general ledger clearing account to use to clear refunds.
You must create at least one activity of this type. Only one Refund activity
within a business unit can be active at a time.
Unearned Discount
You use activities of this type to adjust a transaction if payment is received
after the discount period, as determined by the payment terms on the
transaction.
GL Account Source
When you define a receivables activity, you use the GL Account Sourceto
indicate how Oracle Fusion Receivables derives the accounts for the expense
or revenue generated by the activity.
GL Account Source Options
Activity GL Account
Allocate the expense or revenue to the general ledger account that you
specify for the receivables activity. If the activity type is Bank Error, Late
Charges, Prepayments, and Receipt Write-off, you can only select this option.
Distribution Set
Allocate the expense or revenue to the distribution set that you specify. This
value is only used with Miscellaneous Cash activities.
Revenue on Invoice
Allocate the expense or revenue net of any tax to the revenue accounts
specified on the invoice. If Tax Rate Code Sourceis set to None, allocate
the gross amount to these accounts. You can only choose this option if the
activity type is Adjustment, Earned Discount, or Unearned Discount.
If the revenue on the invoice is unearned, then AutoAccounting derives the
anticipated revenue accounting distribution accounts and amounts.
Receivables then uses this information to allocate the adjustment or discount
amount to these derived revenue accounts.
Tax Rate Code on Invoice
Allocate the net portion using the expense/revenue accounts specified by the
tax rate code on the invoice. If Tax Rate Code Sourceis set to None,
allocate the gross amount to these accounts. You can only choose this option
if the activity type is Adjustment, Earned Discount, or Unearned Discount.
Note
In the event of an adjustment to an invoice with zero amount revenue
distributions, the adjustment activity GL Account Sourcemust not be set to
Revenue on Invoice or Tax Rate Code on Invoice.
Tax Rate Code Source

When you define a receivables activity, you use the Tax Rate Code
Sourceto indicate how Oracle Fusion Receivables derives the tax rate code
for an activity.
Tax Rate Code Source Options

None
Allocates the entire tax amount according to the GL Account Sourceyou

specified. You use this option if you do not want to account for tax separately.
Activity
Allocate the tax amount to the asset or liability tax accounts specified by the
activity.
Invoice
Distribute the tax amount to the tax accounts specified by the tax rate code
on the invoice. You cannot choose this option if the activity type is
Miscellaneous Cash or Late Charges.
Note
In the event of a tax adjustment to an invoice with zero amount tax
distributions, the adjustment activity Tax Rate Code Sourcemust not be set
to Invoice.
If the Tax Rate Code Sourceis Activity or Invoice, you must indicate
whether tax for this activity is recoverable or non-recoverable.
Define AutoCash Rule Sets

Using AutoCash Rules: Examples
You create an AutoCash rule set from a combination of the five AutoCash
rules. You enter the rules in the order in which you want Oracle Fusion
Receivables to use them to apply a receipt to an open debit item.
The AutoCash rules are:
Match Payment with Invoice
Clear the Account
Clear Past Due Invoices
Clear Past Due Invoices Grouped by Payment Terms
Apply to the Oldest Invoice First
When you apply a receipt, Receivables uses the first rule in 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.
These examples illustrate how each rule applies receipts to transactions and
updates customer balances.
Match Payment with Invoice

The Match Payment with Invoice rule applies a receipt to a single invoice,
debit memo, or chargeback only if the receipt amount exactly 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 has the same amount
and due date, Receivables applies the receipt to the item with the lowest
payment schedule ID number (internal identifier).
Receivables uses the values specified for the AutoCash rule set open balance
calculation and the number of discount grace days assigned to the customer
profile to determine the remaining amount due on the debit item. The rule
ignores the value of the Apply partial receiptsoption.
For example, consider the following scenario:
Item/Option
Value
Discounts
Earned Only
Late Charges
No
Receipt
$1800
Receipt Date
14-JAN-03
Discount Grace Days
The invoice details are:
Invoice
Number
Invoice
Amount
Discou
nt
Payment
Terms
Invoice
Date
Due
Date
600
$2000
$20
10% 10/Net
30
01-JAN-03
30-JAN03
The payment terms assigned to this invoice include a 10% discount if the
invoice is paid within 10 days, and the open balance calculation on the
AutoCash rule set allows for 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 on the invoice on January 14 is $1800. Since the
remaining amount due matches the receipt amount, the receipt is applied. If
there had been no discount grace days, Receivables could not apply the
receipt because the remaining amount of the invoice would be $2000.
Clear the Account

The Clear the Account rule applies a receipt only if the receipt amount
exactly matches the customer open balance. Receivables includes all open
debit and credit items when calculating the customer open balance. Open
credit items include credit memos, on-account credits, and on-account and
unapplied cash. The rule ignores the value of the Apply partial
receipts option.
The Clear the Account rule uses the following equation to calculate the open
balance for each debit item:
Open Balance = Original Balance + Late Charges - Discount
Receivables then adds the balance for each debit item to determine the total
account balance. The rule uses this equation for each invoice, chargeback,
debit memo, credit memo, and application of an unapplied or on-account
receipt to a debit item.
profile to determine the customer open balance.
Item/Option
Value
Late Charges
Yes
Items in Dispute
Yes
Receipt
$590
This table shows the customer 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 the Late charges and Items in dispute options are enabled, the
open balance for this customer is $590. Because the receipt amount
matches the customer open balance, the receipt can be applied.
If the receipt amount did not exactly match the customer account balance,
Receivables would use the next rule in the set to attempt to apply the
receipt.
Clear Past Due Invoices

The Clear Past Due Invoices rule applies a receipt only if the receipt amount
exactly matches the customer past due account balance. Receivables
includes all open past due debit and credit items when calculating the past
due account balance. The rule ignores the value of the Apply partial
receipts option.
The Clear Past Due Invoices rule only applies the receipt to items that are
currently past due. A debit item is considered past due if the invoice due
date is earlier than or equal to the date of the receipt that is currently being
applied. Receivables uses the receipt date for unapplied and on-account
cash, and the credit memo date for credit memos and on-account credits, to
determine whether to include these amounts as part of the customer past
due account balance.
For example, if you apply a receipt with a receipt date of 10-JAN-03, all
unapplied and on-account cash, and all credit memos and on-account
credits, that have a transaction date (receipt date or credit memo date)
equal to or earlier than 10-JAN-03 are included when calculating the
customer past due account balance.
profile to determine the customer past due account balance. The settings of
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
customer past due account balance.
Item/Option
Value
Late Charges
No
Items in Dispute
No
Receipt
$420
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 the Late charges and Items in dispute options are not enabled,
Receivables does not include Invoice 89 ($250) or late charges for Invoice 7
($30) in the calculation of the customer past due account balance. Therefore,
the past due account balance for this customer is $420. Because the receipt
amount matches the customer past due account balance, the receipt is
applied. However, Invoice 7 and Invoice 89 are still open, past due debit
items.
Clear Past Due Invoices Grouped by Payment Terms

The Clear Past Due Invoices Grouped by Payment Terms rule applies a receipt
only if the receipt amount exactly matches the sum of the customer 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 payment terms and
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
date of the receipt that is currently being applied. For credit memos,
Receivables uses the credit memo date to determine whether to include
these amounts in the customer account balance.
For example, if you apply a receipt with a receipt date of 10-JAN-03, credit
memos that have a transaction date equal to or earlier than 10-JAN-03 are
included. Credit memos do not have payment terms, so they are included in
each group.
profile to determine the sum of the customer credit memos and past due
invoices. The settings of the Late charges andItems in dispute options
may prevent a past due debit item from being closed, even if the receipt
amount matches the sum of the customer credit memos and past due
invoices.
For example, consider a $900 receipt applied on 25-JUN. This table shows the
related customer activity:
Transaction Number
Payment Terms
Due Date Invoice Amount
25-MAY
$500
25-JUN
$200
25-JUN
$200
20-JUN
$900
25-MAY
$905
Receivables groups these transactions as follows:
Group 1: Transactions 1,2,3Amount: $900Group Due Date: 25-MAY
Group 2: Transaction 4Amount: $900Group Due Date: 20-JUN
Group 3: Transaction 5Amount: $905Group Due Date: 25-MAY
Since both Groups 1 and 2 match the receipt amount, Receivables selects
the group with the oldest due date (Group 1) and applies the receipt to the
transactions in this group.
Apply to the Oldest Invoice First

The Apply to the Oldest Invoice First rule applies receipts to customer debit
and credit items, starting with the item with the oldest due date. Receivables
uses the values specified for the AutoCash rule set open balance calculation
to determine the oldest outstanding item for the customer.
Item/Option
Value
Apply Partial Receipts
Yes
Late Charges
No
Receipt
$200
Invoice Number
Invoice Amount
Late Charges
Due Date
801
$0
$35
01-DEC-02
707
$450
$0
01-JAN-03
If you compare only the due dates for the two invoices, invoice 801 is the
oldest invoice. However, Receivables also checks the open balance
calculation and automatic matching rule options for the AutoCash rule set.
Since the Late charges option is not enabled, Receivables ignores invoice
801 (because the remaining amount only consists of late charges) and
applies the $200 receipt to invoice 707.
If the Apply partial receipts option were not enabled, Receivables could
not apply this receipt and would look at the next rule in the sequence.
Using an AutoCash Rule Set: Worked Example

This example demonstrates how to create and use an AutoCash rule set. You
create an AutoCash rule set to manage the payments received from Global
Freight Carriers. You have an earned discount arrangement with this
company but with no payment or discount grace days, and you do not add
late charges for payments received beyond the due date.
Creating the AutoCash Rule Set

Create the AutoCash Rule set using these values:
Field
Value
Open Balance Calculation: Discounts
Earned Only
Open Balance Calculation: Late Charges
No
Open Balance Calculation: Items in Dispute No

Automatic Matching Rules: Apply Partial
Receipts
Yes
Automatic Matching Rules: Remaining

Remittance Amount
On Account
AutoCash Rule
1. Match Payment with

Invoice
AutoCash Rule
2. Clear The Account
AutoCash Rule
3. Apply To The Oldest

Invoice First
Processing Payment Using the AutoCash Rule Set

Global Freight Carriers has the following outstanding invoices, none of which
are in dispute:
Numbe Amount
r
Remaining
Due
Date
Discount
Date
Discount
Amount
123
$200
11-DEC02
01-DEC-02
$20
124
$300
08-DEC02
30-NOV-02
$30
125
$150
13-DEC02
28-NOV-02
$15
A payment was entered for Global Freight Carriers for $600 with a deposit
date of 10-DEC-02.
Using the AutoCash rule set that you created, Oracle Fusion Receivables
processes the payment in this way:
1. AutoCash rule 1, Match Payment with Invoice, fails because none of the
customer open items have a remaining amount due that is equal to the
amount of the receipt ($600).
2. Receivables looks at AutoCash rule 2.
3. AutoCash rule 2, Clear the Account, fails because the customer
calculated account balance ($650) is not the same as the amount of
the receipt.
4. Receivables looks at AutoCash rule 3.
5. Receivables uses AutoCash rule 3, Apply to the Oldest Invoice First.
a. Receivables first applies the receipt to the oldest invoice, Invoice
124 for $300, and performs these calculations:
Since the discount date of 30-NOV-02 has passed and

the Discount field is set to Earned Only, the $30 discount
is no longer available. The amount due remaining for this
invoice is now equal to either $0 or the amount of any late

charges previously assessed for this item.
Because the Late charges option is set to No, late

charges are not included in the customer open balance
calculation. The remaining receipt amount is now $300.00.
b. Receivables now applies $200 to the next oldest invoice, Invoice

123, and performs these calculations:
As with Invoice 124, the discount date for Invoice 123 has
passed and the $20 discount is no longer available. The
amount due remaining for this invoice is now equal to
either $0 or the amount of any late charges previously
assessed for this item.
Because the Late charges option is set to No, late

charges are not included in the customer open balance
calculation. The remaining receipt amount is now $100.
c. Receivables applies the remaining $100 to Invoice 125 ($150) as

a partial receipt because the Apply partial receipts option is
set to Yes.
Note
If the Apply partial receipts option were set to No,
Receivables could not apply the remaining amount to
Invoice 125. Instead, it would be placed on account,
because the Remaining Remittance Amount option
is set to On Account.
As with the other invoices, the discount date for Invoice

125 has passed and the $15 discount is no longer
available.
If there are no late charges for this invoice, the amount due
remaining is reduced from $150 to $50, and remains open.
FAQs for AutoCash Rule Sets
How is an AutoCash rule set selected and used?
During payment processing, Oracle Fusion Receivables uses the Match

Receipts By rules to attempt to match receipts to open transactions, and
either apply receipts automatically or present recommendations for receipt
application.
If transactions cannot be matched or transaction information is not available,
Receivables uses the AutoCash rule set defined for the customer profile
either at the customer site or customer level to apply the receipt. If the
customer does not have an AutoCash rule set assigned to a profile,
Receivables uses the AutoCash rule set assigned to system options and the
number of discount grace days defined in the customer site or customer
profile to apply the receipt.
If none of the rules in the AutoCash rule set apply, Receivables places the
remaining amount either unapplied or on-account, depending on the setting
of the Remaining Remittance Amount option on the AutoCash rule set.
How can I use partial receipts?

Use the AutoCash rule set Apply partial receipts option with the Apply to
the Oldest Invoice First rule. If enabled, you can apply a receipt to a
transaction that is less than the amount required to close the debit item.
If the AutoCash rule set does not use partial receipts but does include late
charges in the open balance calculation, then Oracle Fusion Receivables can
interpret a receipt application against a transaction amount plus late charges
as a partial receipt.
For example, you intend to close a $100 transaction by applying a $100
receipt, but the transaction has since accumulated a $10 late charge. If
the Apply partial receipts option is not enabled, Receivables cannot apply
the $100 receipt to what is now a $110 open debit item.
Define Approval Limits

Approval Limits Document Types
You can define approval limits for the users in your system for specific
transactions and amount ranges per currency. The document types identify
the transactions that a user can approve.
Document Types
Adjustment
Define Adjustment approval limits by currency and amount. Oracle Fusion
Receivables uses approval limits that have a document type of Adjustment
when you create or approve an adjustment.
When you enter an adjustment that is outside your approval limit range,
Receivables assigns the adjustment a status of Pending until someone with
the appropriate approval limits either approves or rejects it.
Credit Memo
Define Credit Memo approval limits by reason code, currency, and amount.
The approval process sends a notification to an approver, if the credit memo
request is within the approval limit range for the currency and reason code
specified.
Receipt Write-of
Define Receipt Write-off approval limits by currency and amount. Receivables
uses approval limits with this document type whenever you attempt to write
off either an unapplied receipt amount or an underpayment on a receipt.
You cannot write off a receipt amount that is outside your approval limit
range. In addition, the approval limits for write-offs are separate from, but
cannot exceed, the system options write-off amounts.
Credit Memo Refund
Define Credit Memo Refund approval limits by currency and amount.
Receivables uses approval limits with this document type whenever you
attempt to electronically refund an on-account credit memo.
FAQs for Approval Limits
How can I manage the users that have approval limits?

You can only assign approval limits to valid users that are defined in your
system. The combination of user, document type, and currency identify a
specific approval limit record. You can, for example, define multiple approval
limit ranges for the same user and document type in each currency defined
in your system.
Be sure to update approval limits when personnel changes occur and, for
credit memo approvers, whenever you define new credit memo reason
lookups.
Why do credit memo approvals need a reason code?

The reason code identifies the kind of credit memo that is being requested.
An approver can only approve credit memo requests with the same reason
code.
Credit memo approval ranges cannot overlap for approval limits with the
same reason code and currency. For example, the approval range for the
primary approver JSMITH is from -200 USD to -100 USD and the reason code
is Free Product. Therefore, you cannot define a credit memo approval range
for the primary approver AJONES from -250 USD to -150 USD with this same
reason code.
You must identify a primary approver for all approval limits with the Credit
Memo document type.
FAQs for Distribution Sets

What are distribution sets?
Use distribution sets to account for miscellaneous, or non-invoice related,
receipts. Distribution sets are groups of general ledger accounting codes that
you define to determine the credit accounts for positive miscellaneous
receipt amounts and the debit accounts for negative receipt amounts.
22 Define Customer Billing Configuration

Set Up AutoInvoice
Define AutoInvoice Line Ordering Rules
Define AutoInvoice Grouping Rules
Define Payment Terms

Define AutoAccounting
Define Transaction Types
Define Transaction Sources
Define Memo Lines
Define Balance Forward Billing Cycles
FAQs for Salesperson Account References
FAQs for Remit-to Addresses
Set Up AutoInvoice
Setting Up Data for AutoInvoice: Points to Consider
To ensure that the AutoInvoice process works properly, you need to prepare
Oracle Fusion Receivables for any new data that you want to import. If your
original system uses any setup data which is not yet defined in Receivables,
you must define this data within Receivables before using AutoInvoice.
There are these points to consider when setting up data for AutoInvoice:
Data Checklist
AutoInvoice Setup
Transaction Flexfield
Data Checklist
Ensure that you have set up and updated the appropriate records in
Receivables and related applications.
Add or update this setup data:
Add or import customers, if your original system contains data for

customers that are not yet defined in Receivables.
Add units of measure, if your original system uses units of measure not
yet defined.
Add or update in Oracle Fusion General Ledger this data:

o
Currencies, if your original system uses currencies not yet

defined.
Accounting flexfield segment values, if your original system uses

values not yet defined.
Add or update in Oracle Fusion Tax this tax data:

o
Tax rates assigned to tax rate codes that are not yet defined.
Tax rates associated with products shipped to specific locations.
Full or partial customer and item tax exemptions.
Add or update these Receivables lookup codes:

o
Free on Board (FOB) lookup codes, if your original system uses

FOB point codes not yet defined.
Freight carrier lookup codes.
Add or update this Receivables data:

o
AutoAccounting (This is a required setup to use AutoInvoice)
Payment terms
Transaction types
Transaction sources
Salespersons
Revenue scheduling rules
AutoInvoice Setup
Review and update in Receivables data specific to AutoInvoice.
Review and update this data:
AutoInvoice Grouping Rules: Define additional grouping rules or update

the default grouping rule provided by Receivables. AutoInvoice uses
grouping rules to determine how to create transactions.
AutoInvoice uses the following hierarchy when determining the
grouping rule to use:
o
Transaction source
Customer site
Customer profile
System options
AutoInvoice Line Ordering Rules: Define line ordering rules for

AutoInvoice to determine how to order transaction lines. AutoInvoice
randomly orders lines on your transactions if you do not define line
ordering rules.
AutoInvoice Transaction Source Automatic Receipt Handling: If you

want AutoInvoice to automatically evaluate imported credits for receipt
handling, enable the Receipt Handling for Credits option on the
AutoInvoice transaction source.
Profile Options: Set these profile options for AutoInvoice:

o
ID Flexfield Code: Specify the ID of the flexfield code used by

AutoInvoice.
Maximum Lines per AutoInvoice Worker: Specify the

maximum number of lines per AutoInvoice worker.
Source Code: Specify the source code used by AutoInvoice.
Use Parallel Hint: Enable parallel hints in AutoInvoice.
AutoInvoice Gather Statistics Allowed: If you set this profile

option to Yes, then when you submit AutoInvoice, the program
first analyzes the interface tables (RA_INTERFACE_LINES_ALL,
RA_INTERFACE_DISTRIBUTIONS_ALL, and RA_INTERFACE
SALESCREDITS_ALL) and gathers statistics to determine how best
to execute the transaction import.
If the number of records to be imported and the number of

worker processes are approximately the same as the previous
submission of AutoInvoice, then you can set this profile option to
No and skip this analysis.
Transaction Flexfield
Receivables uses the transaction flexfield to uniquely identify each
transaction and transaction line you import using AutoInvoice. Transaction
flexfields are also used to refer to and link transaction lines.
You must define both a line-level and a header-level transaction flexfield. All
segments in the line-level transaction flexfield that refer to header
information must also exist in the header-level transaction flexfield. For
example, if you define a line-level transaction flexfield with four segments,
and only the last two segments refer to line-level information, define the
header-level transaction flexfield using the first two segments.
If you do not create Reference and Link-to transaction flexfields, then
Receivables will use the line-level transaction flexfield structure to link and
reference different lines. You do not have to define separate Reference and
Link-to transaction flexfields in this case.
However, if you are planning to create a customized form to enter interface
data to display the Reference and Link-to transaction flexfields, then you
must define these transaction flexfields. These flexfields must have the same
flexfield structures as the line-level transaction flexfield.
Define AutoInvoice Line Ordering Rules

Line Ordering Rule Transaction Attributes: Explained
AutoInvoice uses line ordering rules to determine how to order and number
each line after your transactions have been grouped into invoices, debit
memos and credit memos. You can specify a line ordering rule for each
grouping rule.
Transaction Attributes
Oracle Fusion Receivables provides the following transaction attributes from
the RA_INTERFACE_LINES_ALL table that you can use for AutoInvoice line
ordering rules:
ACCOUNTING_RULE_DURATION
ACCOUNTING_RULE_ID
ACCOUNTING_RULE_NAME
AMOUNT
ATTRIBUTE_CATEGORY
ATTRIBUTE1-15
FOB_POINT
INTERFACE_LINE_ATTRIBUTE1-15
INTERFACE_LINE_CONTEXT
ORIG_SYSTEM_SHIP_ADDRESS_ID
QUANTITY
QUANTITY_ORDERED
REASON_CODE
REASON_CODE_MEANING
REFERENCE_LINE_ATTRIBUTE1-15
REFERENCE_LINE_CONTEXT
REFERENCE_LINE_ID
SALES_ORDER
SALES_ORDER_DATE
SALES_ORDER_LINE
SALES_ORDER_SOURCE
SHIP_DATE_ACTUAL
SHIP_VIA
TAX_CODE
UNIT_SELLING_PRICE
UNIT_STANDARD_PRICE
UOM_CODE
UOM_NAME
WAYBILL_NUMBER
FAQs for AutoInvoice Line Ordering Rules
When does a grouping rule need a line ordering rule?

Assign an AutoInvoice line ordering rule to an AutoInvoice grouping rule
when you want to organize the transaction lines belonging to a transaction
created by the grouping rule in a specific order. Use the Order By Type to
specify whether to order the values belonging to a transaction attribute from
least to greatest (Ascending) or greatest to least (Descending).
For example, if you are importing transactions from Oracle Fusion Distributed
Order Orchestration, you can define a line ordering rule with the attribute
SALES_ORDER_LINE to list the items on the invoice in the same order as they
appear on the sales order.
Or, you can define a line ordering rule with the attribute AMOUNT and
an Order By Type of Descending to ensure that the highest invoice line
amounts are listed first on the transactions created by the grouping rule.
Define AutoInvoice Grouping Rules

Mandatory and Optional Grouping Rule Attributes: Explained
AutoInvoice grouping rules contain transaction attributes that must be
identical for all items on the same transaction. For example, transaction
number (TRX_NUMBER) is a mandatory attribute of all grouping rules. If you
have two records in the interface tables with different transaction numbers,
AutoInvoice creates separate transactions for each record.
Oracle Fusion Receivables provides both mandatory and optional transaction
attributes for imported transactions. You cannot delete a mandatory attribute
from any grouping rule, but you can add optional attributes to the mandatory
attributes to create a new grouping rule.
Mandatory Transaction Attributes

Receivables provides the following mandatory transaction attributes from the
RA_INTERFACE_LINES_ALL table that must apply to all transactions created
using AutoInvoice grouping rules:
COMMENTS
CONS_BILLING_NUMBER
CONVERSION_DATE
CONVERSION_RATE
CONVERSION_TYPE
CREDIT_METHOD_FOR_ACCT_RULE
CREDIT_METHOD_FOR_INSTALLMENTS
CURRENCY_CODE
CUSTOMER_BANK_ACCOUNT_ID
CUST_TRX_TYPE_ID
DOCUMENT_NUMBER
DOCUMENT_NUMBER_SEQUENCE_ID
GL_DATE
HEADER_ATTRIBUTE1-15
HEADER_ATTRIBUTE_CATEGORY
HEADER_GDF_ATTRIBUTE1-30
INITIAL_CUSTOMER_TRX_ID
INTERNAL_NOTES
INVOICING_RULE_ID
ORIG_SYSTEM_BILL_ADDRESS_ID
ORIG_SYSTEM_BILL_CONTACT_ID
ORIG_SYSTEM_BILL_CUSTOMER_ID
ORIG_SYSTEM_SHIP_CONTACT_ID
ORIG_SYSTEM_SHIP_CUSTOMER_ID
ORIG_SYSTEM_SOLD_CUSTOMER_ID
ORIG_SYSTEM_BATCH_NAME
PAYMENT_SERVER_ORDER_ID
PAYMENT_SET_ID
PREVIOUS_CUSTOMER_TRX_ID
PRIMARY_SALESREP_ID
PRINTING_OPTION
PURCHASE_ORDER
PURCHASE_ORDER_DATE
PURCHASE_ORDER_REVISION
REASON_CODE
RECEIPT_METHOD_ID
RELATED_CUSTOMER_TRX_ID
SET_OF_BOOKS_ID
TERM_ID
TERRITORY_ID
TRX_DATE
TRX_NUMBER
Optional Transaction Attributes

Receivables provides the following optional transaction attributes from the
RA_INTERFACE_LINES_ALL table that you assign to transaction classes within
an AutoInvoice grouping rule:
ACCOUNTING_RULE_DURATION
ACCOUNTING_RULE_ID
ATTRIBUTE1-15
ATTRIBUTE_CATEGORY
INTERFACE_LINE_ATTRIBUTE1-15
INTERFACE_LINE_CONTEXT
INVENTORY_ITEM_ID
REFERENCE_LINE_ID
RULE_START_DATE
SALES_ORDER
SALES_ORDER_DATE
SALES_ORDER_LINE
SALES_ORDER_REVISION
SALES_ORDER_SOURCE
TAX_CODE
TAX_RATE
Using AutoInvoice Grouping Rules: Example
This example illustrates how to use grouping rules to group transaction lines
into transactions during AutoInvoice import.
Scenario
Define an AutoInvoice grouping rule that specifies that to appear on the
same invoice, items must match on all mandatory attributes, such as
currency (CURRENCY_CODE) and customer bill-to address
(ORIG_SYSTEM_BILL_ADDRESS_ID), and must also match on the optional
attribute of sales order type (SALES_ORDER_SOURCE).
Transaction Details
During AutoInvoice import, assume that all mandatory attributes match

other than currency and customer bill-to address.
This diagram illustrates how three imported invoices are created according to
the AutoInvoice grouping rule defined in this example:
Analysis
Items A and B share the same currency and sales order type, so they appear
on the same invoice (Invoice 1). Item C has the same currency as A and B,
but it has a different sales order type, so it appears on its own invoice
(Invoice 2). Items D and E share the same currency and sales order type, so
they appear on the same invoice (Invoice 3).
Result
Because of the optional attribute of sales order type, AutoInvoice created

three invoices. If the grouping rule had designated only mandatory
attributes, then AutoInvoice would have created only two invoices.
FAQs for AutoInvoice Grouping Rules
Why did AutoInvoice reject transactions?

During AutoInvoice processing, if you have transaction lines that fail
validation, Oracle Fusion Receivables looks at the value of the Invalid
Linefield in the transaction source to determine the grouping of transactions.
If the value is Reject Invoice, then AutoInvoice rejects all of the transaction
lines that make up one invoice according to the grouping rule, if any one of
the transaction lines are invalid. For example, if a grouping rule specifies that
three transaction lines should be created as one invoice and one of the
transaction lines has an error, AutoInvoice rejects all three transaction lines
and does not create an invoice.
However, if the value is Create Invoice, AutoInvoice rejects the one invalid
transaction line and creates an invoice from the two remaining valid
transaction lines.
Why did AutoInvoice create transactions with duplicate

transaction numbers?
During AutoInvoice processing, Oracle Fusion Receivables validates that
transaction and document numbers are unique after grouping has
completed. In certain cases, AutoInvoice will create multiple invoices in the
same group with the same transaction or document number. Once grouping
is completed, AutoInvoice checks for duplicate transaction and document
numbers and reports any lines that fail validation.
For example, two lines are imported with the same transaction number, but
they have different currencies. These lines are split into two separate
invoices during grouping due to the different currencies. Once grouping has
completed, both of the invoices will fail validation due to identical transaction
numbers.
What happens if AutoInvoice processes a transaction class

that is not defined for a grouping rule?
If AutoInvoice uses grouping rules and it is processing a transaction class

that is not defined for a grouping rule, then AutoInvoice only uses the
mandatory transaction attributes to group transactions.
Define Payment Terms

Payment Terms: Explained
Use payment terms to identify due dates and discount dates on your
customer transactions. You assign payment terms to customer profiles or to
customer information on transactions.
Considerations for payment terms include:
Payment Terms and Discounts
Split Payment Terms with Installments
Prepayment Payment Terms
Payment Terms and Discounts

Define standard payment terms for your customers to specify the due date
and discount date for their open items. Payment terms can include a
discount percent for early payment, and you can assign multiple discounts to
each line of your payment terms.
For example, the payment terms named 2% 10, Net 30 indicates that a
customer is allowed a two percent discount if payment is received within 10
days; after 10 days, the entire balance is due within 30 days of the
transaction date with no applicable discount.
Enable the Allow discount on partial payments option to let your
customers take discounts for partial payments on items associated with
payment terms. A partial payment is a payment that is less than the
remaining amount due. If you do this, you must also ensure that
theDiscount on partial payment system option is enabled.
Use the Discount Basis field to determine what amount Oracle Fusion
Receivables uses to calculate discounts for the particular payment terms. If
the payment terms use installments, you can assign discount percentages to
each installment.
Split Payment Terms with Installments
Create split payment terms for invoice installments that have different due
dates. The payment terms determine the amount of each installment.
Use the Installment Option field to determine how to allocate the freight
and tax charged to transactions. You can either distribute tax and freight
charges across all installments, or allocate all freight and tax charges to the
first installment.
Define the payment schedule for the split payment terms. The payment
schedule determines when each installment is due, how much in each
installment is due, and how much discount to offer in each installment.
Prepayment Payment Terms

You can optionally define prepayment payment terms by enabling
the Prepayment option. You assign prepayment payment terms to
transactions to indicate which business transactions require prepayment for
goods and services.
Prepayment payment terms do not require the capture of funds in advance of
invoicing or the delivery of prepaid goods or services. You must establish
specific business practices at your enterprise if you want to capture these
funds in advance.
Installment Options and Amounts Due: Explained

Split payment terms derive different amounts due in each installment of the
payment schedule, depending on the setting of the Installment
Option field.
If the base amount is different from the relative amount, and you set
the Installment Option field to Allocate tax and freight, Oracle Fusion
Receivables prorates the base amount across the relative amounts of the
payment schedule based upon the ratio you define. Receivables uses the
following equation to determine the original amount due for each
installment:
Amount Due = Relative Amount/Base Amount * Invoice Amount
If you set the Installment Option field to Include tax and freight in first
installment, the base amount and the relative amounts that you specify for
the payment schedule only indicate how the original line amounts of the
invoices to which you assign these payment terms are distributed across
different installments.
In this case, the original freight and tax amounts are included in the first
installment, in addition to the line amount allocated by the ratio of the base
amount and the relative amount that you specify for the first payment.
Receivables uses the following equation to determine the original amount
due for the first installment:
Amount Due = (Relative Amount/Base Amount * Base Line Amount) + Base Freight
Amount + Base Tax Amount
Payment Terms Discount Basis

The payment terms Discount Basis field determines on what basis Oracle
Fusion Receivables calculates the discount amount.
Discount Basis
Invoice Amount
Calculates the discount amount based on the sum of the tax, freight, and line
amounts of transactions.
Lines Only
Calculates the discount amount based on only the line amounts of
transactions.
Lines, Freight Items and Tax
Calculates the discount amount based on the amount of line items and their
freight and tax amounts, but excludes freight and charges at the transaction
header level.
Lines and Tax, not Freight Items and Tax
Calculates the discount amount based on the line items and their tax
amounts, but excludes freight items and their tax lines.
Calculating Discounts: Explained
Oracle Fusion Receivables uses different formulas to calculate discounts,

depending on your setup, the payment terms on the transaction, and the
type of payment received.
Receivables provides formulas for these discount events:
Maximum Discount
Earned Discounts and Partial Payments Allowed
Unearned Discounts with Partial Payment Discounts Allowed
Earned Discounts with Partial Payment Discounts Not Allowed
Unearned Discounts and Partial Payments Not Allowed
Discount on Lines Only
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 option on the payment terms is
not enabled, 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 option on the payment terms is
not enabled, 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 field on the 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.
Deriving Discount Amounts: Example

This example illustrates how Receivables displays discount information based
on the apply date of the receipt.
When you enter receipts manually, Oracle Fusion 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 both earned and
unearned discounts, as determined by the details of your setup.
Scenario
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
17-DEC-10
NO
YES
10
12-DEC-10
NO
YES
Assume these invoice details:
Invoice #101
Invoice Date = 02-DEC-10
Due Date = 01-JAN-11
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
Receipt
Date
Amount
Default
Discount
Amount
From 02- $990

DEC-10
to 12DEC-10
$110
Messag
e Line
Earned
Unearned
Discount Discount
Allowed Allowed
Discount $110
Earned =
110
None
Total =
110
After 17- $990

DEC-10
0
To take the
unearned
discount,
you must
update the
amount.
From 02- $1000

DEC-10
$10 of the
to 12DEC-10 receipt is left as
Unapplied after
the default
discount.
$110
From 13- $1000

DEC-10
After the
to 17-
$52.63
Discount None
Earned =
0
$110
Total =
110
Discount $110
Earned =
110
None
Total =
110
Discount $52.63
Earned =
$57.37
DEC-10
discount of
$52.63 defaults,
the receipt is
fully applied.
However, there
is still a
remaining
balance of
$47.37 on the
invoice.
After 17- $1000

DEC-10
Since there is no
default discount,
the receipt is
fully applied.
There is a
remaining
balance of $100
on the invoice.
To take the
unearned
discount,
you must
update the
amount.
0
To take the
unearned
discount,
you must
update the
amount.
52.63
Total =
110
Discount None
Earned =
0
$110
Total =
110
FAQs for Payment Terms
What's the difference between balance forward payment

terms and other payment terms?
Balance forward billing payment terms pass the balance forward billing cycle
to the Create Balance Forward Bill program. The billing cycle determines
when customer balance forward bills are generated.
Because balance forward bills cannot be split across installments, all settings
related to installments on balance forward billing payment terms are
disabled. You cannot change existing payment terms back and forth for use
as both a non-balance forward billing and balance forward billing payment
terms.
Define AutoAccounting
AutoAccounting Account Types and Segment Values

Define AutoAccounting to specify how to determine the default general
ledger accounts for transactions that you enter manually or import using
AutoInvoice. You must define AutoAccounting before you can enter
transactions in Oracle Fusion Receivables. When you enter transactions, you
can override the default general ledger accounts that AutoAccounting
creates.
Account Types
Define an AutoAccounting record for each type of account. You can then
assign either a table name or constant value to each segment of the
account.
AutoInvoice Clearing
The clearing account for imported transactions. Receivables uses the
clearing account to hold any difference between the specified revenue
amount and the selling price times the quantity for imported invoice lines.
Receivables only uses the clearing account if you have enabled this option
on the transaction source used for imported transactions.
Freight
The freight account for transactions.
Receivable
The receivable account for transactions.
Revenue
The revenue and late charges account for transactions.
Tax
The tax account for transactions.
Unbilled Receivable
The unbilled receivable account for transaction. Receivables uses this
account when the transaction uses the In Arrears invoicing rule. If the
revenue scheduling rule on the transaction recognizes revenue before the

invoicing rule bills it, Receivables uses this account.
Unearned Revenue
The unearned revenue account for transactions. Receivables uses this
account when a transaction uses the In Advance invoicing rule. If the
revenue scheduling rule on the transaction recognizes revenue after the
invoicing rule bills it, Receivables uses this account.
Table Names
Enter either the table name or constant value that you want Receivables to
use to retrieve information for each accounting flexfield segment of a given
account.
Enter a constant value instead of a table name if you want AutoAccounting to
always use the same value for a given segment. You must ensure that you
enter information that is valid for this segment. For example, if you defined
your Company segment as a two-character segment with valid values
ranging from 00 to 10, you must enter a two-character value within this
range.
Bill-to Site
Use the bill-to site of the transaction to determine this segment of revenue,
freight, receivable, AutoInvoice clearing, tax, unbilled receivable, and
unearned revenue accounts.
Salesperson
Use the salesperson table to determine this segment of revenue, freight,
receivable, AutoInvoice clearing, tax, unbilled receivable, and unearned
revenue accounts.
If you select this option for AutoInvoice clearing, tax, or unearned revenue
accounts, Receivables uses the revenue account associated with the
salesperson on the transaction. If you select this option for the unbilled
receivable account, Receivables uses the receivable account associated with
the salesperson on the transaction.
If the transaction has a line type of Line with an inventory item of Freight,
AutoAccounting uses the revenue scheduling rules for the freight account
rather than the revenue account.
Standard Lines
Use the memo line or inventory item on the transaction to determine this
segment of revenue, AutoInvoice clearing, freight, tax, unbilled receivable,
and unearned revenue accounts.
If you select this option for AutoInvoice clearing, freight, tax, unbilled
receivable or unearned revenue accounts, Receivables uses the revenue
account associated to the memo line item or inventory item.
Tax
Use the tax account assigned to the tax rate codes on the transaction.
Transaction Types
Use the transaction types table to determine this segment of revenue,
freight, receivable, AutoInvoice clearing, tax, unbilled receivable, and
unearned revenue accounts.
AutoAccounting Structure: Points to Consider

To implement AutoAccounting, you first define your AutoAccounting structure
and then define information for each salesperson, transaction type, product,
and tax rate code in order for AutoAccounting to properly create your default
accounts.
You must define your AutoAccounting structure before you can enter invoices
and credit memos, and you can only define one structure for each account
type. During transaction creation, if AutoAccounting cannot determine all of
the Accounting Flexfield segments, it derives what it can and displays an
incomplete Accounting Flexfield. You must provide any missing Accounting

Flexfield information before you can complete a transaction.
There are these points to consider about creating your AutoAccounting
structure:
AutoInvoice Clearing Account
Freight Account
Receivable Account
Revenue Account
Tax Account
Unbilled Receivable Account
Unearned Revenue Account
Available Information for Each Account
This table indicates the information that you can use to create each type of
account. (Rec) and (Rev) indicate whether the account information is taken
from the corresponding Receivables or Revenue Accounting Flexfield.
Information
Source /
AutoAccounti Consta
ng Type
nt
Custom
er BillSalespers Transacti
to Site on
on Type
Tax
Rat
e
Standa Cod
rd Item e
AutoInvoice
Clearing
Account
Yes
Yes
Yes (Rev)
Yes
Yes
(Rev)
No
Freight
Yes
Yes
Yes
Yes
Yes
No
(Rev)
Receivable
Yes
Yes
Yes
Yes
No
No
Revenue
Yes
Yes
Yes
Yes
Yes
No
Tax
Yes
Yes
Yes (Rev)
Yes
Yes
(Rev)
Yes
Unbilled
Receivable
Yes
Yes
Yes (Rec)
Yes
Yes
(Rev)
No
Unearned
Revenue
Yes
Yes
Yes (Rev)
Yes
Yes
(Rev)
No
If AutoAccounting for the AutoInvoice Clearing, Tax, Unbilled Receivable, or

Unearned Revenue accounts is based on standard item, Receivables uses the
segment from the standard item Revenue Accounting Flexfield.
If AutoAccounting for the AutoInvoice Clearing, Tax, or Unearned Revenue
accounts is based on salesperson, Receivables uses the account segment
from the salesperson Revenue Flexfield. If AutoAccounting for Unbilled
Receivable is based on salesperson, Receivables uses the segment from the
salesperson Receivable Flexfield.
If the AutoInvoice Clearing, Revenue, Tax, Unbilled Receivable, or Unearned
Revenue accounts are based on salesperson and there are multiple
salespersons on the transaction, then Receivables creates separate
distributions for each salesperson.
AutoInvoice Clearing Account

During AutoInvoice processing, Receivables uses the AutoInvoice clearing
account to store any differences between the specified revenue amount and
the (price * quantity) for imported invoice lines.
Receivables only uses the AutoInvoice clearing account if you enabled the
Create clearing option on the transaction source assigned to imported
transactions. However, you must define a clearing account in any case.
You can use constant value, customer bill-to site, salesperson, transaction
type, and standard item for your AutoInvoice clearing account. If you select
salesperson or standard item, Receivables uses the specified Revenue
Flexfield.
Freight Account
The freight account controls the account in general ledger to which you post
freight amounts. You can use constant value, customer bill-to site,
salesperson, transaction type, and standard item to specify your freight
account.
If you choose standard item, Receivables uses the specified Revenue
Flexfield. In addition, you cannot import transactions with header-level
freight through AutoInvoice.
If the transaction has a line type of LINE with an inventory item of freight,
AutoAccounting uses the revenue scheduling rules for the freight type
account rather than the revenue type account.
Receivable Account
The receivable account controls the account in your general ledger to which
you post receivable amounts. You can use transaction type, customer bill-to
site, salesperson, and constant value to specify your receivable account.
Revenue Account
The revenue account controls the account in your general ledger to which
you post your revenue amounts. You can use transaction type, customer billto site, standard item, salesperson, and constant value to specify your
revenue account.
Tax Account
The tax account controls the account in your general ledger to which you
post tax amounts. You can use tax rate codes, customer bill-to site,
salesperson, transaction type, standard item, and constant value to specify
your tax account.
If you select salesperson or standard item, Receivables uses the specified

Revenue Flexfield.
Unbilled Receivable Account

Receivables uses the unbilled receivable account for transactions that have
invoicing and revenue scheduling rules. Whenever the revenue scheduling
rule recognizes revenue on the transaction before the invoicing rule bills it,
Receivables posts this amount to the unbilled receivable account.
You can select constant value, customer bill-to site, salesperson, transaction
type, and standard item for your unbilled receivable account.
If you select standard item, Receivables uses the specified Revenue Flexfield.
If you select salesperson, Receivables uses the salesperson Receivable
Flexfield.
Unearned Revenue Account

Receivables uses the unearned revenue account for transactions that have
invoicing and revenue scheduling rules. Whenever the revenue scheduling
rule recognizes revenue on the transaction after the invoicing rule bills it,
Receivables posts this amount to the unearned revenue account.
You can select constant value, customer bill-to site, salesperson, transaction
type, and standard item for your unearned revenue account.
If you select salesperson or standard item, Receivables uses the specified
Revenue Flexfield.
Using AutoAccounting to Derive Accounting Flexfield Segments: Example

This example illustrates how to derive default Accounting Flexfield segments
in AutoAccounting.
Oracle Fusion Receivables uses AutoAccounting to derive the default
accounting, and uses predefined setup in Oracle Fusion Subledger
Accounting so that the Create Receivables Accounting program accepts the
default accounts that AutoAccounting derives without change. However, if
you modify the Subledger Accounting setup to define custom accounting,
then you can select a constant value for all Accounting Flexfield segments.
These two scenarios illustrate how Receivables uses the AutoAccounting
structure you define to determine your Accounting Flexfield defaults.
Flexfield with Four Definitions

You want to define a four segment Revenue Flexfield: 00-000-0000-000
(Company-Cost Center-Account-Product). You can define AutoAccounting to
derive defaults for each segment:
Company, the first segment, is the constant 01.
Cost Center, the second segment, derives from the salesperson (John
Doe).
Account, the third segment, derives from the transaction type

(Standard Invoice).
Product, the fourth segment, derives from the standard line (20
Megabyte Hard Disk).
Salesperson John Doe enters a one line Standard Type invoice for a 20
Megabyte Hard Drive.
This graphic illustrates how AutoAccounting derives the Revenue Flexfield
based on a separate definition for each segment:
Flexfield with Two Definitions

You redefine the structure so that AutoAccounting only uses information from
the transaction type (Standard Invoice) for segments 1 and 2, and standard
line (consulting services) for segments 3 and 4.
This graphic illustrates how AutoAccounting derives the Revenue Flexfield

based on the same definitions for segments 1 and 2 and segments 3 and 4:
FAQs for AutoAccounting
When does AutoAccounting create subledger accounting?

AutoAccounting derives the default accounting for each accounting event in
Oracle Fusion Receivables according to your setup. AutoAccounting assigns
valid Accounting flexfields to invoices and credit memos, and automatically
generates valid Accounting flexfields for all related accounts: freight,
receivable, revenue, AutoInvoice clearing, tax, unbilled receivable, and
unearned revenue.
When you submit the Create Receivables Accounting program, this creates
the subledger accounting entries. Oracle Fusion Subledger Accounting
transfers the final accounting to Oracle Fusion General Ledger.
You can optionally define your own accounting rules in Subledger Accounting
to create accounting that meets your business requirements. If you
customize the Subledger Accounting setup to create your own accounting,
then Subledger Accounting overwrites the default accounts, or individual
segments of accounts, that AutoAccounting originally derived during
transaction entry.
Define Transaction Types
Recording Posted and Non-Posted Activities using Transaction Types:

Critical Choices
Use the Open Receivable and Post to GL options on the transaction type
to manage posted and non-posted activities on transactions.
If the Open Receivable option is enabled, Oracle Fusion Receivables
updates your customer balances each time you create a complete debit
memo, credit memo, chargeback, or on-account credit with this transaction
type. Receivables also includes these transactions in the standard aging and
collection processes.
If the Post to GL option is enabled, Receivables posts transactions with this
transaction type to general ledger. If this option is not enabled, then no
accounting is generated for transactions with this transaction type.
Considerations for defining transaction types include:
Creating a Void Transaction Type
Updating Customer Accounts and Aging
Updating Accounting Only
Creating a Void Transaction Type

You can void a debit memo, credit memo, on-account credit or invoice by
defining a Void transaction type. When you define a Void transaction type,
set the Open Receivable and Post to GL options to No. Then, as long as
there is no activity against the transaction, and it has not been posted to
general ledger, you can make the transaction invalid by changing the
transaction type to Void.
This activity is not included on the Review Customer Account Details page
since the activity does not modify the customer balance.
Updating Customer Accounts and Aging

If you set the Open Receivable option to Yes and Post to GL option to No,
Receivables updates customer accounts with the transaction activity of
transactions assigned this transaction type. Receivables also includes these
transaction in aging reports. There is no effect on accounting.
Use transaction types with these settings during your initial implementation,
where the transaction amount is included in the general ledger beginning
balance for the receivable account, but activity still needs to be aged and
payment collected against it. All related activities against the transaction,
such as credit memos, payments, and adjustments, are accounted as
affecting the customer balance. You can review these activities on the
Review Customer Account Details page.
Updating Accounting Only

If you set the Open Receivable option to No and Post to GL option to Yes,
Receivables updates accounting without any impact on the customer
balance.
Use transaction types with these settings when you want to adjust
accounting activity, such as when you rebill a customer in order to reclassify
the general ledger account. A credit memo and invoice with the Open
Receivable option set to No are created where the credit memo reverses
the general ledger account of the original invoice, and the invoice creates
accounting with the new general ledger account. This activity is transparent
to the customer because the original invoice is used for the cash application
when payment is received.
This activity is not included on the Review Customer Account Details page
since the activity does not modify the customer balance.
Natural Application and Overapplication: Explained

The transaction type that you assign to a transaction defines the type of
application that is permitted against the transaction balance. This definition
is managed by the Natural Application Only and Allow
Overapplication options.
Natural application lets you only apply a payment or credit to a transaction
that brings the transaction balance close to or equal to zero. For example, if
an invoice has a balance due of $400, you can make applications against this
transaction up to $400 only. With natural application, you can only bring the
balance to zero.
Overapplication lets you apply more than the balance due on a transaction.
For example, if you apply a $500 receipt to a $400 invoice, this overapplies
the invoice by $100 and reverses the balance sign from positive to negative.
Using Natural Application and Overapplication
Whether or not a transaction allows overapplication determines the actions

that you can take on that transaction.
If a transaction that allows natural application only is paid in full, then in
order to credit the transaction you must first unapply the transaction from
the receipt before creating the credit.
If you want to use AutoInvoice to import credit memos against paid invoices
and evaluate these credits for automatic receipt handling, then the
transaction type of the paid invoices must allow natural application only.
However, if the Receipt Handling for Credits option is not enabled on the
transaction source of the transaction, AutoInvoice leaves the related credit
memo in the interface tables until you unapply the invoice from the receipt.
Reference Accounts and Transaction Types: Points to Consider

Define the accounting for transaction types of class Invoice, Chargeback,
Credit Memo, and Debit Memo. Oracle Fusion Receivables uses this
information along with your AutoAccounting definition to determine the
accounts to use for transactions with the applicable transaction type.
There are points to consider for each reference account on a transaction
type:
Revenue
Freight
Receivable
Tax
Unbilled Receivable
Unearned Revenue
Revenue
Enter a revenue account, unless the transaction type does not allow freight.
If the Invoice Accounting Used for Credit Memos profile option is set to
No, then a revenue account is not required for Credit Memo transaction
types.
Freight
Enter a freight account, unless the transaction type does not allow freight.
Receivable
Enter a receivable account for all transaction types.
If the Post To GL option on the transaction type is enabled, Receivables
creates a receivable transaction record using this account in order to transfer
accounting to general ledger and create a journal entry.
For Chargeback transaction types, enter the Receivable Chargeback account.
The offset to the Receivable account on the original debit transaction is
generated by the chargeback adjustment.
If the Invoice Accounting Used for Credit Memos profile option is set to
No, then a receivable account is not required for Credit Memo transaction
types.
If this is an Invoice or Debit Memo transaction type, enter an AutoInvoice
clearing account. Receivables uses this account to hold any difference
between the revenue amount specified for the revenue account and the
selling price times the quantity for imported invoice lines.
Receivables only uses the AutoInvoice clearing account for imported
transactions that have a transaction source with the Create clearingoption
enabled. If the Create clearing option is not enabled, then AutoInvoice
requires that the revenue amount on the invoice be equal to the selling price
times the quantity.
Tax
If this is an Invoice, Credit Memo or Debit Memo transaction type, enter a tax
account.
Unbilled Receivable
If this is an Invoice or Credit Memo transaction type, enter an unbilled

receivable account. This account is for transactions that use the In Arrears
invoicing rule.
Unearned Revenue
If this is an Invoice or Credit Memo transaction type, enter an unearned
revenue account. This account is for transactions that use the In Advance
invoicing rule.
FAQs for Transaction Types
How can I arrange the creation of transaction types?

Define your transaction types in the following order:
Credit memo transaction types
Invoice transaction types
Debit memo transaction types
Chargeback transaction types
If applicable, define the transaction types that you want to add to your
transaction sources before defining transaction sources.
If you are using late charges, define a transaction type with a class of Debit
Memo for debit memos, and a transaction type with a class of Invoice for
interest invoices. Specify the receivable and revenue accounts for these
transaction types. Oracle Fusion Receivables uses these accounts instead of
AutoAccounting when generating late charges.
How can I use transaction types to review and update

customer balances?
You can use the Open Receivable option on the transaction type to
implement an approval cycle for any temporary or preliminary transactions.
For example, if you have particularly sensitive debit memos, credit memos,
on-account credits, chargebacks, and invoices that you want to review after
creation, you can define a transaction type called Preliminary with Open
Receivable set to No and assign it to the applicable transactions. This

transaction type does not update your customer balances.
When you review and approve the transaction, you can define a transaction
type called Final with Open Receivable set to Yes and assign it to the same
transactions. This will now update your customer balances on these
transactions.
Define Transaction Sources

Managing Transaction Numbering: Points to Consider
Use the various options on the transaction source assigned to a transaction
to manage your transaction numbering requirements.
There are these points to consider when defining transaction numbering for
transactions assigned to specific transaction sources:
Defining Document Sequences
Using Automatic Transaction Numbering
Copying Document Numbers to Transaction Numbers
Allowing Duplicate Transaction Numbers
Using the Credit Memo Transaction Source
Defining Document Sequences

If necessary, define document sequences to assign unique numbers to each
transaction, in addition to the transaction number automatically assigned by
Oracle Fusion Receivables.
Using Automatic Transaction Numbering

To automatically number new transactions you create using a transaction
source, enable the Automatic transaction numbering option and enter a
number in the Last Number field.
For example, to start numbering transactions with 1000, enter a last number
of 999. Receivables automatically updates the Last Numberfields on
transaction sources, so you can review the transaction source later to see
the last transaction number that was generated.
Note
The last transaction number on the transaction source is an approximation
only, due to caching.
You can use automatic transaction numbering with both Imported and
Manual transaction sources.
Copying Document Number to Transaction Number

If you are using document sequences and you want to use the same value
for both the document number and the transaction number for transactions
assigned to a transaction source, enable the Copy document number to
transaction number option.
If you are using Gapless document sequences, you should enable this option
if you require gapless transaction numbering. This ensures that transaction
numbers are generated sequentially and that there are no missing numbers.
Allowing Duplicate Transaction Numbers

Enable the Allow duplicate transaction numbers option to allow
duplicate transaction numbers within a transaction source.
You cannot use this option with automatic transaction numbering.
Using the Credit Memo Transaction Source

Assign a credit memo transaction source to an invoice transaction source, if
you want to number credit memos differently from the invoices that they
credit.
Sales Credits on Imported Transactions: Explained

During AutoInvoice processing, whether you must provide sales credit
information on imported transaction lines depends on the settings of
the Allow sales credits option on the transaction source and the Require
salesperson system option.
Requirements for Sales Credit Information

These are the requirements for passing sales credit information on imported
transaction lines:
If the Require salesperson system option and the Allow sales

credits option on the transaction source are both enabled, you must
provide sales credit information.
If the Require salesperson system option is not enabled and

the Allow sales credits option on the transaction source is enabled,
you can provide sales credit information, but it is not required.
If the Require salesperson system option is enabled and the Allow

sales credits option on the transaction source is not enabled, you
must provide sales credit information.
If neither the Require salesperson system option nor the Allow

sales credits option on the transaction source are enabled, you
cannot provide sales credit information. AutoInvoice ignores any values
that you pass.
Validating Imported Transactions: How It Works

Use the AutoInvoice Options and Import Information regions of an Imported
transaction source to define how AutoInvoice validates imported transaction
lines assigned a particular transaction source.
You do not have to pass values for all of the fields that are referenced in the
transaction source. If you do not want AutoInvoice to pass certain data, then
where available you can set the related option to None.
Note
Even if you set a transaction source data option to None in order not to
import this information into the interface tables, AutoInvoice can still validate
and reject transaction lines with invalid data.
Settings That Affect the Validation of Imported Transactions
These settings affect the validation of imported transactions:
Invalid Line field: Indicate how AutoInvoice handles imported

transactions with invalid lines by selecting either Reject Invoice or
Create Invoice.
o
If you select Reject Invoice, AutoInvoice does not import this

transaction or any of its lines into the interface tables.
If you select Create Invoice, AutoInvoice creates a transaction

with valid lines only. For example, you import an invoice with
three invoice lines and one of the lines is invalid. AutoInvoice
creates the invoice with only the two valid lines and rejects the
invalid line. You can use the Edit Transaction page to add the
rejected line.
Accounting Date in a Closed Period field: Indicate how AutoInvoice

handles imported transactions that have lines in the interface lines
table that are in a closed period.
o
Select Adjust to have AutoInvoice automatically adjust the

accounting dates to the first accounting date of the next open or
future enterable period.
Select Reject to reject these transaction lines.
In the Import Information subregions, where applicable select Number,

Value, Segment or ID for each option to indicate how AutoInvoice
validates information.
o
Select Number to import a record into the interface tables using

its assigned number.
Select Value to import a record into the interface tables using its
actual name.
Note
Use Value if you intend to use the transaction source to import
data from a non-Oracle system.
Select Segment to use the flexfield segment.
Select ID to use the internal identifier of the record.
Select Amount or Percent to indicate how AutoInvoice validates Sales

Credits and Revenue Account Allocations on transaction lines.
How Imported Transactions Are Validated

AutoInvoice validates imported data based on the settings of the applicable
Imported transaction source. Transactions that fail validation appear in the
Import AutoInvoice Validation report.
AutoInvoice ensures that certain column values agree with each other. These
values can be within an interface table or multiple interface tables. For
example, if the transaction source indicates not to use a revenue scheduling
rule, AutoInvoice ignores any values passed for invoicing rule, revenue
scheduling rule, and revenue scheduling rule duration.
AutoInvoice performs these validations on transaction lines with revenue
scheduling rules:
Requires that these transactions also include an invoicing rule, if you

import transactions that use revenue scheduling rules.
Rejects lines, if the revenue scheduling rule has overlapping periods.
Rejects lines, if all of the accounting periods do not exist for the
duration of the revenue scheduling rule.
FAQs for Transaction Sources
What do I create before creating transaction sources?

You may want to create certain records before creating your transaction
sources.
You can optionally create these objects for all transaction sources:
Transaction types: Define the transaction types that you want to

appear by default on transactions assigned to your transaction
sources.
Invoice transaction flexfield: Define the reference information that you

want to capture in the invoice transaction flexfield and display on
imported transactions, such as a purchase order number.
Credit memo transaction source: Define a transaction source for credit

memos before you define a transaction source for invoices. Use this
transaction source to number the credit memos created against
invoices differently from the invoices they are crediting.
You can optionally create these objects for Imported transaction sources:
AutoInvoice grouping rule: Define the grouping rule to appear by

default on imported transaction lines.
AutoInvoice clearing account: Define an AutoInvoice clearing account,

if you intend to enable the Create clearing option. AutoInvoice puts
any difference between the revenue amount and the selling price times
the quantity for a transaction into this account.
How can I manage credit memos with transaction sources?

Special conditions may apply to the creation of transaction sources for credit
memos.
Review these considerations for transaction sources assigned to credit
memos:
Define Manual transaction sources for credit memos created by the

credit memo request approval process.
Enable the Copy transaction information flexfield to credit

memo option on Manual transaction sources used for credit memos, to
copy the invoice transaction flexfield reference information to the
credit memo that is crediting the invoice.
Define and assign transaction sources for credit memos to transaction

sources for invoices, if you want to number the credit memos created
against invoices differently from the invoices they are crediting.
What happens if I don't enter an AutoInvoice grouping rule?

Assign the AutoInvoice grouping rule to Imported transaction sources that
AutoInvoice uses to group imported transaction lines.
If you do not assign a grouping rule to an Imported transaction source,
AutoInvoice uses the following hierarchy to determine which rule to use:
1. Grouping rule assigned to the transaction source of the transaction
line.
2. Grouping rule assigned to the bill-to customer site profile of the
transaction line.
3. Grouping rule assigned to the bill-to customer profile of the transaction
line.
4. Grouping rule assigned to system options.
What happens if I don't create a clearing account?

If you do not use an AutoInvoice clearing account and enable the Create
clearing option on the transaction source, AutoInvoice requires that the
revenue amount be equal to the selling price times the quantity for all of the
transactions it processes. AutoInvoice rejects any transaction line that does
not meet this requirement.
Define Memo Lines

Revenue Accounts and Memo Lines: Explained
You can optionally associate a revenue account with a memo line.
If AutoAccounting depends on memo line, Oracle Fusion Receivables uses the
revenue account segment values defined for the memo line, in combination
with the rest of your AutoAccounting structure, to determine the default
revenue, freight, AutoInvoice clearing, tax, unbilled receivable, unearned
revenue, and receivable accounts for invoices that include the memo line.
When you create a debit memo or on-account credit memo with memo lines,
Receivables uses the Revenue account from the original receivable item as
the credit account. However, when you create debit memo reversals or
chargebacks, Receivables uses instead the Revenue flexfield from the
original receivable item as the credit account.
FAQs for Memo Lines
When do I use memo lines?

Use memo lines on your transactions when the item is not an inventory item.
For example, you can define a memo line called Consulting Services to
identify charges for consulting activities. You can assign memo lines to debit
memos, on-account credits, debit memo reversals, chargebacks, and
invoices.
How can I use tax memo lines?

You can use tax memo lines on transactions if your tax definition lets you
enter manual tax lines on transactions. After you enter a tax memo line on a
transaction, you can specify the amount of tax to assign to the transaction
line.
Define Balance Forward Billing Cycles

Account and Site Balance Forward Billing: Explained
You can enable and maintain balance forward billing details at the customer
account level and customer site level. The rules governing the interaction
between the account and account sites determine what sites are included in
balance forward bills.
Rules for Account and Site Balance Forward Billing

These rules apply to balance forward billing at the account level and site
level:
Account level customer profile values become the default values for
the related customer sites when you create site profiles.
If balance forward billing is enabled at the account level, you still need
to enable balance forward billing on the related site profiles if you want
to include these sites for balance forward billing.
Once you create a site profile and define balance forward billing
details, the site profile no longer references the account profile. This
lets you define different balance forward billing details for a particular
site.
Balance forward billing definitions at the site level take precedence

over balance forward billing definitions at the account level.
Setting Up Balance Forward Billing: Worked Example

This example demonstrates how to set up balance forward billing for the
customer Business World. The example includes the setup of a balance
forward billing cycle, payment terms and the Business World customer
profile.
This table summarizes key decisions for this scenario.
Decisions to Consider
In This
Example
What billing cycle is used?
Monthly
What day of month is used on the payment terms?
15th
How are balance forward bills consolidated?
Account level
Can the customer exclude transactions from the balance

forward bill?
Yes
Summary of the Tasks

To generate balance forward bills for a customer:
1. Define a balance forward billing cycle.
2. Define balance forward billing payment terms.
3. Set up the customer profile class for balance forward billing.
4. Assign the profile class to the Business World customer account.
Define a Balance Forward Billing Cycle

Define the balance forward billing cycle to use for this customer:
1. Open the Balance Forward Billing Cycle window.
2. Complete the fields, as shown in this table:
Field
Value
Name
Name that identifies this balance forward billing cycle

for this customer.
Frequency
Monthly
Repeat
Every
Day of
Month
Last Day of Month
3.
Define Balance Forward Billing Payment Terms

Define the balance forward billing payment terms to use for this customer:
1. Open the Create Payment Terms page.
2. Complete the fields, as shown in this table:
Field
Value
Name
Name that identifies these payment terms for this

customer.
Billing Cycle
The billing cycle you defined in the previous

step.
Due By Day of
Month
15
3.
Setting Up the Customer Profile Class for Balance Forward Billing

Set up the customer profile for Business World for balance forward billing:
1. Open the Create Receivables Customer Profile Class page.

2. Complete the general required fields for the profile class.
3. Complete the fields on the Profile Class tab, as shown in this table:
Field
Value
Balance Forward
Billing Enable
Enable this option.
Bill Level
Account
Bill Type
Detail
Payment Terms
The balance forward billing payment terms

you defined in the previous step.
Override terms
Enable this option.
4.
5. Note
6. The Override terms option makes available to transactions nonbalance forward payment terms and the one balance forward billing
payment terms you defined in the previous step. This lets you exclude
individual transactions from balance forward billing by assigning the
transaction non-balance forward payment terms.
Assign the Profile Class to the Business World Customer Account

Assign the profile class to the Business World account:
1. Open the Edit Account page for Business World.
2. Click on the Profile tab.

3. Open the Insert Account Profile page and update the Business World
customer account with the profile you defined in the previous step.
4. Make sure that balance forward billing is enabled at the site profile level for
all sites belonging to the customer account that you want to include in
balance forward billing.
FAQs for Balance Forward Billing Cycles
What's a balance forward billing cycle?

The balance forward billing cycle determines the dates in the year that
Oracle Fusion Receivables generates balance forward bills, and the
transactions that are included in balance forward bills. You assign balance
forward billing cycles to payment terms.
When you run the Create Balance Forward Bill program, you must select a
billing cycle. You can also select specific customers, customer sites, and
payment terms. A run of the Create Balance Forward Bill program includes all
transactions not included on a previous balance forward bill that are
assigned the payment terms with the selected billing cycle, or a subset of
these payment terms as determined by the other program parameters.
FAQs for Salesperson Account References

What are salesperson reference accounts?
Assign general ledger accounts to your salespersons. When AutoAccounting
depends on salesperson, Oracle Fusion Receivables uses the account
references that you define here to derive the accounts to use on transactions
that are assigned a particular salesperson.
FAQs for Remit-to Addresses

How can I use remit-to addresses?
The remit-to address lets your customers know where to send payment for
their open debit items. After you create a remit-to address, you can assign it
to the bill-to addresses of the customers and customer sites that you
designate by country and, if applicable, by region and postal code range.
If the Print remit-to address system option is enabled, Oracle Fusion

Receivables prints the remit-to address on the related dunning letters and
statements.
How does AutoInvoice validate remit-to addresses?

During the import process, AutoInvoice rejects all invoices for which it cannot
determine a remit-to address. In order for AutoInvoice to import an invoice,
you must either define a remit-to address for the geographical location of
each applicable bill-to site or define a remit-to address to use as default for
one or more locations.
How can I define a default remit-to address?

Create or select a remit-to address, then open the Receipts from Criteria
dialog box. Select the country that you want to assign to this remit-to
address. If you only select a country, then all customer bill-to sites in this
country are assigned this remit-to address.
If you want to assign this remit-to address to specific locations within the
country, you can optionally select a state (region) within the country, and a
range of postal codes.
Why did the country appear?

When you create a remit-to address, a country appears by default if one was
defined in system options. You can change the default to the applicable
country of the remit-to address.
Why do I verify the address?

If you have Oracle Fusion Trading Community Data Quality installed, you can
expose a Verify Address button on the Create and Edit Remit-to Address
pages for applicable countries.
After you enter a remit-to address, use the Verify Address button to
confirm that the address is in the Oracle Fusion Trading Community Model
registry. If it is not, Oracle Fusion Receivables either presents alternative
addresses or lets you optionally add the address you entered to the registry.
23 Define Revenue Management Configuration

Evaluating Revenue Policy: Points to Consider
Event-Based Revenue Management: How It Works
Revenue Contingencies: Explained
FAQs for Define Revenue Management Configuration
Evaluating Revenue Policy: Points to Consider

Use the Manage Revenue Policies page to specify revenue policies for each
applicable business unit. Oracle Fusion Receivables uses the revenue policy
definition to make automatic revenue recognition decisions for manually
entered and imported transactions.
Receivables compares each transaction against the revenue policy, and
assigns revenue contingencies to the transaction or transaction lines that
deviate from the policy definitions.
There are these points to consider for each revenue policy definition:
Credit Classification
Refund Policy Threshold
Payment Terms Threshold
Credit Classification
Use credit classifications to identify your high risk, noncreditworthy
customers. You can assign up to three levels of risk. Receivables compares
these risk levels to the credit classification assigned to the customer profile.
When you enter or import a transaction for a customer with a credit
classification that matches one of the credit classifications in the revenue
policy, Receivables:
Assigns the Customer Creditworthiness contingency to the transaction.
Defers revenue on the entire transaction.
Recognizes revenue on the transaction only to the extent of payments

received.
Refund Policy Threshold

Use the Refund Policy Threshold column to enter the standard refund
period in days that you typically offer to your customers.
When you enter or import a transaction with a line that is associated with a
contract, Receivables analyzes the contract details. If the contract offers a
refund period that exceeds the refund policy, Receivables:
Assigns the Refund contingency to the transaction line.
Defers revenue on the transaction line.
Recognizes revenue on the transaction line only after the refund period
on the transaction line expires.
Payment Terms Threshold

Use the Payment Terms Threshold column to enter the maximum time
period in days before payment terms become extended.
When you enter or import a transaction with payment terms or an
installment schedule that exceeds the payment terms policy, Receivables:
Assigns the Extended Payment Term contingency to the transaction.
Defers revenue on the entire transaction.
Recognizes revenue on the transaction only to the extent of payments

received.
For example, you enter a payment terms threshold of 180 days on your
revenue policy, and you later enter or import an invoice with payment terms
that have four installments:
Net 60
Net 90
Net 120
Net 200
Receivables defers the entire revenue amount on the invoice because the
last installment exceeds the 180-day threshold by 20 days.
Event-Based Revenue Management: How It Works

Oracle Fusion Receivables automates the timing of revenue recognition for
both manually entered transactions and transactions imported via
AutoInvoice. This automated revenue management process helps you to
comply with the strict revenue recognition requirements mandated by US
GAAP and International Accounting Standards.
The event-based revenue management process evaluates each transaction
and decides whether to immediately recognize revenue, or temporarily defer
revenue to an unearned revenue account based on the contingencies
assigned to the transaction. Revenue is subsequently recognized according
to the removal event assigned to each contingency.
Note
Even if you set up for automated revenue recognition, you can still manually
adjust revenue on transactions. Once you manually adjust revenue,
Receivables discontinues the automatic monitoring of contingencies.
Settings That Afect Event-Based Revenue Management

These settings affect event-based revenue management:
Require salesperson system option: You must enable the Require

salesperson system option to use revenue recognition.
AR_INTERFACE_CONTS_ALL table: You can use the

AR_INTERFACE_CONTS_ALL table to assign revenue contingency IDs to
billing lines, before importing transactions via AutoInvoice or creating
tranactions using the Invoice API.
Note
When importing parent and child transaction lines,
AutoInvoice automatically copies any contingencies from the
parent line to the child lines.
Revenue Contingencies: The revenue contingencies assigned to

transactions, and their corresponding removal events, determine what
revenue is deferred and for how long.
Revenue Policy: Your revenue policy may trigger the assignment of

contingencies to transactions.
Revenue Contingency Assignment Rules: Your active revenue

contingency assignment rules may trigger the assignment of
contingencies to transactions.
Revenue Scheduling Rules: If a revenue scheduling rule is assigned to

the transaction, then revenue is recognized according to the revenue
scheduling rule details and rule start date.
How Event-Based Revenue Management Is Calculated

The event-based revenue management process for deferring and later
recognizing revenue on transactions follows these steps:
1. Receivables evaluates a transaction either entered manually or
imported via AutoInvoice for revenue recognition.
2. If one or more contingencies exist, Receivables defers the
corresponding revenue to an unearned revenue account and records
the reason for the deferral.
3. Receivables monitors the contingencies until an event occurs that can
remove the contingency and trigger revenue recognition.
4. When a removal event occurs, Receivables recognizes the appropriate
amount of unearned revenue on the transaction.
The revenue is recognized either according to the revenue scheduling
rule or the last contingency removal date.
Revenue Contingencies: Explained

You can use predefined revenue contingencies to assign to your customer
transactions. You can define your own contingencies based on the predefined
contingencies, and you can define revenue contingency assignment rules to
control which contingencies are assigned to which transactions.
Revenue Contingencies
This table describes the predefined revenue contingencies and their
corresponding contingency removal events.
Contingency Name
Contingency Removal Event
Cancellation
Contingency expiration date or expiration

period
Customer
Creditworthiness
Receipt application
Delivery
Proof of Delivery
Doubtful Collectibility
Receipt application
Explicit Acceptance
Customer acceptance
Extended Payment Terms
Receipt application
Forfeitures

period
Installation
Customer acceptance
Pre-Billing Acceptance
Invoicing
Refund

period
FAQs for Define Revenue Management Configuration

What's a revenue contingency?
A revenue contingency is the terms and conditions in a sales contract or
business agreement that prevents revenue from being immediately
recognized, based on the revenue recognition requirements mandated by US
GAAP and International Accounting Standards.
Typical contingencies that can delay revenue recognition include customer

creditworthiness, nonstandard payment terms, and nonstandard refund
policies.
When do I use a revenue policy with a contingency?

You can assign a contingency to a transaction based on the revenue policy of
your enterprise.
You have these options:
Credit Classification: The contingency is assigned to the transaction if

the applicable customer has a credit classification that matches one of
the credit classifications defined in your revenue policy.
Payment Terms: The contingency is assigned to the transaction if its

payment terms exceed the payment terms threshold of your revenue
policy.
Refund: The contingency is assigned to the transaction if it includes a

refund policy that exceeds the refund policy threshold of your revenue
policy.
Select None if you do not want to consider any details of your revenue policy
for the contingency.
When do I create revenue contingency assignment

rules?
You must create revenue contingency assignment rules if you want to
automatically assign contingencies to transactions. For each rule that you
define, you specify one or more matching criteria. Whenever the rule criteria
match, Oracle Fusion Receivables assigns the specified contingency to the
applicable transaction lines.
There are two cases where you do not need to create revenue contingency
assignment rules:
Revenue policy violations: Receivables automatically assigns the

appropriate revenue contingencies to transactions whenever any
revenue policy is violated.
Deferred revenue scheduling rules: Transactions assigned a deferred

revenue scheduling rule have all revenue deferred until either the
related contingency expires or you manually schedule revenue.
24 Configure Payment System Connectivity

Validations: Critical Choices
Formats: Explained
Transmission Protocol: Explained
Transmission Configuration: Explained
Payment System: Explained
Payment System Account: Explained
FAQs for Configure Payment System Connectivity
Validations: Critical Choices

Validations are rules that ensure that transactions are valid before they are
printed or submitted electronically to payment systems. You use validations
to ensure that disbursement transactions, such as invoices, payments, and
payment files meet specific conditions before they can be paid. You can
assign validations to payment methods and payment formats. A validation
can be executed at the document payable, payment, or payment file level.
In payment processing, it is critical that payment files sent to payment
systems and financial institutions are valid and correctly formatted. If this is
not done, the payment process is slowed, which results in additional time
and cost due to problem resolution. Oracle Fusion Payments helps you
achieve straight-through processing by ensuring that payment-related details
are valid. To assign validations, you can choose from the following options:
Assigning validations
Creating user-defined validations
Choosing from a predefined library of validations
The following table shows the objects you can validate and when validations
are executed for the applicable setup.
Object
Payment Method-Driven
Payment File Format-
Document
Payable
Validations are Enforced

When...
Driven Validations are

Enforced When...
The invoice is saved in the

source product.
The invoice installment is

selected for payment.
The invoice installment is

selected for payment.
Payment
The payment is created by

building related documents
payable together.
The payment is created by

building related documents
payable together.
Payment
File
Not applicable.
The payment file is created.
Assigning Validations
You can assign user-defined validations to any:
Payment method
Payment file format
You assign a validation to whichever object drives the requirement for

validation. For example, if the proprietary format your bank uses requires
that you limit the number of characters in a specific field, then you can
assign that validation directly to the bank format. By doing this, you ensure
that the validation is enforced only when applicable. However, if you wish to
enforce a general validation that is not specific to the payment method or
format, you can consider timing in your decision between assigning it to the
payment method or to the format.
Payments always validates as early as possible for a given object and setup.
Document payable validations that are associated with payment methods
are enforced earlier in the process than those associated with formats. If you
want validation failures to be handled by the same person who is entering
the invoice, you can opt to associate the validation with the payment
method. This is ideal for business processes where each person has full
ownership of the items entered. However, if you want focused invoice entry,
while validation failures are handled centrally by a specialist or a more
knowledgeable user, you can opt to associate the validation with the format.
This is ideal for some shared service centers.
Creating User-Defined Validations

A user-defined validation explicitly specifies the object to which the
validation applies:
Document payable
Payment
Payment file
User-defined validations are basic validations that correspond to simple

operations. These validations can be used as components, or building blocks,
to build more complex validations. They enable you to validate, for example,
the following conditions:
Length of a value. Example: Payment Detail must be less than 60

characters for your bank-specific payment file format.
Whether a field is populated. Example: Remit to bank account is

required when payment method is Electronic.
Whether content of a field is allowed. Example: Currency must be USD

when using your domestic payment file format.
Choosing From a Predefined Library of Validations

Payments provides a library of predefined validations. You can associate
these predefined validations with any payment method or payment file
format you create. Many of the payment formats provided by Oracle have
predefined validations associated with them by default.
Predefined validations are groups of individual validations that go together
for a specific purpose. Many of the predefined validations that you can
associate with payment formats are country-specific. Predefined validations
cannot be modified, although some have parameters you can set to define
specific values.
Formats: Explained
In Oracle Fusion Payments, formatting is the placement of data in a file by

using a template, or format, that contains prescribed formatting attributes,
such as data location, font type, and font size. Financial institutions, payment
systems, and countries have specific electronic formatting requirements for
payment files and settlement batches. Each format in Payments corresponds
to one Oracle Business Intelligence Publisher (Oracle BI Publisher) template.
Payments uses Oracle BI Publisher templates to format funds capture and
funds disbursement transactions according to the formatting requirements of
specific financial institutions and payment systems.
The purpose of setting up formats is to associate them with Oracle BI
Publisher templates to correctly format funds capture and disbursement
transactions and to enable you to easily manage the formats. You can use
existing Oracle BI Publisher templates or modify them with minimal effort by
using a standard text editor, such as Microsoft Word. For example, when a
payment system or financial institution requires a change to its payment file
format, the change can be made quickly by modifying the appropriate Oracle
BI Publisher template.
Payments has given special consideration to the complexity of creating fixed
position and delimited formats. Oracle BI Publisher's eText feature is used for
these format types. eText allows the format layout to be presented in an
understandable tabular structure.
Formats are associated with specific Oracle BI Publisher templates in the
Create Format page and can also be assigned payment validation sets,
whether predefined or user-defined, to validate transactions that use that
format. Multiple types of formats can be used for a single payment system.
Examples of format types include disbursement payment file formats and
funds capture settlement formats.
Note
Before you can set up formats, you must set up the corresponding templates
in Oracle BI Publisher.
Transmission Protocol: Explained

A transmission protocol is a convention used by computers to communicate
with each other across a network. To transmit data such as a payment file or
settlement batch from Oracle Fusion Payments to an external payment
system, the implementer must define the transmission protocols that the
payment system is capable of receiving.
Payments offers industry-standard transmission protocols, such as FTP, HTTP,

HTTPS, and AS2, predefined. They are comprised of the following:
A code entry point, which the payment system servlet uses to

accomplish transmission
A list of parameters, such as network address and port, for which the
transmission configuration must supply values
Transmission protocol entry points, which are independent of payment

servlets and may be invoked from the Payments engine
While the transmission protocol defines which parameters are expected in

the communication, the transmission configuration defines what value will be
supplied for each parameter, for a given payment system. A specific
transmission configuration and a specific payment system are associated
with each other within the funds capture process profile for funds capture or
within the payment process profile for disbursement.
Transmission Configuration: Explained

A transmission configuration defines a value for each parameter in a
transmission protocol. The values in a transmission configuration are specific
to one payment system or financial institution.
For example, a transmission protocol may require parameters, a Socket IP
Address, and a Socket Port Number. Your payment system that accepts that
protocol will give you the values that it expects to receive for those
parameters. Those values are set up in the Socket IP Address and Socket
Port Number fields in the transmission configuration. The transmission
configuration is then assigned to the payment system within the funds
capture process profile for funds capture or within the payment process
profile for disbursement.
You can set up transmission configurations in the Create Transmission
Configuration page to enable electronic connectivity with payment systems
by specifying parameter values.
Payment System: Explained

A payment system is an external organization that provides financial
settlement services. The payment system can be the bank at which your
company has its bank accounts or it can be a third-party processor or

gateway that connects companies and financial networks. Deploying
companies typically choose payment systems to process their funds capture
settlements and, sometimes, their electronic disbursement payment files.
Payment systems are not required for printed disbursement payments, but
may be required for related services, such as positive pay or other reporting.
The purpose of setting up payment systems is to define the external
organizations that Oracle Fusion Payments collaborates with to process your
funds capture and disbursement transactions.
When creating a payment system on the Create Payment System page, you
perform the following actions:
specify payment instruments the payment system will support for

funds capture transactions
specify which file formats and transmission protocols are accepted by

the payment system
Payment System Account: Explained

A payment system account is the representation of the relationship between
the payment system and your company. It is an account identifier comprised
of payment system-provided values for parameters that the payment system
requires for each transaction or settlement batch. Specific values for settings
are stored in the payment system account, which includes deploying
company identifiers. If your company has multiple relationships with a
payment system, then there will be multiple payment system accounts.
Payment system accounts are associated with the following setup objects:
Internal payees
Funds capture process profiles
Payment process profiles
Internal Payees
You can set up routing rules that are assigned to an internal payee, which
specify which payment system account a transaction will be transmitted to,
based on the values of various attributes of that transaction. If you do not
need granular routing rules for determining which payment system account
is the right one for a transaction, or if you want a fallback value should none
of the routing rules apply, you can set up one default payment system
account on each internal payee for each payment method.
Funds Capture Process Profiles

The funds capture process profile tells Oracle Fusion Payments how to
process a funds capture transaction, including how to communicate with the
payment system. A funds capture process profile is specific to one payment
system and its payment system accounts. For each payment system account
that is enabled on the funds capture process profile, you select up to three
transmission configurations, one each for authorization, settlement, and
acknowledgment. The payment system tells Payments where to send the
transaction, the payment system account tells Payments how to identify
itself to the payment system, and the transmission configurations tell
Payments how to transmit the transaction to the payment system.
Payment Process Profiles

The payment process profile tells Payments how to process a disbursement
transaction, including, in the case where a payment file or positive pay file
will be electronically transmitted, how to communicate with the payment
system. When electronic transmission is required, a payment process profile
is specific to one payment system and its payment system accounts. For
each payment system account that is enabled on the payment process
profile, you select a transmission configuration. The payment system tells
Payments where to send the payment file or positive pay file, the payment
system account tells Payments how to identify itself to the payment system,
and the transmission configuration tells Payments how to transmit the file to
the payment system.
FAQs for Configure Payment System Connectivity

What's a format type?
A format type is a categorization that indicates what a format is used for by
Oracle Fusion Payments.
Examples of format types include the following:
payment file
remittance advice
regulatory report
positive pay file
payment process request status report
accompanying letter
settlement
bank statement
payer notification
Payments offers an extensive library of payment formats of various format

types. However, not all format types have predefined formats. When you
create a new format, you assign it a format type, so that Payments knows
where the format is intended to be used.
25 Define Funds Capture and Payments Security

Funds Capture Process Profile: Explained
Routing Rules: Explained
System Security Options: Critical Choices
FAQs for Define Funds Capture and Payments Security
Funds Capture Process Profile: Explained

A funds capture process profile is a key setup entity that contains all the
rules necessary for processing funds capture transactions. It tells Oracle
Fusion Payments how to communicate with a specific payment system, and
includes the payment system accounts to be used for processing
transactions. During processing, the funds capture process profile is derived
from transaction routing rules, which are created during the setup of internal
payees.
A funds capture process profile contains rules that control each of the
following steps of the funds capture process:
Formatting messages
Building settlements into a settlement batch
Transmitting messages to the payment system
Formatting Messages
When the processing type is Bank Account, a Verification region is displayed
in the Create Funds Capture Process Profile page. When the processing type
is Credit Card, an Authorization region is displayed instead of the Verification
region. In either case, you select the format in which your payment system
expects to receive the online message. This outbound format instructs Oracle
Fusion BI Publisher how the message should look. You also select the format
in which you expect to receive an inbound response from the payment
system.
The Settlement region of the Create Funds Capture Process Profile page
enables you to select a format in which your payment system expects to
receive the settlement message. The settlement will be online for a gatewaytype payment system and in a batch for a processor-type payment system.
Online settlement transactions are typically transmitted in a group, although
they are processed as individual transactions. You also select the format in
which you expect to receive an inbound response from the payment system.
You can select formats for contacting your payment system to retrieve an
acknowledgment, and for receiving the response from the payment system
which specifies whether the transaction succeeded or failed.
Acknowledgments can be pushed by the payment system to your company,
or your company may need to retrieve acknowledgments from the payment
system.
In the Notification to Payer region of the Create Funds Capture Process Profile
page, you select a notification format and the method of notification delivery
to the payer. Payer notification is a message sent to each payer after the
settlement or settlement batch is transmitted, notifying them of a funds
capture transaction that will charge their credit card or bank account.
Building Settlements into a Settlement Batch
In the Creation Rules tab of the Create Funds Capture Process Profile page,
you select settlement grouping attributes. When a specific grouping attribute
is enabled, Payments ensures that settlements within one settlement batch
all share the same value. Settlements with disparate attribute values trigger
the creation of as many settlement batches as there are unique value
combinations. For example, if you select Business Unit and Settlement Date
as grouping rules, then only settlements with the same business unit and
settlement date are grouped in a settlement batch when the funds capture
process profile is used.
You can also limit the size of the settlement batch by amount or number of
settlements.
Transmitting Messages to the Payment System

A funds capture process profile is specific to one payment system and its
payment system accounts. In the Accounts tab on the Create Funds Capture
Process Profile page, you specify payment system accounts to be used with
the funds capture process profile. For each payment system account you
enable, you select up to three transmission configurations, one each for
authorizations or verifications, settlements, and acknowledgments. The
payment system account tells Payments how to identify itself to the payment
system, and the transmission configurations tell Payments how to transmit
the transaction to the payment system.
Routing Rules: Explained

Routing rules route a funds capture transaction to a payment system and
payment system account and determine the funds capture payment profile
to be used based on attributes of the transaction. Oracle Fusion Payments
compares attributes of a transaction, such as payment method, amount, and
currency against the conditions in a routing rule. When all of the conditions
are met, the specified payment system account and funds capture payment
profile are used for the transaction.
You assign routing rules to payees during the setup of internal payees. Each
payee can have routing rules that are prioritized. A routing rule with the
highest priority is evaluated by Payments first. If the values in the requested
funds capture transaction match the conditions in the routing rule, that
transaction is routed to the applicable payment system account for
processing, and the derived funds capture process profile is used to define
how the transaction will be processed. If the attributes in the requested
funds capture transaction do not match the conditions in the routing rule, the
routing rule is disregarded and Payments evaluates the next routing rule. If
all routing rules are evaluated and none apply, Payments looks for a
payment system account and funds capture process profile specific to the
payment method type entered for the payee in the Default Payment System
region of the Set Rules page.
The payment system account and funds capture process profile that are used
for an authorization will automatically be used for any further actions on the
transaction, including settlement and any follow-on refunds.
System Security Options: Critical Choices

Oracle Fusion Payments system security options enable you to set security
options for payment instrument encryption and payment instrument
masking. These options are used for both funds capture and disbursement
processes.
Implementation of the System Security Options should be part of a complete
security policy that is specific to your organization. To secure your sensitive
data, you can choose from the following options:
Credit card data encryption
Bank account data encryption
System key rotation
Credit card number masking
Bank account number masking
Encrypting Credit Card Data

Credit Card Encryption is an advanced security feature within Payments that
enables Oracle applications to encrypt credit card data. Use of the Credit
Card Encryption feature assists you with your compliance with the cardholder
data protection requirements of the following:
Payment Card Industry (PCI) Data Security Standard
Visa's PCI-based Cardholder Information Security Program (CISP)
Credit card numbers entered in Oracle Fusion Receivables and Oracle Fusion
Collections are encrypted automatically based on the setup for credit card
encryption in the System Security Options page. If card numbers are brought
into Payments through import or customization, Oracle recommends that you
run the Encrypt Credit Card Data program immediately afterward.
Encrypting Bank Account Data

Bank Account Encryption is an advanced security feature within Payments
that enables Oracle applications to encrypt supplier and customer bank
account numbers.
Important
The Bank Account Encryption feature does not affect internal bank account
numbers. Internal bank accounts are set up in Oracle Fusion Cash
Management and are used as disbursement bank accounts in Oracle Fusion
Payables and as remit-to bank accounts in Receivables.
Supplier, customer, and employee bank account numbers entered in Oracle
applications are encrypted automatically based on the setup for bank
account encryption in the System Security Options page. If bank account
numbers are brought into Payments through import or customization, Oracle
recommends that you run the Encrypt Bank Account Data program
immediately afterward.
Rotating the System Key

When you enable encryption in Payments, you create one system-level
security key, which is a 168 bit 3-DES key. The system key is the encryption
master key for the entire installation. It is stored in an Oracle Wallet file and
is used to encrypt Payments system subkeys. The Encryption feature enables
you to rotate the system key. System key rotation changes the subkey data,
but does not result in a re-encryption of the credit card numbers or bank
account numbers. To secure your payment instrument data, your security
policy should include a regular schedule to rotate the system keys.
The security architecture for credit card data encryption and bank account
data encryption is comprised of the following components:
Oracle Wallet Manger
Oracle Wallet file
System key
System subkeys
Credit card number storage
Bank account number storage
For payment instrument encryption, Payments uses a chained key approach.

To simplify, the chained key approach is used for data security where A
encrypts B and B encrypts C. In Payments, the system key encrypts the
subkeys and the subkeys encrypt the payment instrument data. This
approach allows easier rotation of the system key. The system key is the
encryption master key for the entire installation. It is stored in a wallet file
and is used to encrypt Payments subkeys.
Before encryption can be enabled for the first time, a wallet file must already
exist on the file system of the Enterprise Storage Server (ESS). You must
create an empty wallet file called ewallet.p12 and, if you would like to use
your own system-level encryption key, a file called key.bits containing your
binary (3DES) encryption key. Both files should be placed in the same
directory, and the directory must be readable and writable by the Weblogic
Server (WLS) container hosting the Payables Java EE application user
interface.
When creating a wallet on the Manage System Security page, the full path of
ewallet.p12 should be entered in the New Wallet File Location field, and if
you are using a user-defined key, the full path of key.bits should be entered
in the Key File Location field.
After the wallet has been created on the Manage System Security page, you
will also need to copy the wallet files to the same path for the Application
Developer Framework (ADF) user interface servers for the Receivables and
Payables Java EE applications. Any time the key is updated, this copy must
be done.
Masking Credit Card and Bank Account Numbers

Payments serves as a payment data repository on top of the Oracle Fusion
Trading Community Model. This model holds party information. Payments
stores all of the party's payment information and its payment instruments,
such as credit cards and bank accounts. This common repository for payment
data provides data security by allowing central encryption management and
masking control of payment instrument information.
On the System Security Options setup page, credit card numbers and
external bank account numbers can be masked by selecting the number of
digits to mask and display. For example, a bank account number of
XXXX8012 represents a display of the last four digits and a masking of all the
rest. These settings specify masking for payment instrument numbers in the
user interfaces of multiple applications.
FAQs for Define Funds Capture and Payments Security

What's an online verification?
Before capturing funds from a payer's bank account, you can send an online
message to the payment system requesting that it contact the bank and
verify that the payer's bank account is valid. This process does not put a hold
on any funds in the account, which is done with a credit card authorization.
You enable online verification in a funds capture process profile by selecting

an outbound format and an inbound response format for verification.
Note
Online payer verification is an optional feature and is not offered by all
payment systems.
26 Define Customer Payments

Define Application Rule Sets
Define Receipt Classes and Methods
FAQs for Receipt Sources
Define Lockbox
Define Transmission Formats for Lockbox
Define AutoMatch Rule Sets
Define Application Exception Rule Sets
Define Customer Paying Relationship Assignments
Define Application Rule Sets

Application Rules: Explained
When you apply a payment or credit memo to a transaction, the application
rule set determines how Oracle Fusion Receivables reduces the balance due
on the line, tax, freight, and late charges 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, then
Receivables uses the system options application rule set.
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 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.
Line and Tax Prorate

The Line and Tax Prorate rule 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
Prorate All
The Prorate All rule 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
Overapplication Rule
The Overapplication rule is always the last rule in an application rule set. 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 allows overapplication, Receivables
applies the remaining amount to the 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 to determine how to apply the remaining
amount.
Using Application Rules: Examples

These examples show how Oracle Fusion Receivables uses each application
rule in an application rule set to apply 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:
Line
Amount
Applied
Freight
Tax Amount Amount
Applied
Applied
Line First - Tax 1040

After
1000
40
Line and Tax

Prorate
1040
912.28
127.72
Prorate All
1040
776.12
108.66
155.22
Application
Rule
Total
Amount
Applied
This table shows the calculations used by each application rule:
Application
Rule
Line First - Tax

After
Calculations
1. Apply payment to open line amount.

2. 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
1. (1040/1340) x 1000 = 776.12 (Receipt Amount /

Invoice Total) * Open Line Amount = Line Amount
Applied
2. (1040/1340) x 140 = 108.66 (Receipt Amount /

Invoice Total) * Open Tax Amount = Tax Amount
Applied
3. (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:
Transacti
on
Amount
Remaini
ng
Amount
$1340
$300
Line
Line Items
Item Remaini
s
ng
Tax
Remaini
Tax ng
$100 $0
0
$14 $100
0
Freig
ht
Freight
Remaini
ng
$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.
using the Line and Tax Prorate rule:
Transacti
on
Amount
Remaini
ng
Amount
$1340
$300
Line
Line Items
Item Remaini
s
ng
Tax
Remaini
Tax ng
$100 $87.72
0
$14 $12.28
0
Freig
ht
Freight
Remaini
ng
$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
Prorate All
The Prorate All rule applies a proportionate amount of the receipt to the line,
tax, and freight for this transaction.
using the Prorate All rule:
Transacti
on
Amount
Remaini
ng
Amount
Line Line
Item Items
s
Remaini
Tax Tax
Remaini
ng
Freig
ht
Freight
Remaini
ng
ng
$1340
$300
$100 $223.88
0
$14 $31.34
0
$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
Using Application Rules with Transactions with Mixed Sign Balances:

Example
This example shows how Oracle Fusion Receivables uses the Prorate All
application rule to apply a payment to a transaction that has mixed sign
balances, that is, not all of the charges that make up the transaction have
the same sign (positive or negative).
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
Remaini
Items ng
Tax
Remaini
Tax ng
<$100 <$100>
>
$10 $28.56
0
Freig
ht
Freight
Remaini
ng
Late
Charg
es
Late
Charges
Remaini
ng
$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
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,
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 rule set.
Define 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.
Remittance Methods
Use the remittance method to determine the accounts that Oracle Fusion
Receivables uses for automatic receipts that you create using the receipt
method assigned to this 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 do not 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 Oracle Fusion Cash
Management.
By Matching
Use this method to clear receipts manually in Cash Management.
Automatic Receipt Processing: Points to Consider

Define the attributes of an automatic receipt method to determine how
automatic receipts are processed against selected transactions.
There are these points to consider when defining an automatic receipt
method:
Receipts Inherit Transaction Numbers
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.
Do not enable this option if you want to use document numbers with
automatic receipts.
Number of Receipts Rule

The Number of Receipts Rule determines the way in which the automatic
receipt process creates and applies receipts against transactions.
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.
Important
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 with different credit
cards, the automatic receipt process create two receipts, one for each credit
card 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, Oracle Fusion 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
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.
Oracle Fusion Payments predefines funds capture payment methods, but you
can define your own.
Fund Transfer Error Handling: Explained

Define fund transfer error handling to automatically correct errors
encountered either during credit card authorization or payment capture, or
during bank account transfer.
Mapping Third-Party Error Codes

To define fund transfer error handling for a given receipt method, you map
the error codes from a third party credit card provider or financial institution
to the corrective actions in Oracle Fusion 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: Explained

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, Oracle Fusion 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.
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 these receipts,
Oracle Fusion 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. You set up
remittance banks in Oracle Fusion Cash Management. 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.
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 and remittance batches. This
includes automatic receipt batches, lockbox receipts, and receipts created
via spreadsheet.
The Automatic Receipts receipt source is used automatically by the
automatic receipt and remittance processes. You do not need to enter this
receipt source.
Define Lockbox
Processing Lockbox Files: How It Works
Use lockbox to create receipts in Oracle Fusion Receivables from data

supplied by your remittance bank and apply receipts to customer
transactions.
The lockbox process has three steps:
Import Data: Lockbox reads and formats the data from your bank file
into the interim table using an SQL*Loader script.
Validate Data: Receivables validates that the data in the interim table
for compatibility, then transfers the data to the receipts tables.
Post Receipts: Apply receipts and update customer balances.
You can submit these steps individually or at the same time. After you post
lockbox receipts, Receivables treats these receipts like any other receipts:
you can reverse and reapply them, and apply any unapplied, unidentified, or
on-account amounts.
This diagram illustrates the lockbox process:
Import
Use the Process Receipts Through Lockbox: Import program to read and
format data from the bank file into the AR_PAYMENTS_INTERFACE_ALL table
using an SQL*Loader script.
Receivables uses the lockbox transmission format that you specify in the
program submission to ensure that data is correctly transferred from the
bank file into the AR_PAYMENTS_INTERFACE_ALL table. The transmission
format contains information such as the customer account number, bank
account number, the amount of each receipt to apply, and transaction
numbers to which to apply each receipt.
Validate
The validation process includes these checks:
No duplicate entries exist.
Customer and receipt information is valid.
Amounts to apply do not exceed the receipt amount.
Columns in the AR_PAYMENTS_INTERFACE_ALL table reference the

correct values and columns in Receivables.
If the receipt and transaction currencies are different, Receivables also

requires specific application information and to determine the conversion
rate between the two currencies.
Receivables transfers the receipts that pass validation to the
AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL
interim tables. At this point, you can optionally review receipts and change
how they are to be applied before posting.
Use the Process Receipts Through Lockbox: Report to review all pass and fail
validations for a lockbox transmission. Receipts that fail validation remain in
the AR_PAYMENTS_INTERFACE_ALL table until you manually correct the
import errors. You can then resubmit the validation step for these receipts.
Post
Use the Post Receipt Batch program to post lockbox receipt batches that
have passed import and validation.
When you process a lockbox receipt batch, Receivables matches receipts to
transactions and applies the receipts automatically. In cases where receipts
are not applied automatically, Receivables generates a list of recommended
transactions for receipt application to complete the process manually.
Match Receipts By Method: Explained

During lockbox and manual receipt processing, Oracle Fusion 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.
Using the Document Type Reference

The five document types used to match receipts to transactions are:
Transaction number
Sales order number
Purchase order number
Balance forward billing number
Shipping reference
Receivables attempts to match the number of an open debit item to the

number of the document type designated for matching according to your
implementation:
If the matched number is a transaction number, Receivables searches

for the first transaction with this number and applies the receipt to that
transaction.
If the matched number is a sales order number, Receivables searches

for the first transaction that belongs to this sales order and applies the
receipt to that transaction.
If the matched number is a sales order number, Receivables searches

for the first transaction that belongs to this purchase order and applies
the receipt to that transaction.
If the matched number is a balance forward bill number, Receivables

identifies the customer of this balance forward bill and applies the
receipt to the transactions included on the bill using the Clear Past Due
Invoices Grouped by Payment Terms AutoCash rule belonging to the
active AutoCash rule set.
If the matched number is a shipping reference, such as a waybill

number, Receivables searches for the first transaction that belongs to
the shipping document and applies the receipt to that transaction.
Note
Receivables allows more than one transaction per sales order or purchase
order. If the Match Receipts By rule is Sales Order or Purchase Order,
Receivables matches with the first transaction that it finds.
Using the Match Receipts By Rule
When Receivables finds a document type with the same number as the
current search, 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 business unit system options.
If Receivables cannot 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.
Matching Rules Examples

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 does
not 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.
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 receipts
sources created and assigned to the business units that belong to the
lockbox set.
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 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 Oracle Fusion Receivables attempts to match
customers to receipts and match receipts to transactions based on your
setup.
If lockbox cannot fully apply a receipt due to invalid transaction numbers,
then Receivables manages the additional amounts according to thePost
Partial Amount as Unapplied option. Receipts are applied to valid
transactions, and the remaining receipt amounts are marked as Unapplied.
Define Transmission Formats for Lockbox

Validating the Lockbox File Transmission: How It Works
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, that there are no duplicate receipts
within a batch, and that the customers and transactions are valid.
Lockbox also validates that all data is compatible with Oracle Fusion
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 does not 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 cannot automatically apply a
payment to these transactions.
If a customer has more than one transaction in the system with the same
number, then lockbox cannot 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
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
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 does not 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 does not
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
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.
Important
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.
Lockbox Transmission Formats

Transmission formats specify how data in a lockbox bank file is organized for
import into the Oracle Fusion Receivables interface tables. The transmission
format is used by the validation program to ensure that data is transferred
correctly.
Transmission Formats
Receivables provides five transmission formats. You can define new
transmission formats based on the formats provided by Receivables.
You use an SQL*Loader control file to import data from bank files to
Receivables. If you define a different transmission format or edit the existing
Default or Convert formats, you must edit the SQL*Loader control file before
you can import data into Receivables.
Example (arxmpl.ctl)
This format contains an example of lockbox header information, receipt
records, and overflow receipt records.
Default (ardeft.ctl)
This is a standard BAI (Bank Administration Institute) format used by most
banks.
Convert (arconv.ctl)
This format is used for transferring payment information from other systems.
Cross Currency (arxcurr.ctl)
This default format used for importing cross currency receipts.
Zengin (arzeng.ctl)
This format is used to import bank files in the Japanese Zengin format.
Lockbox Transmission Format Record Types

Enter the record types to include in a lockbox transmission format. Use
the Identifiercolumn 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.
Record Types
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.
Field Types
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 Oracle Fusion 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
does not include overflow payments, headers, or trailers.
Billing Location
Your bank will be able to transmit 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 Code
The currency of the payment. For cross currency payments, you can also
enter the Invoice Currency Code. If you do not 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 at which the bank receives and deposits the customer payment.
Destination Account
Your business bank account. Your business may have more than one bank
account.
Efective 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 Code 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 does not 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 Dateoption 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 converison 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 do not 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 Lockbox Transmission Formats
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 cannot 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.
Define AutoMatch Rule Sets
AutoMatch Recommendations: How They Are Calculated

During receipt processing, Oracle Fusion Receivables applies receipts to
transactions based on the transaction information provided. In cases where
the transaction information provided does not exactly match the transaction
numbers available in the system, the AutoApply process will attempt 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 will attempt 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 or missing 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:
1. If applicable, remove characters and spaces from the number as
defined by the AutoMatch rule set string handling.
2. 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)
3. 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 does not exist, but Receivables finds the number
AR10001. The recommendation for this number is calculated in this way:
1. 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.
2. It will take one change for 10001 to match 10010. Therefore, the score
for this match is (1 - 1/5) = 80%.
3. The 80% score exceeds the Combined Weighted Threshold value of
70%, so the receipt is automatically applied to transaction AR10001.
AutoMatch Combined Weighted Thresholds: Explained

The combined weighted thresholds on the AutoMatch rule set provide the
qualifying percentage necessary for 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.
Using the Combined Weighted Thresholds

Enter the weight, as a percentage, that the AutoApply process should give to
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 region 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, which is 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
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:
Reference amount: 120.65
AutoApply performs these calculations:
Customer match: The match between account number 1001 and 1005
has a calculated score of 75%. 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

86%. Since the transaction weighted threshold value is 70%, this
provides a final score of 60.20%.
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 85.20%, 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 generates
recommendations for user review. If the score were below the Minimum
Match Threshold value, then AutoApply does not generate recommendations.
AutoMatch Amount Weight Exceptions: Explained

The values you enter in the Amount Weight Exceptions region qualify the
meaning of the open balance amount that is considered by theAmount
Weight threshold.
Using the 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 there is an exact match between the receipt amount and transaction

amount, AutoApply uses the Amount Weight threshold value without
reference to the amount weight exceptions.
If there is not an exact match 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:
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:
Reference amount: 120
Because there is not an exact match 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.
String Handling: How It Works

The String Handling region provides rules that assist in the search for
transaction matches against the Match Receipt By document reference.
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:

zeros, empty spaces or any value, including 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.
Define Application Exception Rule Sets

Exception Rules Conditions and Actions: Explained
Use the Exception Rules region to indicate how to process each overpayment
and underpayment condition.
Using Exception Rules

Each exception rule consists of a condition, the amount and percentage that
applies to the condition, and the action to take when this 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, the above rule does not 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.
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.
In both cases, after customer payments are processed, overpayment or
underpayment amounts may remain. The AutoApply process then uses the
details of the application exception rule set either to process overpayments
and underpayments automatically or to present overpayments and
underpayments for user review and manual adjustment.
Define Customer Paying Relationship Assignments

Customer Hierarchies and Paying Relationships: How They Work Together
The customer hierarchy describes the structure of an enterprise or portion of
an enterprise. These structures are defined and maintained in the FND_HIER
tables. There are three predefined hierarchies: Customer hierachy, Trading
Community party hierarchy, and Duns and Bradstreet hierarchy.
You assign a paying relationship to a hierarchy to indicate how the parties in
a hierarchy can 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 diagram illustrates the customer hierarchy in Acme Corporation:
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.
FAQs for Customer Paying Relationship Assignments
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.
27 Define Customer
Define Customer Account
Manage Receivables Customer Profile Classes
Manage Customers
Define Customer Account

Customer Account Relationships: Explained
Use customer account relationships to manage the sharing of billing and
shipping services and payment activities between two accounts.
Account relationships let you identify accounts that can receive shipments or
invoices for another account, as well as accounts that can pay for the open
debit items of other accounts.
Using Customer Account Relationships

Use the Relationships tab of the Edit Account page to create and maintain
account relationships for a particular customer account.
A customer account relationship is either a one-way relationship or a
reciprocal relationship. By default an account relationship is one-way,
meaning that the parent account can apply receipts to open debit items of
the related account, but receipts in the related account cannot be applied to
open debit items of the parent account. If you want to allow the two accounts
to pay for each other's open debit items, then enable the Reciprocal option
for the relationship definition.
Enable the Bill To and Ship To options for relationships that involve billing
and shipping services. In a one-way relationship, the parent account can
process invoices and receive shipments for the related account. In a
reciprocal relationship, either account can manage these services for the
other account.
You can use the Allow payment of unrelated transactions system option
to help manage customer account relationships. Do not enable this option if
you want to restrict the sharing of receipt application and billing and
shipping services to the account relationships that you define for each
customer account.
If you do enable the Allow payment of unrelated transactions system

option, then any customer account can pay for the open debit items of any
other customer account. You can still use account relationships to manage
billing and shipping services.
Manage Receivables Customer Profile Classes

Profile Classes: Explained
Use profile classes to organize your customer accounts into categories that
reflect the needs of your enterprise. The profile class record contains generic
options that you can set in different ways to group your customers into broad
categories, such as by industry, location, size, creditworthiness, business
volume, or payment cycles.
For example, you might define three profile classes that reflect customer
payment behavior: one for customers who pay promptly; one for late paying
customers with high late charge rates; and a third for customers who for the
most part pay on time, with discount incentives for early payment.
Working with Profile Classes

When you create a customer account, Oracle Fusion Receivables assigns the
profile class DEFAULT. Use the Edit Account page to modify this profile class
or assign another profile class to the customer account.
When you create an account site, Receivables does not assign either the
DEFAULT profile class or the profile class of the customer account. Use the
Create Site Profile page to assign the first profile class to an account site. Use
the Edit Site page to update or assign a new profile class to a customer site.
After you assign a profile class to an account or site, you can customize
details of the profile class to meet specific requirements for that account or
site. For example, a particular site may transact business in a separate
currency, or the site may be subject to additional late charges or penalty
charges. These updates apply only to that particular account or site and do
not affect the profile class record itself.
Profile class updates and assignments are managed using effective date
ranges. Each profile class that you assign or update supersedes the previous
profile class for the given date range. In this way you can manage over time
the changes that take place in customer behavior or customer requirements.
The date of a given transaction or receipt determines which account or site
profile applies to the activity. The profile history for an account or site
provides details of when a given version of a profile class is active.
FAQs for Manage Receivables Customer Profile Classes
When are profile class defaults used?

The customer profile class shares these default settings with other parts of
Oracle Fusion Receivables: Match Receipts By; AutoMatch rule set; AutoCash
rule set; AutoInvoice Grouping rule; payment terms; and tax printing options.
Each of these settings is used according to the hierarchy required by the
transaction or receipt process.
For receipt processing:
Receivables searches for a Match Receipt By value to use for receipt

and transaction comparison in the order: customer site profile,
customer account profile, lockbox (for lockbox processing), and system
options.
Receivables searches for an AutoMatch rule set to determine how

receipts are applied automatically and transactions recommended for
manual application in the order: customer site profile, customer
account profile, lockbox (for lockbox processing), and system options.
If Receivables cannot match receipts to transactions, the application

searches for an AutoCash rule set to use to apply receipts in the order:
customer site profile, customer account profile, and system options.
For transaction processing:
During AutoInvoice import, Receivables searches for an AutoInvoice

grouping rule to use to group transaction lines into transactions in the
order: transaction source, customer site profile, customer account
profile, and system options.
Receivables searches for the payment terms to use on a transaction in

the order: customer site profile, customer account profile, and
transaction type. If the payment terms come from the site profile or
account profile, and the Override terms option is enabled, then you
can update the default payment terms on the transaction.
Receivables searches for the tax printing option to use to print tax on
transactions in the order: customer site profile, customer account
profile, and system options. If no value is found then Receivables uses
Total Tax Only as the default value to print transactions.
Manage Customers
Customer and Party: Explained
You create customers to properly record and account for sales transactions,
as well as to identify other attributes of the selling relationship. Recording a
sales transaction requires that a customer, stored as a party in Oracle Fusion
Trading Community Model, has both an account and an account site with a
bill-to purpose.
To understand the role of a customer in the context of the trading community
model, it is helpful to understand a few related concepts. The key concepts
related to customers and customer activities are:
Party
Customer
Customer Account
Site
Relationship
Contact
Party
A party is an entity that can enter into a business relationship with another
party, such as buying and selling goods or offering services. A party is either
an organization or a person. A party exists separately from any business
relationship that it enters into with another party.
Customer
A customer is a party, either an organization or a person, with whom you
have a selling relationship. This selling relationship can result, for example,
from the purchase of products and services or from the negotiation of terms
and conditions that provide the basis for future purchases.
Customer Account
A customer account represents the attributes of the business relationship
that a party can enter into with another party. The customer account has
information about the terms and conditions of doing business with the party.
For example, you can create a commercial account for purchases made by a
company for its internal use, and a reseller account for purchases made by
the same company for sales of your products to end users.
You can create multiple customer accounts for a party to maintain
information about different categories of business activities. For example, to
track invoices for different types of purchases, you can maintain an account
for purchasing office supplies and another account for purchasing furniture.
You can also maintain multiple customer accounts for a customer that
transacts business with more than one line of business in your organization.
You can share information about a party, such as profile, addresses and
contacts, across the customer accounts of the party. In addition, you can also
maintain separate profiles and contacts, along with contact addresses and
contact points, for each customer account.
Site
A site is a point in space described by an address. A party site is the place
where a party is physically located.
An account site is a party site that is used in the context of a customer
account. A customer account can have multiple account sites.
A customer address is an account site that is used for billing, shipping, or
other purposes that are part of the selling relationship. An identifying
address is the party site address that identifies the location of the party.
Every party has only one identifying address, but a party can have multiple
party sites.
Relationship
A party relationship is the role of the party in the context of another party.
Examples include affiliate, subsidiary, partner, employee of, or contact of.
An account relationship between different customer accounts of a party
allows for the sharing of billing, shipping, and payment information.
Contact
A contact is a person who communicates for or acts on behalf of a party or
customer account. A contact can exist for a customer at the account or site
level.
A person usually acts as a contact for an organization, but can also act as a
contact for another person. For example, an administrative assistant is often
the contact for an executive.
Party Relationships: Explained

Use party relationships to model your customer records according to the way
you conduct your business. Party relationships can help you better
understand and make decisions about the customers that you do business
with.
Using Party Relationships

Define party relationships to use with your customer records. A party
relationship record contains the name of the party that relates to the
customer, the way in which the party relates to the customer (relationship
role), and the period of time that this particular relationship exists. You can
then add these parties as contacts belonging to the accounts or account
sites of a given customer.
A party relationship represents the way two entities interact with each other,
based on the role that each entity takes with respect to the other. For
example, the employment relationship between a person and an
organization is defined by the role of the person as the employee and the
organization as the employer.
A relationship can be reciprocal. Each entity is either the subject or object,
depending on the perspective, or direction. The party that you define
relationships for is the subject, and the party that you relate to is the object.
For example, if Joe is the employee of Oracle, then Joe is the subject and
Oracle is the object. Oracle as the employer of Joe, which reverses the
subject and object, still describes the same relationship.
Tax Profiles: Explained

Use the tax profile to maintain optional tax information about your customers
and customer sites. You create third party tax profiles under Oracle Fusion
Tax. You can update the tax profile record in Oracle Fusion Receivables for
the applicable customer or customer site.
Receivables does not populate an account site record with the tax profile
belonging to the customer record. You must define a separate tax profile for
each account site, according to the requirements of the site. Tax profile
records defined at the account site level take precedence over the tax profile
record defined at the customer level.
For example, a customer level tax profile might not include tax exemptions.
However, one of the related customer account sites may be located in a
developing country or region, where tax incentives for businesses include tax
exemptions on specific products or services. In this case, you should define
and maintain a separate tax profile for this account site.
FAQs for Manage Customers
Does a new customer belong to a customer account?

No, creating the customer person or organization record only establishes this
party as having some kind of selling relationship with you. After creating a
customer, you also need to create at least one account and one account site
with a bill-to purpose under the customer record in order to properly record
and account for both sales transactions with the party and other attributes of
the selling relationship with the party.
What happens if I enter customer information that already

exists?
If you have Oracle Fusion Data Quality installed, the Oracle Fusion Trading
Community Model manages the control of duplicate and redundant party
information.
If you enter party information resembling or matching existing information,
then depending on your setup you are prompted in different ways to manage
this information: prevention of data entry; inclusion with confirmation of the
data entry; or review and selection of matching or similar data.
How can I update other customer information?

Use the Edit Account pages to update information related to the accounts
created for this customer.
Use the Edit Site pages to update information related to the sites created
under a customer account. This includes address information and the tax
profile for the related account site.
28 Manage Receivables System Options

Updating System Option Records: Critical Choices
Using Header Level Rounding: Example
Tax Invoice Printing Options
Tuning Segments: Explained
Log File Message Levels: Explained
FAQs for Receivables System Options
Updating System Option Records: Critical Choices

Certain system option settings can have critical implications for the way
Oracle Fusion Receivables functions for a given business unit. You may need
to do some advance planning before deciding how to set certain system
options.
Considerations for system option settings include:
Salespersons
Header Level Rounding
Allow Change to Printed Transactions
Discounts
Salespersons
If you intend to use revenue accounting, you must enable the Require
salesperson system option. Revenue accounting requires that you assign
sales credits to all transactions that can be adjusted for either revenue or
sales credits.
If you enable the Require salesperson system option, use the Sales
Credit Percent Limit field to limit the percentage of revenue plus nonrevenue sales credit that a salesperson can have on any transaction line.
If you do not enter a value in the Sales Credit Percent Limit field, then no
sales credit limit validation is performed during revenue accounting.
Header Level Rounding

Depending on the legal requirements of your home country, you may need to
round amounts at the transaction header level for the receivable account,
and then account for and post the difference in a separate account between
this rounded amount and the sum of the rounded line amounts for the
respective revenue accounts. To do this, enable the Use header level
rounding option and define a Header Rounding Account.
The rounding difference between the header level and line level rounding is
assigned to the Header Rounding Account.
If you enable the Use header level rounding option, then Receivables
displays a rounding distribution line for all transactions, regardless of
currency. If the transaction is in the ledger currency, then the amount of this
line is zero.
If you do not enable the Use header level rounding option, Receivables
rounds amounts at the line level and posts any rounding difference to the
receivable account.
Important
Once you enable Header Level Rounding and save the system options record,
you cannot disable the feature.
Allow Change to Printed Transactions

To allow updates to transactions that have been printed, enable the Allow
change to printed transactions option. This option also determines
whether you can update a customer address when printed, posted, or
applied transactions are assigned to that address.
Important
You cannot update a transaction if it has activity against it, regardless of how
you set this option. Examples of activity include payments, credit memos,
adjustments, accounting, and including the transaction on a balance forward

bill.
Discounts
To allow Receivables to accept unearned discounts, enable the Allow
unearned discounts option. Unearned discounts are discounts a customer
takes after the discount period passes. The system options record is the only
place that determines whether you can accept unearned discounts for the
given business unit.
To allow discounts to be taken for partial payments against open debit items,
enable the Discount on partial payment option. A partial payment is a
payment that is less than the remaining amount due. If this option is
enabled, you can still decide to disallow discounts on partial payments at the
transaction level when defining payment terms.
If you never allow discounts on partial payments, set this option to No.
Using Header Level Rounding: Example

This example illustrates how header level rounding processes currency
conversions and accounts for rounding differences.
Scenario
ABC Company uses euros as the ledger currency, and it receives an invoice
with three line items in Norwegian kroners. For this example, the conversion
rate between the kroner and the euro is 6.55957.
Transaction Details
The Use header level rounding system option is enabled for the
applicable business unit and a Header Rounding Account is defined.
This table shows the calculations performed to convert each line amount on
the invoice:
Item/Descriptio Amount in
n
Kroners
Conversion
Rate
Amount in
Euros
Comment
Paper
15.00
6.55957
2.29
rounded up
Pens
12.00
6.55957
1.83
rounded up
Envelopes
25.00
6.55957
3.81
rounded
down
Subtotal
52.00
N/A
7.93
sum of
items
Rounding
Difference
N/A
N/A
- 0.01
N/A
Total Amount
52.00
6.55957
7.92
rounded
down
Analysis
Because the Use header level rounding system option is enabled, Oracle
Fusion Receivables must calculate the rounding difference between the
currency conversion of the total invoice amount at the header level assigned
to the receivable account and the sum of the currency conversions at the line
level assigned to each revenue account. This difference is placed in the
designated header rounding account.
Conversion Results
Receivables first converts each line item separately from kroners to euros,
and then adds them together, for a total of 7.93 EUR. Receivables then
separately adds the line amounts in the invoice currency (kroners) and then
converts to the ledger currency, for a total of 7.92 EUR.
The rounding difference of .01 is assigned to the header rounding account as
defined in system options.
The Tax Invoice Printing Options system option identifies the method
Oracle Fusion Receivables uses to print tax amounts on transactions. The
value you enter here becomes the default value for customer profile classes.

European Tax Format
Does not itemize tax information for each line, but does print tax rates as the
last column of invoice lines. Prints freight items last. At the end of the
invoice, the Tax Summary by Tax Name section includes a summary of
taxable amounts and tax charged for each tax rate code.
Itemize and Sum
Itemizes tax information for each invoice line. At the end of the invoice, the
Tax Summary by Tax Name section includes a summary of the tax charged
for each tax rate code. At the end of the invoice, Receivables prints the
invoice subtotal, tax, shipping, and invoice total.
Itemize Taxes
Itemizes tax information for each invoice line.
Itemize With Recap
Itemizes tax information for each invoice line. At the end of the invoice, the
for each tax rate code.
Recap
Does not itemize tax information for each line. At the end of the invoice, the
for each tax rate code.
Sum Taxes
for each tax rate code. At the end of the invoice, Receivables prints the
invoice subtotal, tax, shipping, and invoice total.
Summarize By Tax Name

for each printed tax name and rate.
Total Tax Only
Displays only the total tax amount at the bottom of the document.
Tuning Segments: Explained

You can designate Accounting and System Items flexfield segments as tuning
segments, to help increase performance of AutoInvoice. The tuning segment
is the segment most frequently accessed by AutoInvoice.
Accounting Flexfield Tuning Segment

If you want to increase the performance of AutoInvoice and indices already
exist for the GL_CODE_COMBINATIONS table, use the value that you specified
for your index as the Accounting Flexfield tuning segment. If you defined a
concatenated index use the first column of your concatenated index.
If no indices exist for the GL_CODE_COMBINATIONS table, enter the segment
with the most distinct values for your Accounting Flexfield tuning segment.
System Items Flexfield Tuning Segment

If you want to increase the performance of AutoInvoice and indices already
exist for the MTL_SYSTEM_ITEMS table, use the value that you specified for
your index as your System Items Flexfield tuning segment. If you defined a
concatenated index, use the first column of your concatenated index.
If no indices exist for the MTL_SYSTEM_ITEMS table, enter the segment with
the most distinct values for your System Items Flexfield tuning segment.
Log File Message Levels: Explained

Enter a log file message level from 0 to 5 to indicate the amount of detail
that you want to display in the AutoInvoice log file.
For day-to-day business needs and to improve performance, set the level to
0. If you experience errors while running AutoInvoice, you can set the output
to a higher level to review more detailed information in the log about the
error.
Meaning of the Log File Message Levels

Message Level 0 provides the following entries in the log file:
Product Version
Program Name
AutoInvoice Start Time
AutoInvoice Concurrent Request Arguments
Error and Warning Messages
AutoInvoice End Time
AutoInvoice Logical Steps
Message Level 1 provides all of the entries for Message Level 0 plus:
Time-Stamped function labels
Message Level 2 provides all of the entries for Message Levels 0 and 1 plus:
Sizes of allocated arrays
Dynamic SQL statements
Number of rows updated, inserted, and deleted
Message Level 3 provides all of the entries for Message Levels 0, 1, and 2
plus:
Method IV SQL array values
Message Level 4 provides all of the entries for Message Levels 0, 1, 2, and 3
plus:
Values of all variables that are used to call FND or Tax routines
Message Level 5 provides all of the entries for Message Levels 0, 1, 2, 3, and
4 plus:
Details of all bad lines and rejected lines. This provides all messages
needed for C debugging of Autoinvoice.
FAQs for Receivables System Options

What's the days per posting cycle?
The Days per Posting Cycle setting lets you process the transactions you
are posting in smaller groups to ensure that you do not run out of rollback
space during posting.
For example, if your accounting period is 30 days and you set this value to
30, the posting program uses only one cycle. If your accounting period is 30
days and you set this value to 17, the posting program uses two cycles. It is
recommended to set this field to a value that is less than the number of days
in your accounting period.
What happens if I allow transaction deletion?

Enable the Allow transaction deletion option if you want to let users
delete transactions from Oracle Fusion Receivables after the transactions
have been saved. If you do not enable this option, all Receivables users are
prevented from deleting transactions. If an installation is legally required to
number transactions sequentially with no missing transaction numbers, then
you should not enable this option.
If you enable the Allow transaction deletion option, you can still control
which users can delete transactions using function security.
How can I determine the memory allocation?

Enter in the Maximum Memory in Bytes field the value that represents the
amount of memory to allocate to AutoInvoice for validation. The default is
65535 bytes. For best results, enter a value that is the maximum number of
records that you import, rounded to an even number, multiplied by 1024. For
example, if you use AutoInvoice to import no more than 100 records at a
time, enter a value of 102400.
During AutoInvoice processing, if you receive a message that indicates the

application failed to allocate memory, then enter a lower number. If you
receive a message that the memory is not large enough, then enter a higher
number.
When do I use days to AutoApply a receipt?

Enter in the Days to AutoApply a Receipt field the number of days that
AutoApply attempts to apply a receipt to a transaction. Use this field if your
customers often pay for transactions before they are created. AutoApply
looks for and attempts to apply open receipts for the number of days that
you specify.
If you do not enter a value in this field, AutoApply tries to apply the receipt
only once.
What are the exception rule activities?

The active application exception rule set determines the action to perform on
overpayment and underpayment amounts after receipt application. You can
define the default receivables activity to use to process these payments
when the action is either a billing adjustment or a write-off.
The Exception Rule Adjustment Activity field provides the default
receivables activity to use for adjustments on overpayments or
underpayments. The Exception Rule Write-of Activity field provides the
default receivables activity to use for write-offs of overpayments or
underpayments.
When are receipts required for a bill-to site?

Enable the Require billing location for receipts option to require that a
bill-to site be associated with a cash receipt. If enabled, Oracle Fusion
Receivables does not create receipts that do not have a bill-to site.
It is recommended to use this option if you have customers without
statement sites. If you do not enable this option, and you have receipts for
customers without statement sites and without a bill-to site associated with
the receipt, the unapplied amount of the receipt will not appear on any of the
statements for this customer.
What's the difference between the realized gains and losses

accounts and the cross currency rounding account?
The realized gains and realized losses accounts are used to account for the
conversion rate gain or loss in the ledger currency resulting from a cross
currency receipt application. For example, if the conversion rate for a foreign
currency invoice is 1.7 and the conversion rate of the payment for this
invoice is 2.0, Oracle Fusion Receivables posts the difference as a gain to the
realized gains account.
The cross currency rounding account is used to record rounding error
amounts created during a cross currency receipt application for currencies
that have a fixed rate relationship. You must define a rounding error account
if you create cross currency receipts.
29 Manage Aging Methods

Aging Method: Explained
Creating an Aging Method: Worked Example
FAQs for Manage Aging Methods
Aging Method: Explained

Aging methods are periods of time used to group receivables, debit and
credit items to achieve an understanding of a customers delinquency profile.
Grouping transactions by buckets of time creates an aging view of the
customer. Aged information allows the collector to be effective when trying
to recover delinquent debt and also allows a collections organization to
develop more effective policies to assign work and streamline efficiencies.
Aging Method Features

Aging is the concept of calculating a customers past due and current
transactions. Oracle Fusion Advanced Collections groups overdue debt by
time and assigns work based on buckets of debt items. Aging shows the
amounts owed to the company by its customers and includes the length of
time the amounts have been outstanding. For example, aging categorizes
receivables into buckets such as; current, 30 days, 60 days, 90 days, and
120 days and over. Collections aging functionality consists of an Aging
Methods Setup screen and a separate Aging tab. Aging methods can be
used during the creation of dunning plans. Aging is a view of transaction or

receivables data that helps a collector understand the overdue amounts
viewed over time. This understanding enables the collector to take a
payment or create an adjustment or dispute. Collections delivers
preconfigured aging methods and allows the ability to create new aging
methods based on company requirements.
Creating an Aging Method: Worked Example

This example demonstrates how to create an aging method not predefined in
Oracle Fusion Advanced Collections.
Your company requires an aging method that is not a collections predefined
aging method. You are to create a new aging method. Use the default values
except where indicated. Create an aging method named 1 to 120 Days
Method, with the following segments:
Sequenc Bucket
e
Type
Aging Days
From
Aging Days
To
Aging Bucket
Heading
Current
-9999
Current
Past Due
45
45 Past Due
Past Due
46
60
60 Past Due
Past Due
61
90
90 Past Due
Past Due
91
120
120 Past Due
Past Due
121
9999
121+ Past Due
Creating an Aging Method

1. Start from the Manage Aging Methods page.
2. From the Aging Method region, click the green plus sign to create an
aging method.
3. Complete the fields, as shown in this table.
Field
Value
Aging Method
Name
1 to 120 Aging Day Method
Aging Type
Statement Aging; 4 bucket and 7 bucket aging are

options, depends on the number of buckets for
your aging method.
Enable
Yes
Aging Method
Set
Common Set
Aging Method
Description
Current to 120 Day Aging method.
4.
5. Click Save.
6. From the 1 to 120 Aging Day Method: Details, complete the fields, as
shown in this table.
Field
Value
Sequence
Bucket Type
Past Due
Aging Days
From
Aging Days To
45
Aging Bucket
Heading
45 Past Due; Click the Create icon to create the

row for the next sequence.
Sequence
Bucket Type
Past Due
Aging Days
From
46
Aging Days To
60
Aging Bucket
Heading
60 Past Due
7.
8. Repeat the steps for sequences 4 to 6 and increase the Aging Days
From and Aging Days To accordingly.
9. Click the Save and Close to complete the creation of a new aging
method.
The following validation rules are in place when creating or modifying
an aging method:
o A bucket must contain at least 2 bucket lines and at most 7 lines.
o A Bucket Type passes from the user interface as a fixed constant
value.
o A bucket must have Aging Days From less than Aging Days To.
o All buckets must cover the range from -9999 to 9999 and there is
no way to update a field with the value of -9999 or 9999.
o Aging buckets cannot have any gaps between -9999 to 9999.
FAQs for Manage Aging Methods

How can I modify a predefined aging method?
Predefined aging methods cannot be modified, however they can be copied,
are renamed and allow modifications made to the duplicate. From the
Manage Aging Methods page, select one of the delivered aging methods and
select the Duplicate button. It is renamed as copy in front of the name of
the duplicated aging method. For example a 5 Bucket Aging becomes Copy 5
Bucket Aging, and allows you to make your modifications. Saving your
changes creates the modified aging method.
30 Manage Collectors

Setting Up a Collector: Points to Consider
Creating Collectors: Worked Example
FAQs for Manage Collectors
Setting Up a Collector: Points to Consider

A collector is an individual or a group of individuals, assigned to a customer
to conduct various collections work. Tasks include sending correspondence,
reviewing customer history and collecting payment from customers. Prior to
creating a collector, the individual must be set up as an employee in Oracle
Fusion Human Resources and as a resource in Oracle Fusion Customer
Relationships Management (CRM) applications.
Setting Up Collectors
Consider the following when setting up individuals as collectors:
A collector can individually be assigned to one or more customers or

can be a group member that collects from one or more customers.
Evaluate what are the most appropriate collection needs for your
organizations.
Collectors can be assigned at the customer, account or site level.

Determine how your organization interacts with customers.
Research how your organization divides the work and tasks among
collectors.
Collections organization structures can be created in several ways

based on the number of customers. There are many ways in which a
collections organization is structured. For example, you can group
customers according to size, small to large or divide customers
regionally or by the monetary volume you do with a customer.
Creating Collectors: Worked Example

This example demonstrates creating collectors and assigning them as an
employee assignment and a group assignment. Infusion American Division
Corporation wants to create five individuals as collectors. The Collections
Department collects on a regional basis, north, south, east and west. Acme
Corporation is a large customer and they want to assign one collector to this
account. All five individuals have been created as a Person Party and
Employee, a prerequisite to creating a collector. The regions have also been
created as groups.
The following information is required for each individual:
Field
Action
Name
Employee Name
Description
Optional; detail information
Correspondence
Name used on sent correspondence
Telephone Number
Contact number
Employee Name
Active employee list
Group
Uses group from setup feature
Active or Inactive
Collector status
Creating an Employee Assignment

1. Start on the Collectors Setup page.
2. You can search or create a new collector from this page.
3. Click the Add or Create Collector icon.
4. Enter the Collector Name.
5. Enter the Type of collector as employee.
6. Select the name of the employee from the drop down list from
the Employee or Group column.
7. Set the status as Enabled.
8. Select the appropriate Collector Set.
9. Click the Save and Close button.
Creating a Collector Group

1. Start on the Collectors Setup page.
2. You can search or create a new collector from this page.
3. Click the Add or Create Collector icon.
4. Enter the Collector Name.
5. Enter the Type of collector as group.
6. Select the appropriate group from the Employee or Group drop down
list. In this example each would be assigned to one of the regions;
north, south, east or west.
7. Set the status as Enabled.
8. Select the appropriate Collector Set.
9. Save your work by clicking Save and Close .
FAQs for Manage Collectors

What's the diference between an employee
assignment and a group assignment?
An employee assignment is a collector assigned to one customer. You must
create individuals as employees before you can set them up as users,
resources or collectors.
A group assignment is created to assign work and customers to a group of
collectors. You can have multiple employees or collectors in one group.
31 Manage Dunning Configurations

Aged or Staged Dunning: Explained
Customer Dunning Configuration: Points to Consider
FAQs for Manage Dunning Configurations
Aged or Staged Dunning: Explained

Two dunning methods, aged or staged can be used to set up customer
correspondence. The dunning methods are supported at the customer,
account, and bill-to site levels.
Aged dunning method
Staged dunning method
Aged Dunning Method

Companies sending collection letters to their customers based on the oldest
aged transaction can use the Aged Dunning method. Delinquent transactions
are identified automatically when the Delinquency Identification concurrent
process is run. Preconfigured dunning notice templates are available, or the
deploying company can create their own dunning notice templates. As the
oldest aged transaction moves into the next aging bucket, the content of the
dunning letter can change. A single consolidated letter can be sent to
eliminate sending multiple aged dunning letters to the same customer who
has more than one delinquent transaction. The templates are associated to
aging buckets in the dunning configuration process.
Staged Dunning Method

Staged dunning is based on the number of days since the last dunning letter
was sent, rather than the number of days transactions are past due. A single
consolidated letter can be sent to eliminate sending multiple staged dunning
letters to the same customer who has more than one delinquent transaction.
Delinquent transactions are identified automatically when the Delinquency
Identification concurrent process is run. In cases where transactions have
installment due dates, the staged dunning letter includes each overdue
installment date in the body of the consolidated letter. Staged dunning
letters are sent at delayed intervals defined in the Dunning Configuration
process. These intervals control the timing of each letter sent. Use
preconfigured dunning templates or create new ones.
Customer Dunning Configuration: Points to Consider

Configure dunning plans and letters to facilitate regular correspondence with
your customers. All of the following options except rerun the dunning process
are created in the Correspondence Configuration in Functional Setup

Manager.
The following are Dunning features:
Dunning letter options
Delivery options for dunning letters
Dunning configuration set
Dunning transactions
Rerun the dunning process
Dunning Letter Options

Use the preconfigured aged or staged dunning letters delivered by the
application or create new dunning letters to meet unique requirements.
Configure dunning to run in one of two methods; aged dunning which is
based on the oldest past due debit item or staged dunning which is based on
the number of days since the previous letter was sent.
Delivery Options for Dunning Letters

Delivery of dunning letters to customer is:
E-Mail
Fax
Regular mail
Dunning Transactions
Select the transactions and charges to include in the dunning letters.
The Dunning Letter Generate program can include invoices, debit

memos, chargebacks, unapplied, and on-account receipts that are
overdue.
The dunning letters can include current transactions.
Finance charges can be included as a line item.
Transactions in full dispute can either be not included or tagged with

an asterisk and a note indicating it is not included in the total.
Dunning Configuration Set

Dunning can be configured by one business unit or multiple business units.
A Set ID defines a subset of a master list of business objects, such as
suppliers, customers, or in this case a Dunning Configuration Set. A Set
Determinant is a business object, usually a type of organizational unit, that
has a 1 to 1 relationship to Set ID. When Set Determinant is visible, Set ID
can be hidden. A Set of business objects can be associated with an
organizational unit, such as Business Unit or Legal Entity, to enforce data
security. Then, when you are associated with organizational units, they
automatically see only the subset of business objects appropriate for their
organizational units. A Set or Set Determinant field appears to you as a
lookup code that determines which subset of a master list of objects their
organizational unit uses. For example, if you are performing a Purchasing
transaction, the Set or Set Determinant value would determine which
Suppliers can be used.
Rerun the Dunning Process

Rerun the dunning process to correct errors or regenerate dunning letters:
Rerun the dunning process should there be an error during any phase
of the program.
Regenerate a previous dunning letter if a customer request another

copy.
Keep customers from receiving dunning letters by indicating them as Exclude

from dunning on the Profile tab.
FAQs for Manage Dunning Configurations

What's the difference between an aged and staged dunning
method?
Aged dunning sends dunning letters based on the age of the oldest
transaction. Managers identify the dunning letter to be sent for each aging
bucket and whether a follow up call is manually scheduled if the delinquency
is not resolved.
Staged dunning sends dunning letters based on the age of the oldest
transaction and the number of days since the last letter was sent. Managers
specify how long to wait before executing the next stage and whether a
follow up call is manually scheduled if the delinquency is not resolved.
32 Manage Collections Preferences

Setting Up Collection Preferences: Points to Consider
Defining Collection Preferences: Worked Example
FAQs for Manage Collections Preferences
Setting Up Collection Preferences: Points to Consider

Oracle Fusion Advanced Collections provides a user interface to guide you
through the collection preferences. The two required setup regions are:
Global Preferences and Preferences. You answer questions and make
decisions about how the application behaves, such as date ranges and
defaults. Consider the following decisions before defining preferences:
Decision
Is This Fusion Applicable?
How many employees,

locations and
organizations to create?
Yes, depends on the setup of the enterprise

structure. Review and verify before setting up
Advanced Collections.
Which employees to
create?
Yes, determine the number of employees who

are involved with the collection process.
Assign collectors?
Yes, how are the collectors going to be assigned;

by customer account, account, site or other
criteria?
Set Up Oracle Fusion

Accounts Receivables?
Yes, how is Receivables being set up and what is

the impact on Advanced Collections.
Enable AR Transactions
Summary Tables?
Yes, a profile option set in Receivables to update

activities applied to transactions.
Set Up Oracle Fusion

Payments?
Yes, set up to use credit cards and automatic

fund transfers to apply to transactions.
Set Up Units of Measure?
Yes, a Receivables set up needed for

transactions.
Set Up Security and

Users?
Yes, set up through Oracle Fusion Identity

Management to grant access to collections.
Set Up Notes?
Yes, is an Oracle Fusion Common Application

Components (CAC) feature allowing collectors to
comment on interactions with customers.
Set Up Tasks?
Yes, is a CAC feature allowing collectors or

managers to assign follow-up tasks.
Set Up Oracle Business

Intelligence Publisher?
Yes, but needs to be verified that Business

Intelligence Publisher is working to run collection
reports.
Global Preferences
Selections made in the Global Preference region impact the view the
collectors see from the Collections Customer Work Area and Collections
Dashboard. Global Preferences define the following:
Default transaction class that appears
Display of open transactions
Display of closed transactions
Number of days for prior and future transactions to be displayed
Default aging method
Delimiter used to separate data and the number of characters required

to do a search
Preferences
Selections made in the Preference region impact the defaults the collector
encounters when going through the collection process. Preferences define
the following
Preference set
Collections business level
Summarize or age credits
Default exchange rate
Send method of dunning
Default contact for unknown dunning recipients
Defining Collection Preferences: Worked Example

This example demonstrates how to set preferences for collections. You have
been tasked to set up the two regions of preferences: Global and Preferences
Your company requires collectors to review transaction that are 90 days past
due and current ones 30 days into the future. Collectors review customers by
account and send out past due notices by E-Mail. Notices are sent to the
accounts payable manager if no contact information is available. Reviewing a
customer's history requires viewing current and closed transactions. Your
company allows up to two days for rescheduling work on the dashboard.
Adjustments and disputes are handled within 1 business day of being
recorded. Credits on an account are summarized. Aging is displayed by a 5
bucket aging method. The conversion rate is based on a rate set by the
corporation. The delimiter symbol used to separate data is a pipe. A threecharacter minimum is required and recommended to perform a search on
customer accounts. Create the preferences based on this information.
Define preferences based on the following table:
Global Preferences
1. Defining Global Preferences
Field
Value
Select the default transaction type Select Invoice, other transaction

for the Transactions tab
choices are all, credit or debit
memos.
Automatically display closed
Yes is select to view closed
transactions on Transaction tab
transactions as part of the

customers history.
Automatically display current

transactions on Transaction tab
Yes is selected to view current or

open transaction the customer has
pending.
Enter the number of days before

the current date the transaction
date range should start
In this example, 90 days gives the

collector 3 months of history. 1 to
9999 is the range that can be used.
Enter the number of days after

the current date the transaction
date range should end
30 days of current or open

transactions are displayed. 1-9999
is the range that can be used.
Enter the maximum number of

Two days is the allowable change
days work can be rescheduled on in schedule for work. 1-9999 is the
the dashboard
range that can be used.
Enter the number of days after
submitting an adjustment or
dispute that an activity is
generated
One day generates the disputes and

adjustments. 1-9999 is the range
that can be used.
Select the default Aging Method
5 Bucket Aging, several aging

buckets can be defined and may be
available.
Enter the delimiter used to

The pipe symbol, other available
separate customer, account and
choices are the greater than, dash,
site on the Collections Dashboard and colon symbols.
Enter the minimum number of
characters required to perform a
search
Three characters is the Oracle

recommended number for a search.
1-9999 is the range that can be
used.
2.
3. Defining Preferences
Field
Value
Collections Preference Set
Choose the value; Common Set
Select the Collections Business
Account, other choices are
Level
customer and site.
Select whether open credits should

be aged or summarized by default
Summarized, credits can be

displayed as aged.
Select the exchange rate type for

converting multi-currency
transactions
Corporate, several choices can be

defined and are displayed.
Select the default method to send

collections notifications
E-Mail, other methods are fax or

print.
Enter the default contact for

unknown dunning recipients
Accounts Payable Manager. User

defined if no contact is listed.
4.
5. Save or Save and Close to enable your preferences.
FAQs for Manage Collections Preferences

What's the diference between Global Preferences and
Preferences?
Global preferences affect the Collections Customer Work Area, such as
display of closed or open transactions and setting date range parameters.
Preferences can be set uniquely for a specific business unit. Preferences
impact the default settings, such as preference set and default method to
send notifications.
What's the diference between customer, account, and

site at the Business Level?
Transactions set at the customer level to view or modify, encompasses all of
the transaction activity associated with the customer. For example, a
dunning letter at the customer level is inclusive of transactions at the
customer and account level.
Transactions set at the account level to view or modify, are for a particular
account and include transactions for all the bill-to sites under that account.
Transactions set at the site level to view or modify, are specific to the bill-to
location.
What's the diference between minimum dunning

amount and minimum dunning invoice amount?
Minimum dunning amount is the total amount set for all overdue transactions
to have correspondence generated. For example, if your minimum dunning
amount is set to $100 and you have three overdue transactions of $25, $35,
and $55 totaling $105, a dunning letter is generated listing the three
invoices as overdue.
Minimum dunning invoice amount is the amount set for an overdue
transaction to generate correspondence. For example, if your minimum
dunning invoice amount is set to $25 and you have three overdue
transactions of $15, $50, and $75, a dunning letter is generated for the $50
and $75 transactions.
33 Manage Intercompany Balancing Rules and

Ledger Balancing Options
Manage Intercompany Balancing Rules
Manage Ledger Balancing Options
Manage Intercompany Balancing Rules

Intercompany Balancing Rules: Explained
Intercompany balancing rules are used to generate the accounts needed to
balance journals that are out of balance by legal entity or primary balancing
segment values.
You specify the intercompany receivables and intercompany payables
accounts you want to use. The intercompany balancing feature then uses
these rules to generate the accounts of the balancing lines it creates.
Defining Intercompany Balancing Rules

You can define intercompany balancing rules at the following rule levels:
1. Primary balancing segment
2. Legal entity
3. Ledger
4. Chart of accounts
The rules are evaluated in the order shown above. For example, you can
define a Primary Balancing Segment rule and a Legal Entity level rule. If both
rules are used to balance a particular journal, the Primary Balancing
Segment rule is used, as it has a higher precedence.
You have flexibility in defining your intercompany balancing rules. You can
have a simple setup in which you define one rule for your chart of accounts.
This rule is used for all intercompany balancing for all ledgers that use this
chart of accounts. Alternatively, you can have a more granular set of rules.
For example, you can define a different rule for each legal entity and one
chart of accounts rule to cover any gaps in your rule definitions. You can gain
even more granularity by defining rules for specific journal and/or category
combinations or intercompany transaction types.
Intercompany Balancing Rules: Examples

This topic provides examples of intercompany balancing rules and the
intercompany balancing lines generated. These rules are used to generate
the accounts needed to balance journals that are out of balance by legal
entity or primary balancing segment values.
Scenario
Simple Chart of Accounts
In this scenario the enterprise has one chart of accounts for all its ledgers.
The chart of accounts has an intercompany segment. They are using this
intercompany segment and the company segment to identify the
intercompany trading partners for each transaction. They do not have a need
to track their intercompany activity at a granular level such as by journal
source and journal category or by intercompany transaction type.
Setup
InFusion USA Chart of Accounts
Primary
Segment Balancing
Qualifier Segment
Second
Balancing
Segment
Segment
Name
Cost Center Product
Company
Third
Balancing
Segment
Accou
nt
Intercompan
y Segment
Account Intercompany
Ledger, Legal Entity, Primary Balancing Segment Value Assignments
Ledger
Legal Entity
Primary Balancing Segment

Value
InFusion
USA
InFusion Farms
3100, 3200, 3300, 3400, 3500
InFusion
USA
InFusion Textiles
4000
InFusion
USA
InFusion Production
(East)
5000
InFusion
USA
InFusion Production
(West)
6000
InFusion
USA
1000, 9000
Chart of Accounts Rule
Rule
Chart of
Numbe Account
r
s
Payable
Receivable s
s Account Account
Sourc Categor Transactio

e
y
n Type
InFusion
USA
Chart of
Accounts
1000-0001000000000013010-0000 0000210100000
Other
Other
None
Journal Balancing
o Journal before Balancing
Lin Line
e
Type
Legal
Cost
Entit Compa Cent Prod
y
ny
er
uct
Accou Intercomp Deb Cre

nt
any
it
dit
Expen InFusi 3100

se
on
Farms
100
1200
52330 0000
Liabili InFusi 4000

ty
on
Textile
s
500
1300
40118 0000
150
150
Journal Balancing
o Journal after Balancing
Us
es
Ru Li Line
le ne Type
Lega
Cos
l
t
Entit Comp Cen Prod Acco Intercom De
y
any
ter uct
unt
pany
bit
Expense InFus 3100

ion
Farm
s
100
1200 5233
0
0000
Liability
500
1300 4011
0000
InFus 4000
Cre
dit
150
150
ion
Textil
es
Intercom InFus 3100

pany
ion
Payable Farm
s
100
1200 2101
0
4000
Intercom
pany
Receivab
le
500
1300 1301
0
3100
InFus 4000
ion
Textil
es
150
150
Scenario
Legal Entity and Chart of Accounts Rules
In this example the legal Entity InFusion Textiles intercompany
manufacturing activities are tracked separately from its non-manufacturing
activities. In order to achieve this legal entity level rules are defined
specifically between the legal entity InFusion Textiles and the two
manufacturing legal entities, InFusion Production (East) and InFusion
Production (West). A chart of accounts rule is created to cover all other
intercompany activities.
Setup
Primary
Segment Balancing
Qualifier Segment
Second
Balancing
Segment
Segment
Name
Cost Center Product
Company
Third
Balancing
Segment
Intercompany
Segment
Accou
nt
Intercompany
Ledger
Legal Entity

Value
InFusion
USA
InFusion Farms
3100, 3200, 3300, 3400, 3500
InFusion
USA
InFusion Textiles
4000
InFusion
USA
InFusion Production
(East)
5000
InFusion
USA
InFusion Production
(West)
6000
InFusion
USA
1000, 9000
Rule
Chart of
Numbe Account
r
s
Payable
Receivable s
s Account Account
1000-0001000000000013050-0000 0000210500000
InFusion
USA
Chart of
Accounts

e
y
n Type
Other
Other
None
Legal Entity Level Rule
Rul From To
e
Legal Legal
No. Entity Entity
Payabl
Receivabl es
es
Accoun Sourc Catego
Account
t
e
ry
Transacti
on Type
1000-000-
None
InFusio InFusion
1000-
Other
Other
n
Textile
s
4
Producti
on
(West)
InFusio InFusion
n
Producti
Textile on (East)
s
0000130200000
0000000210200000
1000-0000000130300000
10000000000210300000
Other
Other
None
Journal Balancing
Cost
Compa Cent Prod
ny
er
uct

nt
any
it
dit
3100
100
1200
52330 0000
150
Expe
nse
InFusio 5000
n
Product
ion
(East)
100
1200
52340 0000
200
Expe
nse
InFusio 6000
n
Product
ion
(West)
200
1300
52345 0000
300
Liabili InFusio 4000

ty
n
Textiles
500
1300
40118 0000
Lin Line
e
Type
Legal
Entity
Expe
nse
InFusio
n
Farms
Journal Balancing
650
Us
es
Ru Li Line
le ne Type
Cos
t
Legal Comp Cen Prod Acco Intercom De
Entity any
ter uct
unt
pany
bit
Expense InFusi
on
Farms
3100
100
1200 5233
0
0000
150
Expense InFusi 5000

on
Produc
tion
(East)
100
1200 5234
0
0000
200
Expense InFusi 6000

on
Produc
tion
(West)
200
1300 5234
5
0000
300
Liability
InFusi 4000
on
Textile
s
500
1300 4011
8
0000
Interco
mpany
Receiva
ble
InFusi 4000
on
Textile
s
500
1300 1305
0
3100
Interco
mpany
Payable
InFusi
on
Farms
3100
100
1200 2105
0
4000
Interco
mpany
Receiva
ble
InFusi 4000
on
Textile
s
500
1300 1303
0
5000
Interco
mpany
Payable
InFusi 5000
on
Produc
tion
(East)
100
1200 2105
0
4000
Cre
dit
650
150
150
200
200
Interco
mpany
Receiva
ble
InFusi 4000
on
Textile
s
500
1300 1302
0
6000
10 Interco
mpany
Payable
InFusi 6000
on
Produc
tion
(West)
200
1300 2105
0
4000
300
300
Manage Ledger Balancing Options

Defining Ledger Balancing Options: Explained
Ledger balancing options are defined for the ledger to balance the second
balancing segment and/or the third balancing segment, when a transaction is
unbalanced by one of these segments.
Ledger balancing options include the following settings:
Receivables and payables accounts used for ledger balancing
Summarization options
Clearing company options
Receivables and Payables Accounts used for Ledger Balancing

You can choose to specify the receivables and payables accounts to be used,
if your chart of accounts has the second balancing segment and/or the third
balancing segment enabled. These accounts are used for the balancing lines
generated when a journal is balanced by its primary balancing segment
values but is not balanced by its second balancing segment and/or third
balancing segment.
Summarization Options
You can choose to summarize balancing lines generated for a primary
balancing segment out of balance scenario, where all the primary balancing
segment values are assigned to the same legal entity. You do this by
specifying the Summarization option of Summary Net or Detail. You can

choose to summarize by primary balancing segment value or alternatively
have individual balancing lines (that have not been summarized) generated.
Note that summarization always applies to balancing lines generated in a
cross legal entity scenario.
Clearing Company Options

You can choose to set clearing company options to balance a journal with
different primary balancing segment values that all belong to a single legal
entity. Set the following options to handle your clearing company balancing.
Clearing company condition

o You can choose to balance using a clearing company value for all
journals or for journals with many legal entities on the debit side
and many legal entities on the credit side.
o The default value for this option is to error Many-to-Many
journals.
Clearing Company Source

o Choose how the clearing company value is derived for your
balancing lines, from the following options:
Default clearing balancing segment value. Choose this

option if you want a single specific primary balancing
segment value for your clearing company.
Default Rule. Choose this option if you want to allow the

system to derive the clearing company value from a
default intercompany balancing rule.
Manually entered clearing balancing segment value.

Choose this option if you want to enter the clearing
company value when you create a journal.
Clearing Company Value

o If you chose the default clearing balancing segment value as
your clearing company source, you can enter your chosen
primary balancing segment value in this field.
Defining Ledger Balancing Options: Examples

This topic provides examples of ledger balancing options, the setup required,
and the journal before and after balancing.
Scenario
Simple ledger balancing option with no clearing company options
In this scenario the enterprise has the second balancing segment and the
third balancing segment enabled for its chart of accounts. The journal is
balanced by primary balancing segment but is out of balance by the second
balancing segment and the third balancing segment.
Setup
Primary
Segment Balancing
Qualifier Segment
Second
Balancing
Segment
Segment
Name
Cost Center Product
Company
Third
Balancing
Segment
Intercompany
Segment
Accou
nt
Intercompany
Ledger
Legal Entity

Value
InFusion
USA
InFusion Farms
3100, 3200, 3300, 3400, 3500
InFusion
USA
InFusion Textiles
4000
InFusion
USA
InFusion Production
(East)
5000
InFusion
USA
InFusion Production
(West)
6000
InFusion
USA
1000, 9000
Rule
Numbe
r
Ledger e
y
n Type
1
InFusio
n USA
Other
Other
None
Receivable
s Account
Payables
Account
1000-0001000-0000000-13010- 00000000
210100000
Journal Balancing
o Journal Before Balancing
Lin Line
e
Type
Legal
Cost
y
ny
er
uct

nt
any
it
dit
Expen InFusi 3100

se
on
Farms
100
1200
52330 0000
Liabili InFusi 3100

ty
on
Farms
500
1300
40118 0000
Journal Balancing
150
150
Us
es
Ru Li Line
le ne Type
Lega
l
Entit Comp
y
any
Cost
Cen Prod
ter
uct
Acco
unt
Intercom
pany
De
bit
150
Cre
dit
Expen
se
InFusi 3100
on
Farm
s
100
1200
5233
0
0000
Liabilit InFusi 3100

y
on
Farm
s
500
1300
4011
8
0000
150
Ledger
Balanc
ing
Payabl
e
InFusi 3100
on
Farm
s
100
1200
2101
0
0000
150
Ledger
Balanc
ing
Receiv
able
InFusi 3100
on
Farm
s
500
1300
1301
0
0000
150
Scenario
Ledger balancing options with detail summarization and clearing company
options set
In this scenario the enterprise has the second balancing segment and the
third balancing segment enabled for its chart of accounts. Management has
decided to use a clearing company for balancing Many-to-Many journals only.
Since the primary balancing segment values in the journal are out of balance
intercompany balancing is required. Additionally since clearing company
options have been specified they will be used to balance the journal. Note
that if the primary balancing segment values were balanced and only the
second balancing segment and the third balancing segment were out of
balance, the clearing company options would not be used.
Setup
InFusion 1000, USA Chart of Accounts
Primary
Segment Balancing
Qualifier Segment
Second
Balancing
Segment
Segment
Name
Cost Center Product
Company
Third
Balancing
Segment
Intercompany
Segment
Accou
nt
Intercompany
Ledger
Legal Entity

Value
InFusion
USA
InFusion Farms
3100, 3200, 3300, 3400, 3500
InFusion
USA
InFusion Textiles
4000
InFusion
USA
InFusion Production
(East)
5000
InFusion
USA
InFusion Production
(West)
6000
InFusion
USA
1000, 9000
Rule
Chart of
Numbe Account
r
s
Payable
Receivable s
s Account Account

e
y
n Type
1000-000-
Other
InFusion
1000-
Other
None
USA
Chart of
Accounts
000000013050-0000 0000210500000
Rule
Numbe
r
Ledger e
y
n Type
2
InFusio
n USA
Other
None
Payables
Account
1000-0001000-0000000-13010- 00000000
210100000
Clearing Company Options
Rule
Numbe Ledge
r
r
2
Other
Receivable
s Account
Sourc Categor Transactio Conditio

e
y
n Type
n
Source
InFusio Other
n USA
Other
None
Use for
many-tomany
journals
only
Valu
e
Default 9000
clearing
balancin
g
segmen
t value
Note
The Ledger Balancing Options and Clearing Company Options appear as one
line on the form.
Journal Balancing
Lin Line
e
Type
Legal
Cost
y
ny
er
uct

nt
any
it
dit
Expen InFusi 3100

se
on
Farms
100
1200
52330 0000
150
Expen InFusi 3100

se
on
Farms
300
1200
52340 0000
200
Expen InFusi 3300

se
on
Farms
200
1300
52345 0000
300
Liabili InFusi 3400

ty
on
Farms
500
1300
40118 0000
320
Liabili InFusi 3500

ty
on
Farms
600
1400
40112 0000
330
Journal Balancing
Us
es
Ru Li Line
le ne Type
Lega
Cos
l
t
Entit Comp Cen Prod Acco Intercom De
y
any
ter uct
unt
pany
bit
Expense InFus 3100

ion
Farm
s
100
1200 5233
0
0000
150
Expense InFus 3100

ion
Farm
300
1200 5234
0
0000
200
Cre
dit
s
3
Expense InFus 3300

ion
Farm
s
200
1300 5234
5
0000
300
Liability
InFus 3400
ion
Farm
s
500
1300 4011
8
0000
320
Liability
InFus 3500
ion
Farm
s
600
1400 4011
2
0000
330
Intercom
pany
Receivab
le
9000
000
0000 1305
0
3100
Intercom
pany
Payable
3100
100
1200 2105
0
9000
Intercom
pany
Receivab
le
9000
000
0000 1305
0
3100
Intercom
pany
Payable
3100
300
1200 2105
0
9000
10 Intercom
pany
Receivab
le
9000
000
0000 1305
0
3300
11 Intercom
pany
Payable
3300
200
1300 2105
0
9000
12 Intercom
pany
Receivab
le
3400
200
1300 1305
0
9000
150
150
200
200
300
300
320
13 Intercom
pany
Payable
9000
000
000
2105
0
3400
14 Intercom
pany
Receivab
le
3500
600
1400 1305
0
9000
15 Intercom
pany
Payable
9000
000
000
3500
2105
0
320
330
330
34 Define Financial Reporting

Financial Reporting Center Configuration: How It Works
Setting up Your Financial Reporting Center: Critical Choices
Financial Reporting Center Configuration: How It

Works
The Oracle Fusion Financial Reporting Center provides entry to General
Ledger balances financial reporting functions. It provides secure, self-service
access to reports that use real time account information.
You can design traditional financial report formats such as balance sheets,
profit and loss statements, and cash flow reports. You can also design
nontraditional formats for financial or analytic data that include text and
graphics.
Components
Financial Reporting Center is comprised of numerous components:
Financial Reporting: Financial users and analysts access live reports

and books or published snapshot reports and books from previously
scheduled batches in a variety of formats. Other functionality includes:
o Refreshing report data using runtime points of view or
parameters
o Drill through capability from parents to other parents
o Drill down to detail balances, journal lines, and subledger
transactions.
Smart View: Financial analysts view, import, manipulate, distribute, and

share data from your Oracle Fusion General Ledger balances in
Microsoft Excel.
Account Monitor and Account Inspector: Financial analysts monitor and

track key account balances in real time at every level of your
dimensions and hierarchies. These tools provide multidimensional

account analysis and drill down capability.
Financial Reporting Workspace: Reporting administrators create, open,

save, and delete folders and store report objects, reports, and
snapshot reports.
Financial Reporting Studio: Report authors use an object-oriented

graphical report layout with report objects, such as text boxes, grids,
images, and charts, to design reports.
Setting up Your Financial Reporting Center: Critical

Choices
Oracle Fusion Financial Reporting Center is a powerful tool for accessing,
designing, and presenting financial reports and analytic data. The steps
needed to configure and install the components in Financial Reporting Center
consist of:
Configuring Financial Reporting Center
Configuring Workspace Database Connection
Installing Financial Reporting Studio
Installing Smart View
Configuring Financial Reporting Center

Users access reports through the folder structure in Workspace.
Administrators should define the folder structure in Workspace considering
security requirements for both folder and reports, as well as report
distribution requirements for financial reporting batches. Security should be
set up on folders and reports from Workspace so users can only view the
folders and the reports that they can access.
For more information on configuring the Financial Reporting Client including
user name, password, server, and report structure, see the following:
Oracle Hyperion Enterprise Performance Management System

Installation Start Here for Oracle Hyperion Enterprise Performance
Management. See especially the following topics:
o Installing EPM System Products

o Financial Reporting Ports

Installation and Configuration Guide for Hyperion Enterprise
Performance Management. See especially the following topics:
o Configuring EPM System Products
o Performing Post Configuration Tasks
Oracle Hyperion Financial Reporting, Fusion Edition Administrator's

Guide for Oracle Hyperion Financial Reporting
Configuring Workspace Database Connection

Administrators need to create database connections from Workspace so
users can access the cubes from either Workspace or Financial Reporting
Studio.
Note
Ledger setup has to be completed before the database connection can be
created. Cubes are created as part of ledger setup. There is a separate cube
for each combination of chart of accounts and accounting calendar. A
database connection is needed for each cube.
Steps to define a database connection are:
1. From Workspace -> BI Catalog (main tab), select Tools ->
Database Connection Manager
2. Select New button
3. Enter a user friendly name for the connection
4. Enter the Essbase server, user and password, and select Application
(i.e. cube) and database
For more information on configuring Essbase database connections in
Workspace see: Oracle Essbase Database Administrator's Guide for Oracle
Essbase
Note
The database connection is available in both Workspace and Financial

Reporting Studio. Optionally, it can be setup in Financial Reporting Studio
when putting grids on a report. This should only be done by an administrator.
Installing Financial Reporting Studio

Financial Reporting Studio is client-based software. Report authors need to
download the installation files in Workspace from Navigator -> Tools ->
Download Desktop Integrator Installer to install Financial Reporting
Studio.
After completing the installation, obtain financial reporting server information
from your system administrator to connect from the local client to the Oracle
Fusion instance.
For more information on configuring Financial Reporting Studio client for
users, see the following:

Installation and Configuration Guide for Oracle Hyperion Enterprise
Performance Management. See especially the following topics:
o Installing Financial Reporting Studio and Financial Reporting Print
Server
o Configuring the Financial Reporting Print Server
o Administrative Information for Financial Reporting
Installing Smart View

Smart View is an Excel add-in that must be loaded to each client. Users need
to download the installation files in Workspace from Navigator -> Tools ->
Download Desktop Integrator Installer and select to install Smart View.
Note
Since Smart View is an add-in to Microsoft Office products, you can install
Smart View only on Windows operating system.
Once Smart View is installed, it must be configured to connect to Oracle
Fusion Applications. Obtain the Smart View Shared Connections URL
information from your system administrator and enter it in Microsoft Excel
using the following navigation path: Smart View -> Options -> Advanced
-> Shared Connections URL..
For more information on configuring Smart View client for users, see the
following:

Installation and Configuration Guide, for Oracle Hyperion Enterprise
Performance Management, especially the Installing Smart View topic
Oracle Hyperion Smart View for Office, Fusion Edition User's Guide for
Oracle Hyperion Smart View
Glossary
3DES
Abbreviation for Triple Data Encryption Standard. An algorithm that applies
the Data Encryption Standard (DES) cipher algorithm three times to each
data block.
abstract role
A description of a person's function in the enterprise that is unrelated to the
person's job (position), such as employee, contingent worker, or line
manager. A type of enterprise role.
accompanying letter
A letter accompanying a payment file which summarizes its contents.
account rule
The rule that builds the account on a subledger journal entry. It can be used
to derive complete accounts or a segment value. Conditions can be defined
within a rule so that a different account is used based on particular attributes
of a transaction.
accounting attribute
Predefined fields that map to components of subledger journal entries.
Sources are assigned to accounting attributes.
accounting event class
Categories that classify transaction types and group event types for
accounting rules.
accounting event type
Represents a business operation that may have an accounting impact.
accounting flexfield
The chart of accounts that determines the structure, such as the number and
order of individual segments, as well as the corresponding values per
segment.
accounting method
A set of journal entry rules which determine how a subledger journal entry is
to be created for each event class or event type.
accounting period
The fiscal period used to report financial results, such as a calendar month or
fiscal period.
action
The kind of access named in a security policy, such as view or edit.
ADF
Acronym for Application Developer Framework. A set of programming
principles and rules for developing software applications.
application feature
A standardized functionality that is available to implemented.
application identity
Predefined application level user with elevated privileges. An application
identity authorizes jobs and transactions for which other users are not
authorized, such as a payroll run authorized to access a taxpayer ID while
the user who initiated the job is not authorized to access such personally
identifiable information.
application role
A role specific to applications and stored in the policy store.
Applications Core
Abbreviation for Oracle Fusion Middleware Extensions for Applications. The
technical product code is FND.
AS2
Acronym for Applicability Statement 2. A specification for Electronic Data
Interchange (EDI) between businesses using the Internet's Web page
protocol, the Hypertext Transfer Protocol (HTTP). The AS2 standard allows
businesses to use a common, single communications solution, which
eliminates the complications and costs when different businesses in a
network use different transfer protocols.
assignment
A set of information, including job, position, pay, compensation, managers,
working hours, and work location, that defines a worker's or nonworker's role
in a legal employer.
automatic assignment catalog
A non-hierarchical catalog to which categories that match the catalog's
Catalog Structure value are automatically added. Add categories and share
categories actions are disabled for this catalog configuration.
automatic ofset
A method for balancing invoice and payment journal entries that cross
primary balancing segment values.
AutoPost criteria sets
A grouping of options and submission frequencies used to select journal
entries for automatic posting.
balancing segment
A chart of accounts segment used to automatically balance all journal entries
for each value of this segment.
bar code
A printable bar code that uniquely identifies each employee's expense
report.
beneficiary
A person or organization designated to receive benefits from a compensation
plan on the death of the plan participant.
bill payable
Payment documents that are payable at maturity.
both pay
The deploying company pays the corporate card issuer for business
expenses and the employee pays the corporate card issuer for personal
expenses.
BPEL
Business Process Execution Language; a standard language for defining how
to send XML messages to remote services, manipulate XML data structures,
receive XML messages asynchronously from remote services, manage events
and exceptions, define parallel sequences of execution, and undo parts of
processes when exceptions occur.
browsing category
Parent or intermediate category that is associated with other categories in
the catalog hierarchy, but has no assigned items.
business function
A business process, or an activity that can be performed by people working
within a business unit and describes how a business unit is used.
business object
A resource in an enterprise database, such as an invoice or purchase order.
business unit
A unit of an enterprise that performs one or many business functions that

can be rolled up in a management hierarchy.
calendar event
A period that signifies an event, such as a public holiday or a training course,
that impacts worker availability.
card feed file
A file containing corporate card transactions that originated from the card
issuer's server.
catalog
A collection of categories used to classify items which can be organized into
a hierarchy that represents a taxonomy.
category
Catalog component that is associated to a catalog to classify items.
chained key
An encryption approach used for data security where A encrypts B and B
encrypts C.
chart of accounts
The account structure your organization uses to record transactions and
maintain account balances.
clause adoption
Reusing a clause from the global business unit in local business units either
by adopting the clause without change or by localizing it.
clause localization
A type of clause adoption where the adopted clause is edited to suit the local
business unit needs.
clearing company
The intercompany clearing entity used to balance the journal.

company pay
The deploying company pays the corporate card issuer for all transactions.
condition
An XML filter or SQL predicate WHERE clause in a data security policy that
specifies what portions of a database resource are secured.
constant
Holds the numeric value used to evaluate numeric conditions in Contract
Expert rules. A constant permits you to reset the conditions of many rules
with just one edit.
context
A grouping of flexfield segments to store related information.
context segment
The flexfield segment used to store the context value. Each context value
can have a different set of context-sensitive segments.
context-sensitive segment
A flexfield segment that may or may not appear depending upon a context
such as other information that has been captured. Context-sensitive
segments are custom attributes that apply to certain entity rows based on
the value of the context segment.
contingent worker
A self-employed or agency-supplied worker. Contingent worker work
relationships with legal employers are typically of a specified duration. Any
person who has a contingent worker work relationship with a legal employer
is a contingent worker.
contract deviations
Differences between the contract terms in a contract and those in the

contract terms template applied to that contract and any deviations from
company policies as determined by Contract Expert feature rules.
Contract Expert
A feature of the application that permits you to create business rules in the
Contract Terms Library to enforce corporate policies and standards for
contracts.
Contract Terms Library
A repository of standard clauses, contract terms templates, and business
rules built using Contract Expert.
corporate card program
An agreement between the corporate card issuer and the deploying
company that governs the issuance of corporate cards to the deploying
company's employees and the payments to the card issuer.
corporate rate type
Rate you define to standardize rates used in conversion of one currency to
another over a period of time. This rate is generally a standard market rate
determined by senior financial management for use throughout the
organization.
cost center
A unit of activity or group of employees used to assign costs for accounting
purposes.
cost organization
A grouping of inventory organizations that indicates legal and financial
ownership of inventory, and which establishes common costing and
accounting policies.
country holding company
A legal entity that acts on behalf of several divisions within an enterprise,
and is the legal employer in a country.
cube
A block of data that contains three or more dimensions. An Essbase database
is a cube.
data dimension
A stripe of data accessed by a data role, such as the data controlled by a
business unit.
data instance set
The set of human capital management (HCM) data, such as one or more
persons, organizations, or payrolls, identified by an HCM security profile.
data role
A role for a defined set of data describing the job a user does within that
defined set of data. A data role inherits job or abstract roles and grants
entitlement to access data within a specific dimension of data based on data
security policies. A type of enterprise role.
data role template
A template used to generate data roles by specifying which base roles to
combine with which dimension values for a set of data security policies.
data security
The control of access to data. Data security controls what action a user can
taken against which data.
data security policy
A grant of entitlement to a role on an object or attribute group for a given
condition.
database resource
An applications data object at the instance, instance set, or global level,
which is secured by data security policies.
department
A division of a business enterprise dealing with a particular area of activity.

description rule
The rule that defines the description content that appears on the subledger
journal header and line.
descriptive flexfield
Customizable expansion space, such as fields used to capture additional
descriptive information or attributes about an entity, such as customer
cases. Information collection and storage may be configured to vary based
on conditions or context.
deskew
The process of straightening a crooked or skewed image.
despeckle
The process of removing unwanted dots or speckles on an image.
determinant
A value that determines which reference data set will be used in a specific
business context.
determinant type
Designates the field within transactional columns that controls how data is
shared across organizations such as business unit, asset book, cost
organization or project unit. The type determines the reference data sets that
would be used in a transaction.
determinant type
An additional and optional field within transactional columns (besides
category and application) that is used to assign document sequences. The
available determinant types are Business Unit, Ledger, Legal Entity, and Tax
Registration.
determinant value
A value specific to the determinant type dimension of a document sequence.

The determinant value is relevant in a document sequence assignment only
if the document sequence has a determinant type. If Ledger is the
determinant type for a document sequence, the determinant value is the
specific ledger number whose documents are numbered by the document
sequence.
disbursement bank account
The deploying company's bank account.
distribution set
A predefined group of accounts used to automatically create invoice
distributions for an invoice not matched to a purchase order.
division
A business-oriented subdivision within an enterprise. Each division is
organized to deliver products and services or address different markets.
DMZ
Acronym for demilitarized zone. An isolated internal network used for servers
that are accessed by external clients on the Internet, such as web servers, to
provide a measure of security for internal networks behind the firewall.
document category
A high level grouping of person documents such as visas, licences, and
medical certificates. Document subcategories provide further grouping of
document categories.
document event class
Categorization of events within an application, such as Payables, Purchasing,
or Receivables. For example, Payables event classes include standard
invoices, prepayment invoices, and credit memos.
document fiscal classification
A classification used by a tax authority to categorize a document associated
with a transaction for a tax.
document payable
An item that is ready to be paid. Equivalent to an installment in Oracle Fusion
Payables.
document sequence
A unique number that is automatically or manually assigned to a created and
saved document.
document type
A categorization of person documents that provides a set of options to
control what document information to retain, who can access the documents,
whether the documents require approval, and whether the documents are
subject to expiry. A document type exists for a combination of document
category and subcategory.
duty role
A group of function and data privileges representing one duty of a job. Duty
roles are specific to applications, stored in the policy store, and shared within
an Oracle Fusion Applications instance.
eFolio
Summary corporate card transactions. Also known as Level 2 transactions.
EFT
Acronym for Electronic Funds Transfer. A direct transfer of money from one
account to another, such as an electronic payment of an amount owed a
supplier by transferring money from a payer's disbursement bank account
into the supplier's bank account.
employment terms
A set of information about a nonworker's or employee's job, position, pay,
compensation, working hours, and work location that all assignments
associated with the employment terms inherit.
enterprise
An organization with one or more legal entities under common control.
enterprise role
Abstract, job, and data roles are shared across the enterprise. An enterprise
role is an LDAP group. An enterprise role is propagated and synchronized
across Oracle Fusion Middleware, where it is considered to be an external
role or role not specifically defined within applications.
entitlement
Grants of access to functions and data. Oracle Fusion Middleware term for
privilege.
error amount
When setting up corporate card usage policies to enforce the use of
corporate cards, an amount that exceeds the cash limit and for which an
error displays during expense entry in the expense report, which prevents
submission of the report.
error tolerance
corporate cards, a range that is from the cash limit up to the error tolerance
amount. Above that amount, the expense report is not submitted.
error tolerance percentage
corporate cards, a percentage that, when added to the cash limit, defines the
error amount. If you spend more than the error amount, the expense report
is not submitted.
ESS
Acronym for Enterprise Storage Server. An application that optimizes data
storage.
eText
A feature in Oracle Business Intelligence Publisher (BI Publisher) that enables
the format layout for fixed position and delimited formats to be presented in
an understandable tabular structure.
Europe, Middle East, and Africa (EMEA)
A regional designation used for government, marketing and business

purposes for countries in Europe, the Middle East, and Africa.
expense template
An administrator-defined list of related expense types. When you enter
expenses on your expense report, you must select a specific expense
template.
expense type
A potential expense that you can incur that has been defined by the
administrator during setup.
extensible flexfield
Customizable expansion space, as with descriptive flexfields, but able to
capture multiple sets of information within a context and multiple contexts
grouped to appear in a named region of a user interface page. Some
extensible flexfields allow grouping contexts into categories.
extract
An XML file that contains the superset of data relevant to a payment file.
feature choice
A selection you make when configuring offerings that modifies a setup task
list, or a setup page, or both.
financial reporting book
Comprised of reports and other documents such as text, PDF, PowerPoint,
Excel and Word files. When run, the report data is dynamically retrieved from
the database; the snapshot data remains static.
first party payer
The deploying company making disbursements. The first party payer
disburses funds to pay suppliers, customer refunds, and to reimburse
employee expenses.
fixed rate type
Rate you set between two currencies that remains constant. For example, a
rate set between the euro currency and each Economic and Monetary Union
(EMU) currency during the conversion to the euro currency.
flexfield
Grouping of extensible data fields called segments, where each segment is
an attribute added to an entity for capturing additional information.
flexfield segment
An extensible data field that represents an attribute on an entity and
captures a single atomic value corresponding to a predefined, single
extension column in the Oracle Fusion Applications database. A segment
appears globally or based on a context of other captured information.
format
A key setup entity in Oracle Fusion Payments, which ties together formatting
attributes, such those used by Oracle Fusion Business Intelligence Publisher
(BI Publisher) templates and validations to execute during transaction
processing.
format type
A categorization that indicates what a format is used for by Oracle Fusion
Payments. Examples of format types include payment file, remittance advice,
and bank statement.
FTP
Acronym for File Transfer Protocol. A system for transferring computer files,
generally by the Internet.
function security
The control of access to a page or a specific widget or functionality within a
page. Function security controls what a user can do.
funds capture payment profile
A key setup entity that holds rules for funds capture processing.
global area
The region across the top of the user interface. It provides access to features
and tools that are relevant to any page you are on.
grade
A component of the employment model that defines the level of
compensation for a worker.
HCM data role
A job role, such as benefits administrator, associated with specified instances
of Oracle Fusion Human Capital Management (HCM) data, such as one or
more positions or all persons in a department.
HCM securing object
An HCM object that secures access to both its own data and data in other,
related objects. For example, access to a specified set of person records can
allow access to data secured by person records, such as goal plans and
evaluations.
HTTP
Acronym for Hypertext Transfer Protocol. A request and response standard
typical of client-server computing. In HTTP, web browsers or spiders act as
clients, while an application running on the computer hosting the web site
acts as a server. The client, which submits HTTP requests, is also referred to
as the user agent. The responding server, which stores or creates resources
such as HTML files and images, may be called the origin server. In between
the user agent and origin server may be several intermediaries, such as
proxies, gateways, and tunnels.
HTTPS
Acronym for Hyper Text Transfer Protocol Secure. A protocol primarily
developed for secure, safe Internet transactions. HTTPS allows secure ecommerce transactions, such as online banking.
identity
A person representing a worker, supplier, or customer.
Incoterms
Incoterms are a series of international sales terms that represent

international commercial transportation practices and are used in contracts
for the sale of goods. These terms help clarify and divide transaction costs,
risks, and responsibilities between buyer and seller.
individual pay
The employee pays the corporate card issuer for all corporate card
transactions.
installment
Any of several parts into which a debt or other sum payable is divided for
payment at successive fixed times.
intended use fiscal classification
A tax classification based on the purpose for which a product is used.
internal payee
The deploying company or any of its business units that receive funds from
their customers, the payers. Payees receive funds from their customers by
credit card payments, debit card payments, direct debits to bank accounts,
or bills receivable transactions sent to banks.
inventory organization
A logical or physical entity in the enterprise that is used to store definitions
of items or store and transact items.
inventory organization
An organization that tracks inventory transactions and balances, and can
manufacture or distribute products.
invoice distribution
Accounting information for an invoice line, such as accounting date, amount,
and distribution combination. An invoice line can have one or more invoice
distributions.
item master
A collection of data that describes items and their attributes recorded in a

database file.
item organization
Item definition where inventory balances are not stored and movement of
inventory is not tracked in the applications. Item attributes that carry
financial and accounting information are hidden.
item subinventory
An association of an item with a subinventory that is created when you add
an item to a subinventory.
Java EE
An abbreviation for Java Platform, Enterprise Edition. A programming
platform used as the standard for developing multi-tier Java enterprise
applications.
job
A generic role that is independent of any single department or location. For
example, the jobs Manager and Consultant can occur in many departments.
job role
A role for a specific job consisting of duties, such as an accounts payable
manager or application implementation consultant. A type of enterprise role.
journal
An element of a journal entry consisting of the name, accounting date,
category, ledger, and currency for single currency journal entries. Used to
group journal lines.
journal batch
An element of a journal entry consisting of the name, source, and accounting
period. Used to group journals for processing and easier querying.
journal category
A name used to group journal entries with similar characteristics, such as

adjustments, accruals, or reclassifications.
journal entry
Point of entry of business transactions into the accounting system.
Chronological record, with an explanation of each transaction, the accounts
affected, and the amounts to increase or decrease each account.
journal line
An element of journal entries consisting of account combinations and credit
or debit amounts. Optionally, contains statistical quantities, currency
information for multicurrency journals, and additional information.
journal line rule
A rule that includes options to convert transactional data into a subledger
journal line. A condition can be defined within a rule so that the rule is only
used based on particular attributes of a transaction.
journal source
A name that indicates the origin of journal entries, such as payables,
receivables, or manual. Used as an attribute in automatic posting and journal
import processes.
key flexfield
Configurable key consisting of multiple parts or segments, each of which
may be meaningful individually or in combination with the others. Key
flexfields are commonly implemented to represent part numbers and account
numbers.
key flexfield segment instance
A single occurrence of a key flexfield segment in a key flexfield structure
instance.
key flexfield structure
The arrangement of segments in a key flexfield. In some cases, multiple
structures can be defined for a single key flexfield.
key flexfield structure instance

A single occurrence of a key flexfield structure that shares the same order of
segments as every other instance of the key flexfield structure, but uses
different value sets to validate the segments.
legal authority
A government or legal body that is charged with powers such as make laws,
levy and collect fees and taxes, and remit financial appropriations for a given
jurisdiction.
legal classification
A classification associated with a legal entity that represents its legal status
within a country and which also guides the tax determination process.
legal employer
A legal entity that employs people.
legal entity
An entity is identified and given rights and responsibilities under commercial
law, through the registration with the country's appropriate authority.
legal reporting unit
The lowest level component of a legal structure that requires registrations.
Used to group workers for the purpose of tax and social insurance reporting
or represent a part of your enterprise with a specific statutory or tax
reporting obligation.
legislative data group
A means of partitioning payroll and related data. At least one legislative data
group is required for each country where the enterprise operates. Each
legislative data group is associated with one or more payroll statutory units.
Level 2
Summary corporate card transactions. Also known as eFolio.
Level 3
Detailed corporate card transactions.

line of business
Set of one or more highly related products which service a particular
customer transaction or business need. Refers to an internal corporate
business unit.
lookup code
A value available for lookup within a lookup type such as the code BLUE
within the lookup type COLORS.
lookup type
A set of lookup codes to be used together as a list of values on a field in the
user interface.
lossy
A data encoding method which compresses data by discarding (losing) some
of it.
mainline
A branch of data that serves as a single source of truth.
managed person
In Oracle Fusion Human Capital Management security, a person for whom the
user can maintain some information. For example, line managers can
maintain information about their direct and indirect reports, and workers can
maintain information about themselves, their dependents, and their
beneficiaries.
manual payment
A payment created outside of Oracle Fusion Payables, but recorded in the
application.
manufacturing facilities
Employed in the making of goods for sale such as a factory or plant.
mapping set
Maps a combination of input source values to specific output values A
mapping set can have a segment, account, or value set as output. The
output value of a mapping set is used to derive accounts or segments in
account rules.
merchant category code
A four-digit code that identifies the industry in which the deploying company
operates.
MIS industry code
A code provided by the card issuer that identifies the type of transaction.
model profile
A collection of the work requirements and required skills and qualifications of
a workforce structure, such as a job or position.
native catalog
A catalog that a user is managing.
natural account
Categorizes account segment values by account type, asset, liability,
expense, revenue, or equity, and sets posting, budgeting, and other options.
natural account segment
A chart of accounts segment used to categorize your accounting transactions
by account type: asset, liability, owner's equity, revenue, or expense.
ofering
A comprehensive grouping of business functions, such as Sales or Product
Management, that is delivered as a unit to support one or more business
processes.
Oracle BI Publisher
An Oracle application that performs the following formatting tasks for Oracle
Fusion Payments: 1) formats extracted data into a message, such as a
settlement batch or payment file, that can be understood by the payment
system, 2) supports remittance advice formatting and delivery.
Oracle BI Publisher templates
Format patterns provided by Oracle Business Intelligence Publisher (BI
Publisher) that Oracle Fusion Payments uses to correctly format funds
capture and disbursement transactions and which enable users to easily
manage modifications to their formats.
party fiscal classification
A classification used by a tax authority to categorize a party for a tax.
payee
A supplier or employee who receives payment.
payment instrument
A credit card, debit card, or bank account used by a payee to collect a
payment from an external payer.
payment method
Indicates the method of payment, such as check, cash, or credit.
payment process profile
A setup entity which drives processing behavior for each document payable,
payment, and payment file.
payment request
A grouping of documents payable for which payment is requested. A
payment request specifies the template to use in Oracle Fusion Payables,
selects invoices for a pay run, and groups the invoices into payments based
on setup rules.
payment system
An external organization that provides financial settlement services. The

payment system can be the bank at which the deploying company has its
bank accounts or it can be a third-party processor that connects companies
and financial networks.
payroll statutory unit
A legal entity registered to report payroll tax and social insurance. A legal
employer can also be a payroll statutory unit, but a payroll statutory unit can
represent multiple legal employers.
pending worker
A person who will be hired or start a contingent worker placement and for
whom you create a person record that is effective before the hire or start
date.
person type
A subcategory of a system person type, which the enterprise can define.
Person type is specified for a person at the employment-terms or assignment
level.
personally identifiable information
Any piece of information that can potentially be used to uniquely identify,
contact, or locate a single person. Within the context of an enterprise, some
PII data can be considered public, such as a person's name and work phone
number, while other PII data is confidential, such as national identifier or
passport number.
PL/SQL
Abbreviation for procedural structured queried language.
PO
Abbrevation for purchase order.
point of view
User selected dimensions that are not included in the grids at the row,
column or page levels for a particular report. Only these dimensions can be
overridden at run time, unless user also specifically defined Prompt for the
dimensions on the grid.
position
A specific occurrence of one job, fixed within one department, also often one
location. For example, the position Finance Manager is an instance of the job
Manager in the Finance Department.
primary balancing segment value
A segment value used to represent a legal entity in the chart of accounts and
automatically balance all intercompany and intracompany transactions and
journal entries.
primary ledger
Main record-keeping ledger.
privilege
A grant or entitlement of access to functions and data. A privilege is a single,
real world action on a single business object.
process
A program that you schedule and run to process data and, if appropriate,
generate output as a report. Also known as scheduled process.
product category fiscal classification
A classification defined for a noninventory-based product category, that is
used for tax determination or tax reporting purpose.
product fiscal classification
A classification used by a tax authority to categorize a product for a tax.
There could be more than one by tax. For example, for Brazil two
classifications are required.
profile option
User preferences and system configuration options consisting of a name and

a value, that can be set at hierarchical levels of an enterprise. Also called a
profile or user option.
profile option level
A level at which profile option values are defined. Site, product, and user are
predefined levels.
profile option level hierarchy
The ordering of profile option levels. The order of the levels in the hierarchy
determines which levels take precedence.
profile option value
The value portion of a profile option's name and value. A profile option may
have multiple values set at different levels, such as site or user.
project expenditure organization
An organization that can incur expenditures and hold financial plans for
projects.
public person
In Oracle Fusion Human Capital Management security, a person for whom
some basic information is publicly available. For example, users typically
access the contact details of public persons, such as phone numbers and
locations, using the person gallery.
quick payment
A single payment that you create for one more invoices without submitting a
payment process request.
reference data
Data in application tables that is not transactional and not high-volume such
as sales methods, transaction types, or payment terms, and can be shared
and used across organizational boundaries.
reference data set
Contains reference data that can be shared across a number of business

units or other determinant types. A set supports common administration of
that reference data.
reference group
A logical grouping of tables that correspond to logical entities such as
payment terms defined across multiple tables or views. Grouping establishes
common partitioning requirements across the entities causing them to share
the same set assignments.
reference object
Standardized data model containing reference information owned by other
subledger applications and used by the Create Accounting program to create
subledger journal entries from accounting events.
referenced category
A category within the native catalog that is shared from a designated source
catalog. A reference category is not editable.
registration
The record of a party's identity related details with the appropriate
government or legal authorities for the purpose of claiming and ensuring
legal and or commercial rights and responsibilities.
reporting entity
A person or organization that has a unique tax identification number. Used
for US 1099 tax reporting.
role
Controls access to application functions and data.
role hierarchy
Structure of roles to reflect an organization's lines of authority and
responsibility. In a role hierarchy, a parent role inherits all the entitlement of
one or more child roles.
role mapping
A relationship between one or more job roles, abstract roles, and data roles
and one or more conditions. Depending on role-mapping options, the role
can be provisioned to or by users with at least one assignment that matches
the conditions in the role mapping.
role provisioning
The automatic or manual allocation of an abstract role, a job role, or a data
role to a user.
sandbox
A runtime session that commits changes out of reach of mainline users.
security profile
A set of criteria that identifies one or more human capital management
(HCM) objects of a single type for the purposes of securing access to those
objects. Security profiles can be defined for persons, organizations, positions,
countries, LDGs, document types, payrolls, and payroll flows.
security reference implementation
Predefined function and data security in Oracle Fusion Applications, including
role based access control, and policies that protect functions, data, and
segregation of duties. The reference implementation supports identity
management, access provisioning, and security enforcement across the
tools, data transformations, access methods, and the information life cycle of
an enterprise.
segregation of duties
An internal control to prevent a single individual from performing two or
more phases of a business transaction or operation that could result in fraud.
separate remittance advice
A notice sent to a payee that lists the invoices that the deploying company
has paid electronically to that payee's bank account.
service provider model
A business unit that provides specific business functions for another business
unit.
servlet
A Java programming language class used to extend the capabilities of
servers that host applications accessed via a request-response programming
model. Although servlets can respond to any type of request, they are
commonly used to extend the applications hosted by Web servers. For such
applications, Java Servlet technology defines HTTP-specific servlet classes.
set
Reference data that is organized into groups appropriate to organizational
entities, to enable reference data sharing.
set enabled
An entity, such as a lookup, customer, location, organization, or document
attachment, that is allowed to participate in reference data sharing by
drawing on the data of a reference data set.
settlement
A funds capture transaction that moves money from the account of the
cardholder or the bank account owner into the account of the payee.
settlement batch
A group of transactions, typically settlements and credits, that are sent to
the payment system together in a file. Settlement batches are generally
used with a processor-model payment system.
shared category
A category within a source catalog that has been added to a native catalog
as a referenced category. The category can be shared with one or more
catalogs.
SIC code
A Standard Industrial Classification code, which represents a United States
government system for classifying industries by a four-digit code.
SOA
Abbreviation for service-oriented architecture.
source
Contextual and reference information from subledger applications. This
information is used in conjunction with accounting rules to create subledger
journal entries.
source product
The product that owns a transaction and submits the request for
disbursement or funds capture to Oracle Fusion Payments.
spot rate type
Rate you enter to perform conversion based on this rate as of a specific date.
This rate applies to the immediate delivery of a currency.
SQL predicate
A type of condition using SQL to constrain the data secured by a data
security policy.
storage facilities
Commercial building for storage of goods such as a warehouse.
subledger
A low-level ledger that stores and manages the details that substantiate the
monetary value stored in the general ledger. Oracle Fusion Receivables and
Oracle Fusion Payables are examples of subledgers.
subledger journal entry
A detailed journal entry generated for a transaction in a subledger
application.
subledger journal entry line
An individual debit or credit line that is part of a subledger journal entry.
subledger journal entry rule set
A set of rules defining how to generate a complete journal entry for an
accounting event.
supporting reference
Stores additional source information about a subledger journal entry either at
the header or line level. They can be used to establish a subledger balance
for a particular source value or combination of source values for a particular
account.
system key
The encryption master key for the entire installation. It is stored in an Oracle
Wallet file and is used to encrypt Payments system subkeys.
system person type
A fixed name that the application uses to identify a group of people.
tax
The classification of a charge imposed by a government through a fiscal or
tax authority.
tax determining factor
An input that affects the outcome of a tax calculation process. Tax
determining factors are grouped into tax determining factor sets and used to
define tax condition sets and tax rules.
tax exception
A condition or combination of conditions that result in a change from the
standard values for a particular product.
tax exemption
A full or partial exclusion from taxes within a given time period.
tax formula
A tax formula is used to define the taxable basis and tax calculation for a
given tax.
tax jurisdiction
A geographic area where a tax is levied by a specific tax authority.
tax rate
The rate specified for a tax status for an effective time period. A tax rate can
be expressed as a percentage or a value per unit quantity.
tax recovery
The full or partial reclaim of taxes paid on the purchase or movement of a
product.
tax regime
The set of tax rules that determines the treatment of one or more taxes
administered by a tax authority.
tax registration
The registration of a party with a tax authority that confers tax rights and
imposes certain tax obligations.
tax rule
A user-defined rule that looks for a result for a specific tax determination
process, such as determining place of supply or tax registration, in relation to
a tax on a transaction.
tax status
The taxable nature of a product in the context of a transaction for a tax.
trading partner
An external party, such as a supplier, in the Oracle B2B application for which
electronic documents are sent or from which documents are received. A
trading partner in Oracle B2B corresponds to a supplier site.
transaction business category
A business classification used to identify and categorize an external
transaction into a tax transaction.
transaction codes
Codes that the card issuer assigns to corporate card transactions in the
corporate card feed file.
transaction fiscal classification
A classification used by a tax authority to categorize a transaction for a tax.
There could be more than one by tax. For example, for Brazil, three
classifications are required: a) transaction nature, such as free sample,
demonstration, consignment, donation; b) transaction classification, such as
the sale of products previously acquired, the sale of products that were
manufactured by the company; and c) operation classification, such as ship
from - ship to relationship.
transaction object
Standardized data model containing transaction information used by the
Create Accounting program to create subledger journal entries from
accounting events.
transmission configuration
Configuration for transmitting files such as payment files.
transmission protocol
A method used to electronically transmit data, such as FTP and Secure HTTP.
tree
Information or data organized for display into a hierarchy with one or more
root nodes connected to branches of nodes. Each node corresponds to data
from one or more data sources. A tree must have a structure.
tree structure
Characteristics applied to trees, such as what data to include or how the tree
is versioned and accessed.
tree version
An instance of a tree. If a tree is associated with a reference data set, all
versions belong to one set. Includes life cycle elements such as start and end
date and a status indicator whether the tree is active or not.
usage rules
Rules that determine when payment methods and payment process profiles
can be assigned for use on documents payable.
user rate type
Rate you enter at journal entry time to convert foreign currency transactions
to your functional currency.
validations
Rules that ensure that transactions are valid before they are printed or
submitted electronically to payment systems. You use validations to ensure
that disbursement transactions, such as invoices, payments, and payment
files meet specific conditions before they can be paid.
value set
A set of valid values against which values entered by an end user are
validated. The set may be tree structured (hierarchical).
value-added tax (VAT)
An indirect tax on consumer expenditure that is collected on business
transactions and imported goods. Value-added tax (VAT) is charged at each
production, distribution, and retail stage in the supply of products. If
customers are registered for VAT and use the supplies for taxable business
purposes, then they will typically receive credit for the VAT that is paid.
warning amount
corporate cards, an amount that exceeds the cash limit and for which a
warning displays during expense entry in the expense report.
warning tolerance
corporate cards, a range that is from the cash limit up to the warning
tolerance amount. Above that amount, a warning displays.
warning tolerance percentage

corporate cards, a percentage that, when added to the cash limit, defines the
warning amount. If you spend more than the warning amount, a warning
displays.
withholding tax group
A collection of one or more withholding tax codes.
WLS
Acronym for Weblogic Server. The application server for building and
deploying enterprise Java enterprise applications.
work relationship
An association between a person and a legal employer, where the worker
type determines whether the relationship is a nonworker, contingent worker,
or employee work relationship.
workflow
An automated process in which tasks are passed from a user, a group of
users, or the application to another for consideration or action. The tasks are
routed in a logical sequence to achieve an end result.
XML filter
A type of condition using XML to constrain the data secured by a data
security policy.

Oracle Fusion Applications Financials Implementation Guide II

Uploaded by

Copyright:

Available Formats

Oracle Fusion Applications Financials Implementation Guide II

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Fusion Applications Financials Implementation Guide II

Uploaded by

Copyright:

Available Formats

What are the three configuration tasks for Notes mapping to Receivables?

What are the three configuration tasks for Notes mapping to Receivables?

What are the seven configuration tasks necessary to create an operational Receivables environment?

What are the seven configuration tasks necessary to create an operational Receivables environment?

21 Define Common Accounts Receivable

Simple Configuration to Operate Receivables:

Receivables Configuration Tasks

3. Define AutoAccounting Rules

Notes Mapping for Receivables: Explained

Notes Mapping Configuration Tasks

Define Receivables Activities

Using Receivables Activity Types

GL Account Source Options

Tax Rate Code Source

Tax Rate Code Source Options

Allocates the entire tax amount according to the GL Account Sourceyou

Define AutoCash Rule Sets

Match Payment with Invoice

Clear the Account

Clear Past Due Invoices

Clear Past Due Invoices Grouped by Payment Terms

Apply to the Oldest Invoice First

Match Payment with Invoice

Discount Grace Days

The invoice details are:

Clear the Account

This table shows the customer activity:

Past Due Debits/Credits

Invoice Amount Late Charges In Dispute

Credit Memo 100

Clear Past Due Invoices

This table shows the customer activity:

Past Due Debits/Credits

Invoice Amount Late Charges In Dispute

Clear Past Due Invoices Grouped by Payment Terms

Due Date Invoice Amount

Receivables groups these transactions as follows:

Group 1: Transactions 1,2,3Amount: $900Group Due Date: 25-MAY

Group 2: Transaction 4Amount: $900Group Due Date: 20-JUN

Group 3: Transaction 5Amount: $905Group Due Date: 25-MAY

Apply to the Oldest Invoice First

Apply Partial Receipts

This table shows the customer activity:

Using an AutoCash Rule Set: Worked Example

Creating the AutoCash Rule Set

Open Balance Calculation: Discounts

Open Balance Calculation: Late Charges

Open Balance Calculation: Items in Dispute No

Automatic Matching Rules: Remaining

1. Match Payment with

2. Clear The Account

3. Apply To The Oldest

Processing Payment Using the AutoCash Rule Set

Since the discount date of 30-NOV-02 has passed and

invoice is now equal to either $0 or the amount of any late

Because the Late charges option is set to No, late

b. Receivables now applies $200 to the next oldest invoice, Invoice

Because the Late charges option is set to No, late

c. Receivables applies the remaining $100 to Invoice 125 ($150) as