2Payments
This chapter contains the following:
Prepare and Record Payments
Payment Process Request Template
A payment process request is a group of installments submitted for payment. You can submit a payment process request on the Submit Payment Process Request page. You can also create a template on the Create Payment Process Request Template page and schedule the template to submit the payment process request later.
By using a template, you can:
-
Minimize date entry for frequently used payment processing settings.
-
Identify cash requirements by running the Payables Cash Requirement report against the template before submitting the template for processing.
-
Schedule payment process requests to run on a regular basis. The video Submitting a Scheduled Process is a narrated visual overview of the process. Details on scheduling processes can be found in the topic Submitting Scheduled Processes and Process Sets Procedures.
For each payment process request you can specify:
-
Selection criteria
-
Payment attributes
-
Processing options
Selection Criteria
Selection criteria, such as invoice business unit, payment business unit, and payment priority determine which installments are selected for payment.
This table describes the fields on the Selection Criteria tab on the Submit Payment Process Request and Create or Edit Payment Process Request Template pages.
Selection Criteria | Description |
---|---|
Pay through date |
Latest due date for an installment. |
Pay from date |
Earliest due date for an installment. |
From payment priority |
Lowest payment priority assigned to an installment. |
To payment priority |
Highest payment priority assigned to an installment. |
Date basis |
Basis for the date that affects installment selection and whether to take a discount. |
Include zero amount invoices |
Include invoices that have a zero amount due. |
Pay groups |
Invoice categorization for payment. The default setting includes all pay groups, but you can specify one or more pay groups. |
Currencies |
Currencies for invoices and payments. The default setting includes all currencies, but you can specify either one or more invoice currencies, or one or more payment currencies. |
Business units |
Business units for invoices and payments. The default setting includes all business units. If you specify:
|
Legal entities |
Legal entity associated with an invoice. The default setting includes all legal entities, but you can specify one or more legal entities. |
Supplier type |
Supplier classification, such as tax authority or contractor. |
Payment method |
Method of payment for an installment. |
Invoice conversion rate type |
Type of rate that converts the invoice currency to the ledger currency. |
Supplier or party |
Supplier or party on an invoice. |
Invoice group |
User-defined name assigned to one or more invoices. Note: If you implemented centralized payment processing,
the service provider setup and your business unit access affect the
list of values in the Invoice Group field. The invoice groups are from the invoice business units that
are serviced by the payment business units that you have access to.
|
Payment Attributes
Specify payment details with attributes, such as payment date and payment process profile.
Processing Options
The processing options for a payment process request determine the level of automation for that request. For example, you can set options that submit the request through to completion without stopping, or you can stop the request to review selected installments.
This table describes the options on the Processing Options tab on the Submit Payment Process Request and Create or Edit Payment Process Request Template pages.
Option | Description |
---|---|
Apply credits up to zero amount payment |
Applies credits and creates a zero amount payment if the sum of the selected installments is negative after the installments are grouped for payment. Note: If you set this option and bank charges apply, the
payment process request rejects the installments because they might
reduce the payment amount less than zero.
|
Review installments |
Stops the payment process request after selecting the installments. You can:
|
Review proposed payments |
Stops the payment process request after grouping installments into payments and before building the payments. |
Create payment files immediately |
Creates payment files for the submitted request instead of waiting to combine payments from other requests into payment files. |
Validation failure handling for documents |
Specifies processing instructions for handling document validation failures. |
Validation failure handling for payments |
Specifies processing instructions for handling payment validation failures. |
How Payment Process Requests Are Processed
When you submit a payment process request, the request passes through various stages of processing. Within each stage, a request can have a different status. Some statuses require that you take action. You can use the Payments Overview page to view and act on payment process requests.
Settings That Affect Payment Process Request Processing
You can control the level of automation of a payment process request by setting the following options on the Submit Payment Process Request and the Create Payment Process Request Template pages:
-
Apply credits up to zero amount payment
-
Review installments
-
Review proposed payments
-
Create payment files immediately
-
Handle document and payment validation failures
Depending on how you set these options, a payment process request might require your input before processing can complete. Issues that arise during payment processing might also require your input, regardless of how these options are set.
How Payment Process Requests Are Processed
This table describes the stages and statuses that a payment process request can have and indicates whether user action is required.
Stage | Status | Status Description | Requires User Action? |
---|---|---|---|
Installment selection |
Pending |
System resources aren't yet available to begin processing. |
No |
Installment selection |
Pending installments review |
The option to review installments is enabled, so manual review is required. |
Yes |
Installment selection |
Missing payment conversion rates |
The payment conversion rate type is User and payment conversion rates are missing. |
Yes |
Installment selection |
Missing cross-currency rates |
Cross-currency rates or the cross-currency rate type is missing. |
Yes, except for missing non-User rate types. |
Installment selection |
Installments selected |
The installments are selected for payment. |
No |
Document validation |
Pending action to complete information required |
Documents are missing required information, such as disbursement bank account or payment process profile. |
Yes |
Document validation |
Assignment complete |
All documents have the required information. |
No |
Document validation |
Pending action to address document validation errors |
Some installments failed validation and the option for handling document validation failures is set to Stop process for review. Manual review is required. |
Yes |
Document validation |
Retry document validation |
Documents are ready for retrying validation. |
No |
Document validation |
Documents validated |
Documents were validated. Some documents may be rejected. This is a short-lived, transitional status. |
No |
Payment validation |
Pending action to address payment validation errors |
Some payments failed validation and the option for handling payment validation failures is set to Stop process for review. Manual review is required. |
Yes |
Payment validation |
Retry payment creation |
The payment process request is ready to start another payment creation and validation. |
No |
Payment validation |
Pending proposed payment review |
Payments were created and the option to review the proposed payments is enabled, so manual review is required. |
Yes |
Payment file build |
Waiting for payment file processing |
Payments are either included in one or more payment files, or are waiting to be picked up. For example, the Create Payment Files process is scheduled, but not yet started. This status remains unchanged until every valid payment in an active payment process request is completed. |
Depends on the status of the payment file. |
Terminated |
Terminated |
The payment process request was terminated. |
No |
Terminated |
No available installments |
None of the installments available for payment meet the selection criteria. |
No |
Terminated |
Failed document validation |
One of the following has occurred:
|
No |
Terminated |
Failed payment validation |
One of the following has occurred:
|
No |
Refining the Installment Selection
Enhance your installment selection by configuring your payment process file and your internal bank account to filter installments during the payment request process. The payment request process selects installments based on business unit, currency, and payment method and confirms they match the usage rules defined in the payment process profile. Refine your selection process by adding business units and currencies to the internal bank account as selection criteria. Using the internal bank account in the payment request process, only selects installments that have in combination, any of the business units and currencies defined in the internal bank account. Your efficiency improves by refining the selection process and prevents installment rejections during the build payment process due to mismatched installment attributes with the payment process profile or the internal bank account.
How Payment Requests Import Data is Processed
Use the Import Payables Payment Requests process to create payment requests from data in the Payment Request interface table. After the import is complete, you can search for the payment requests in Payables to pay the invoices.
Create the payment requests by completing the following steps:
-
Prepare the data using the predefined XLSM template.
-
Generate the CSV file.
-
Transfer the data.
-
Load and import the data.
-
Reload the corrected data as necessary.
Settings That Affect the Import Payment Requests
This table describes the parameters for submitting the Payables Payment Requests Import process.
Parameter | *Required | Description |
---|---|---|
*Ledger |
Yes |
Enter the name of a ledger. |
Business Unit |
Optional |
Enter the name of the business unit for the payment request. |
*Source |
Yes Note: The Source used for importing payment requests must be created in the Payables Lookups and in the Trading Community Architecture. Configuring the source for Payables can be found in the FSM task: Manage Payables Lookup with the lookup type as: SOURCE. Configuring the Source for TCA can be found in the FSM task Manage Trading Community Source Systems. |
Enter the source of payment request. |
Import Set |
Optional |
Enter the name of an import set to limit the import to payment request with a particular import set in the Payment Request Interface table. You can import data for the same source by specifying a unique import set for each request. This reduces the processing time of your import. The Import Payables Payment Request process imports data with the source and group combination that you specify. |
Invoice Group |
Optional |
Enter the name of an invoice group. |
Accounting Date |
Optional |
Enter an accounting date. If you don't enter a date, the Accounting Date is assigned based on the Accounting Date Basis option. |
Summarize Report |
Optional |
Enter whether to summarize the audit portion of the Payables Payment Request Interface Import Report. If you don't summarize, and you're importing a large number of payment requests records, the report could be very long. |
Purge |
Optional |
Enter Yes, for Payables to delete records that match the Source and Group ID of this import. Enter No, to keep all the records except the rejected records |
How Import Payment Requests is Processed
Submit the Import Payables Payment Requests process from the Manage Scheduled Processes page. Successfully imported payment requests are in the status validated, have distributions and installments, and can be queried in Manage Invoices page. The import process rejects payment requests records with insufficient or invalid data. The process produces a report so you can review the payment requests that weren't imported. Correct the payment request information and resubmit this template with the corrected data. Only data which was incorrect is required to be submitted again.
Early Payment Discount Offers
You can pay invoices early in return for real-time discounts with Payables Early Payment Discount Offers feature. These discount offers are available to you on a real-time basis on every single day of the payment cycle. The discounts decrease on a sliding scale depending on what the supplier and you have agreed upon for taking discounts.
Here are two ways to offer early payment discounts to your suppliers:
Through dynamic offers (on an ad hoc basis) for single payments.
Through standing offers for payment process request.
Dynamic Offers
Oracle Financials Cloud uses the adaptive intelligence models to calculate discount recommendations for single payments. When you create payments, you can accept the recommended APR for the discount or override it. The discount rate you accept, combined with the number of days paid early, determines the actual discount and payment amounts. Dynamic discounts (Ad hoc discounts) are helpful when managing an unexpected early payment request. Standing Offers.
Standing Offers
When you enroll a supplier into standing offers, you're creating a set of criteria for recurring offers over an agreed time period. Standing offers use a combination of adaptive intelligence calculations with manual overrides that you specify, such as APR and site assignment. Use the Supervisory Controls page as a starting place to view suppliers and manage their enrollments. In your payment process request, select the options to take early payment discounts based on standing offers.
Required Set Up for Early Payment Discount Offers
Prior to using Early Payment Discount Offers or commonly referred to as Dynamic Discounts, you must do the following:
-
In the Offerings work area, enable the Dynamic Offers and Standing Offers for Early Payment Offers feature as follows:
-
Offering: Financials
-
Functional Area: Payables
-
Features: Dynamic Offers for Early Payment Offers.
-
Click Done to go back to the Setup: Financials page.
Note: There's no additional steps needed.
-
-
You must have the license for the Adaptive Intelligent Applications (AI). This application provides the integration for Payables to calculate various discounts.
Processing Early Payment Discount Offers
Use the dynamic discount when applying payment to a supplier invoice. When you create the payment, you have the following options available:
-
You retrieve the AI data science driven discount recommendations.
-
You can accept or override the AI discount recommendations.
-
The discount rate that's accepted and combined with the days paid early, determines the various discount amounts and payment amounts.
Processing Early Payment Discount Offers: Standing Offers
Use the standing offer when applying payment through a payment process request. You can submit a payment process request on the Submit Payment Process Request page. For the payment process request, you can specify new Selection criteria: Select Early Payment Invoices. (Refer screen below for the selection option)
-
If the selection is 'Yes' you select the installments for payment based on pay through dates and other selection criteria both for the regular and enrolled suppliers
If the selection is 'Yes' you select the installments for payment based on pay through dates and other selection criteria both for the regular and enrolled suppliers If the selection is Yes you select the installments for payment based on pay through dates and other selection criteria both for the regular and enrolled suppliers. You can:
-
Review installments eligible for early payments.
-
Remove or add installments for early payments.
-
Edit discount amounts, annual percentage rate (APR) and payment amount.
Points to Consider
The benefits of using the early payment discount offers are the following:
-
You can manage early payment requests from the supplier efficiently.
-
Provides the buyer with additional funds to use due to the amount saved by the return of funds from the discount.
-
When you pay suppliers early, they have access to the additional funds in exchange of a nominal return.
Examples of Reviewing Early Payment Discount Offers
You can select the available early payment discount offers based on the invoice amount, the payment due date, number of accelerated days, and the annual percentage rate (APR).
Rates Based on Adaptive Intelligent Applications Information
You have three invoices for 10,000 USD that you want to pay on January 1. These invoices are eligible for early payment discounts. Each one of the invoices have either a different due date, annual percentage rate (APR), or both. You have deployed the Adaptive Intelligent Applications and presented with the data science driven targeted discount rates for all three invoices. The process has calculated the discounts for you based on your accepted APR, accelerated days (the number of days you plan to pay early), and provides you with the discount amount and payment amount. You can choose to accept, reject, or take no action on the discounts presented.
This table show an example of the three invoices with the calculated sliding scale discount amount and the new payment amount. The calculation is based on the due date, days accelerated, and different APRs:
Invoice Number and Amount | Payment Date | Current Due Date | Days Accelerated | APR (%) | Calculated Discount Amount | New Payment Amount |
---|---|---|---|---|---|---|
1 |
01-Jan |
08-Jan |
7 |
18 |
35.00 USD |
9,965.00 USD |
2 |
01-Jan |
08-Jan |
7 |
24 |
46.67 USD |
9,953.33 USD |
3 |
01-Jan |
15-Jan |
14 |
24 |
93.33 USD |
9,9606.67 USD |
Points to Consider
-
Changing or overriding the payment term discount:
-
You are provided options for discounts based on when you want to pay the invoice.
-
You can either accept or reject the discounts provided. If the discount rate is accepted, the payment term discount is overridden. Although it's recommended to have a payment term without discount rates.
-
-
Changing a previously accepted discount rate:
-
You can revert the decision at any time after accepting the discount rate.
-
You can have 2 situations:
-
If you haven't completed the payment, you can change the discount selection.
-
If you have completed the payment, void it and create a new payment with the new rate.
-
-
-
Reviewing the discount offer:
-
If you don't review or choose not to accept the discount offer, the invoice is paid according to the payment terms.
-
-
Fixed discount amount:
-
The discount amount varies based on the rate and days of advanced payment.
-
-
Sliding scale discount:
-
A sliding scale discount is a variable discount amount based on the days paid early, where the amount of the invoice discount decreases the closer the early payment comes to the payment term due date.
-
-
Changing the invoice process:
-
You don't need to change your invoicing process. The recommendation is to receive and process invoices in a timely fashion to provide more flexibility in payment timing and take advantage of available discounts.
-
Payables Cash Requirement Report
This topic includes details about the Payables Cash Requirement Report.
Overview
The Payables Cash Requirement Report forecasts immediate cash needs for invoice payments.
The following figure is an example of the report.

Key Insights
The report identifies the cash required for making a payment in a payment batch.
Frequently Asked Questions
The following table lists frequently asked questions about the Payables Cash Requirement Report.
FAQ | Answer |
---|---|
How do I find this report? |
Schedule and run this report from the Scheduled Processes work area on the Navigator menu. |
Who uses this report? |
|
When do I use this report? |
Before every payment process request to determine cash requirements for that request. |
What can I do with this report? |
|
What type of report is this? |
Oracle Business Intelligence Publisher |
Payables Cash Requirement Report
Use this report to forecast immediate cash needs for invoice payments. You can run the Payables Cash Requirement report before submitting every payment process request to determine cash requirements for that request. You can also submit this report for the next two or three payment process requests to forecast future cash requirements.
The report produces output based on the definition of the payment process request template and the payment business units that you're allowed to access.
Run the report from the Reports and Analytics work area or from the following pages:
-
Manage Scheduled Processes
-
Manage Payment Process Requests
-
Create or Edit Payment Process Request Template
- Payment Business Unit
-
Specify a payment business unit, which is a business unit with the Payables Payment business function that's responsible for processing payment transactions.
- Template
-
Select the payment process request template to forecast cash requirements for.
- Pay Through Date
-
Enter a date to determine which invoices to select for payment.
- Payment Date
-
Enter a date to determine discounts and interest calculations.
Note: The report might include invoices that you plan to pay with a bill payable, if the payment date is before the expected maturity date. - Summary Option
-
Select the level of invoice information to report.
-
No: Lists unpaid or partially paid invoices for a currency, by payment date and supplier name, starting with invoices with the earliest due or discount date.
-
Yes: Lists the payment amount due, but doesn't provide individual invoice information.
-
- Include Unvalidated Invoices
-
Select whether to include invoices that aren't validated.
Note: When you include unvalidated invoices, the invoice amount might change before the invoice is paid. For example, invoice validation hasn't completed certain tax calculations, or the invoice may be on hold for an amount-related issue. - Include Unapproved Invoices
-
Select whether to include invoices that aren't approved.
- Included Selected Invoices
-
Select whether to include invoices that have been selected by other payment process requests.
Tip: Consider excluding unvalidated, unapproved, and selected invoices because these invoices are excluded from payment process request processing.
Parameters
Considerations for Payment File Creation
You can set up a payment process request to create payment files immediately, or you can submit a scheduled process to create the payment files.
Immediate Payment File Creation
To create payment files immediately, select the Create payment files immediately option on the payment process request template or payment process request submission pages. Consider enabling this option for spontaneous payment runs. The entire process can be completed without having to set up, or wait for, a process that's scheduled for a later time.
Some additional points to consider:
-
More payment files might be created than necessary. Immediate payment file creation precludes grouping of similar payments that originated in different payment process requests into a single payment file.
-
You must specify a payment process profile when submitting the payment process request.
Scheduled Payment File Creation
To create payment files through a scheduled process, accept the default setting for the Create payment files immediately option, which defers payment file creation. Then on the Scheduled Processes page, schedule the Create Printed Payment Files and Create Electronic Payment Files processes.
Consider scheduling payment file creation as part of a business process where payment selection is local or decentralized, and payment processing is centralized.
Some additional points to consider:
-
Payments are built into the fewest number of payment files, without being limited by which payment process request the payments were created in.
-
When you don't select a payment process profile for the request, a default profile is provided for each document payable based on that document's attributes. The decision of which invoices to pay is made on business needs, such as cash flow and discounts, instead of payment method and processing needs.
How You Can Apply Credits Up to Zero Amount Payments
When you submit a payment process request, you can enable the Apply credits up to zero amount payment option. Enabling the option causes the payment process to apply credits when the credits reduce the payment amount less than zero.
The following scenarios illustrate the impact of this option.
Invoice Amount Greater Than Credit Amount
An invoice for 200 USD and a credit memo for 125 USD are due for payment. The option setting has no effect because the payment amount with the applied credit is 75 USD, which is greater than zero.
Credit Amount Greater Than Invoice Amount
An invoice for 200 USD and a credit memo for 225 USD are due for payment.
The following table describes the payment processing that occurs based on the setting for the Apply credits up to zero amount payment option.
Setting | Payment Processing |
---|---|
Enabled |
Applies 200 USD of the credit memo to the invoice and creates a payment for 0 USD. The remaining credit is 25 USD. |
Disabled |
Doesn't select the invoice or credit memo for payment because the credit reduces the payment to -25 USD, which is less than zero. |
How the Maximize Credits Option Is Processed
You can use the Apply credits up to zero amount payment option, which is on the Submit Payment Process Request page, to offset credit amounts against standard invoices issued by your supplier. This option is applicable only when the total credit amount for a payment process request is greater than the total standard invoice amount. If you don't use the option, and the total credit amount for a payment process request is greater than the total standard invoice amount, no invoices are selected for payment and the payment process request terminates. Navigate to: Navigator > Payables menu > Payments link > Payments Tasks pane > Submit Payment Process Request link > Submit Payment Process Request page.
Settings That Affect the Maximize Credits Option
To enable the maximize credits option, select the Apply credits up to zero amount payment check box on the Payment and Processing Options tab of the Submit Payment Process Request page.
How the Maximize Credits Option Is Processed
The following table shows payment installments that are available for selection in a payment process request where the total standard invoice amount is greater than the total credit amount.
Invoice Number | Type | Amount (USD) |
---|---|---|
SINV1001 |
Standard Invoice |
100 |
SINV1002 |
Standard Invoice |
50 |
SINV1003 |
Standard Invoice |
200 |
SINV1004 |
Standard Invoice |
150 |
CM100 |
Credit Memo |
-100 |
CM101 |
Credit Memo |
-150 |
In the preceding table, the assumption is that all available installments in the payment process request are selected. For this example, the following is true:
-
Invoice total = 500 USD
-
Credit total = -250 USD
-
Payment total = 250 USD
Since the invoice total is greater than the credit total, the total payment amount is a positive 250 USD. In this scenario, the maximize credits option is irrelevant.
The following table shows payment installments that are available for selection in a payment process request where the total standard invoice amount is less than the total credit amount.
Invoice Number | Type | Amount (USD) |
---|---|---|
SINV1001 |
Standard Invoice |
100 |
SINV1002 |
Standard Invoice |
50 |
SINV1003 |
Standard Invoice |
200 |
SINV1004 |
Standard Invoice |
150 |
CM100 |
Credit Memo |
-100 |
CM101 |
Credit Memo |
-150 |
CM102 |
Credit Memo |
-300 |
CM103 |
Credit Memo |
-200 |
In the preceding table, the assumption is that all available installments in the payment process request are selected. For this example, the following is true:
-
Invoice total = 500 USD
-
Credit total = -750 USD
-
Payment total = -250 USD
Since the invoice total is less than the credit total, the total payment amount is a negative -250 USD. When the payment amount is negative, Oracle Fusion Payments checks whether the Apply credits up to zero amount payment check box is selected.
If the maximize credits option is selected, the application creates a zero payment by offsetting the credit memos against the standard invoices. When the credit total is a negative amount, Payments selects invoice installments and adjusts credit memo amounts so that the total amount of the payment process request is zero as shown in the following table.
Invoice Number | Type | Amount (USD) |
---|---|---|
SINV1001 |
Standard Invoice |
100 |
SINV1002 |
Standard Invoice |
50 |
SINV1003 |
Standard Invoice |
200 |
SINV1004 |
Standard Invoice |
150 |
CM100 |
Credit Memo |
-50 |
CM101 |
Credit Memo |
-150 |
CM102 |
Credit Memo |
-300 |
In the preceding table, the assumption is that the payment process request selects all available invoice installments and selects and adjusts specific credit memos. For this example, the following is true:
-
Invoice total = 500 USD
-
Credit total = -500 USD
-
Payment total = 0 USD
If the maximize credits option is deselected, the payment process request is terminated with a message that indicates no invoices were selected.
Pay Through Dates and Payment Dates in Payment Process Requests
Payment process requests use the Pay Through Date and Payment Date values to determine whether to select an installment for payment and take a discount.
The following scenario illustrates the effect of these values in a payment process request, along with the impact of the Always Take Discount option.
Pay Through Dates and Payment Dates in Payment Process Requests
An invoice that's ready for payment has an installment with the following information:
-
Due date of August 30, 2015
-
First discount date of July 15, 2015, for 150 USD
-
Second discount date of July 30, 2015, for 100 USD
The Date Basis on the payment process request is Pay Date, and the Pay Date Basis for the supplier site is set to Discount.
This table provides examples of different Pay Through Date, Payment Date, and Always Take Discount combinations, and the resulting installment and discount information.
Example | Pay Through Date | Payment Date | Always Take Discount Option | Installment Selected? | Discount Taken Amount |
---|---|---|---|---|---|
1 |
July 14, 2015 |
July 17, 2015 |
Enabled or disabled |
No. The Pay Through Date is before the first discount date. |
None. The installment isn't selected. |
2 |
July 15, 2015 |
July 17, 2015 |
Enabled or disabled |
Yes. The Pay Through Date is on or after the first discount date. |
100 USD. The Payment Date is after the first discount date, but before the second discount date. |
3 |
July 15, 2015 |
July 31, 2015 |
Disabled |
Yes |
None. The Payment Date is after the discount dates and the Always Take Discount option is disabled. |
4 |
July 15, 2015 |
July 31, 2015 |
Enabled |
Yes |
150 USD. Although the Payment Date is after the discount dates, the first discount is taken because the Always Take Discount option is enabled. |
5 |
July 15, 2015 |
August 31, 2015 |
Disabled |
Yes |
None. The Payment Date is after the due date and the Always Take Discount option is disabled. Note: Interest may be calculated depending on your settings.
|
6 |
July 15, 2015 |
August 31, 2015 |
Enabled |
Yes |
150 USD. Although the Payment Date is after the due date, the first discount is taken because the Always Take Discount option is enabled. Note: Interest may be calculated depending on your settings.
|
Examples of Date Basis in Payment Process Requests
You can specify a date basis of either Pay date or Due date on the Selection Criteria tab on the payment process request pages. Date basis affects the installment selection and discount taken.
The following scenarios illustrate the effect of the date basis setting in a payment process request.
For both scenarios, the invoice has the following information:
-
Amount: 3,000 USD
-
Due date: March 31
-
First discount date: February 15
-
First discount amount : 150 USD
-
Second discount date: February 28
-
Second discount amount: 100 USD
The payment process request includes the following selection criteria:
-
Payment date: February 8
-
Pay through date: March 30
Pay Date
If you set the Date Basis field to Pay date, the Pay Date Basis setting on the supplier site also affects the installment selection and discount taken.
The following table shows the effect of the Pay Date Basis on the payment process request.
Pay Date Basis on Supplier Site | Installment Selected for Payment? | Discount Amount | Additional Information |
---|---|---|---|
Discount |
Yes |
150 USD |
|
Due |
No |
Not applicable |
The installment isn't selected because the due date of March 31 is later than the pay through date of March 30. |
Due Date
If you set the Date Basis field to Due date, the installment isn't selected for payment because the due date of March 31 is later than the pay through date of March 30.
Considerations for Payment Types
Payment types identify how a payment is recorded in Oracle Fusion Payables. When you manage payments, you can search for payments by type.
Payment Types
The following table describes each payment type.
Type | Description |
---|---|
Payment Process Request |
A payment that's processed through a payment process request. |
Quick |
A single payment that's created without submitting a payment process request. |
Manual |
A payment created outside of Payables and then recorded in Payables. |
Refund |
A payment for a negative amount that closes an outstanding credit balance. |
Payment Actions, Types, and Statuses
The actions that you can take on a payment depend on the type and status of that payment.
This table lists each payment action and the applicable payment types and statuses.
Action | Types | Statuses |
---|---|---|
Void |
Negotiable, Issued, Stop initiated |
|
Initiate stop |
Payment process request, Quick, Manual, Refund |
Negotiable, Issued |
Cancel stop |
Payment process request, Quick, Manual, Refund |
Stop initiated |
Add or remove invoices |
Manual |
Negotiable, Issued |
Reissue |
Quick |
Negotiable |
Print remittance |
Payment process request, Quick, Manual, Refund |
Negotiable, Issued, Cleared, Stop initiated, Voided |
-
Void a payment for a prepayment that's applied. You must first unapply the prepayment, then void the payment.
-
Initiate a stop payment for a prepayment that's applied.
-
Reissue a payment for invoice documents with a bills payable or electronic payment method.
How Payment Statuses Change
The status of a payment changes depending on the actions that you take.
How Payment Statuses Change
This figure shows the flow of payment actions and statuses.

This table describes how payment actions affect the status of a payment.
Action Taken | Status of the Payment |
---|---|
One of the following actions was taken:
|
Negotiable |
A bills payable document was paid and hasn't matured yet, or it did mature, but the status hasn't yet been updated from Issued to Negotiable. |
Issued |
A stop payment request was initiated for a payment. |
Stop initiated |
A payment was voided and no longer valid for payment. |
Voided |
A payment was reconciled to a bank statement in Oracle Fusion Cash Management. |
Cleared |
How Disbursement Bank Accounts and Payment Process Profiles Are Assigned
Oracle Fusion Payments enables you to select documents payable for inclusion in a payment process request. Each document payable selected must be assigned a disbursement bank account and a payment process profile so the payment process request can proceed to the document validation phase of the payment process.
The following steps are performed by you or the application to ensure the assignment of disbursement bank account and payment process profile to documents payable:
-
You select a disbursement bank account and a payment process profile when submitting a payment process request.
-
Payments derives a disbursement bank account and a payment process profile from usage rules.
Settings That Affect Assignment of Disbursement Bank Accounts and Payment Process Profiles
The following options affect payment processing:
-
Create Payment Process Request Template page, Payment Attributes section:
-
Disbursement bank account choice list
-
Payment Process Profile choice list
-
-
Submit Payment Process Request page, Payment Attributes section:
-
Disbursement bank account choice list
-
Payment Process Profile choice list
-
-
Create and Edit Payment Process Profiles pages, Usage Rules tab:
-
Payment Methods radio buttons
-
Disbursement Bank Account radio buttons
-
Business Units radio buttons
-
Currencies radio buttons
-
How Disbursement Bank Accounts and Payment Process Profiles Are Assigned
Disbursement bank accounts and payment process profiles are assigned to documents payable in the following sequence:
-
Before submitting a payment process request, you select parameters on the Submit Payment Process Request page, Payment and Processing Options tab, Payment Attributes section that will apply to each document payable in the payment process request. These parameters include Disbursement Bank Account, Payment Process Profile, Currency, Business Unit, Legal Entity, and Payment Method. If you use a payment process request template, a disbursement bank account and a payment process profile default from the template on to documents payable.
-
If you don't select either a Disbursement Bank Account or a Payment Process Profile or both during a payment process request submission, Payments derives the missing disbursement bank account or payment process profile by looking at the usage rules, by business unit, and compares them to the attributes of each document payable in the payment process request.
The following paragraphs discuss the derivation of a disbursement bank account. For each document payable selected for inclusion in a payment process request, Payments selects the Business Unit and the payment Currency parameters from the document payable and calls an API provided by Oracle Fusion Cash Management called CE_BANK_AND_ACCOUNT_UTIL.get_internal_bank_accts. The payment currency is provided to ensure that the disbursement bank account is valid for the payment currency on the document payable. The CE_BANK_AND_ACCOUNT_UTIL.get_internal_bank_accts API returns a list of disbursement bank accounts associated with the applicable business unit.
If the CE_BANK_AND_ACCOUNT_UTIL.get_internal_bank_accts API returns only one disbursement bank account associated with a particular business unit, then Payments defaults that disbursement bank account onto to the document payable.
If the CE_BANK_AND_ACCOUNT_UTIL.get_internal_bank_accts API returns more than one disbursement bank account, a bank account can't default on to the document payable and Payments sets the document payable status to Missing Account. You must then manually select the correct disbursement bank account on the Assign Payment Process Attributes page if you need to assign the disbursement bank account to groups of documents payable. If you need to assign the disbursement bank account to individual documents payable rather than to groups, use the Assign Attributes at Document Payable Level page.
Navigate to the Assign Payment Process Attributes page or the Assign Attributes at Document Payable Level page as follows: Navigator > Payments link > Overview page > Requiring Attention tab > Action icon for status Pending action to complete information required > Assign Payment Process Attributes page > Assign at Document Payable Level button > Assign Attributes at Document Payable Level page.
The following paragraphs discuss the derivation of a payment process profile.For each document payable selected for inclusion in a payment process request, Payments attempts to match the Payment Method, Business Unit, Disbursement Bank Account, and payment Currency parameters specified on the document payable with the corresponding payment process profile whose usage rules match all of the parameters on the document payable.
If only one payment process profile is found that matches all the parameters on the document payable, then that payment process profile defaults onto the document payable.
If more than one payment process profile is found that matches all the parameters on the document payable, a payment process profile can't default onto the document payable and Payments sets the document payable status to Missing Profile. You must then manually select the correct payment process profile on the Assign Payment Process Attributes page if you need to assign the payment process profile to groups of documents payable. If you need to assign the payment process profile to individual documents payable rather than to groups, use the Assign Attributes at Document Payable Level page.
Navigate to the Assign Payment Process Attributes page or the Assign Attributes at Document Payable Level page as previously described in this step 2.
-
Payments stops the payment process and you must manually assign missing disbursement bank account or payment process profile to groups of documents payable or to individual documents payable on the Assign Payment Process Attributes and Assign Attributes at Document Payable Level pages respectively.
Navigate to the Assign Payment Process Attributes page or the Assign Attributes at Document Payable Level page as described in step 2.
Automatic Population of Bank Accounts by Company Codes
The disbursement bank account is one of two parameters that is required for processing a payment process request. You can enter the bank account as a parameter on the payment process request when you submit the payment process request. If you do not enter the bank account when you submit the payment process request, Payments derives and automatically populates the bank account onto the payment process request based on the business unit and currency of the invoice to be paid.
An alternate way to automatically populate the bank account onto the payment process request is to configure a predefined lookup type, ORA_IBY_DEFAULT_BANK_ACCOUNT. Using the lookup type, the bank account automatically populates onto the payment process request based on company codes and currency.
The following table describes the predefined lookup values and contains sample lookup data.
Lookup Code | Lookup Code Meaning | Lookup Code Description |
---|---|---|
Company code, or balancing segment value, and currency separated by an underscore mark. |
A unique meaning |
The description contains the bank account number. |
001_US |
Bank account for 001_US currency |
1024514001 |
001_EUR |
Bank account for 001_ EUR currency |
1024155110 |
001_GBP |
Bank account for 001_ GBP currency |
1514225110 |
The priority of the automatic population of the bank account is as follows:
-
The bank account of the balancing segment value with currency combination automatically populates onto the payment process request.
-
The bank account setup up for the company code automatically populates onto the payment process request.
When you configure the predefined lookup to automatically populate bank accounts onto invoices, you assume the following:
-
The bank account number is unique.
-
The bank account is active.
-
The company codes are set up correctly.
-
Multiple ledgers use different company codes.
Unique Bank Account Number
The application evaluates the lookup codes to match the bank account to be automatically populated for the company codes. If the same bank account number is present for the same legal entity in different banks, then the bank account isn't automatically populated onto the payment process request.
Active Disbursement Bank Account
The bank account that automatically populates based on bank account setup must be an active disbursement bank account with access by the business unit.
Correct Setup of Company Codes
The automatic population of the bank account is based on the setup of the lookup codes. You must enter the correct company code with currency combination and the correct bank account number for the following conditions:
-
Foreign currency payments made from the bank account in the respective foreign currency.
-
A multicurrency domestic bank account is used to pay either functional currency or foreign currency invoices.
-
The bank account is not a multicurrency bank account.
Multiple Ledgers Use Different Company Codes
If the same chart of accounts is used across multiple ledgers, then the application can't derive the bank account based on company codes.
Automatic Population of Payment Process Profiles by Company Codes
A payment process profile, hereafter known as a profile, and a disbursement bank account are two parameters that are required to process a payment process request. A profile is a setup that provides complete processing instructions for each payment. You can enter a profile as a parameter on the payment process request when you submit the request. If you do not enter a profile when you submit the payment process request, Payments derives it from usage rules that were specified on the Usage Rules tab of the Create Payment Process Profile page. Usage rules specify whether a profile applies to all or specific payment methods, bank accounts, business units, or currencies. If you specify a profile as generic with no usage rules, it can be used with all payments. If you do specify usage rules, you limit a profile to payments that have a specific bank account, payment method, business unit, or currency.
An alternate way of automatically populating a profile on a payment process request is to configure the predefined lookup type, ORA_IBY_DEFAULT_BANK_ACCOUNT. Using the lookup type, the bank account and profile automatically populate the payment process request based on company codes and currency.
If the profile is inconsistent with the usage rules, it doesn't automatically populate the payment process request.
The following table describes the predefined lookup values and contains sample lookup data for a bank account and profile combination.
Lookup Code Field | Lookup Code Meaning Field | Lookup Code Description Field | Tag Field |
---|---|---|---|
Company code, or balancing segment value, and currency separated by an underscore mark. |
A unique meaning. |
The description contains the bank account number. |
The profile name. |
01-USD |
US Payment Process Profile |
1024514001 |
US PPP |
When you configure the predefined lookup to automatically populate profiles on invoices, the following business rules apply:
-
Data entry in the Meaning field is mandatory.
-
Data entry in the Tag field is optional.
If you enter a valid profile name in the Tag field, the profile automatically populates invoices. If you enter an invalid profile name in the Tag field, only the bank account automatically populates from the number entered in the Description field.
-
One company code and currency combination can only be associated with one bank account and profile combination. For example, a company code and currency combination of 01-USD is associated with bank account 1024514001 and payment process profile US PPP.
The following table describes the automatic population behavior of valid and invalid bank account and profile combinations.
Valid Bank Account and Profile | Invalid Bank Account and Profile |
---|---|
They both automatically populate. |
Neither automatically populates. |
The following table contains conditions that result in invalid bank accounts or profiles.
Invalid Bank Account | Invalid Profile |
---|---|
|
|
For bank account and profile derivation, the order of precedence is as follows:
-
The automatic population of the bank account is based on the predefined lookup type, ORA_IBY_DEFAULT_BANK_ACCOUNT.
-
The automatic population of the bank account from an Oracle Cash Management API.
-
The automatic population of the profile is based on the predefined lookup type, ORA_IBY_DEFAULT_BANK_ACCOUNT
-
The automatic population of the profile is based on the profile usage rules.
Considerations for Resolving Payment Validation Errors
When payments files are built from documents payable in Oracle Fusion Payments, the Build Payments program validates the payments, based on validations that were assigned during Payments setup. When you submit a payment process request, you specify whether payments that fail validation are rejected or whether the Build Payments program stops the payment process for review. If review is required for payments that fail validation, you navigate to the Resolve Payment Validation Errors page, which displays the proposed payments and validation errors, as well as the documents payable that comprise each proposed payment. In the Resolve Payment Validation Errors page, you can perform the following actions to resolve payment validation errors:
-
Remove payments from the payment process request.
-
Remove documents payable from the payment process request.
-
Terminate the payment process request.
-
Change the setup of remittance bank accounts, third party payees, payment methods, or payment formats
Removing Payments from the Payment Process Request
You can resolve payment validation errors on the Resolve Payment Validation Errors page by removing one or more payments with validation errors from the payment process request. For example, you may decide to take this action when one or more payments exceeds a defined amount limit. Removing payments can lower the payments amount below the limit. When this action is taken, Payments removes the payment and associated documents payable from the payment process request. Payments then informs the source product that the documents payable in the payment aren't being paid. The source product then unlocks the documents payable and resets their status. This enables the documents payable to be corrected, if necessary, and selected in a new payment process request. After removing the applicable payments from the payment process request, you can then resume the payment process on the Resolve Payment Validation Errors page.
Removing Documents Payable from the Payment Process Request
You can resolve payment validation errors on the Resolve Payment Validation Errors page by removing one or more documents payable from a payment that's included in the payment process request. Payments removes them from the payment process request and informs the source product that the documents payable aren't being paid. The source product then unlocks the documents payable and resets their status. This makes the documents payable ready for correction, if necessary, and for selection in a new payment process request. After removing the applicable documents payable from a payment process request, you can then resume the payment process on the Resolve Payment Validation Errors page.
Terminating the Payment Process Request
You can resolve payment validation errors by terminating the entire payment process request. To terminate a payment process request, click the Terminate Payment Process button in the Resolve Payment Validation Errors page. Payments then informs the source product that none of the documents payable in the payment process request are being paid. The source product then unlocks the documents payable and resets their status. This makes the documents payable ready for correction, if necessary, and for selection in a new payment process request.
Changing the Setup of Remittance Bank Accounts, Third Party Payees, Payment Methods, or Payment Formats
You can resolve some payment validation errors by leaving the Resolve Payment Validation Errors page and changing the setup of remittance bank accounts, third party payees, payment methods, or payment formats to allow the payments to pass validation. When payments are revalidated, any setup changes you made are activated. After changing applicable setups, you can then return to the Resolve Payment Validation Errors page and remove applicable payments or documents payable from the payment process request, or ignore the validation errors and resume the payment process on the Resolve Payment Validation Errors page.
Interest Invoices
If you enable automatic interest calculation for a supplier and pay an overdue invoice, an invoice for the interest is automatically created and paid.
Setup
To set up automatic interest rate calculation:
-
Define interest rates using the Manage Interest Rates task.
-
Set the Create Interest Invoices option using the Manage Suppliers task.
-
Enable the Create interest invoices option using the Manage Invoice Options task.
Attributes
This table describes some of the attributes of an interest invoice.
Attribute | Description |
---|---|
Number |
The interest invoice number is the overdue invoice number plus the suffix -INTx, where x is the number of interest invoices for that overdue invoice. For example, if the invoice number is 54362, the invoice number for the third interest invoice is 54362-INT3. |
Payment terms |
The payment terms on an interest invoice are immediate. If immediate terms aren't defined, the payment terms for the interest invoice are the same as the payment terms for the overdue invoice. |
Amount |
The interest calculation is based on the rate on the Manage Interest Rates page and is in accordance with the United States Prompt Payment Act. The calculation formula compounds interest monthly, up to a maximum of 365 days interest. |
Currency |
The invoice currency for an interest invoice is the same as the invoice currency on the overdue invoice. The payment currency for an interest invoice is the same as the payment currency on the overdue invoice. |
How Interest on Overdue Invoices is Calculated
You can configure your setup to calculate the interest owed to a supplier for overdue invoices.
Settings That Affect Interest Calculation
Set the Minimum Interest Amount option on the Manage Invoice Options page and define interest rates on the Manage Interest Rates page.
How Interest Is Calculated
When you pay an invoice that's overdue, the interest calculation uses:
-
The invoice due date to determine the number of days that the invoice is overdue
-
The interest rate in effect the day after the invoice due date
This figure shows the formula for calculating interest.

The interest formula uses the following variables:
-
I = interest payable
-
P = principal net amount payable to the supplier before adding on interest
-
i = interest rate expressed in decimal form
-
n = number of full periods for example, the number of days divided by 30
-
z = number of residual days that's, number of days less than a 30-day period divided by 360
Document Sequencing in Payables
Document sequences are unique numbers that are automatically or manually assigned to a created and saved document. You can sequence invoices and payments by assigning them voucher numbers.
To set up sequencing for invoices and payments, perform the following tasks:
-
Specify Ledger Options
-
Manage Payables Document Sequences
-
(Optional) Manage Invoice Options
-
(Optional) Manage Payment Options
You can configure the spreadsheet to automatically create a document sequence for invoices and payments. The spreadsheet upload process assigns the invoice document sequence to predefined document sequence categories, such as Standard Invoices and Credit Memo Invoices.
Specifying Ledger Options
You can set the following ledger options:
-
Sequencing By: Enables document sequencing for the ledger or legal entities associated with that ledger.
-
Enforce Document Sequencing: When set to Payables, indicates that invoices and payments require voucher numbers.
-
Enforce Chronological Order on Document Date: Checks the accounting date on the invoice header when you save an invoice. The date must be the same as, or later than, the latest accounting date of an existing invoice with the same legal entity and sequence.
Note: The Enforce Chronological Order on Document Date option applies only when you sequence by legal entity.
This table describes how the combination of ledger option settings affects the assignment of voucher numbers to invoices and payments.
Sequencing By | Enforce Document Sequencing for Payables? | Enforce Chronological Order on Document Date? | Voucher Number Assignment on Invoices and Payments |
---|---|---|---|
Ledger |
No |
No |
Optional |
Ledger |
Yes |
No |
Required |
Legal entity |
No |
No |
Optional |
Legal entity |
Yes |
No |
Required |
Legal entity |
No |
Yes |
Required |
Legal entity |
Yes |
Yes |
Required |
No sequencing |
Not applicable |
Not applicable |
Optional for imported invoices only |
Managing Payables Document Sequences
With the Manage Payables Document Sequences task you can:
-
Create a document sequence for the applicable determinant type: ledger or legal entity.
-
Assign the sequence to one or more document sequence categories.
-
Specify the ledgers or legal entities that the assignment applies to.
-
Optionally enable the Audit option to store audit information in the AP_DOC_SEQUENCE_AUDIT table.
Note: You can view audit information by running the Payment Audit by Voucher Number Report and the Payables Invoice Audit by Voucher Number Listing.
Managing Invoice Options
You can set the Allow document category override option to allow changes to the default document category on an invoice.
Managing Payment Options
You can set the Allow document category override option to allow changes to the default document category on a payment.
Cross-Currency Payments
You can pay invoices in any currency, irrespective of the currency on the invoice. With cross-currency payments you can make payments in the most stable currency or comply with legal regulations that prescribe payment in a specific currency.
-
During invoice creation, your setup determines the default payment currency or you can manually select the payment currency, irrespective of the invoice currency.
-
During payment creation, the cross-currency rate converts the invoice amount to the payment amount.
For example, you can make a payment in Euros for invoices created in Pounds Sterling.
This table lists the currencies and cross-currency rate information.
Invoice Currency | Payment Currency | Cross-Currency Rate |
---|---|---|
GBP |
EUR |
1.25 |
This table shows the conversion of the invoice amount to the payment amount using the cross-currency rate.
Invoice Amount | Invoice Amount * Cross-Currency Rate | Payment Amount |
---|---|---|
100 GBP |
100 * 1.25 |
125 EUR |
Benefits
With cross-currency payments you can:
-
Manage your cross-border transactions effectively.
-
Comply with legal regulations and make payments in the prescribed currency mandated by the country authorities for the resident supplier.
-
Save costs by making payments in the most stable currency and avoiding losses due to currency rate fluctuations.
Conversion Rates
In addition to cross-currency rates, other conversion rates can apply when invoices and payments have different currencies. Following is the list of conversion rates:
-
Invoice conversion rate: Converts the invoice currency to the ledger currency
-
Cross-currency conversion rate: Converts the invoice currency to the payment currency
-
Payment conversion rate: Converts the payment currency to the ledger currency
This table provides an example of the different conversion rates along with the converted transactions for a ledger currency of US dollars and an invoice entered in Pounds Sterling and paid in Euros.
Starting Transaction Amount | Type of Conversion Rate | From Currency | To Currency | Conversion Rate | Converted Transaction Amount |
---|---|---|---|---|---|
100 GBP |
Invoice |
GBP |
USD |
1.75 |
175 USD |
100 GBP |
Cross-currency |
GBP |
EUR |
1.25 |
125 EUR |
125 EUR |
Payment |
EUR |
USD |
1.45 |
181.25 USD |
Setup
You can set up a default payment currency for:
-
A supplier site on the Invoicing tab of the Supplier Site page.
-
An invoice business unit on the Manage Invoice Options page.
How You Set Up Third-Party Payments
A third-party payment is a payment that you make to a supplier on behalf of another supplier. Setting up third-party payments includes the following tasks:
Creating the Third Party
-
In the Suppliers work area, click Create Supplier.
-
Complete the information on the Profile and Address tabs.
-
Set the Address Purpose field to Remit to.
-
(Optional) Associate a bank account and default payment method with the address.
-
Defining the Relationship Between the Third Party and the Supplier
-
In the Suppliers work area, click Manage Suppliers.
-
Search for the supplier on whose behalf the third party receives payment.
-
Add the third party to the Third-Party Payment Relationship section on the Invoicing tab on the Edit Site page. Consider marking the relationship as the default relationship for new invoices and payments.
This table describes each attribute of a third-party payment relationship.
Attribute Description Remit-to Supplier
Enter the party designated to receive payment on behalf of the supplier on the invoice.
Address Name
Enter the address of the party designated to receive payment on behalf of the supplier on the invoice.
From Date, To Date
Specify an inclusive date range for the relationship. When you create an invoice or payment, the invoice and payment dates are used to identify valid third-party payment relationships for the supplier site.
Note: When you end date an existing relationship, you must review all unpaid or partially paid invoices for that relationship.Description
Enter text to include in the payment file. For example, you can enter text to print on the payment document as reference information.
(Optional) Setting the Remit-to Supplier Override Option
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Payables
-
Task: Manage Invoice Options, with the business unit scope set
-
Click Apply and Go to Task.
-
Select the Allow remit-to supplier override for third-party payments option to allow override of the remit-to supplier on the invoice.
(Optional) Setting the Payee Override Option
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Payables
-
Task: Manage Payment Options, with the business unit scope set
-
Click Apply and Go to Task.
-
Select the Allow payee override for third-party payments option to allow override of the payee on the payment.
How You Add Cross-Currency User Rates to a Payment
This example demonstrates how to add cross-currency rates to a single payment when the cross-currency rate type for the payment is User.
The following table summarizes key decisions for this scenario.
Decision to Consider | In This Example |
---|---|
Is the invoice currency different from the payment currency? |
Yes |
Is the invoice due for payment? |
Yes |
What's the payment conversion rate type? |
Corporate |
Adding Cross-Currency User Rates
-
On the Payments Overview page, click Create Payment to open the Create Payment page.
-
On the Payment Details tab, complete the required fields.
-
On the Advanced tab, complete the fields as shown in this table.
Field Value Payment Conversion Rate Type
Corporate
Cross-Currency Rate Type
User
-
In the Invoices to Pay section, select the action Add Cross-Currency User Rates.
If you select the invoices to pay before adding the rates, a warning appears that cross-currency rates are missing.
-
In the Add Cross-Currency User Rates dialog box, click the Create icon.
-
Select a value for the From Currency field.
-
Enter the conversion rate.
-
Click OK.
-
In the Invoices to Pay section, select the action Select and Add: Invoices to Pay.
-
In the Select and Add: Invoice to Pay dialog box, select the invoice.
-
Click OK.
-
Click Save and Close.
-
Click OK to acknowledge the payment confirmation message.
Centralized Payment Processing Across Business Units
Centralized payment processing enables you to implement a shared payment service model.
In this model, a single payment business unit provides payment services to multiple invoice business units. That is, any business unit with the Payables Payment business function can provide payment services to other business units with the Payables Invoicing business function.
The designated payment business unit processes invoices from multiple invoice business units and generates a consolidated payment for a given supplier. Because payment processing is centralized, you can exercise better control of supplier payments and reduce the cost of payment processing.
Payment Processing and Invoice Business Unit Setup
The payment business unit groups standard invoices, prepayments, and credit memos for the same supplier name and site, from all of the invoice business units that the payment business unit services.
Although invoices are grouped into a single payment, the payment business unit honors the setup values that apply to each of the invoice business units. For example, the US Headquarters payment business unit provides payment services to invoice business units US West and US East.
This table shows how the Discount Allocation Method invoice option is set for each invoice business unit.
Business Unit | Discount Allocation Method |
---|---|
US West |
Single distribution |
US East |
All invoice lines |
This table shows invoices for the same supplier and supplier site, along with whether discounts apply.
Invoice Number | Business Unit | Discount Applicability |
---|---|---|
INV-West-001 |
US West |
Yes |
INV-West-002 |
US West |
No |
INV-East-001 |
US East |
Yes |
INV-East-002 |
US East |
Yes |
While processing the payments, US Headquarters groups the invoices together and generates a single payment for all four invoices. However, when accounting for the invoices the:
-
Discount on invoice INV-West-001 is allocated to a single distribution.
-
Discounts on invoices INV-East-001 and INV-East-002 are allocated to all of the invoice lines.
So even if a single payment is made, setups for the applicable invoice business units are respected.
This table shows setup tasks for invoice and payment options and the business unit that the tasks apply to.
Setup Task | Applicable Business Unit |
---|---|
Manage Common Options for Payables and Procurement |
Invoice |
Manage Invoice Options |
Invoice |
Manage Payment Options |
Payment |
Manage Tax Reporting and Withholding Tax Options |
Invoice |
Payment Service Models
The different models of payment services that you can implement are:
-
Dedicated
-
Self-Service
-
Dedicated and Self-Service
In a dedicated payment service model, the payment business unit works solely as an outsourced payment processing unit to service other invoice business units.
The following figure is an example of a dedicated payment services model.

In a self-service model, the invoice business unit services itself, acting as its own payment service provider.
The following figure is an example of a self-service payment services model.

In a dedicated and self-service model, the payment business unit, in addition to servicing itself, also services other invoice business units.
The following figure is an example of a dedicated and self-service payment services model.

Benefits of Centralized Payments
When you centralize payments you:
-
Have better control of supplier payments. You can:
-
Effectively manage supplier payments by grouping credit memos from one invoice business unit with standard invoices of other business units, thereby reducing net cash flows.
-
Effectively communicate and reconcile any disputes with your suppliers.
-
-
Develop and use organization skills effectively.
-
Reduce processing costs, such as administration and transaction costs by generating consolidated payments for invoices across multiple invoice business units.
How Payment Approval Is Processed
The payment approval process allows management to control payments by prioritizing available funds. Payment approval lets you send payments to approvers for review before final payments are made to suppliers or employees. If enabled, the payment process stops and approvers can optionally remove payments directly from a payment process request and then approve it.
The payment approval process generates and routes payment approval notifications to approvers. Approvers can approve or reject payment process requests directly from e-mails. They can also perform other approval actions from payment approval worklist notifications.
Settings That Affect Payment Approval
To enable payment approval, navigate to Setup and Maintenance, search, and select Manage Disbursement System Options. On the Manage Disbursement System Options page, select the Enable payment approval option.
How Payment Approval Is Processed
When Payment approval is enabled, all payment process requests go through the payment approval process. When a payment process request is submitted, payment approval is automatically triggered after it reaches the Review Proposed Payments stage. The status of the payment process request is then set to Payments Approval Initiated. Payment approvers then receive payment approval e-mail notifications, as well as payment approval BPM Worklist notifications.
As the following table shows, approvers can perform different payment approval actions depending on the payment approval mechanism used, whether from the Review Proposed Payments page, from email notifications, or from BPM Worklist notifications.
Payment Approval Mechanism | Approval Actions Available | Navigation |
---|---|---|
Review Proposed Payments page |
|
Navigate to: Spring board > Payables icon > Payments icon > Overview page > Tasks icon > Click Manage Payment Process Requests link > Manage Payment Process Requests page > Status: Pending Proposed Payment Review > Search button > Manage Payment Process Requests page >Action icon > Review Proposed Payments page. |
E-mail notification |
|
Your e-mail inbox. |
BPM Worklist notification |
|
Navigate to: Tools > Worklist > Financials |
To specify a payment approval action on the Review Proposed Payments page, approvers select an option from the Actions menu. The following table lists the payment approval actions that payment process request submitters and approvers can take, when the actions are available, who takes the payment approval action, and the result of the action.
Payment Approval Actions Available on the Review Proposed Payments Page | Availability of Action | Person Performing the Action | Result of Action |
---|---|---|---|
Approve payment |
Only when the payment process request status is Payments Approval Initiated. |
Approvers only. |
|
Reject payment |
Only when the payment process request status is Payments Approval Initiated. |
Approvers only. |
|
Withdraw approval |
Only when the payment process request status is Payments Approval Initiated. |
Submitter of the payment process request or approver. |
|
Resubmit for approval |
Only when the payment process request status is Withdrawn from payments approval and Error in payments approval. |
Submitter of the payment process request or approver. |
|
Terminate payment process request |
Always. |
Anyone. |
|
Approvers can review the payment approval statuses of payment process requests that require action on the Requiring Attention tab on the Overview page as the following table lists.
Page | Payment Process Request Approval Statuses | Navigation |
---|---|---|
Overview page |
|
Requiring Attention tab. |
FAQs for Prepare and Record Payments
What happens if I don't define an interest rate for an overdue invoice?
If you enable the Create interest invoices option but don't define a rate for the day after the invoice is due, interest isn't calculated and an interest invoice isn't created.
What happens if I void a payment?
The accounting and payment records for the invoices that were paid are automatically reversed.
If applicable, the following transactions also occur:
-
Realized gains or losses on foreign currency invoices are reversed.
-
If the Create interest invoices option on the Manage Invoice Options page is enabled, all related interest invoices are reversed.
-
If the invoice is associated with a withholding tax invoice and tax is withheld at payment, a reversing invoice is automatically created. This reversing invoice for the tax authority offsets the withholding tax invoice.
What's a stop payment request?
A stop payment request records the dates that a stop payment order was placed with, or released from, a financial institution.
For example:
-
A supplier tells you that they didn't receive a payment.
-
You ask the bank to stop the payment.
-
You record a stop payment request using the Manage Payments task.
-
If the bank confirms the payment was stopped, you void the payment.
-
If the bank tells you that the payment has already cleared, you cancel the stop payment request.
Why didn't an installment get selected for payment?
An installment can meet the selection criteria of a payment process request, but not get selected for payment for one or more reasons. You can review installments that weren't selected for payment and the reasons they weren't selected, on the Not Selected tab on the Review Installments page.
Here are the reasons why an installment might not get selected for payment.
-
An approver rejected the invoice.
-
The calculation for withholding tax ended in error.
-
A credit reduced the payment amount to less than zero.
-
The invoice must be revalidated.
-
The invoice requires approval.
-
The invoice was never validated.
-
The payment date is in a closed period.
-
Having the payment date before the system date isn't allowed.
-
The installment is on hold.
-
The supplier site is on payment hold.
-
The installment was manually removed from the payment process request.
-
Zero amount installments are excluded from payment.
Why did the payment require a conversion rate when the option to require a conversion rate is disabled?
Regardless of how you set the Require conversion rate entry option, a payment requires a conversion rate if:
-
The payment is in a foreign currency.
-
The payment has an invoice that's subject to automatic withholding.
-
Automatic withholding occurs at time of payment.
What's a third-party payment?
A third-party payment is a payment that you make to a supplier on behalf of another supplier.
This figure provides an example of a third-party payment. An office supply company sells their receivables to a collections agency for cash and customers send payments to the collections agency.

Why is the payee name on the payment different from the supplier name on the paid invoice?
The payment was made to a third party. You can view the third-party payment setup in the Third-Party Payment Relationship section on the Invoicing tab on the Edit Site page.
What happens if I create an invoice using Supplier Portal for a supplier that is set up for third-party payments?
If a default third-party payment relationship is defined for the invoice date, the third-party information is copied to the invoice when you submit the invoice.
You can see the third-party information when you review the invoice installments from the Manage Invoices page.
How can I fix a payment process request that's missing cross-currency rates?
A payment process request can have a status of Missing cross-currency rates for multiple reasons.
Depending on the reason, selecting the action icon on the Manage Payment Process Requests page opens the page where you can resolve the issue or view information on how to resolve it.
This table describes the reasons for the Missing cross-currency rates status along with the actions you can take to resolve them.
Reason | Action |
---|---|
The cross-currency rate type is User, but you didn't enter any rates. |
On the Edit Cross-Currency Conversion Rates page, add the rates that convert the invoice currencies to the payment currencies. |
The cross-currency rate type has a value other than User and the rates are missing for the specified payment date. |
On the View Missing Cross-Currency Rate page, see which currencies are missing rates and define them on the Manage Daily Rates page. |
The payment process request includes cross-currency payments, but you didn't select a cross-currency rate type. |
On the Select Cross-Currency Rate type page, select the type of conversion rate to use for cross-currency payments. |
How can I use social networking to get approval for adding installments to a payment process request?
Use the Social link on the Review Installments page to invite your manager to a conversation about adding installments to a payment process request.
For example, you submit a payment process request for all of the invoices belonging to a specific invoice group. While reviewing the installments, you receive a request from a supplier to pay some invoices that were recently received.
You add the installments to the payment process request, but before continuing with payment processing, you must first get management approval.
From the Review Installments page:
-
Click Social to open Oracle Social Network.
-
Click Share.
-
Create a related conversation.
-
Invite your manager to join the conversation.
The details of your conversation are recorded within the context of the payment process request. Your manager can review the details on the payment process request wall. The recorded conversation acts as an approval for adding these installments to the existing payment process request.
Why do I get a permissions error when I click on an invoice number link from the Manage Payments page?
The business unit for the invoice is different from the business unit for the payment and you don't have access to that invoice business unit. You can view general invoice information on the Paid Invoices tab, but you can't drill down to view the invoice details.
What are the changes in the payment attributes flow when I create third-party payment?
The payee is the party who receives payment. Whether the payee is a third-party or the invoicing supplier, the payment attributes flow the same way.
The following attributes default on the invoice from the payee setup:
-
Payment method
-
Remit-to account
-
Pay each document alone
-
Bank charge bearer
-
Payment reason
-
Payment reason comments
-
Settlement priority
-
Delivery channel
The following attributes pull from the payee setup when you make a third-party payment or any payment.
-
Bank Instruction 1
-
Bank Instruction 2
-
Bank Instruction Details
-
Payment Text Message 1
-
Payment Text Message 2
-
Payment Text Message 3
-
Service Level
-
Separate Remittance Advice
Why do I see different names for the Payee and the Supplier or Party on payment process request pages?
The names are different because you're making a third-party payment. The Supplier or Party column displays the invoicing supplier. The Payee column displays the third-party that receives payment on behalf of the invoicing supplier.
What happens to payment validations when I create a third-party payment?
The payee is the party who receives payment. Whether the payee is a third-party or the invoicing supplier, validations on payee attributes perform the same way.
What's the impact on grouping of installments for third-party payments?
Installments are grouped first by the invoicing supplier and then by the third-party payee.
How Payment Status Bell Notifications Are Displayed
You can submit a payment batch for straight through processing or you can stop and review the payment process at various stages. When the payment batch stops for required action or when the payment processing is complete, you conveniently receive a payment status bell notification.
Settings That Affect Payment Status Bell Notifications
Payment status bell notifications are activated by selecting any of the following check boxes on the Submit Payment Process Request page, Processing Options section:
-
Review installments
-
Review proposed payments
-
Create payment files immediately
How Payment Status Bell Notifications Are Displayed
Payment status bell notifications are displayed:
-
When the payment process request stops at a milestone or waits for your required action
-
If you select any of three processing option check boxes when you submit a payment process request
Selection of any processing option check box causes the payment process to stop for review, which causes the payment status bell notification to display. The payment status bell notification has a link in it that you can click to take you to the page that requires action.
Payment status bell notifications:
-
Display when the payment process request stops for your required action
-
Provide links so you can navigate to the applicable page
-
Disappear when the link in the notification is clicked
When do payment status bell notifications appear?
When the payment batch stops for required action or when the payment processing is complete. Payment status bell notifications have links, which allow you to navigate directly to the page that requires action. These notifications disappear after the links are clicked. Payment status notifications are supported for payments processed by payment process requests, but not for payments created through the create payment option.
How can I access payment reports after a payment file is generated?
By clicking the links provided on the Payment File page, you can directly access the Separate Remittance Advice report, the Positive Pay report, and the Payment File Register report. You do not need to navigate to the Scheduled Processes area to retrieve them.
How Payment Reports Are Displayed
You can access Oracle Fusion Payments reports by clicking links on the UI so you don't have to navigate to the scheduled processes area to retrieve them.
Settings That Affect Reports
The following settings on the Create Payment Process Profile page, Reporting tab, affect the generation of reports:
-
Payment File Register section: Automatically submit when payments are confirmed check box.
-
Positive Pay section: Automatically transmit file check box
-
Separate Remittance Advice section: Automatically submit when payments are confirmed check box
How Reports Are Displayed
You can configure the automatic generation of various ancillary payment reports. These reports result from the processing of a payment process request. You can view several reports and the payment file from the Payment File page.
The following table lists links to reports that appear on multiple pages in the payment process flow:
Sequence | Payment Process Request Status | Page Name | Report or File Generated |
---|---|---|---|
1 |
Pending installments reviewed |
Review Installments page |
Payables Selected Installments Report |
2 |
Pending proposed payments reviewed |
Review Proposed Payments page |
Payment Process Request Status Report |
3 |
Payment file generated |
Payment File page |
|
What's Adaptive Intelligent Applications?
Adaptive Intelligent Applications is a separate application with several components to analyze and predict outcomes using several sources of data. It is capable of taking in large volumes of data and through Decision Science, where it stores, processes, and predicts outcomes. The integration of AI in Payables is to calculate discounts (predicted outcomes) based on several resources such as payment terms, due dates, invoice amounts, and annual percentage rates (resources for storing and processing data).
What happens if I want to use the discount, do I need to have any special payment terms for the discount?
No, you continue to use the existing payment term. The due date with the existing payment term is used to derive the discount amount.
What's the difference between a supplier score and a credit score?
The supplier score is an aggregation of a series of risk and performance metrics derived by Adaptive Intelligent Applications.
A credit score is an analysis of a person's credit file, credit history, and Lenders, such as banks, credit card companies, and retail stores. Credit scores are used to evaluate the potential risk posed by lending money to consumers.
Can I use my PayPal account to make payments to suppliers?
Yes. To make payments using your PayPal account, you must first capture the PayPal ID at the supplier level. You can capture the PayPal account ID in the supplier E-Mail field on the Supplier Address page.
Alternatively, you can capture the PayPal account ID in any of the following supplier bank account fields: Bank Account Number, Bank Account Name, Bank Account Alternate Name.
For your convenience, a predefined Oracle Business Intelligence Publisher (Oracle BI Publisher) template is available for PayPal payments, along with a PayPal payment format, and a PayPal payment process profile. The template's layout is based on the assumption that the PayPal ID is captured at the supplier address level in the E-Mail field. If you want to use the alternative way of capturing the PayPal ID in the supplier bank account fields, then you must configure the Oracle BI Publisher template according to your setup.
Record Accounting for Payments
How Invoices and Payments Are Accounted
You can create accounting entries for invoice and payment transactions using Oracle Fusion Subledger Accounting. Subledger Accounting creates the final accounting for subledger journal entries and transfers the accounting to Oracle Fusion General Ledger. Subledger Accounting uses a set of predefined account rules to create accounting, but you can define your own detailed accounting rules.
Payables Event Classes and Types
Subledger Accounting uses predefined accounting event classes and accounting event types. You can modify your accounting setup to create accounting for some events and not for others.
This table lists the predefined payables event classes and types.
Event Class | Event Type |
---|---|
Adjustment Entry |
Manual |
Bills Payable |
|
Credit Memos |
|
Debit Memos |
|
Invoices |
|
Payments |
|
Prepayment Applications |
|
Prepayments |
|
Reconciled Payments |
|
Refunds |
|
Third-Party Merge |
|
How Missing Conversion Rates Are Applied to Invoices
The Apply Missing Conversion Rate process automatically applies conversion rates to foreign currency invoices or payments that have no conversion rate and a conversion rate type other than User. If a foreign currency invoice is missing a conversion rate, then the invoice validation process applies a No rate hold, which prevents invoice accounting and payment.
Settings That Affect Applying Missing Conversion Rates
Run the Apply Missing Conversion Rates process when the Require conversion rate entry option on the Manage Common Options for Payables and Procurement page is disabled.
How Missing Conversion Rates Are Applied to Invoices
The Apply Missing Conversion Rates process uses conversion rate information from the Manage Daily Rates page to apply the conversion rates. The next time you validate the invoice, the No rate hold is automatically removed.
How Cross-Currency Payments Are Accounted
Cross-currency payments are payments in a currency different from the currency on the respective invoices. The accounting process records entries for cross-currency payments in both the invoice currency and the payment currency.
How Cross-Currency Payments Are Accounted
You can account for cross-currency payments individually or through the Create Accounting process. The accounting entries for the payment relieve the liability account in the invoice currency with an offset to the cash or cash clearing account in the payment currency.
Example
This table shows the invoice and payment accounting entries for an invoice with the following currency information:
-
Invoice amount and currency: 100 GBP
-
Payment currency: EUR
-
Ledger currency: USD
This table shows the invoice, payment, and cross-currency conversion rates that are in effect.
Type of Rate | From Currency | To Currency | Conversion Rate |
---|---|---|---|
Invoice conversion rate |
GBP |
USD |
1.75 |
Payment conversion rate |
EUR |
USD |
1.45 |
Cross-currency rate |
GBP |
EUR |
1.25 |
This table shows the payment transaction in the payment and ledger currencies.
Invoice Amount (GBP) | Cross-Currency Rate | Payment Amount (EUR) | Payment Conversion Rate | Payment Amount in Ledger Currency (USD) |
---|---|---|---|---|
100 |
1.25 |
125 |
1.45 |
181.25 |
This table shows the resulting accounting entries for both the invoice and payment transactions.
Accounting For | Accounting Class | Entered Debit | Entered Credit | Accounted Debit (USD) | Accounted Credit (USD) |
---|---|---|---|---|---|
Invoice |
Item expense |
100 GBP |
|
175.00 |
|
Invoice |
Liability |
|
100 GBP |
|
175.00 |
Payment |
Liability |
100 GBP |
|
175.00 |
|
Payment |
Cash Clearing |
|
125 EUR |
|
181.25 |
Payment |
Loss |
0 EUR |
|
6.25 |
|
Payment |
Balance |
125 EUR |
|
175.00 |
|
Payment |
Balance |
|
100 GBP |
|
175.00 |
Process Payment Files
Electronic Payments
To pay your suppliers, you can make payments through electronic funds transfer by transmitting payment files to your bank or payment system.
This topic includes the following tasks:
-
Creating an ISO payment process profile
-
Submitting a payment process request
-
Reviewing selected invoices
-
Reviewing proposed payments
-
Transmitting payment files
-
Viewing payments and invoices
Creating an ISO Payment Process Profile
The first step is to set up a payment process profile that contains all the necessary details to manage the payment process. You will create an ISO payment process profile. ISO is a global standard for financial payment formats and messages, which is accepted by most banks. ISO has two versions: SEPA for European countries and CGI for non-European countries.
To create an ISO payment process profile, complete these steps:
-
Sign in as a setup user.
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Payment Process Profiles
-
-
On the Manage Payment Process Profiles page, in the Search Results section, click Add.
-
On the Create Payment Process Profile page in the Name field, enter ISO_PPP_XXX.
-
In the Code field, enter ISO_Code_XXX.
Tip: In place of XXX, enter the appropriate number. -
In the From Date field, accept the default setting of today's date.
-
From the Payment File Format choice list, search and select the ISO20022 Common Global Implementation Format.
-
From the Processing Type choice list, select Electronic.
-
From the Payment Confirmation Point choice list, select When the payment file is transmitted.
-
Select the Usage Rules tab.
-
Click the All option for Payment Methods, Disbursement Bank Accounts, Business Units, and Currencies so that the payment process profile can be used with any payment.
Note: You can click the Specify option to limit the use of this profile to payments that have specific payment methods, disbursement bank accounts, business units, or currencies. -
Select the Payment System tab.
You can specify that the payment file is automatically transmitted after formatting. You can also configure the payment file transmission to allow payment file downloading to the Universal Content Management folder after the payment file is transmitted.
-
From the Payment System choice list, select ISO20022 Payment System.
-
Select the Automatically transmit payment file after formatting check box.
-
In the Payment System Accounts section, for the payment system account of Settings_CGI, select ISO_UCM_Upload from the Payment File Transmission Configuration choice list.
-
For the payment system account of Settings_SEPA, enter today's date in the To Date field.
-
Select the Payment tab.
On the Payment tab, you can specify attributes for grouping invoices in the same payment if they share the same attribute.
-
In the Document Grouping Rules section, select these check boxes: Due date, Settlement priority, and Delivery channel.
-
Select the Payment File tab.
On the Payment File tab, you can specify rules for grouping payments into payment files.
-
In the Overrides section, from the Service Level choice list, select the type of payment.
-
From the Delivery Channel choice list, select the delivery type.
-
Select the Grouping tab.
Since you're creating an ISO payment process profile, you must select transaction grouping rules on the Grouping tab. Grouping is based on the ISO standardized method of grouping transactions in each transmission file.
-
In the Transaction Grouping Rules section, select these check boxes: Payment Date, Disbursement Bank Account, Service Level and Delivery Channel.
-
Select the Reporting tab.
On the Reporting tab, you can specify the timing and types of reports to generate.
-
In the Payment File Register section, from the Format choice list, select Payment File Register Format with Document Detail.
-
Select the Automatically submit when payments are confirmed check box.
-
In the Separate Remittance Advice section, from the Format choice list, select Separate Remittance Advice Format.
-
Select these check boxes: Automatically submit when payments are confirmed and Allow multiple copies for payment file.
-
From the Condition choice list, select All payments.
-
From the Delivery Method choice list, select E-Mail.
-
Click Save and Close. A Confirmation message appears.
-
Click OK.
-
Click Done.
-
Sign out.
Submitting a Payment Process Request
The second step is to submit a payment process request. A payment process request is a grouping of documents payable for which a source product requests payment. The payment process request will make payments of three invoices with different due dates.
To submit a payment process request, complete these steps:
-
Sign in as a transaction user.
-
On the Home page, click Payables > Payments.
-
On the Overview page, click the Tasks icon and then click the Submit Payment Process Request link.
-
On the Submit Payment Process Request page, select the Selection Criteria tab.
-
In the Name field, enter ISO_PPRXXX.
-
From the Invoice Group choice list, search and select 129Group.
Tip: In place of XXX, enter the appropriate number. -
Select the Payment and Processing Options tab.
On the Payment and Processing Options tab, you can specify payment attributes and processing options. You can select the disbursement bank account from which invoices will be paid, the payment process profile you just created, and several processing options to stop the process for review. If the reviews are satisfactory, payment files are created immediately.
-
From the Disbursement Bank Account choice list, search and select BofA-204.
Note: Choose the BofA-204 bank account that has Account Number: 10271-17621-619. -
From the Payment Process Profile choice list, search on ISO and select ISO_PPP Settings_CGI .
-
From the Payment Conversion Rate Type choice list, select Corporate.
-
In the Processing Options subsection, select these check boxes: Review installments, Review proposed payments, and Create payment files immediately.
-
In the Validation Failure Handling subsection, from the Document choice list, select Stop process for review.
-
From the Payment choice list, select Stop process for review.
-
Click Submit.
A Confirmation message appears with the process number.
-
Click OK.
-
Scroll down to the Schedule Requests section to check the status of the request.
-
Click the Refresh icon until Succeeded displays in the Status column for both Initiate Payment Process Request and Payables Selected Installments Report processes that correspond to your process ID.
-
On the Overview page, click the Tasks icon.
-
Click the Manage Payment Process Requests link.
-
On the Manage Payment Process Requests page, enter ISO_PPRXXX in the Name field.
Note: In place of XXX, enter the appropriate number. -
Click Search.
Note: The payment process request shows a Status of Pending installment review. -
Click the Action icon.
On the Selected tab, three invoices were selected by the payment process request. Since the selected installments look fine, the process continues.
Reviewing Selected Invoices
The third step is to review selected invoices.
To review selected invoices, complete these steps:
-
On the Review Installments page, click Submit.
A Confirmation message appears that states your process ID.
-
Click OK.
-
Expand the Search section.
-
The Name field contains the name of the payment process request, ISO_PPRXXX.
-
Click Search.
Note: The status of the payment process request changes to Pending proposed payment review. -
Click the Action icon.
Reviewing Proposed Payments
The fourth step is to review proposed payments.
To review proposed payments, complete these steps:
-
On the Review Proposed Payments page, click Resume Payment Process.
A Confirmation message appears that states the process was submitted and specifies a process ID.
-
Click OK.
Note: In the Payment Summary section, two payments were created and none were rejected or removed. Since the proposed payments are fine, you can continue.
Transmitting Payment Files
The fifth step is to transmit payment files.
To transmit payment files, complete these steps:
-
Expand the Search section.
-
Click Search.
Note: The status of the payment process request is Payments completed. The status of the payment file is now Transmitted.The payment process request completed and the payment files were transmitted to the payment system.
-
In the Name field, enter the payment process request name, ISO_PPR_XXX.
Note: In place of XXX, enter the appropriate number. -
Click the payment file number.
The Payment File page appears.
-
In the Payments section, click the Eye glasses icon to view the invoices.
Viewing Payments and Invoices
The final step is to view payments and invoices.
To view payments and invoices, complete these steps:
-
On the Manage Payment Process Requests page, click the payment file number link.
-
Scroll down the Payment File page to the Payments section.
The Payments section contains two payments.
-
Click the Eye Glasses icon for the $800.00 USD payment.
-
On the Payment page, select the Documents Payable tab.
The two invoices within Payment XXX are visible.
-
Click Done.
Check Payments
To pay your suppliers, you can make payments by printing checks.
This topic includes the following tasks:
-
Creating the payment document
-
Setting up a payment process profile
-
Submitting the payment process request
-
Reviewing installments and proposed payments
-
Printing checks
-
Recording the print status
-
Reviewing a check
Creating the Payment Document
To make check payments, you must first set up a payment document, or check stock, at the disbursement bank account level.
To create a payment document at the disbursement bank account level, complete these steps:
-
Sign in as a Cash manager.
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Cash Management and Banking
-
Task: Manage Bank Accounts
-
-
On the Manage Bank Accounts page, in the Account Name field, enter BofA-204 and click Search.
The record of the bank account appears in the Search Results section.
-
Select the account and click the Edit icon.
On the Edit Bank Account page, you can view payment documents that have been previously created for the disbursement bank account. To create a payment document, you must provide a name, select the type of paper stock, format, and specify first and last check numbers.
-
On the Edit Bank Account page, Payment Documents section, click Create.
-
In the Create Payment Document dialog box, in the Payment Document field, enter Payments Numbered Check Stock.
-
From the Paper Stock Type choice list, select Numbered Stock.
-
From the Format choice list, search and select Standard Check Format (Stub after Payment).
-
In the First Available Document Number field, enter 373001.
-
In the Last Available Document Number field, enter 373100.
-
Click OK.
-
Click Save and Close.
An Information message is displayed.
-
Click OK.
-
Click Done.
-
Click Done.
-
Sign out.
Setting Up a Payment Process Profile
A payment process profile is a setup that contains all the necessary details to manage the payment process. To print checks, you must create a payment process profile with a Processing Type of Printed. You name the profile and enter a code. Then, you select the same disbursement payment file format that you used to create the payment document.
To create a payment process profile for printing checks, complete these steps:
-
Sign in as a setup user.
-
In the Setup and Maintenance work area, go to the following:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Payment Process Profiles
-
-
On the Manage Payment Process Profile page in the Search results section, click the Add icon.
-
On the Create Payment Process Profile page, in the Name field, enter PPP_XXX.
-
In the Code field, enter PPP_XXX_Code.
Note: In place of XXX, enter the appropriate number. -
In the From Date field, accept the default setting of today's date.
-
From the Payment File Format choice list, search and select Standard Check Format (Stub after Payment).
-
From the Processing Type choice list, select Printed.
-
For the Pay File option, accept Send to printer.
-
Select the Usage Rules tab.
-
Click the All option for Payment Methods, Disbursement Bank Accounts, Business Units, and Currencies so that the payment process profile can be used with any payment.
Note: You can click the Specify option to limit the use of this payment process profile to payments that have specific payment methods, disbursement bank accounts, business units, or currencies. -
Select the Payment System tab.
You can configure the payment file transmission to allow electronic transmission of the positive pay report to the payment system or bank.
-
From the Payment System choice list, select BofA File System.
-
From the Payment File Transmission Configuration choice list, select UCMPut.
-
In the From Date field, accept the default value of today's date.
-
Select the Payment tab.
On the Payment tab, you can specify attributes for grouping invoices in the same payment if they share the same attribute.
-
In the Document Grouping Rules section, select the Due date check box.
-
In the Document Limits section, in the Maximum Documents per Payment field, enter 5.
-
Select the Reporting tab.
On the Reporting tab, you can specify parameters for the positive pay report. This report lists checks issued by your company with payee names, amounts, and currency. Transmission of the report to your payment system or bank prevents the payment of fraudulent checks, since unauthorized payments are not listed on the report.
-
In the Positive Pay section, from the Format choice list, select Positive Pay File Format.
-
Select the Automatically transmit file check box.
-
Click Save and Close.
A Confirmation message appears.
-
Click OK.
-
Click Done.
-
Click Done.
-
Sign out.
Submitting a Payment Process Request
A payment process request is a grouping of documents payable, for which a source product requests payment. You can name the payment process request and select the invoice group.
To submit a payment process request, complete these steps:
-
Sign in as a transaction user.
-
Click the Payables icon and select Payments.
-
On the Overview page, click the Tasks icon and select Submit Payment Process Request.
-
On the Submit Payment Process Request page in the Name field, enter PPR_XXX.
-
Select the Selection Criteria tab.
-
From the Invoice Group choice list, search and select XXXGroup.
Tip: In place of XXX, enter the appropriate number. -
Select the Payment and Processing Options tab.
On the Payment and Processing Options tab, you can specify payment attributes, processing options, and validation failure handling. You select the disbursement bank account from which the invoices are paid, the payment document and payment process profile you created and other options to stop the process for review and to take action if validations fail. If the reviews are satisfactory, a payment file is created.
-
From the Disbursement Bank Account choice list, search and select BofA-XXX.
-
From the Payment Document choice list, select Payments Numbered Stock.
-
From the Payment Process Profile choice list, select PPP_XXX Positive Pay.
-
From the Payment Conversion Rate Type choice list, accept Corporate.
-
In the Processing Options subsection, select these check boxes: Review installments, Review proposed payments, and Create payment files immediately.
-
In the Validation Failure Handling subsection, from the Document choice list, accept Stop process for review.
-
From the Payment choice list, accept Stop process for review.
-
Click Submit.
A Confirmation message with the process number of the payment process request is displayed.
-
Click OK.
-
Scroll down to the Schedule Requests section to check the status of the payment process request.
-
Click the Refresh icon until Succeeded is displayed in the Status column for the Initiate Payment Process Request and the Payables Selected Installments Report processes that correspond to your process ID.
The invoice selection process was successfully completed and the Payables Selected Installments report was generated.
Reviewing Installments and Proposed Payments
You opted to stop the process to review invoices and proposed payments.
To review installments and proposed payments, complete these steps:
-
On the Overview page, Requiring Attention tab, click the Refresh icon. The payment process request appears.
Note: The payment process request shows a Status of Pending installments review because you opted to stop the process to review the invoices. In the Selected Installments section, five invoices were selected by the payment process request. Since the selection looks fine, you can continue. -
Click the Action icon.
-
On the Review Installments page, review the invoices.
-
Click Submit.
A Confirmation message is displayed.
-
Click OK.
-
On the Overview page, Requiring Attention tab, click the Refresh icon.
Note: The payment process request displays the status of Pending proposed payment review because you opted to stop the process to review the proposed payment. Since the proposed payment looks fine, you can continue. -
Click the Action icon.
The Payment Summary section on the Review Proposed Payments page, contains the number of payments created with the total payment amount. Since the payments look fine, you can continue.
-
On the Review Proposed Payments page, click Resume Payment Process.
A Confirmation message is displayed.
-
Click OK.
Printing Checks
The payment process request finished processing. The payment file was automatically formatted and is now ready to print.
To print checks, complete these steps:
-
On the Overview page, Requiring Attention tab, expand the payment process request icon to display the payment file.
-
Click the Refresh icon.
Note: The status of the payment process request is Waiting for payments file processing and the status of the payment file is Formatted and ready for printing. -
Click the Action icon.
-
On the Print Payment Documents page, from the Printer choice list, select PO 407.
-
Click Print.
A Confirmation message is displayed.
-
Click OK.
-
On the Overview page, Requiring Attention tab, click Refresh to requery the payment process request.
The payment file status changes to Submitted for printing.
-
Click the Action icon.
Recording the Print Status
After you print checks, you must examine the printed checks to confirm that they're not spoiled or skipped. If a check is spoiled or skipped, you record the print status.
To record the print status, complete these steps:
-
On the Payment File page, review the payments and their check numbers. If your checks look fine, click Record Print Status.
-
On the Record Print Status: Payment File page, click Submit.
A Warning message is displayed.
-
Click Record the Print Status.
A Confirmation message is displayed.
-
Click OK.
-
Click Done.
Note: On the Manage Payment Process Requests page, the payment process request status is Waiting for payment file processing. The payment file status is Printed. -
Click Done.
The Overview page appears.
Reviewing a Check
After printing checks, you can review them.
To review a check, complete these steps:
-
On the Overview page, scroll down to the Schedule Requests section.
You can review the schedule requests to verify the status of the positive pay file.
-
Click Refresh.
-
On the Create Positive Pay File process row, click the View Output icon to see the output that was transmitted to the payment system or bank.
A Create Positive Pay File, XXXXX, Output dialog box appears.
-
Click the ESS link.
A .txt of the positive pay report is displayed.
-
On the Format Payment Files process row, click the View Output icon to review the .pdf file of the printed checks.
A Format Payment Files, XXXXX, Output dialog box appears.
-
Click the ESS link.
A .pdf of the check is displayed.
How Disbursements Are Processed
The disbursement process starts when a source product calls Oracle Fusion Payments to process disbursements. For example, Oracle Fusion Payables uses the disbursement process to pay supplier invoices and Oracle Fusion Receivables uses it to pay customer refunds. The disbursement process ends when either electronic payments are transmitted to a payment system or financial institution or paper payment documents, such as checks or promissory notes, are printed.
Electronic processing creates a payment file that is transmitted to a payment system or other financial institution. The file contains instructions that tell the payment system or financial institution how to remit funds. In some cases, funds are remitted electronically by an automatic deposit to a bank account. In other cases, the payment file can instruct the payment system or financial institution to issue a check for payment.
Settings That Affect Disbursements
The following settings in the header region on the Create Payment Process Profile page impact electronic disbursements:
-
Payment File Format choice list: You specify the payment file format to use for the electronic payment file.
-
Processing Type choice list: Electronic.
-
Payment Confirmation Point choice list: Point at which a payment is confirmed. Payments can be automatically confirmed, either when the payment file is formatted or when the payment file is transmitted to the payment system.
-
Allow Manual Setting of Payment Confirmation check box: You can manually confirm payments on the following pages:
-
Manage Payment Files
-
Payment File
-
Overview page in the Payments work area
-
The following settings in the header region on the Create Payment Process Profile page impact printed disbursements:
-
Payment File Format choice list: You specify the payment file format to use for the printed payment file.
-
Processing Type choice list: Printed.
-
Default Payment Document choice list
-
Send to File radio button: Produces a formatted output file, which is printed outside of Oracle Fusion Applications.
-
Send to Printer radio button
-
Automatically Print After Formatting check box
-
Default Printer choice list
How Disbursements Are Processed
The following figure illustrates the flow of the disbursement process.

The following figure illustrates the flow of the payment approval process within the disbursement process.

The following table describes the action steps performed by the disbursement process, which starts in Payables and ends in Payments.
Action | Description |
---|---|
Create documents |
Source product creates documents payable, such as invoices. |
Select documents |
Source product selects documents. Selected documents are grouped into a payment process request. |
Submit payment process request |
Payment process request is submitted to Payments for processing. |
Assign bank account and payment process profile |
Disbursement bank accounts, which are your company's bank accounts, and payment process profiles are assigned to documents payable within the payment process request. Payments automatically assigns these values when possible. When not possible, the application asks you to supply the values on the Assign Payment Process Attributes page. |
Validate documents |
Payments executes any document level validations set up on the payment method or format. Documents payable that fail validation can be automatically removed and returned to the source product. Valid documents payable continue in the disbursement process, or the payment process request can be stopped for resolution, depending on options set during the submission of the payment process request. |
Create and validate payments |
Payments groups like documents payable into payments, according to rules set up in the payment process profile. It then executes any payment level validations set up on the payment method or format. Payments that fail validation can be automatically removed and the documents payable returned to the source product. Valid payments continue in the disbursement process, or the payment process request can be stopped for resolution, depending on options set during the submission of the payment process request. |
Review and modify payment process request |
When the payment process request is submitted, it can be set to stop for review as soon as all payments pass validation. During the review, you can optionally remove payments from the payment process request or documents payable from payments. If you make any changes during the review, validations are executed again. |
Approve or reject payment process request |
When payment approval is enabled, the payment process stops at the Review Proposed Payments stage, and approvers can optionally remove payments directly from a payment process request and then approve it. The approval process generates and routes payment approval notifications to approvers. Approvers can approve or reject payment process requests directly from e-mails or from the Review Proposed Payments page. |
Create payment file |
Payments processes payments within each payment process request and groups them according to their disbursement bank accounts, payment process profiles, and other grouping rules to create payment files. |
Validate payment file |
Payments executes any payment file level validations set up on the format. Payment files that fail validation can be corrected by removing payments or the validation can be overridden. |
Create extract and format |
An extract, or XML file, is created that contains the data relevant to the payment file. Oracle BI Publisher applies a format template to the data in the extract. The result is a formatted file that contains data specified by the format. |
Transmit payment file |
If the payment process profile for a formatted payment file specifies electronic processing, the payment file is transmitted to the payment system. The payment system is a bank or other financial institution that processes the file and moves funds from the disbursement bank account to the payee bank account. |
If the payment process profile for a formatted payment file specifies printed processing, the payment file is printed onto payment documents, such as checks. If any checks print incorrectly, they can be reprinted. After checks print successfully, you can record the print status, which allows Payables to account for the payments. |
|
Perform post-processing |
After creating payments, you can optionally use reports as follows:
|
How a Separate Remittance Advice Report Is Processed
The Separate Remittance Advice report is a predefined disbursement report that is sent to suppliers, which lists the invoices your company paid. You can manually run the report from the Payments Tasks pane by clicking the Send Separate Remittance Advice link or you can automatically run the report after you select specific options on the Reporting tab of the Payment Process Profile page. The automatic process is called internally on payment completion. Any required parameter values are known by Oracle Fusion Payments without your intervention. Payments uses Oracle BI Publisher templates to format and deliver the report.
The following table shows the report details.
Report Name | Process Name | Description | Output |
---|---|---|---|
Disbursement Separate Remittance Advice Formats |
Send Separate Remittance Advice |
Creates notices that can be faxed, E-Mailed, or printed and mailed to suppliers. Lists the invoices paid electronically or by printed payment. |
Document |
To manually run the report, navigate to: Navigator > Payables > Payments link > Send Separate Remittance Advice link.
To set up a payment process profile, navigate to: Navigator > Tools > Setup and Maintenance > All Tasks tab > Search field: Task Lists and Tasks > Name field: Payments > Search button > Define Invoicing and Payments Configuration > Define Disbursements > Manage Payment Process Profiles task > Go to Task > Manage Payment Process Profiles page > Create button > Create Payment Process Profile page.
To automatically run the report, navigate to the Reporting tab on the Payment Process Profile page, provide a format, select the condition as All Payments, and select the Automatically submit when payments are confirmed check box.
Settings That Affect Submit Separate Remittance Advice
The following settings on the Reporting tab of the payment process profile affect the Separate Remittance Advice report:
-
Report format selected
-
Whether the report needs to be automatically generated on payment completion
-
Whether multiple copies of the report are allowed for a payment file
-
Conditions under which the report is generated
-
Delivery method of the report
How the Submit Separate Remittance Advice Report Is Processed
The following table describes how the Separate Remittance Advice report is processed.
Action | Description |
---|---|
Application reads the separate remittance advice setup on the payment process profile. |
On the Reporting tab of the Create or Edit Payment Process Profile page, you can specify whether automatic submission of a separate remittance advice is required when payments are confirmed. |
Does a Separate Remittance Advice report need to be generated after payment confirmation? |
If the payment process profile indicates that no Separate Remittance Advice report is required, then the process is complete. If a Separate Remittance Advice report is required, then the process continues. |
Application checks whether the delivery method is selected on the payment process profile. |
The Payment Process Profile page, Separate Remittance Advice section, contains the delivery method of the Separate Remittance Advice report. The delivery method specifies how the report is to be delivered to the supplier. Delivery methods include E-Mail, print, and fax. If you select Printed as the delivery method in the Separate Remittance Advice section on the Reporting tab, you will see the Override payee delivery method preference check box. If you select it, the Separate Remittance Advice report prints, regardless of any delivery method you selected at the supplier. |
Application reads the delivery address from the Payments table called iby_external_payees_al. |
After the delivery method is determined, then the delivery address, whether E-Mail or fax number, is read. |
Application passes the extract XML message to Oracle Business Intelligence Publisher (Oracle BI Publisher). |
The extract XML message is sent to Oracle BI Publisher to format the Separate Remittance Advice report. |
Oracle BI Publisher applies the template to the XML message. |
Payments tells Oracle BI Publisher which template to apply to the XML message. |
Oracle BI Publisher formats, stores output, and delivers the Separate Remittance Advice report. |
Oracle BI Publisher formats the Separate Remittance Advice report and stores the output. It then delivers the report to the supplier using the specified delivery method. |
Application processes E-Mail delivery method if applicable. |
Payments sends the Separate Remittance Advice report by E-Mail if the following fields are completed on the Manage Disbursement System Options page:
|
How a Positive Pay File Is Generated
A positive pay file is a predefined disbursement report, which acts as a security measure that your company can implement. The report prevents check fraud by informing your payment system or bank of issued payment documents and their amounts. The positive pay file prevents your payment system or bank from paying fraudulent checks, since unauthorized payments aren't listed on the positive pay report.
Run the positive pay file using these methods:
-
To manually run the report, navigate: Navigator > Payables > Payments > Create Positive Pay File link.
-
Payments automatically runs the report when you select options on the Reporting tab of the Create Payment Process Profile page.
In the Setup and Maintenance work area, select: Offering: Financials, Functional Area: Payments, Task: Manage Payment Process Profiles, and the click the Create icon. To automatically run the positive pay report as part of the payment process request submission process, select the Automatically transmit file check box on the Reporting tab. Payments uses Oracle Business Intelligence Publisher (Oracle BI Publisher templates) to format the report. Payments then has the capability to transmit the file electronically to your payment system or bank.
This table describes the details of the Positive Pay file.
Report Name | Process Name | Description | Output |
---|---|---|---|
Disbursement Positive Pay File Formats |
Create Positive Pay File |
Creates a document that you transmit to your payment system or bank to inform it of payments made by check. |
Document |
Parameters That Affect a Positive Pay Report
The parameters listed in this table affect the output of the Positive Pay report when you run it manually.
Parameter | Mandatory or Optional |
---|---|
Payment Process Profile choice list |
Mandatory |
From Payment Date |
Mandatory |
To Payment Date |
Optional |
Allow sending replacement copy choice list. You can include payments in the report that were included in a previous positive pay file. |
Mandatory |
Select Status choice list. You must select one of the following for inclusion in the positive pay file: only negotiable payments, only payments that have been voided, or all payments. |
Mandatory |
Transmit File choice list. |
Optional. Choices are Yes or No. Note: You can select Yes to manually transmit the positive pay file only if the payment system
account on the Payment System tab of the payment process profile includes
values for these fields:
|
How a Positive Pay Report File Is Generated
This table describes the flow of the manual Create Positive Pay File process.
Action | Description |
---|---|
The Create Positive Pay File process runs when you click the Create Positive Pay File link from the Payments Tasks pane and select appropriate parameters. |
The Create Positive Pay File process selects:
|
The application invokes the applicable Oracle BI Publisher format. |
Payments invokes Oracle BI Publisher, which takes Payments data and generates the positive pay file. |
The application may transmit the positive pay file to your payment system or bank. |
You can decide whether or not to manually transmit the positive pay file if the payment system account on the Payment System tab of the payment process profile includes values in these fields:
|
This table describes the flow of the automatic Create Positive Pay File process.
Action | Description |
---|---|
Payments automatically runs the Create Positive Pay File if you select the Automatically transmit filecheck box on the Reporting tab of the Payment Process Profile page. |
After you select the Automatically transmit file check box, the next time you submit a payment process request with the applicable payment process profile, the positive pay file is generated and automatically transmitted. |
The application transmits the positive pay file to your payment system or bank. |
Payments transmits the positive pay file to your payment system or bank. |
How You Confirm Electronic Payment Files
A confirmed electronic payment file is considered complete and done. Oracle Fusion Payments notifies source products when payments are confirmed, so they can perform necessary accounting. The point at which an electronic payment is considered confirmed depends on:
-
Your company's business practices
-
The notification that your payment system supports, such as acknowledgment and clearing
Electronic payment files can be confirmed by:
-
Specifying an automatic payment file confirmation point
-
Manually confirming payment files
Specifying an Automatic Payment File Confirmation Point
When you create a payment process profile during setup, you can specify the point at which an electronic payment file is automatically confirmed. The confirmation point can be one of the following:
-
When the payment file is formatted
-
When the payment file is transmitted to your payment system
Manually Confirming Payment Files
When you create a payment process profile during setup, you can also specify whether you want to enable manual confirmation of the payment file. You can choose to manually confirm payment files before they're automatically confirmed. You may need this option available for timing reasons.
The following table describes where and how you can manually confirm electronic payment files.
Page | Action |
---|---|
Manage Payment Files. |
|
Payment File. |
Select the applicable option from the Actions menu. |
How Printed Payment File Statuses Are Impacted
The application processes printed payment files. Printed payment files are printed onto checks or promissory notes. As a printed payment file is processed, the payment file status changes, depending on the actions performed by the source product, Oracle Fusion Payments, and you.
Settings That Affect Printed Payment Files Statuses
The following settings in the header of the Create Payment Process Profile page affect printed payment file statuses:
-
Processing Type choice list: Printed.
-
Default Payment Document choice list
-
Send to file radio button: Produces a formatted output file, which is printed outside of Oracle Fusion Applications
-
Send to printer radio button
-
Automatically Print After Formatting check box
-
Default Printer choice list
-
Payment File Format choice list. You can specify the payment file format to use for the printed payment file.
How Printed Payment Files Statuses Are Impacted
The following figure illustrates the flow of statuses when printing payment files, which includes printing to a file as well as to a printer.

The following table describes the stages and statuses of printed payment files and the subsequent action taken by you or the application.
Printed Payment File Stage | Printed Payment File Status | Action You or the Application Takes |
---|---|---|
The payment file is created and validated, but fails validation. |
Failed validation and pending action |
You must take remedial action. |
You review a payment file that failed validation and remove payments or override errors. |
Retry payment file validation |
Payments validates the payment file again. |
The payment file passes validation. |
Created |
Payments starts the formatting process. |
The payment file is terminated. |
Terminated |
Payments returns the documents payable to the source product. |
The payment file failed formatting. |
Failed formatting and pending action |
You must take remedial action. |
Payments was set up to allow printing outside the application rather than within it. The data extract was created and formatting is complete. |
Formatted and ready for recording |
The payment file is created, formatted, and ready to be recorded. |
Payments was set up to allow printing outside the application rather than within it. Creation of the data extract and formatting are incomplete because another payment file has locked the payment document. |
Created and ready for formatting |
The payment file is created and ready to be formatted. |
Creation of the data extract and formatting are incomplete for a printed payment file because another payment file has locked the payment document. |
Created and ready for printing |
The payment file is created and ready to print. |
Creation of the data extract and formatting is complete for a printed payment file. Payments was set up to print immediately, but the print program has not yet submitted the file to Oracle Business Intelligence Publisher (Oracle BI Publisher). This status is very short-lived and is rarely seen. |
Formatted |
The payment file is created and formatted. |
Creation of the data extract and formatting was completed for a printed payment file. Payments was set up for deferred printing. |
Formatted and ready for printing |
The payment file is created, formatted, and ready to print. |
You initiated printing on the Print Payment Documents page or on the Reprint Payment Documents page. |
Submitted for printing |
The payment file is sent to the printer. You can reprint payments or record the print status. |
The printer prints the payment file. |
Printed |
You record the final print status on the Record Print Status page. |
You void a payment. |
Terminated |
If the payment was the last one in the file, the payment file is terminated. |
How Electronic Payment File Statuses Are Impacted
As an electronic payment file is processed, the payment file status changes depending on the setup and actions performed by the source product, Oracle Fusion Payments, and you. An electronic payment file is transmitted to a payment system or financial institution for final processing and disbursement.
Settings That Affect Electronic Payment File Statuses
The following settings in the header of the Create Payment Process Profile page affect electronic payment file statuses:
-
Processing Type choice list: Electronic.
-
Payment Confirmation Point choice list: Point at which a payment is confirmed. Payments can be automatically confirmed when the payment file is formatted or when the payment file is transmitted to the payment system.
-
Allow Manual Setting of Payment Confirmation check box: You can manually confirm payments on the following pages:
-
Manage Payment Files
-
Payment File
-
Overview page in the Payments work area
-
-
Payment File Format choice list: Format that Oracle Business Intelligence Publisher (Oracle BI Publisher) uses to prepare the payment file for transmission.
How Electronic Payment File Statuses Are Impacted
The following figure illustrates the flow of statuses that are associated with the creation of electronic payment files.

The following table describes how actions performed by Payments or by you change the status of the electronic payment file.
Action Taken by Payments or By You | Status of the Electronic Payment File |
---|---|
|
Failed validation and pending action |
|
Retry payment file validation |
|
Created |
|
Terminated |
|
Failed formatting and pending action |
|
Formatted |
|
Formatted and ready for transmission |
Payments successfully transmitted an electronic payment file to the payment system or financial institution. |
Transmitted |
Payments failed to transmit an electronic payment file to the payment system or financial institution. |
Transmission failed |
|
Transmitted |
|
Terminated |
Skipped and Spoiled Payment Documents
A skipped numbered payment document scenario is where the payment is printed onto a payment document with a different number than you intended. A spoiled numbered payment document is ruined and one that you don't intend to reprint.
The following payment document scenarios can occur:
-
Skipped numbered payment document
-
Spoiled numbered payment document
-
Spoiled blank payment document
Skipped Numbered Payment Document
Numbered payment documents have the document or check number already printed on them.
If your printer skips a numbered payment document, mark the payment document as skipped on the Record Print Status page. The application renumbers subsequent payment documents and presents the results to you for review on the Record Print Status page.
You can take the following action with skipped numbered payment documents:
-
Save them for a future single payment.
-
Save them for a manual payment.
-
Destroy the paper document and void it in Oracle Fusion Cash Management on the Edit Bank Account page.
Spoiled Numbered Payment Document
A spoiled payment document is ruined during printing and can't be used. Numbered payment documents have the document or check number already printed on them.
If you choose to reprint, perform both of the following steps:
-
Reprint the payment onto a new numbered payment document on the Reprint Payment Documents page.
-
Report the payment as issued on the Record Print Status page.
The application notes the spoiled numbered payment document, associates the new number with that payment, and reprints the new numbered payment document.
If you choose not to reprint, mark the numbered payment document as spoiled on the Record Print Status page and then destroy the paper document.
Spoiled Blank Payment Document
A spoiled payment document can't be used. Blank payment documents don't have the document or check number already printed on them.
The following table summarizes the actions that you and the application can take when your printer ruins a blank payment document:
Actions You Take | Actions the Application Takes |
---|---|
Void or destroy the spoiled blank payment document. |
The application takes no action. |
If you choose to reprint, perform both of the following steps: 1. Reprint onto a new blank payment document on the Reprint Payment Documents page. 2. Report the payment as issued on the Record Print Status page. |
The application reprints onto a new blank payment document. |
If you choose not to reprint, mark the blank payment document as spoiled on the Record Print Status page. |
The application removes the payment from the payment file and releases the documents payable back to Oracle Fusion Payables for future payment. |
Options for Resolving Payment File Transmission Failures
When a payment file transmission failure occurs, you can choose from the following options:
-
Transmit the file again.
-
Ignore the transmission failure.
-
Stop the payment process.
Transmitting the File Again
Transmitting the file again assumes that any previous transmission failure was the result of a temporary issue or that setup was corrected after the original attempt to transmit. This action attempts to retransmit the payment file.
Ignoring the Transmission Failure
Ignore the transmission failure:
-
When you must force the payment file status to Transmitted after successfully transmitting the file outside the application
-
When you confirm with your bank that it was successfully received despite the failure status
When you instruct the application to ignore the failure, it updates the status of the payment file to Transmitted.
Stopping the Payment Process
When you decide to terminate the payment file, the application sets the status of the payment file to Terminated. Oracle Fusion Payments informs the source product of the terminated documents payable. For each payment in the payment file, Payments sets the status to Canceled. The source product unlocks the documents and resets their status so they are available for future selection.
Options for Resolving Payment File Validation Errors
In payment processing, it's critical to ensure that payment files sent to payment systems and financial institutions are valid and correctly formatted. Payment file validations are rules that check the validity of payment files. If a payment file fails validation, it is always stopped for review.
To resolve payment file validation errors, you can choose from the following actions:
-
Override the validation error.
-
Remove payments from the payment file.
-
Change payment method setup or format setup.
Overriding the Validation Error
To resolve payment file validation errors, you can override certain errors and then provide the override justification. For example, suppose your company has a payment file validation that specifies that the total amount of a payment file cannot be more than 1 million USD. If a payment file is 2 million USD and must be processed, you can acknowledge the error, provide a justification, and override the error.
After you override the error, the payment process formats and then prints or transmits the payment file.
Removing Payments from the Payment File
If you remove a payment from the payment file that has a payment file or formatting validation error, the validation error is no longer applicable. For example, suppose your company has a payment file validation that specifies that the total amount of a payment file cannot be more than 1 million USD. The payment file is comprised of 12 payments. The error can be corrected by removing one or more payments from the payment file until the total amount of the payment file is 1 million USD or less.
Changing the Payment Method Setup or Format Setup
You can do the following during setup:
-
Payment method setup: assign predefined validations or create user-defined validations
-
Payment formats setup: assign predefined validations
To resolve an unwanted payment file validation, you can modify or remove it from the applicable payment method or payment format.
How Payment Document Number Generation of Electronic Payments Are Processed
You can generate paper document numbers for electronic payments. Paper document numbers can be sent to your payment system or bank so they can be printed onto your outsourced checks. To achieve this, you assign paper document numbering values, which are check numbers, to electronic formats. The application then generates paper document numbers for electronic payments. Payments also generates a unique payment reference number that identifies each payment. Payment reference numbers are also transmitted to your payment system or bank.
The following table describes what is stamped on electronic payments, whether paper document numbering for electronic payments is enabled or disabled.
Paper Document Numbering for Electronic Payments is Enabled | Paper Document Numbering for Electronic Payments is Disabled |
---|---|
Values stamped on electronic payments:
|
Values stamped on electronic payments:
|
Settings That Affect Payment Document Number Generation of Electronic Payments
The following table lists the locations, navigation, and action that you can take that affect payment document numbering of electronic payments.
Location | Navigation | Action You Take |
---|---|---|
Create Payment Document page. |
Setup and Maintenance > Set Up Banks, Branches, and Accounts > Manage Bank Accounts task > Create Payment Document page. |
From the Format choice list, select an electronic payment file format. |
Create Payment Process Profile page. |
Setup and Maintenance > Define Invoicing and Payments Configuration > Define Disbursements > Manage Payment Process Profiles task > Manage Payment Process Profiles page > Create Payment Process Profile page.. |
|
Create Electronic Payment Files submission page. |
Navigator > Payables > Payments link > Payments Tasks pane: Create Electronic Payment Files link > Create Electronic Payment Files submission page. |
From the Payment Document choice list, select a payment document number. Note: If you don't select a payment document when selecting
parameters, then Payments refers to the payment document selected
when you submit the payment process request on the Submit Payment
Process Request page. This scenario is applicable only if the Create payment files automatically check
box is deselected when you submit the payment process request.
|
Submit Payment Process Request page. |
Navigator > Payables > Payments link > Payments Tasks pane: Submit Payment Process Request link > Submit Payment Process Request page. |
From the Payment Document choice list, select a payment document number. Note: If you don't select a payment document when you select
parameters on the Submit Payment Process Request page, then Payments
refers to the default payment document selected for the applicable
payment process profile.
|
How Payment Document Numbers for Electronic Payments Are Generated
You can generate payment document numbers for electronic payments by taking one of the following actions:
-
Select a payment document when you submit a payment process request.
-
Select a payment document when you submit the Create Electronic Payment Files submission page
The following table describes the values displayed in the Payment Document choice list on submission pages when you select options from various choice lists. Selection of an option from the Payment Document choice list is optional.
Submission Page | If You Select an Option Only From... | Then the Payment Document Choice List Displays... |
---|---|---|
Create Electronic Payment File. |
Disbursement Bank Account choice list. |
All payment documents created for the selected internal bank account. |
Create Electronic Payment File. |
Payment Process Profile choice list. |
All payment documents associated with the payment file format selected on the payment process profile. |
Create Electronic Payment File. |
Disbursement Bank Account choice list and the Payment Process Profile choice list. |
All payment documents created for the selected internal bank account and attached to the electronic payment file format selected on the payment process profile. |
Submit Payment Process Request. |
Disbursement Bank Account choice list. |
All payment documents created for the selected internal bank account. |
Submit Payment Process Request. |
Disbursement Bank Account choice list and the Payment Process Profile choice list. |
All payment documents created for the selected internal bank account and attached to the electronic payment file format selected on the payment process profile. |
On occasion, a single payment process request results in multiple payment files. When this occurs, the following behavior applies:
-
The first payment file refers to the applicable payment document. Payment document numbering values are generated.
-
When the first payment file is completed, the status of other payment files are Created - Ready for Formatting.
-
After the first payment file is transmitted, the applicable payment document is released and you can assign it to another payment file.
Tip: If you attempt to assign a payment document which is already in use by another electronic payment file, you will see an error message stating that you can't assign your payment document to the applicable payment file because it's already in use by another payment file.
How You Group ISO 20022 SEPA and CGI Credit Transfer Messages
A credit transfer message is a payment initiation message format that is sent by an initiating party to an forwarding agent or debtor agent. It's used to request the movement of funds from a debtor account to a creditor. This message format, which is known as CustomerCreditTransferInitiationV05 (pain.001.001.05), was approved by the International Organization for Standardization (ISO). ISO 20022 is a global standard for the development of all financial messages.
Oracle Fusion Payments provides two versions of the credit transfer message format; one for SEPA and one for CGI. Single Euro Payment Area (SEPA) is a system that provides a standardized process for credit transfers and a cheaper way for individuals and firms to make transactions within European member countries or regions. Common Global Implementation (CGI) is an organization that provides a forum that promotes wider acceptance of ISO 20022 as the common XML standard used between corporate enterprises and banks.
The ISO 20022 credit transfer message format has a three-level XML message structure as described in the following table.
Level | Level Name | Level Content |
---|---|---|
1 |
Group header |
Information shared by all individual transactions included in the message. |
2 |
Payment information |
Data that applies to the debit side of the payment transactions included in the credit transfer initiation. |
3 |
Supplementary data |
Additional information that can't be captured in the structured elements or any other specific block. |
Mandatory Grouping Options
The Grouping tab on the Create and Edit Payment Process Profile page contains mandatory ISO 20022 grouping options for both SEPA and CGI versions of the credit transfer message format that tell Payments how to group transactions within a payment file.
The following table describes the mapping between Payments grouping options and the ISO 20022 elements in the SEPA and CGI versions of the credit transfer message format.
Mandatory Grouping Options on Grouping Tab on Create and Edit Payment Process Profile Page | Mapping to ISO 20022 Element |
---|---|
Payment date |
Requested execution date |
Disbursement bank account |
|
Optional Grouping Options
The Grouping tab on the Create and Edit Payment Process Profile page contains optional ISO 20022 grouping options for both SEPA and CGI versions of the credit transfer message format that tell Payments how to optionally group transactions within a payment file.
The following table describes the mapping between Payments grouping options and the ISO 20022 elements in the SEPA and CGI versions of the credit transfer message format.
Optional Grouping Options on Grouping tab on Create and Edit Payment Process Profile Page | Mapping to ISO 20022 Element |
---|---|
Settlement Priority |
Instruction priority |
Service Level and Delivery Channel |
Service level and local instrument |
Ultimate Debtor |
Ultimate debtor |
Charge bearer |
Charge bearer |
Category purpose |
Category purpose |
Validations for ISO 20022 SEPA and CGI Credit Transfer Messages
Oracle Fusion Payments predefines two BI Publisher templates and two corresponding payment formats for the SEPA (Single Euro Payments Area) and CGI (Common Global Implementation) versions of ISO 20022 credit transfer messages. Payments attaches validations to the ISO 20022 credit transfer message formats for SEPA and CGI to verify that required data is present in the credit transfer messages formats.
The following table describes the predefined validations that are attached to the ISO 20022 SEPA payment format by Payments.
Predefined Validations Attached to ISO 20022 SEPA Credit Transfer Message Format
Format Name | Validation | Description |
---|---|---|
ISO20022 Single Euro Payments Areas v5.0 Format (pain.001.001.03) |
SEPA Validation |
Verifies the value entered in the Alias attribute in the payment method. If the value for the Alias attribute in the payment method is TRF, then the document is selected for SEPA payment. |
|
SEPA Validation |
Verifies that the payment currency is always EUR. If the payment currency is EUR, then the document is selected for SEPA payment. |
|
SEPA Validation |
Verifies that the disbursement bank branch country is within the EUROZONE. If the bank branch country is within the EUROZONE, then the payment process request proceeds to the next step. |
|
SEPA Validation |
Verifies that the payee bank branch country is within the EUROZONE. If the bank branch country is within EUROZONE, then the payment process request proceeds to the next step. |
|
SEPA Validation |
Verifies that the disbursement bank has a valid IBAN. If the IBAN is valid, the payment process request proceeds to the next step. |
|
SEPA Validation |
Verifies that the payee bank has a valid IBAN. If the IBAN is valid, the payment process request proceeds to the next step. |
|
SEPA Validation |
Verifies that the disbursement bank has a BIC. If the BIC exists, the payment process request proceeds to the next step. |
|
SEPA Validation |
Verifies that the payee bank has a BIC. If the BIC exists, the payment process request proceeds to the next step. |
|
Service Level Validation |
Verifies that the Payment Service Level is present in the payment file. |
|
Local Instrument Validation |
Verifies that Delivery Channel value is present in the payment file. |
|
SEPA Initiating Party Validation |
Verifies that Initiating Party Identification is present in the payment file. |
The following table describes the predefined validations that are attached to the ISO 20022 CGI payment format by Payments.
Predefined Validations Attached to ISO 20022 CGI Credit Transfer Message Format
Format Name | Validation | Description |
---|---|---|
ISO20022 Common Global Implementation Format |
CGI Validation |
Verifies the value entered in the Alias attribute in the Payment Method. If the value for the Alias attribute in the payment method is TRF, then the document is selected for SEPA payment. |
|
Service Level Validation |
Verifies that the Payment Service Level is present in the payment file. |
|
Local Instrument Validation |
Verifies that Delivery Channel value is present in the payment file. |
|
Creditor Agent Country Validation |
Verifies that Payee Bank Branch Country is present in the payment file. |
|
Creditor Agent Country Validation |
Verifies that Payer Bank Branch Country is present in the payment file. |
|
Initiating Party Validation |
Verifies that Initiating Party Identification is present in the payment file. |
Differences exist between the SEPA and CGI versions of the ISO 20022 credit transfer message formats. The following is a list of conditions that are specific to the ISO 20022 CGI payment file format:
-
Payment currency can be any currency.
-
No restriction on disbursement bank branch location.
-
No restriction on payee bank branch location.
-
Payee bank account number is required for all EFTs.
-
A user-defined validation achieves this condition.
-
Payments Mapping of ISO 20022 Credit Transfer Message Structure for SEPA and CGI
ISO 20022 is a global standard for the development of all financial messages that is proposed by the International Organization for Standardization (ISO). This topic provides data mapping information for SEPA and CGI versions of the ISO 20022 credit transfer message format as supported by Oracle Fusion Payments.
The ISO 20022 credit transfer message structure contains the following blocks of message elements:
-
Group header message elements
-
Payment information message elements
-
Credit Transfer Transaction Information message elements
Group Header Message Elements
The following table lists the group header message elements and Payments data mapping information for SEPA and CGI versions of the ISO credit transfer message.
ISO Element Number | Message Element | <XML Tag> | SEPA Implementation Mapping | CGI Implementation Mapping |
---|---|---|---|---|
|
Customer Credit Transfer Initiation |
<CstmrCdtTrfInitn> |
Tag |
Tag |
1.0 |
GroupHeader |
<GrpHdr> |
Tag |
Tag |
1.1 |
Message |
<MsgId> |
Maps to system generated payment file ID, unique across the application. The ID is exposed to the end user as the primary search key for the payment file |
Maps to system generated payment file ID, unique across the application. The ID is exposed to the end user as the primary search key for the payment file |
1.2 |
CreationDateTime |
<CreDtTm> |
Payment file creation date time |
Payment file creation date time |
1.4 |
Code |
<Cd> |
Additional Optional Service - Not supported |
Bilaterally Determined (Optional element). Not supported |
1.5 |
Proprietary |
<Prtry> |
Additional Optional Service - Not supported |
Bilaterally Determined (Optional element). Not supported |
1.6 |
NumberOfTransactions |
<NbOfTxs> |
Total number of credit transaction records within the payment file. |
Total number of credit transaction records within the payment file. |
1.7 |
ControlSum |
<CtrlSum> |
Sum of 'instructed Amount' in all credit transaction record. (Regardless of currency and without any conversions) |
Sum of 'instructed Amount' in all credit transaction record. (Regardless of currency and without any conversions) |
1.8 |
InitiatingParty |
<InitgPty> |
Tag |
Tag |
9.1.0 |
Name |
<Nm> |
Mapping precedence: ISO20022 Initiating Party Name entered in the Payment System Account Settings. Else Legal Entity Name |
Mapping precedence: ISO20022 Initiating Party Name entered in the Payment System Account Settings. Else Legal Entity Name |
9.1.1 |
PostalAddress |
<PstlAdr> |
Additional Optional Service - Not supported |
Element not used - Not supported |
9.1.12 |
Identification |
<Id> |
Tag |
Tag |
9.1.13 |
OganisationIdentification |
<OrgId> |
Tag Either BICOrBEI or Other is passed. |
Tag Either BICOrBEI or Other is passed. |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Mapped to the ISO20022 Initiating Party BICorBEI entered in the Payment System Account Settings |
Mapped to the ISO20022 Initiating Party BICorBEI entered in the Payment System Account Settings |
9.1.15 |
Other |
<Othr> |
Tag |
Tag |
9.1.16 |
Identification |
<Id> |
Mapping Precedence: Pass, ISO20022 Initiating Party Other Identification entered if available. Else Pass, Legal Entity Registration Number of Disbursement Bank Account Legal Entity. |
Mapping Precedence: Pass, ISO20022 Initiating Party Other Identification entered if available. Else Pass, Legal Entity Registration Number of Disbursement Bank Account Legal Entity. |
9.1.17 |
SchemeName |
<SchmeNm> |
Tag AOS Element, Not Supported. |
Tag Element not used - Not supported |
9.1.21 |
PrivateIdentification |
<PrvtId> |
As we propose to map disbursement bank legal entity to initiating party, private identification-related elements. |
Element not used - Not supported |
1.9 |
ForwardingAgent |
<FwdgAgt> |
Additional Optional Service - Not supported |
Element not used - Not supported |
Payment Information Message Elements
The following table lists the payment information message elements and Payments data mapping information for SEPA and CGI versions of the ISO credit transfer message.
ISO Element Number | Message Element | <XML Tag> | SEPA Implementation Mapping | CGI Implementation Mapping |
---|---|---|---|---|
|
|
|
|
|
2.0 |
PaymentInformation |
<PmtInf> |
|
|
2.1 |
PaymentInformationIdentification |
<PmtInfId> |
Maps to system generated payment group ID, unique across the application. The ID is exposed to the end user as the primary search key for the payment group; the ID is available for payment acknowledgments and bank statement matching |
Maps to system generated payment group ID, unique across the application. The ID is exposed to the end user as the primary search key for the payment group; the ID is available for payment acknowledgments and bank statement matching |
2.2 |
PaymentMethod |
<PmtMtd> |
Maps to 'Alias' field in Payment Method setup. It will be users responsibility to enter the right code that has to be displayed in payment file. |
Maps to 'Alias' field in Payment Method setup. It will be users responsibility to enter the right code that has to be displayed in payment file. |
2.3 |
BatchBooking |
<BtchBookg> |
Map to 'Batch booking' check box at Payment Process Profile |
Map to 'Batch booking' check box at Payment Process Profile |
2.4 |
NumberOfTransactions |
<NbOfTxs> |
Total number of credit transaction records within the payment information group. |
Total number of credit transaction records within the payment information group. |
2.5 |
ControlSum |
<CtrlSum> |
Sum of 'Instructed Amount' in all credit transaction record within the payment information group.(Regardless of currency and without any conversions) |
Sum of 'instructed Amount' in all credit transaction record. (Regardless of currency and without any conversions) |
2.6 |
PaymentTypeInformation |
<PmtTpInf> |
Tag All element components of Payment Type Information will be provided as optional grouping attributes at Payment Process Profile. If user selects to group a payment information record based on one or more additional attributes, then this information will be displayed as part of payment type information. |
Tag All element components of Payment Type Information will be provided as optional grouping attributes at Payment Process Profile. If user selects to group a payment information record based on one or more additional attributes, then this information will be displayed as part of payment type information. |
2.7 |
InstructionPriority |
<InstrPrty> |
Maps to settlement priority as part of management installments, values are HIGH or NORMAL |
Maps to settlement priority as part of management installments, values are HIGH or NORMAL |
2.8 |
ServiceLevel |
<SvcLvl> |
Tag |
Tag |
2.9 |
Code |
<Cd> |
We will configure the value 'SEPA' into the source code. |
We will provide attribute at payee level with an option to override at PPP level. This element should not be displayed if payment method is 'CHK'. |
2.10 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
2.11 |
LocalInstrument |
<LclInstrm> |
Tag |
Tag |
2.12 |
Code |
<Cd> |
This element is mapped to 'Delivery channel' with an override option at PPP level. Mapping Precedence: Override Value entered at PPP will take precedence over the value appearing on invoices. |
This element is mapped to 'Delivery channel' with an override option at PPP level. Mapping Precedence: Override Value entered at PPP will take precedence over the value appearing on invoices. |
2.13 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
2.14 |
CategoryPurpose |
<CtgyPurp> |
Tag |
Tag |
2.15 |
Code |
<Cd> |
Maps to payment function. As supplier payments are integrated to AP, we will have the code as 'SUPP. |
Maps to payment function. As supplier payments are integrated to AP, we will have the code as 'SUPP. |
2.16 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
2.17 |
RequestedExecutionDate |
<ReqdExctnDt> |
Payment date |
Payment date |
2.18 |
PoolingAdjustmentDate |
<PoolgAdjstmntDt> |
Not supported |
Element not used - Not supported |
2.19 |
Debtor |
<Dbtr> |
Tag Maps to Disbursement bank account owning Legal Entity |
Tag Maps to Disbursement bank account owning Legal Entity |
9.1.0 |
Name |
<Nm> |
Disbursement Bank Account Legal entity Name |
Disbursement Bank Account Legal entity Name |
9.1.1 |
PostalAddress |
<PstlAdr> |
Tag |
Tag |
9.1.5 |
StreetName |
<StrtNm> |
Additional Optional Service - Not supported |
HZ_Locations Address line 1 |
9.1.6 |
BuildingNumber |
<BldgNb> |
Additional Optional Service - Not supported |
Bilaterally Determined (Optional element). Not supported |
9.1.7 |
PostCode |
<PstCd> |
Additional Optional Service - Not supported |
HZ_Locations postal code |
9.1.8 |
TownName |
<TwnNm> |
Additional Optional Service - Not supported |
HZ_Locations city |
9.1.9 |
CountrySubDivision |
<CtrySubDvsn> |
Additional Optional Service - Not supported |
HZ_Locations county, state/province |
9.1.10 |
Country |
<Ctry> |
HZ_Locations country. |
HZ_Locations country. |
9.1.11 |
AddressLine |
<AdrLine> |
HZ_Locations address1 ~ 4 |
Bilaterally Determined (Optional element). Not supported. In the initial release, we will support only structured address format. |
9.1.12 |
Identification |
<Id> |
Tag |
Tag |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Tag |
Tag |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Maps to Debtor BICorBEI entered in the Payment System Account Setting. |
Maps to Debtor BICorBEI entered in the Payment System Account Setting. |
9.1.15 |
Other |
<Othr> |
Tag |
Tag |
9.1.16 |
Identification |
<Id> |
Maps to ISO20022 Debtor BICOrBEI entered in the Payment System Account Setting. Else Legal Entity Registration number of the disbursement bank account legal entity is passed. |
Maps to ISO20022 Debtor BICOrBEI entered in the Payment System Account Setting. Else Legal Entity Registration number of the disbursement bank account legal entity is passed. |
9.1.17 |
SchemeName |
<SchmeNm> |
Tag |
Tag |
9.1.18 |
Code |
<Cd> |
AOS Element - Not supported |
Maps to ISO20022 Debtor ID Scheme Name |
9.1.19 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
9.1.20 |
Issuer |
<Issr> |
Not supported |
Element not used - Not supported |
9.1.21 |
PrivateIdentification |
<PrvtId> |
Not Supported. |
Element not used - Not supported |
2.20 |
DebtorAccount |
<DbtrAcct> |
Tag Maps to Disbursement bank account on payment |
Tag Maps to Disbursement bank account on payment |
1.1.0 |
Identification |
<Id> |
Tag |
Tag |
1.1.1 |
IBAN |
<IBAN> |
As per SEPA guidelines, only IBAN is allowed. So, this element is mapped to IBAN of disbursement bank account. |
This element is mapped to IBAN of disbursement bank account. |
1.1.2 |
Other |
<Othr> |
Tag |
Tag |
1.1.3 |
Identification |
<Id> |
Not supported |
Bank account number is populated if IBAN is not available. |
1.1.8 |
Type |
<Tp> |
Tag |
Tag |
1.1.9 |
Code |
<Cd> |
Additional Optional Service - Not supported |
Bank account type |
1.1.10 |
Proprietary |
<Prtry> |
Additional Optional Service - Not supported |
Not supported |
1.1.11 |
Currency |
<Ccy> |
This element is mapped to disbursement bank account currency. |
This element is mapped to disbursement bank account currency. |
1.1.12 |
Name |
<Nm> |
Additional Optional Service - Not supported |
Element not used - Not supported |
2.21 |
DebtorAgent |
<DbtrAgt> |
Tag |
Tag |
6.1.0 |
FinancialInstitutionIdentification |
<FinInstnId> |
Tag |
Tag |
6.1.1 |
BIC |
<BIC> |
As per SEPA guidelines, only BIC is allowed. So this element is mapped to BIC of disbursement bank account. |
BIC if available on the branch setup |
6.1.2 |
ClearingSystemMemberIdentification |
<ClrSysMmbId> |
Tag |
Tag |
6.1.3 |
ClearingSystemIdentification |
<ClrSysId> |
Tag |
Tag |
6.1.4 |
Code |
<Cd> |
Not supported as per SEPA guidelines |
Not supported |
6.1.5 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
6.1.6 |
MemberIdentification |
<MmbId> |
Not supported as per SEPA guidelines |
Branch Number if BIC is not available. |
6.1.7 |
Name |
<Nm> |
Not supported as per SEPA guidelines |
Element not used - Not supported |
6.1.8 |
PostalAddress |
<PstlAdr> |
|
|
6.1.17 |
Country |
<Ctry> |
Bank branch country. |
Bank branch country. |
6.1.25 |
BranchIdentification |
<BrnchId> |
|
|
6.1.26 |
Identification |
<Id> |
Not supported as per SEPA guidelines |
Mapped to Branch number of disbursement bank branch. |
6.1.27 |
Name |
<Nm> |
Not supported as per SEPA guidelines |
Element not used - Not supported |
2.23 |
UltimateDebtor |
<UltmtDbtr> |
Legal entity on invoice If the invoices included in payment have different invoice legal entities, then no value will be passed for ultimate debtor. |
Legal entity on invoice If there are multiple invoice legal entities, then no value will be passed for ultimate debtor. |
9.1.0 |
Name |
<Nm> |
Invoice legal entity - Name If the invoices included in payment have different invoice legal entities, then no value will be passed for ultimate debtor name. |
Invoice legal entity - Name If the invoices included in payment have different invoice legal entities, then no value will be passed for ultimate debtor name. |
9.1.1 |
PostalAddress |
<PstlAdr> |
Tag The postal address for ultimate debtor is not supported as its AOS element. |
Tag Not Supported. |
9.1.12 |
Identification |
<Id> |
Tag |
Tag |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Tag |
Tag |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Not supported. |
Not supported. |
9.1.15 |
Other |
<Othr> |
|
|
9.1.16 |
Identification |
<Id> |
In XLE, we have legal entity registration number. This registration number will be used for this element. If the invoices included in payment have different invoice legal entities, then no value will be passed for identification. |
In XLE, we have legal entity registration number. This registration number will be used for this element. If the invoices included in payment have different invoice legal entities, then no value will be passed for identification. |
9.1.17 |
SchemeName |
<SchmeNm> |
Not Supported |
Not Supported |
9.1.18 |
Code |
<Cd> |
Not supported |
Not supported |
9.1.19 |
Proprietary |
<Prtry> |
Not supported |
Not supported |
9.1.20 |
Issuer |
<Issr> |
Not supported |
Element not used - Not supported |
9.1.21 |
PrivateIdentification |
<PrvtId> |
Not Supported |
Element not used - Not supported |
2.24 |
ChargeBearer |
<ChrgBr> |
We will configure the value 'SLEV' directly into the source code. |
Bank Charge bearer field in manage installments. This element should not be displayed if the payment method is 'CHK'. |
2.25 |
ChargesAccount |
<ChrgsAcct> |
Additional Optional Service - Not supported |
Bilaterally Determined (Optional element). Not supported |
Credit Transfer Transaction Information Message Elements
The following table lists the credit transfer transaction information message elements and Payments data mapping information for SEPA and CGI versions of the ISO credit transfer message.
ISO Element Number | Message Element | <XML Tag> | SEPA Implementation Mapping | CGI Implementation Mapping |
---|---|---|---|---|
2.27 |
CreditTransferTransactionInformation |
<CdtTrfTxInf> |
|
|
2.28 |
PaymentIdentification |
<PmtId> |
Tag |
Tag |
2.29 |
InstructionIdentification |
<InstrId> |
Map to Payment ID |
Map to Payment ID |
2.30 |
EndToEndIdentification |
<EndToEndId> |
Mapped to payment reference number. |
Mapped to payment reference number. |
2.31 |
PaymentTypeInformation |
<PmtTpInf> |
The payment type information is supported in payment information block. |
The payment type information is supported in payment information block. |
2.42 |
Amount |
<Amt> |
Tag |
Tag |
2.43 |
InstructedAmount |
<InstdAmt Ccy="AAA"> |
Payment amount with the currency as 'EUR'. |
Payment amount. This element is used for all invoices where the transaction currency and payment currency is same. |
2.44 |
EquivalentAmount |
<EqvtAmt> |
Not supported. |
|
2.51 |
ChargeBearer |
<ChrgBr> |
This element is hard coded with the value as 'SLEV'. |
Charge bearer' field in manage installments. This element should not be displayed if the payment method is 'CHK'. |
2.52 |
ChequeInstruction |
<ChqInstr> |
Additional Optional Service - Not supported |
Not supported. |
2.58 |
DeliveryMethod |
<DlvryMtd> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.70 |
UltimateDebtor |
<UltmtDbtr> |
Tag. This data element is populated in the payment information block. |
Tag |
2.71 |
Intermediary Agent1 |
<IntrmyAgt1> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.72 |
Intermediary Agent1Account |
<IntrmyAgt1Acct> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
2.73 |
Intermediary Agent2 |
<IntrmyAgt2> |
Additional Optional Service.Not supported. |
Element not used. Not supported. |
2.77 |
CreditorAgent |
<CdtrAgt> |
Tag |
Tag |
6.1.0 |
FinancialInstitutionIdentification |
<FinInstnId> |
Tag |
Tag |
6.1.1 |
BIC |
<BIC> |
As per SEPA guidelines, only BIC is allowed. This element is mapped to BIC of payee bank account. |
This element is mapped to BIC of payee bank account. |
6.1.2 |
ClearingSystemMemberIdentification |
<ClrSysMmbId> |
|
|
6.1.3 |
ClearingSystemIdentification |
<ClrSysId> |
|
|
6.1.4 |
Code |
<Cd> |
Not supported. |
Not supported. |
6.1.5 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
6.1.6 |
MemberIdentification |
<MmbId> |
Not supported. |
Mapped to Payee Bank Branch number. |
6.1.7 |
Name |
<Nm> |
Not supported. |
Mapped to Payee Bank Branch Name. |
6.1.8 |
PostalAddress |
<PstlAdr> |
Not supported. |
Not supported. |
6.1.19 |
Other |
<Othr> |
Not supported. |
Element not used. Not supported. |
6.1.20 |
Identification |
<Id> |
Not supported. |
Element not used. Not supported. |
6.1.21 |
SchemeName |
<SchmeNm> |
Not supported. |
Element not used. Not supported. |
6.1.22 |
Code |
<Cd> |
Not supported. |
Element not used. Not supported. |
6.1.23 |
Proprietary |
<Prtry> |
Not supported. |
Element not used. Not supported. |
6.1.24 |
Issuer |
<Issr> |
Not supported. |
Element not used. Not supported. |
6.1.25 |
BranchIdentification |
<BrnchId> |
|
|
6.1.26 |
Identification |
<Id> |
Not supported. |
This element is mapped to BIC of payee bank account. |
2.78 |
CreditorAgentAccount |
<CdtrAgtAcct> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.79 |
Creditor |
<Cdtr> |
Tag |
Tag |
9.1.0 |
Name |
<Nm> |
Payee name |
Payee name |
9.1.1 |
PostalAddress |
<PstlAdr> |
Tag |
Tag |
9.1.2 |
AddressType |
<AdrTp> |
Not supported. |
Element not used. Not supported. |
9.1.3 |
Department |
<Dept> |
Not supported. |
Optional element. Not supported. |
9.1.4 |
SubDepartment |
<SubDept> |
Not supported. |
Optional element. Not supported. |
9.1.5 |
StreetName |
<StrtNm> |
Not supported. |
HZ_Locations Address line 1 |
9.1.6 |
BuildingNumber |
<BldgNb> |
Not supported. |
Optional element. Not supported. |
9.1.7 |
PostCode |
<PstCd> |
Not supported. |
HZ_Locations postal code |
9.1.8 |
TownName |
<TwnNm> |
Not supported. |
HZ_Locations city |
9.1.9 |
CountrySubDivision |
<CtrySubDvsn> |
Not supported. |
HZ_Locations county, state/province |
9.1.10 |
Country |
<Ctry> |
HZ_Locations country. |
HZ_Locations country |
9.1.11 |
AddressLine |
<AdrLine> |
HZ_Locations address1 ~ 4 The number of address lines vary for each legislation address style. |
Bilaterally Determined (Optional element) - Not supported. Only structured address format is supported. |
9.1.12 |
Identification |
<Id> |
Tag |
Tag |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Tag |
Tag |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Not supported. |
Not supported. |
9.1.15 |
Other |
<Othr> |
|
|
9.1.16 |
Identification |
<Id> |
The Identification of Creditor is populated in the following order: 1. Supplier Tax registration number, else 2. Supplier Legal entity registration number, else 3. Supplier number, else 4. Party number |
The Identification of Creditor is populated in the following order: 1. Supplier Tax registration number, else 2. Supplier Legal entity registration number, else 3. Supplier number, else 4. Party number |
9.1.17 |
SchemeName |
<SchmeNm> |
|
|
9.1.18 |
Code |
<Cd> |
Not supported. |
Not supported. |
9.1.19 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
9.1.20 |
Issuer |
<Issr> |
Not supported. |
Not supported. |
9.1.21 |
PrivateIdentification |
<PrvtId> |
These elements are supported only in the case of expense payments to employees. |
These elements are supported only in the case of expense payments to employees. |
9.1.22 |
DateAndPlaceOfBirth |
<DtAndPlcOfBirth> |
Employee date and place of birth |
Employee date and place of birth. |
9.1.23 |
BirthDate |
<BirthDt> |
Employee date of birth - HRMS. |
Employee date of birth - HRMS. |
9.1.24 |
ProvinceOfBirth |
<PrvcOfBirth> |
Not supported. |
Optional element. Not supported. |
9.1.25 |
CityOfBirth |
<CityOfBirth> |
Not supported. |
Optional element. Not supported. |
9.1.26 |
CountryOfBirth |
<CtryOfBirth> |
Country of birth - HRMS. |
Country of birth - HRMS. |
9.1.27 |
Other |
<Othr> |
|
|
9.1.28 |
Identification |
<Id> |
Mapped to national identifier of employee. |
Mapped to national identifier of employee. |
9.1.29 |
SchemeName |
<SchmeNm> |
Tag Not supported |
Tag. Not supported. |
9.1.30 |
Code |
<Cd> |
Not supported. |
Not Supported. |
9.1.31 |
Proprietary |
<Prtry> |
Not supported. |
Optional element. Not supported. |
9.1.32 |
Issuer |
<Issr> |
Not supported. |
Optional element. Not supported. |
9.1.33 |
CountryOfResidence |
<CtryOfRes> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
9.1.34 |
ContactDetails |
<CtctDtls> |
Tag. Not supported. |
Tag. Not supported. |
2.80 |
CreditorAccount |
<CdtrAcct> |
Tag |
Tag |
1.1.0 |
Identification |
<Id> |
Tag. Only IBAN is used. |
Tag - Either IBAN or Other tag is populated |
1.1.1 |
IBAN |
<IBAN> |
As per SEPA guidelines, only IBAN is allowed. This element is mapped to IBAN of payee bank account. |
This element is mapped to IBAN of payee bank account. |
1.1.2 |
Other |
<Othr> |
|
|
1.1.3 |
Identification |
<Id> |
Not supported. |
Bank account number of the Payee bank account. |
1.1.4 |
SchemeName |
<SchmeNm> |
|
Bilaterally Determined (Optional element). Not supported. |
1.1.5 |
Code |
<Cd> |
Not supported. |
This element is hard coded with value as 'BBAN' based on ISO external code list. |
1.1.6 |
Proprietary |
<Prtry> |
Not supported. |
Bilaterally Determined (Optional element). Not supported. |
1.1.7 |
Issuer |
<Issr> |
Not supported. |
Bilaterally Determined (Optional element). Not supported. |
1.1.8 |
Type |
<Tp> |
|
|
1.1.9 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
1.1.10 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
1.1.11 |
Currency |
<Ccy> |
Bank Account Currency. |
Bank Account Currency. |
1.1.12 |
Name |
<Nm> |
Payee Bank account name |
Payee Bank account name |
2.81 |
UltimateCreditor |
<UltmtCdtr> |
Tag |
Tag |
9.1.0 |
Name |
<Nm> |
Remit to supplier value if remit to supplier is different from the supplier. |
Remit to supplier value if remit to supplier is different from the supplier. |
9.1.1 |
PostalAddress |
<PstlAdr> |
Tag |
Tag |
9.1.2 |
AddressType |
<AdrTp> |
Element not used - Not supported |
Element not used. Not supported. |
9.1.3 |
Department |
<Dept> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.4 |
SubDepartment |
<SubDept> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.5 |
StreetName |
<StrtNm> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.6 |
BuildingNumber |
<BldgNb> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.7 |
PostCode |
<PstCd> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.8 |
TownName |
<TwnNm> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.9 |
CountrySubDivision |
<CtrySubDvsn> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.10 |
Country |
<Ctry> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.11 |
AddressLine |
<AdrLine> |
Optional element. Not supported. |
Optional element. Not supported. |
9.1.12 |
Identification |
<Id> |
Tag |
Tag |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Tag |
Tag |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Not supported. |
Not supported. |
9.1.15 |
Other |
<Othr> |
Tag |
Tag |
9.1.16 |
Identification |
<Id> |
The Identification of remit to supplier is provided as follows: 1. Tax registration number, else 2. Legal entity registration number, else 3. Supplier number, else 4. Party number, else 5. First party reference |
The Identification of remit to supplier is provided as follows: 1. Tax registration number, else 2. Legal entity registration number, else 3. Supplier number, else 4. Party number, else 5. First party reference |
9.1.17 |
SchemeName |
<SchmeNm> |
|
|
9.1.18 |
Code |
<Cd> |
Not supported. |
Not supported. |
9.1.19 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
9.1.20 |
Issuer |
<Issr> |
Not supported. |
Not supported. |
9.1.21 |
PrivateIdentification |
<PrvtId> |
Not supported. |
Not supported. |
9.1.22 |
DateAndPlaceOfBirth |
<DtAndPlcOfBirth> |
Not supported. |
Not supported. |
9.1.23 |
BirthDate |
<BirthDt> |
Not supported. |
Not supported. |
9.1.24 |
ProvinceOfBirth |
<PrvcOfBirth> |
Not supported. |
Not supported. |
9.1.25 |
CityOfBirth |
<CityOfBirth> |
Not supported. |
Not supported. |
9.1.26 |
CountryOfBirth |
<CtryOfBirth> |
Not supported. |
Not supported. |
9.1.27 |
Other |
<Othr> |
Not supported. |
Not supported. |
9.1.28 |
Identification |
<Id> |
Not supported. |
Not supported. |
9.1.29 |
SchemeName |
<SchmeNm> |
Not supported. |
Not supported. |
9.1.30 |
Code |
<Cd> |
Not supported. |
Not supported. |
9.1.31 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
9.1.32 |
Issuer |
<Issr> |
Not supported. |
Not supported. |
9.1.33 |
CountryOfResidence |
<CtryOfRes> |
Not supported. |
Not supported. |
9.1.34 |
ContactDetails |
<CtctDtls> |
Not supported. |
Not supported. |
9.1.35 |
NamePrefix |
<NmPrfx> |
Not supported. |
Not supported. |
9.1.36 |
Name |
<Nm> |
Not supported. |
Not supported. |
9.1.37 |
PhoneNumber |
<PhneNb> |
Not supported. |
Not supported. |
9.1.38 |
MobileNumber |
<MobNb> |
Not supported. |
Not supported. |
9.1.39 |
FaxNumber |
<FaxNb> |
Not supported. |
Not supported. |
9.1.40 |
EmailAddress |
<EmailAdr> |
Not supported. |
Not supported. |
9.1.41 |
Other |
<Othr> |
Not supported. |
Not supported. |
2.82 |
InstructionForCreditorAgent |
<InstrForCdtrAgt> |
Tag Additional Optional Service. Not supported. |
Tag |
2.83 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Mapped to bank instruction (2) in payment process profile. The value should be displayed only if the payment method element in payment information block or credit transaction record contains the value as 'TRF'. |
2.84 |
InstructionInformation |
<InstrInf> |
Additional Optional Service. Not supported. |
Mapped to bank instruction details in payment process profile. The value should be displayed only if a.. The payment method element in payment information block or credit transaction record contains the value as TRF b. 'Code element contains a value. |
2.85 |
InstructionForDebtorAgent |
<InstrForDbtrAgt> |
Additional Optional Service. Not supported. |
Maps to bank instruction (1) in payment process profile. The value is displayed only if the payment method element in payment information block or credit transaction record contains the value as 'TRF'. |
2.86 |
Purpose |
<Purp> |
Tag |
Tag |
2.87 |
Code |
<Cd> |
Maps to payment reason. |
Maps to payment reason |
2.88 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
2.89 |
RegulatoryReporting |
<RgltryRptg> |
Tag Additional Optional Service. Not supported. |
Tag Optional element. Not supported. |
2.90 |
Tax |
<Tax> |
Additional Optional Service. Not supported. |
Tag This tag is populated only if there is any withholding tax deducted. |
13.1.0 |
Creditor |
<Cdtr> |
Additional Optional Service. Not supported. |
Tax invoice supplier |
13.1.1 |
TaxIdentification |
<TaxId> |
Additional Optional Service. Not supported. |
Tax invoice supplier tax registration number |
13.1.2 |
RegistrationIdentification |
<RegnId> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.3 |
TaxType |
<TaxTp> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.4 |
Debtor |
<Dbtr> |
Additional Optional Service. Not supported. |
Disbursement bank legal entity |
13.1.5 |
TaxIdentification |
<TaxId> |
Additional Optional Service. Not supported. |
Legal entity tax registration number to be referred from XLE. |
13.1.8 |
Authorization |
<Authstn> |
Additional Optional Service. Not supported |
Optional element. Not supported. |
13.1.32 |
Rate |
<Rate> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.33 |
TaxableBaseAmount |
<TaxblBaseAmt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.34 |
TotalAmount |
<TtlAmt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.35 |
Details |
<Dtls> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.36 |
Period |
<Prd> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
13.1.39 |
FromToDate |
<FrToDt> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.91 |
RelatedRemittanceInformation |
<RltdRmtInf> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.92 |
RemittanceIdentification |
<RmtId> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.93 |
RemittanceLocationMethod |
<RmtLctnMtd> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.94 |
RemittanceLocationElectronicAddress |
<RmtLctnElctrncAdr> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.95 |
RemittanceLocationPostalAddress |
<RmtLctnPstlAdr> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.96 |
Name |
<Nm> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.97 |
Address |
<Adr> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
2.98 |
RemittanceInformation |
<RmtInf> |
Out of box solution contains mapping for both structured remittance information. |
Out of box solution contains mapping for both structured remittance information. |
2.99 |
Unstructured |
<Ustrd> |
Not supported. |
Not Supported. |
2.100 |
Structured |
<Strd> |
|
Tag |
2.101 |
ReferredDocumentInformation |
<RfrdDocInf> |
Additional Optional Service. Not supported. |
Tag |
2.102 |
Type |
<Tp> |
Additional Optional Service. Not supported. |
Tag |
2.103 |
CodeOrProprietary |
<CdOrPrtry> |
Additional Optional Service. Not supported. |
Tag |
2.104 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Map to document type for the following cases: Document Type ISO Document Type STANDARD This is Commercial Invoice. For mapping 'CINV', a value is passed to the message. CREDIT This is the CreditNote. For mapping 'CREN', a value is passed. DEBIT This is the DebitNote. For mapping ' DEBN', a value is passed. |
2.105 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.106 |
Issuer |
<Issr> |
Additional Optional Service. Not supported. |
Supplier Name |
2.107 |
Number |
<Nb> |
Additional Optional Service. Not supported. |
Document Reference Number (Invoice number) |
2.108 |
RelatedDate |
<RltdDt> |
Additional Optional Service. Not supported. |
Document Date (Invoice Date) |
2.109 |
ReferredDocumentAmount |
<RfrdDocAmt> |
Tag |
Tag |
2.110 |
DuePayableAmount |
<DuePyblAmt Ccy="AAA"> |
Additional Optional Service - Not supported |
Total Document Amount (Invoice Amount) |
2.111 |
DiscountAppliedAmount |
<DscntApldAmt Ccy="AAA"> |
Additional Optional Service - Not supported |
Discount taken amount |
2.112 |
CreditNoteAmount |
<CdtNoteAmt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.113 |
TaxAmount |
<TaxAmt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Total Document Tax amount |
2.114 |
AdjustmentAmountAndReason |
<AdjstmntAmtAndRsn> |
Tag Additional Optional Service. Not supported. |
TagBilaterally Determined (Optional element). Not supported. |
2.115 |
Amount |
<Amt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.116 |
CreditDebitIndicator |
<CdtDbtInd> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.117 |
Reason |
<Rsn> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.118 |
AdditionalInformation |
<AddtlInf> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
2.119 |
RemittedAmount |
<RmtdAmt Ccy="AAA"> |
Additional Optional Service. Not supported. |
Payment Amount |
2.120 |
CreditorReferenceInformation |
<CdtrRefInf> |
Tag |
Tag This tag is only passed only if the Unique Remittance Identifier is entered on invoice. Else only Referred Document information is passed. |
2.121 |
Type |
<Tp> |
Tag |
Tag |
2.122 |
CodeOrProprietary |
<CdOrPrtry> |
Tag |
Tag |
2.123 |
Code |
<Cd> |
Based on 'Document Type3 code' and SEPA guidelines. The hard coded value 'SCOR' is passed for this element. |
Not supported. |
2.124 |
Proprietary |
<Prtry> |
Not supported. |
Not supported. |
2.125 |
Issuer |
<Issr> |
Invoice supplier name. |
Invoice supplier name. This tag is only passed only if the Unique Remittance Identifier is entered on invoice. Else only Referred Document information is passed. |
2.126 |
Reference |
<Ref> |
Unique Remittance Identifier (URI) is passed. If URI is not available, then Invoice number should be displayed. |
The Creditor Reference Code is passed only if the URI is entered on the payment installments. Else only the reference document number details are passed. |
2.127 |
Supplier |
<Invcr> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
9.1.0 |
Name |
<Nm> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
9.1.1 |
PostalAddress |
<PstlAdr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.2 |
AddressType |
<AdrTp> |
Additional Optional Service - Not supported |
Element not used. Not supported. |
9.1.3 |
Department |
<Dept> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.4 |
SubDepartment |
<SubDept> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.5 |
StreetName |
<StrtNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.6 |
BuildingNumber |
<BldgNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.7 |
PostCode |
<PstCd> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.8 |
TownName |
<TwnNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.9 |
CountrySubDivision |
<CtrySubDvsn> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.10 |
Country |
<Ctry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.11 |
AddressLine |
<AdrLine> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.12 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.15 |
Other |
<Othr> |
Additional Optional Service - Not supported |
Element not used. Not supported. |
9.1.16 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.17 |
SchemeName |
<SchmeNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.18 |
Code |
<Cd> |
Additional Optional Service - Not supported |
Element not used. Not supported. |
9.1.19 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.20 |
Issuer |
<Issr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.21 |
PrivateIdentification |
<PrvtId> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.22 |
DateAndPlaceOfBirth |
<DtAndPlcOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.23 |
BirthDate |
<BirthDt> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.24 |
ProvinceOfBirth |
<PrvcOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported |
9.1.25 |
CityOfBirth |
<CityOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.26 |
CountryOfBirth |
<CtryOfBirth> |
Additional Optional Service Not supported. |
Element not used. Not supported. |
9.1.27 |
Other |
<Othr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.28 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.29 |
SchemeName |
<SchmeNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.30 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.31 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.32 |
Issuer |
<Issr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.33 |
CountryOfResidence |
<CtryOfRes> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.34 |
ContactDetails |
<CtctDtls> |
Additional Optional Service. Not supported. |
Element not used. Not supported. . |
9.1.35 |
NamePrefix |
<NmPrfx> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.36 |
Name |
<Nm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.37 |
PhoneNumber |
<PhneNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.38 |
MobileNumber |
<MobNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.39 |
FaxNumber |
<FaxNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.40 |
EmailAddress |
<EmailAdr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.41 |
Other |
<Othr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
2.128 |
Invoiced |
<Invcee> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
9.1.0 |
Name |
<Nm> |
Additional Optional Service. Not supported. |
Bilaterally Determined (Optional element). Not supported. |
9.1.1 |
PostalAddress |
<PstlAdr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.2 |
AddressType |
<AdrTp> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.3 |
Department |
<Dept> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.4 |
SubDepartment |
<SubDept> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.5 |
StreetName |
<StrtNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.6 |
BuildingNumber |
<BldgNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.7 |
PostCode |
<PstCd> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.8 |
TownName |
<TwnNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.9 |
CountrySubDivision |
<CtrySubDvsn> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.10 |
Country |
<Ctry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.11 |
AddressLine |
<AdrLine> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.12 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used - Not supported. |
9.1.13 |
OrganizationIdentification |
<OrgId> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.14 |
BICOrBEI |
<BICOrBEI> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.15 |
Other |
<Othr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.16 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.17 |
SchemeName |
<SchmeNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.18 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.19 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.20 |
Issuer |
<Issr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.21 |
PrivateIdentification |
<PrvtId> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.22 |
DateAndPlaceOfBirth |
<DtAndPlcOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.23 |
BirthDate |
<BirthDt> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.24 |
ProvinceOfBirth |
<PrvcOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.25 |
CityOfBirth |
<CityOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.26 |
CountryOfBirth |
<CtryOfBirth> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.27 |
Other |
<Othr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.28 |
Identification |
<Id> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.29 |
SchemeName |
<SchmeNm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.30 |
Code |
<Cd> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.31 |
Proprietary |
<Prtry> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.32 |
Issuer |
<Issr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.33 |
CountryOfResidence |
<CtryOfRes> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.34 |
ContactDetails |
<CtctDtls> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.35 |
NamePrefix |
<NmPrfx> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.36 |
Name |
<Nm> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.37 |
PhoneNumber |
<PhneNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.38 |
MobileNumber |
<MobNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.39 |
FaxNumber |
<FaxNb> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.40 |
EmailAddress |
<EmailAdr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
9.1.41 |
Other |
<Othr> |
Additional Optional Service. Not supported. |
Element not used. Not supported. |
2.129 |
AdditionalRemittanceInformation |
<AddtlRmtInf> |
Additional Optional Service. Not supported. |
Optional element. Not supported. |
Oracle Payments Disbursement Predefined Reports
Oracle Payments provides the following disbursement predefined reports:
-
Disbursement Accompanying Letter Formats
-
Disbursement Payment File Formats
-
Disbursement Payment File Register Formats
-
Disbursement Payment Process Request Status Report Formats
-
Disbursement Positive Pay File Formats
-
Disbursement Separate Remittance Advice Formats
All of the preceding reports are:
-
Processes that result in a formatted file
-
Formatted using a specific template
-
Manually generated, if opted, using the Scheduled Processes page
-
Automatically generated, if opted, using setup pages
Running Disbursement Reports Manually
To manually run Payments reports, perform the following steps from the Scheduled Processes page using the Navigator menu.
-
Click the Schedule New Process button.
-
Search on the Process Name.
-
Enter the applicable parameters.
-
Enter the applicable process options and schedule.
-
Click the Submit button.
Running Disbursement Reports Automatically
The following table lists disbursement reports with their corresponding processes that automatically run after you select specific options on the applicable page.
Name of Report and Process | Report Description | Options You Select for the Automatic Process | Output |
---|---|---|---|
Report: Disbursement Payment File Formats Process: Create Printed Payment Files or Process: Create Electronic Payment Files |
Groups payments into payment files, and then validates, formats, and prints the payment documents (printed payment files) or transmits (electronic payment files) the payment to the payment system. |
Location: Submit Payment Process Request page. Options to select:
|
Printed payment documents, such as checks or promissory notes. or Electronic payment files. |
Report: Disbursement Accompanying Letter Formats Process: Payment File Accompanying Letter |
Creates an accompanying letter for a payment file that your company either prints and mails to the bank, along with the payment file on a disk or manually transmits to the bank, along with the payment file. |
Location: Create Payment Process Profile page, Payment File tab. Option to select: Payment File Accompanying Letter format. |
Document. |
Report: Disbursement Positive Pay File Formats Process: Create Positive Pay File |
Creates a document that your company transmits to its payment system or bank to inform it of payments made by check. |
Location: Create Payment Process Profile page, Reporting tab, Positive Pay section. Option to select: Automatically transmit file check box. |
Document. |
Report: Disbursement Separate Remittance Advice Formats Process: Send Separate Remittance Advice |
Creates notices that can be faxed, emailed, or printed and mailed to external payees that list the invoices your company has electronically paid to the external payee's bank account. |
Location: Create Payment Process Profile page, Separate Remittance Advice section. Option to select: Automatically submit when payments are confirmed check box. |
Document. |
Report: Disbursement Payment File Register Formats Process: Payment File Register |
Creates a report displaying the contents of a payment file, which your company keeps for its records. |
Location: Create Payment Process Profile page, Reporting tab, Payment File Register section. Option to select: Automatically submit when payments are complete check box. |
Document. |
Report: Disbursement Payment Process Request Status Report Formats Process: Payment Process Request Status Report |
Creates a report that displays the contents and status of a payment process request, which your company reviews online or prints. |
Location: Manage Disbursement System Options page. Option to select: Automatically submit at payment process request completion check box. |
Document. |
Payment Process Request Status Reports
This topic includes details about the Payment Process Request Status report.
Overview
The Payment Process Request Status report is a predefined disbursement report that displays the details of all the payments generated in a specific payment process request. You can use the report to verify the payments created in a payment process request.
The following figure is an example of a 3-page Payment Process Request Status report.



Key Insights
The following table lists the difference between the formal Payment Process Request Status report name and the process name that you must use to generate the report on the Scheduled Processes page.
Report Name | Process Name | Output |
---|---|---|
Disbursement Payment Process Request Status Report Formats. |
Payment Process Request Status Report |
PDF file. |
Automatic Generation of the Payment Process Request Status Report
To automatically generate the Payment Process Request Status report, perform the following steps:
-
Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Disbursement System Options > Go to Task > Manage Disbursement System Options page.
-
On the Manage Disbursement System Options page, Payment Process Request Status Report section, perform the following steps:
-
From the Format choice list, select Payment Process Request Status Report Format.
-
Select the Automatically submit at payment process request completion check box.
-
Manual Generation of the Payment Process Request Status Report
To manually generate the Payment Process Request Status report from within Oracle Fusion Payments, perform the following steps:
-
Navigate: Navigator > Payables > Payments link.
-
In the Payments Tasks pane, click the Submit Payment Process Request link to open the Submit Payment Process Request page.
-
Select the Payment and Processing Options tab.
-
In the Processing Options section, select the Create payment files immediately check box.
-
Navigate: Navigator > Tools > Scheduled Processes link. The Scheduled Processes page appears.
-
Click the Schedule New Process button. The Schedule New Process dialog box appears.
-
From the Name choice list, select Payment Process Request Status Report. If you don't see Payment Process Request Status Report in the choice list, click the Search link to display the Search and Select: Name dialog box.
-
If you don't see Payment Process Request Status Report in the choice list, enter the following in the Name field using headline capitals as shown here: Payment Process Request Status Report, and click Search.
-
Select the resulting row and click OK.
-
In the Schedule New Process dialog box, click OK. The Process Details dialog box appears.
-
Select the applicable parameters and click Submit. A confirmation message displays with a process ID.
Tip: Write down or remember the process ID. -
In the Process ID field on the Scheduled Processes page, enter the process ID and click Search.
-
Click the Refresh icon until the result displays in the Search Results section.
-
Select the resulting row in the Search Results section to display additional details on the Scheduled Processes page.
-
In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> .PDF output file.
Report Parameters
The following table describes the process parameters.
Name | Description |
---|---|
Payment Process Request |
The payment process request for which the Payment Process Request Status report is generated. |
Format |
Name of the applicable format, which is Payment Process Request Status Report Format. |
Frequently Asked Questions
The following table lists frequently asked questions and provides answers about the Payment Process Request Status report.
FAQ | Answer |
---|---|
How do I find this report? |
You can find the Payment Process Request Status report by selecting the 1 more link in the Log and Output section in the Search Results section on the Scheduled Processes page. |
Who uses this report? |
|
When do I use this report? |
The Payment Process Request Status report is used when you want to verify the payments created in a payment process request. |
What can I do with this report? |
You can:
|
What type of report is this? |
Oracle Business Intelligence Publisher |
Payment File Register Reports
This topic includes details about the Payment File Register report.
Overview
The Payment File Register report is a predefined disbursement report that displays details of payments that are included in a payment file. You can retain this report for your records.
The following figure illustrates an example of the Payment File Register report.

Key Insights
The following table lists the difference between the formal Payment File Register report name and the process name that you must use to manually generate the report on the Scheduled Processes page.
Report Name | Process Name | Output |
---|---|---|
Disbursement Payment File Register Formats |
Payment File Register |
.PDF file |
Generation of the Payment File Register Report
To generate the Payment File Register report, perform the following steps:
-
Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Payment Process Profiles > Go to Task > Manage Payment Process Profiles page > Create button.
-
On the Create Payment Process Profile page, Reporting tab, select the Automatically submit when payments are confirmed check box.
-
Navigate: Navigator > Tools > Scheduled Processes link. The Scheduled Processes page appears.
-
Click the Schedule New Process button. The Schedule New Process dialog box appears.
-
From the Name choice list, select Payment File Register. If you don't see Payment File Register in the choice list, click the Search link to display the Search and Select: Name dialog box.
-
If you don't see Payment File Register in the choice list, enter the following in the Name field in headline capitals as shown here: Payment File Register, and click Search.
-
Select the resulting row and click OK.
-
In the Schedule New Process dialog box, click OK. The Process Details dialog box appears.
-
From the Payment File choice list, select the applicable payment file.
-
From the Format choice list, select Payment File Register Format and click Submit. A confirmation message displays with a process ID.
Tip: Write down or remember the process ID. -
In the Process ID field on the Scheduled Processes page, enter the process ID and click Search. The result displays in the Search Results section
-
Select the resulting row in the Search Results section to display additional details on the page.
-
In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> .PDF output file.
Report Parameters
The following table describes the process parameters of the Payment File Register report.
Name | Description |
---|---|
Payment File |
Payment file for which you are generating the Payment File Register report. |
Format |
Name of the applicable payment format, which is Payment File Register Format. |
Frequently Asked Questions
The following table lists frequently asked questions and provides answers about the Payment File Register report.
FAQ | Answer |
---|---|
How do I find this report? |
You can find the Payment File Register report by selecting the 1 morelink in the Log and Output section in the Search Results section on the Scheduled Processes page. |
Who uses this report? |
|
When do I use this report? |
The Payment File Register report is used when you want to retain a record of the payments in a payment file. |
What can I do with this report? |
You can:
|
What type of report is this? |
Oracle Business Intelligence Publisher |
Separate Remittance Advice Reports
This topic includes details about the Separate Remittance Advice report.
Overview
The Separate Remittance Advice report is a predefined disbursement report that's faxed, emailed as a PDF attachment, or printed and mailed to a supplier, which lists the invoices you paid.
This image illustrates an example of the Separate Remittance Advice report.

Key Insights
This table lists the distinction between the formal Separate Remittance Advice report name and the process name.
Report Name | Process Name | Output |
---|---|---|
Disbursement Separate Remittance Advice Formats |
Send Separate Remittance Advice |
Emailed as a PDF attachment or as HTML in the body of the email |
Automatic Generation of the Separate Remittance Advice Report
To automatically generate the Separate Remittance Advice report, complete these steps:
-
In the Setup and Maintenance work area, select:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Payment Process Profiles
-
-
On the Manage Payment Process Profiles page, click the Create icon.
-
On the Create Payment Process Profile page, Reporting tab, Separate Remittance Advice section, from the Format choice list, select Separate Remittance Advice Format.
-
Select the Automatically submit when payments are confirmed check box.
-
Optionally, select a condition for which the Separate Remittance Advice report is generated.
-
Select how you want the Separate Remittance Advice report delivered to the supplier, whether by email, as a PDF attachment to an email, faxed, or printed and sent by the postal service.
Specification of Delivery Method on Supplier Site
To specify the delivery method of the Separate Remittance Advice report on a supplier site, complete these steps:
-
Navigate to: Navigator > Procurement > Suppliers link > Manage Suppliers link > Search for applicable supplier > Supplier link > Sites tab > Site link > Edit Site page.
-
Select the Payments tab.
-
Select the Payment Attributes tab.
-
Select the Separate Remittance Advice Delivery tab.
-
From the Remittance Advice Delivery Method choice list, optionally select Printed, Fax, Email, or Email with PDF as attachment. The latter option lets you attach the Separate Remittance Advice report to an email as a PDF attachment.
-
In the Remittance Advice Delivery Email ID field, you can enter single or multiple emails. If you enter multiple emails, separate them by a comma.
-
Generation of the Separate Remittance Advice Report
To manually generate the Separate Remittance Advice report, complete these steps:
-
In the Setup and Maintenance work area, select:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Payment Process Profiles
-
-
On the Manage Payment Process Profiles page, click the Create icon.
-
On the Create Payment Process Profile page, Reporting tab, Separate Remittance Advice section, from the Format choice list, select Separate Remittance Advice Format.
-
Optionally, select the Allow multiple copies for payment file check box to generate multiple copies of the Separate Remittance Advice report.
-
Optionally, select a condition for which the Separate Remittance Advice report is generated.
-
Select how you want the Separate Remittance Advice report delivered to the supplier, whether by email, as a PDF attachment to an email, faxed, or printed and sent by the postal service.
-
Navigate to: Navigator > Payables > Payments.
-
In the Tasks pane, click the Send Separate Remittance Advice link. The parameters page for the Separate Remittance Advice report appears.
-
Select applicable parameters from the choice lists and click Submit. A confirmation message displays with a process ID.
Note: Write down or remember the process ID. -
Navigate to: Navigator > Tools > Scheduled Processes.
-
In the Process ID field on the Scheduled Processes page, enter the process ID and click Search. The result displays in the Search Results section.
-
Select the resulting row in the Search Results section to display additional details on the page.
-
In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> PDF output file.
Report Parameters
The following table describes the process parameters.
Name | Description |
---|---|
Payment File |
Payment file for which you're generating the Separate Remittance Advice report. |
Format |
Choice list that provides all formats defined as Separate Remittance Advice Format or as Separate Remittance Advice Report that you can use to generate the report. |
Payment Reference From |
Payment reference number generated by Payments, which identifies the starting payment within the payment file. |
Payment Reference To |
Payment reference number generated by Payments, which identifies the ending payment within the payment file. |
Frequently Asked Questions
The following table lists frequently asked questions and provides answers about the Separate Remittance Advice report.
FAQ | Answer |
---|---|
How do I find this report? |
You can find the Separate Remittance Advice report by selecting the 1 more link in the Log and Output section in the Search Results section on the Scheduled Processes page. |
Who uses this report? |
|
When do I use this report? |
The Separate Remittance Advice report is used when you make payments to a supplier, whether by check or electronically. |
What can I do with this report? |
You can:
|
What type of report is this? |
Oracle Business Intelligence Publisher |
Positive Pay Reports
This topic includes details about the Positive Pay report.
Overview
The Positive Pay report is a predefined disbursement report that lists checks issued by your organization with their corresponding payee names, amounts, and currency. Since the report is included in the electronic transmission to your payment system or bank, it prevents the payment of fraudulent checks, since unauthorized payments aren't listed on the Positive Pay report.
The following figure is an example of a Positive Pay report.

Key Insights
The following table lists the difference between the formal Positive Pay report name and the process name.
Report Name | Process Name | Output |
---|---|---|
Disbursement Positive Pay File Formats |
Create Positive Pay File |
Document |
Prerequisites for Positive Pay Report Generation
Before you can generate a Positive Pay report, you must complete these prerequisite steps:
-
Create a payment process profile.
-
In the Setup and Maintenance work area, select:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Payment Process Profiles
-
-
On the Manage Payment Process Profiles page, click the Create icon.
-
On the Create Payment Process Profile page, enter values on the Usage Rules tab.
-
On the Payment System tab, configure a payment system account by entering values in these fields:
-
Payment System Account
-
Configuration Profile
-
Payment File Transmission Configuration
-
From Date and To Date
-
-
-
-
Create a transmission configuration.
-
In the Setup and Maintenance work area, select:
-
Offering: Financials
-
Functional Area: Payments
-
Task: Manage Transmission Configurations
-
-
On the Manage Transmission Configurations page from the Select Protocol choice list, select a protocol and click Create.
-
On the Create Transmission Configurations page, enter any of these dynamic naming attributes in the Value field for the Sent File Name parameter:
-
&REQUESTID
Request ID refers to the process ID of the Create Positive Pay File process
-
&DATE
Date is displayed in YYYYMMDD format.
-
&TIME
Time is displayed in HHMMSS format.
For example, if you specify dynamic naming for the transmitted file as &REQUESTID_&DATE_&TIME, then for a process ID of 123456 run on October 20, 2019 at 09:10:45, the file name of the transmitted file is 123456_20191020_091045.
Note: The dynamic naming attributes in the Value field for the Sent File Name parameter on the transmission configuration is honored only when you don't specify a file prefix or a file extension, or both on the payment process profile. If naming attributes are specified at both the payment process profile and the transmission configuration, the setup at the payment process profile always takes precedence. -
-
On the Create Transmission Configuration page, you can use a static naming convention to name the transmitted positive pay files. Enter any of the following combinations in the Sent File Name parameter:
-
A static naming attribute
-
One or more dynamic naming attributes
-
A combination of a static naming attribute and one or more dynamic naming attributes
Note: If no naming convention is specified, then the default file extension is REQUESTID.file extension. -
-
Automatically Generate a Positive Pay Report
To automatically generate a positive pay report, complete this step:
-
On the Create Payment Process Profile page, Reporting tab, select the Automatically transmit file check box to automatically run the positive pay report as part of the payment process request submission process.
Note: Performing this step results in automatic generation of the Positive Pay report when you use this payment process profile in a payment process request. However, when you use the payment process profile to create a single payment, the Positive Pay report isn't generated automatically and you will need to manually generate it.
Manually Generate a Positive Pay Report
To manually generate a positive pay report, complete these steps:
-
Navigate: Navigator > Payables > Payments.
-
In the Tasks pane, click the Create Positive Pay File link. The parameters page for the Positive Pay report appears.
-
Select the applicable parameters from the choice lists and click Submit. A confirmation message displays with a process ID.
Tip: Write down or remember the process ID.
-
-
Navigate: Navigator > Tools > Scheduled Processes link.
-
In the Process ID field on the Overview page, enter the process ID that you wrote down in Step 1b and click Search. The result displays in the Search Results section.
-
Select the resulting row in the Search Results section to display additional details on the page.
-
In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> .PDF output file.
-
Report Parameters
The following table describes the process parameters.
Name | Description |
---|---|
Payment Process Profile |
Payment process profile used to process the payments. |
From Payment Date |
Starting date within a date range of payments. |
To Payment Date |
Ending date within a date range of payments. |
Allow Sending Replacement Copy |
The inclusion of payments in the Positive Pay report that were included in a previous report if, for example, the eText file was misplaced and your payment system or bank requests a duplicate copy of the Positive Pay report. |
Select Status |
Inclusion of one of the following in the Positive Pay report file:
|
Transmit File |
When set to Yes, transmits positive pay files that are generated using the Create Positive Pay File process. Ensure that the following setup is completed:
|
Frequently Asked Questions
The following table lists frequently asked questions and provides answers about the Positive Pay report.
FAQ | Answer |
---|---|
How do I find this report? |
You can find the Positive Pay report by selecting the 1 more link in the Log and Output section in the Search Results section on the Scheduled Processes page. |
Who uses this report? |
|
When do I use this report? |
The positive pay report is used when you print checks and you want to send a report of check numbers, dates, and amounts of all issued checks to your bank or payment system as a means to detect and prevent fraud. Checks that have their payment amounts altered or that are derived from stolen check stock are identified by the bank. |
What can I do with this report? |
You can:
|
What type of report is this? |
Oracle Business Intelligence Publisher |
Disbursement Accompanying Letters
This topic includes details about the Disbursement Accompanying Letter.
Overview
The Disbursement Accompanying Letter is a predefined disbursement report that is sent to your payment system or bank. The report accompanies a payment file and summarizes its contents.
The following figure is an example of the Disbursement Accompanying Letter report.

Key Insights
The following table shows you the difference between the formal Disbursement Accompanying Letter report name and the process name.
Report Name | Process Name | Output |
---|---|---|
Disbursement Accompanying Letter Formats |
Create Payment File Accompanying Letter |
.PDF file |
Generation of the Disbursement Accompanying Letter Report
To generate the Disbursement Accompanying Letter report from within Oracle Fusion Payments, perform the following steps:
-
Navigate: Navigator > Payables > Payments link.
-
In the Payments Tasks pane, click the Payment File Accompanying Letter link. The parameters page for the Create Payment File Accompanying Letter appears.
-
From the Payment File choice list, select a payment file and click Submit. A confirmation message displays with a process ID.
Tip: Write down or remember the process ID -
Navigate: Navigator > Tools > Scheduled Processes link.
-
In the Process ID field on the Scheduled Processes page, enter the process ID and click Search
-
Click the Refresh icon until the result displays in the Search Results section.
-
Select the resulting row in the Search Results section to display additional details on the Scheduled Processes page.
-
In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> .PDF output file.
Report Parameters
The following table describes the process parameter:
Name | Description |
---|---|
Payment File |
Payment file for which you are creating the Disbursement Accompanying Letter |
Frequently Asked Questions
The following table lists frequently asked questions about the Disbursement Accompanying Letter.
FAQ | Answer |
---|---|
How do I find this report? |
You can find this report by selecting the 1 more link in the Log and Output section in the Search Results section on the Scheduled Processes page. |
Who uses this report? |
|
When do I use this report? |
The Disbursement Accompanying Letter is used when you want to:
|
What can I do with this report? |
You can:
|
What type of report is this? |
Oracle Business Intelligence Publisher |
FAQs for Process Payment Files
What's a payment validation?
Payment validations are rules that ensure disbursements are correct before they are printed or transmitted to your bank or financial institution. Validations help find problems early in the payment process and decrease costs by preventing invalid data from reaching your bank.
During implementation, validations can be attached to payment methods, payment file formats, or both. Validations are handled differently at transaction time based on the object to which they are attached.
If the validation is attached to a payment method, it can be:
-
Executed early in the process. Problems can be identified as early as invoice entry in Oracle Fusion Payables.
-
Applied to a document payable, invoice installment, or a payment
If the validation is attached to a format, it can be:
-
Optionally executed only on transactions in a specific country
-
Optionally executed only on a specific combination of payment method and format
-
Executed on a document payable (although the validation won't happen during invoice entry), payment, or payment file
The following table describes characteristics of predefined and user-defined validations.
Predefined Validations | User-Defined Validations |
---|---|
Predefined for you |
|
Complex groupings of validations can be assigned to payment methods or formats |
|
What happens if I terminate the payment process?
The application sets the status of the payment file to Terminated and informs the source product of the terminated documents payable. For each payment in the payment file, the application sets the status to Canceled. The source product unlocks the documents payable and resets their status so they're available for future selection.
How can I unlock payment documents locked by another payment file?
Record the print status for Payment File 1 before attempting to print Payment File 2 onto payment documents. If Payment File 1 is printing onto payment documents, those payment documents are unavailable and considered locked.
What happens to payment numbering if I reprint a range of numbered payment documents?
You can reprint documents that have been damaged during the initial printing. The application marks the original payment documents as void and then assigns new payment document numbers to each payment. You specify the range or ranges of documents that were spoiled, and the payment document number on which to start the reprint. The application then renumbers and reprints the spoiled payments. To reprint a single document payable, enter the same number in both the Document Number From field and the Document Number To field.
Reprinting allows affected documents payable to be paid, despite initial printing issues. It's an alternative to marking payment documents as spoiled, which returns the unpaid documents payable to the source product.
What happens to payment numbering if I reprint the complete payment file of numbered payment documents?
The application retains the original numbering when you reprint the entire file. This option is recommended only for cases where no printing was started. If you reprint the entire payment file after successfully printing one or more numbered payment documents, the numbering on the documents will be incorrect.
Why did the payment file transmission fail?
Occasionally, a payment file transmission fails.
Transmission failures occur because:
-
A payment file transmission from your company to the payment system was not tested or set up properly.
-
A false transmission failure occurred. The transmission was actually successful.
-
The transmission terminated prematurely.
What's a confirmed printed payment?
A payment document that is recorded as printed on the Record Print Status page.
When payments in a payment file are confirmed, the source product is notified and you can no longer terminate the payment file. Instead of terminating the payment file, you must void any printed payments with issues.
When do I manually confirm electronic payment files?
When the timing of the confirmation point relies on an external event, such as notification from a bank that the payment file was processed. You must manually confirm when all of the following conditions apply:
-
The payment process profile attached to the payment file is the Electronic processing type.
-
The Allow Manual Setting of Payment Completion check box is selected.
-
The status of the payment file is one of the following:
-
Formatted
-
Formatted and Ready for Transmission
-
Transmitted
-
Transmission Failed
-