2Payments

This chapter contains the following:

Prepare and Record Payments
Record Accounting for Payments
Process Payment Files

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: A payment business unit, the selection process finds installments for the invoice business units that the payment business unit services. An invoice business unit, the selection process finds installments for that invoice business unit.
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.

Note: Payment attributes don't affect installment selection.

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 installments Add or remove installments Edit payment and discount amounts Specify user conversion rates Calculate withholding and interest
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.

Note: If issues arise during payment processing that require your input, the process pauses, regardless of how the processing options are set.

How Payment Process Requests Are Processed

Watch video

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.

Note: The table doesn't include all of the transitional statuses, such as Terminating.

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: One or more payable documents has failed validation and the option for handling document failures is set to Reject all documents in request. All documents payable have failed validation and the options for handling document failures is set to anything other than Stop process for review.	No
Terminated	Failed payment validation	One of the following has occurred: One or more payments has failed validation, and the option for handling payment failures is set to Reject all payments in request.. All payments have failed validation and the option for handling payment failures is set to anything other than Stop process for review.	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.

Related Topics

Submit Scheduled Processes and Process Sets

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.

Note: You can load data to the payment requests interface tables using predefined templates and the Load Interface File for Import scheduled process. Both are part of the External Data Integration Services for Oracle Cloud. For more information about file-based data import, see the File Based Data Import guide for your cloud services.

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.

Related Topics

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:
1. Offering: Financials
2. Functional Area: Payables
3. Features: Dynamic Offers for Early Payment Offers.
4. 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:
  1. If you haven't completed the payment, you can change the discount selection.
  2. 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?	Financial Manager Financial Specialist
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?	Use the information to configure multiple payment process request templates. Forecast cash requirements for a specific period, such as 30 days, by defining a payment process request template with the applicable parameters.
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

Parameters

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.

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.

Note: If you centralize payment processing using the service provider model, invoices and credit memos are first grouped together across the invoice business units. The payment process then determines whether to apply the credits.

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

Note: CM103 is not selected and the amount for CM100 is adjusted from -100 to -50 to equal the payment total of zero, 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.

Note: Results are different if the Date Basis is Due Date, or the Date Basis is Pay Date and the supplier Pay Date Basis is Due. In this case, the payment process request selects the installment only when the Pay Through Date is on or after the due date.

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.

Note: Specify the Pay Date Basis in the Terms section of the Invoicing tab on the Supplier Site pages.

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	The installment is selected because the pay through date of March 30 is later than at least one of the discount dates. The discount is 150 USD because the payment date of February 8 is before the first discount date of February 15. Note: If the payment date was after February 15, but before February 28, the second discount of 100 USD would be taken.
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

Watch video

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	Payment process request, Quick, Manual, Refund	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

Caution: You can't:

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: A payment was created and ready to be cashed by a supplier. A request to stop a payment was canceled. A bills payable payment matured and you submitted the Update Matured Bills Payables Status process to change the payment status from Issued to Negotiable.	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.

Note: Within a single payment process request, it's possible to cycle through some combination of steps 2 or 3 for documents payable missing disbursement bank accounts or payment process profiles. Similarly, it's also possible to obtain a missing disbursement bank account or a payment process profile using different steps for any one document payable.

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
The bank account is invalid for the payment business unit on the invoice. The bank account has an invalid payment currency. The bank account is inactive on the payment date.	The profile is invalid for the automatic population of the bank account and payment method, business unit, and currency combination. That is, the usage rules specified on the profile do not match the parameters on the payment. The profile is inactive on the payment date.

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.

Note: You may choose to change setups to resolve payment validation errors; however, you can't change details of the documents payable or invoices, such as amounts or currencies, since those are locked during the payment process. To change details on the documents payable, you must remove the payment or document payable from the payment process request and then make changes in the Edit Invoice 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.

Caution: You must pay the overdue invoice in a payment process request or through a quick payment.

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.

Note: You can add, change, or delete an interest rate at any time. If a rate isn't defined, the interest calculation uses a zero rate.

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.

Related Topics

Interest Allocation Methods

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

Note: The interest calculation is in accordance with the US Prompt Payment Act, and isn't an effective yearly rate. Interest is compounded monthly. For example, if the interest rate on a 100 USD invoice is 7 percent, after a year, the interest owed is 7.23 USD.

This figure shows the formula for calculating interest.

The interest formula is I equal left bracket, P
left parenthesis, 1 plus i over 12 right parenthesis, superscript
n, minus P right bracket, plus left bracket, P plus left parenthesis,
P left parenthesis, 1 plus i over 12 right parenthesis, superscript
n, minus P right parenthesis, right bracket, left parenthesis, i right
parenthesis, left parenthesis, z right parenthesis.

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

Note: The Create Chart of Accounts, Ledger, Legal Entities, and Business Units in Spreadsheet task is an alternative method for creating document sequences.

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

Note: The invoice import process rejects invoices if the Enforce Document Sequencing for Payables option is set to Yes and you manually provide a voucher number. If you require manual voucher numbering during import, set the Sequencing By option to No sequencing.

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.

Related Topics

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.

Note: You can't update the payment currency on an invoice once you save the invoice.

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.

Note: You don't have to create a supplier site unless the third party is a supplier that sends you invoices.

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.

Note: The Merge Supplier process doesn't merge third-party payment relationships.

(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.

Related Topics

Guidelines For Invoice Options

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.

Dedicated and self-service payment service 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.

Related Topics

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	Approve Reject Withdraw approval Resubmit for approval	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	Approve Reject	Your e-mail inbox.
BPM Worklist notification	Withdraw approval Resubmit for approval Reassign Delegate Request for more information	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.	Allows the payment process request to continue Status of payment process request changes to Approved Final approver manually initiates the Format payments process to complete the payment process request process
Reject payment	Only when the payment process request status is Payments Approval Initiated.	Approvers only.	Terminates the payment process request immediately Status of payment process request changes to Terminated
Withdraw approval	Only when the payment process request status is Payments Approval Initiated.	Submitter of the payment process request or approver.	Terminates the payment approval task Status of the payment process request changes to Withdrawn Ensures that all active payment approval notifications are removed from approvers Approver reinitiates payment approval by selecting the Resubmit for approval action after correcting the issue
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.	Reinitiates the payment approval process for the payment process request Status of payment process request changes to Payments Approval Initiated
Terminate payment process request	Always.	Anyone.	Terminates the payment process Ensures that all active payment approval notifications are removed from approvers

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	Payments approval initiated Pending payment approvals Withdrawn from payments approval Payments approved	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.

Note: When you void a payment, you can select to cancel the invoices, place a hold on the invoices, or leave the invoices available for payment.

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.

Note: Invoices for automatically withheld taxes are always created in the ledger currency.

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.

Related Topics

What does social networking have to do with my job

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

Tip: Payment status bell notifications aren't displayed to notify you of report availability.

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	Payment file Separate Remittance Advice Report Positive Pay Report Payment File Register Report

Related Topics

Payables Selected Installments Report: Explained

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	Bill Payable Matured Bill Payable Maturity Adjusted Bill Payable Maturity Reversed
Credit Memos	Credit Memo Adjusted Credit Memo Canceled Credit Memo Validated
Debit Memos	Debit Memo Adjusted Debit Memo Canceled Debit Memo Validated
Invoices	Invoice Adjusted Invoice Canceled Invoice Validated
Payments	Manual Payment Adjusted Payment Adjusted Payment Canceled Payment Created
Prepayment Applications	Prepayment Application Adjusted Prepayment Applied Prepayment Unapplied
Prepayments	Prepayment Adjusted Prepayment Canceled Prepayment Validated
Reconciled Payments	Payment Cleared Payment Clearing Adjusted Payment Uncleared
Refunds	Refund Adjusted Refund Canceled Refund Recorded
Third-Party Merge	Full Merge Partial Merge

Related Topics

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.

Related Topics

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

Watch video

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

Watch video

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.

This figure illustrates the flow of the disbursement
process.

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

This 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.
Print payment documents	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: Separate Remittance Advice reports can be sent to suppliers, which lists the invoices you paid. Positive Pay reports can be sent to banks to prevent fraud since unauthorized payments are not listed on the Positive Pay report. Payment file registers can be created for internal use. They display details of payments that are included in a payment file. You can retain this report for your records.

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.

Note: Before you can automatically generate a Separate Remittance Advice report, you must set up a payment process profile.

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: Separate Remittance Advice From E-Mail Separate Remittance Advice Subject

Related Topics

Payment Process Profiles

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: Configuration Profile Payment File Transmission Configuration From Date and To Date

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: Payments that have a status of Completed. The payment process profile you specify for the process, which has a positive pay format specified in the Positive Pay section on the Reporting tab. The payment process profile you specify for the process, which has one, multiple, or no disbursement bank account specified on the Usage Rules tab.
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: Configuration Profile Payment File Transmission Configuration From Date and To Date

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:

Payments that have a status of Completed.
The payment process profile you specify for the process, which has a positive pay format specified in the Positive Pay section on the Reporting tab.
The payment process profile you specify for the process, which has one, multiple, or no disbursement bank account specified on the Usage Rules tab.

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:

Configuration Profile
Payment File Transmission Configuration
From Date and To Date

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.	Select the applicable payment file row from the search results. Select the applicable option from the Actions menu.
Payment File.	Select the applicable option from the Actions menu.

Note: After the payments in a payment file are confirmed, the source product is notified. Simultaneously, you can no longer terminate the payment file. Instead, if you have any issues with payments, you must void them.

Related Topics

Payment Process Profiles

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.

Tip: If you don't want to print payment files immediately, you must manually submit the payment file for printing. Manual submission is done on the Print Payment Documents page.

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.

This 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.

This 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
The payment file was created and validated, but failed validation. You must take remedial action.	Failed validation and pending action
You reviewed a payment file that failed validation. You removed payments or overrode errors. This status prompts Payments to validate the payment file again.	Retry payment file validation
The payment file passed validation. This status prompts Payments to start the formatting process.	Created
The payment file was terminated. The documents payable were returned to the source product.	Terminated
The payment file failed formatting You are prompted to take remedial action.	Failed formatting and pending action
The payment file was formatted. No further action is needed.	Formatted
The payment file was formatted. It's ready for transmission to the payment system or financial institution.	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
You ignored a transmission failure after confirming transmission outside Payments. You overrode it on the Resolve Payment File Transmission Failure page. The payment file was successfully transmitted to the payment system or financial institution.	Transmitted
You voided a payment. No valid payments remain in the payment file, which causes the payment file to be automatically terminated.	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.

Tip: Click the Mark as Spoiled button only if you are not going to reprint.

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.

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.

Note: At the payment file level, you don't have the option of removing individual documents payable from a payment.

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.

Related Topics

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:

Payment document numbering, which are passed to Oracle Fusion Payables.
Payment reference numbers

Values stamped on electronic payments:

Payment reference numbers, which are passed to Payables.

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..	From the Processing Type choice list, select Electronic. From the Default Payment Document choice list, select a default payment document.
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	Debtor account Debtor Debtor agent

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.

Note: You can use an ISO 20022 CGI credit transfer payment format for ISO 20022 SEPA credit transfer payments. In this case, you must attach all SEPA credit transfer predefined validations to the CGI credit transfer payment file format.

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.

Note: The applicable process is called internally. Any required parameter values are known by Payments without your intervention.

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: Create payment files immediately check box. Provide a default payment document and a payment process profile.	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.

This figure is an example of the first page of
a 3-page Payment Process Request Status report.

This figure is an example of the second page of
a 3-page Payment Process Request Status report.

This figure is an example of the third page 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:
1. From the Format choice list, select Payment Process Request Status Report Format.
2. 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?	Financial Manager Financial Specialist
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: Generate the Payment Process Request Status report. Download the .PDF file and retain it for your records.
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.

This 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?	Financial Manager Financial Specialist
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: Generate and schedule the Payment File Register report Retain the Payment File Register report for your records
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.

This figure 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.
1. 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.
2. 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?	Financial Manager Financial Specialist
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: Generate the Separate Remittance Advice report Send the Separate Remittance Advice report to suppliers by email, postal service, or fax.
What type of report is this?	Oracle Business Intelligence Publisher

Related Topics

Payment Process Profiles

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.

This figure is an example if 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.
1. In the Setup and Maintenance work area, select:
  1. Offering: Financials
  2. Functional Area: Payments
  3. Task: Manage Payment Process Profiles
2. On the Manage Payment Process Profiles page, click the Create icon.
  1. On the Create Payment Process Profile page, enter values on the Usage Rules tab.
  2. On the Payment System tab, configure a payment system account by entering values in these fields:
    1. Payment System Account
    2. Configuration Profile
    3. Payment File Transmission Configuration
    4. From Date and To Date
Create a transmission configuration.
1. In the Setup and Maintenance work area, select:
  1. Offering: Financials
  2. Functional Area: Payments
  3. Task: Manage Transmission Configurations
2. On the Manage Transmission Configurations page from the Select Protocol choice list, select a protocol and click Create.
3. On the Create Transmission Configurations page, enter any of these dynamic naming attributes in the Value field for the Sent File Name parameter:
  1. &REQUESTID
    
    Request ID refers to the process ID of the Create Positive Pay File process
  2. &DATE
    
    Date is displayed in YYYYMMDD format.
  3. &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.
4. 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:
  1. A static naming attribute
  2. One or more dynamic naming attributes
  3. 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.
1. In the Tasks pane, click the Create Positive Pay File link. The parameters page for the Positive Pay report appears.
2. 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.
1. 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.
2. Select the resulting row in the Search Results section to display additional details on the page.
3. 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: Only negotiable payments Only payments that have been voided All payments
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: Specify a valid payment system account in the Payment System tab of the payment process profile. Select a value from the Payment File Transmission Configuration choice list in the Payment System tab of the payment process profile.

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?	Financial Manager Financial Specialist
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: Generate the Positive Pay report Automatically generate and transmit the Positive Pay report to your payment system or bank during payment processing.
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.

The 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?	Financial Manager Financial Specialist
When do I use this report?	The Disbursement Accompanying Letter is used when you want to: Summarize the contents of the payment file. Manually send the summary and the payment file to the payment system or bank.
What can I do with this report?	You can: Generate and schedule the Disbursement Accompanying Letter Print and mail the Disbursement Accompanying Letter to the payment system or bank, along with the payment file on a disk.
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

Note: If the validation is attached to a payment method, it can't be applied to a payment file, because one payment file may span multiple payment methods.

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	You define. You configure.
Complex groupings of validations can be assigned to payment methods or formats	You can specify one attribute at a time during implementation. You can make them completely granular.

Related Topics

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.

Caution: If the initial printing attempt results in one or more checks printing successfully, do not reprint the complete payment file. Instead, reprint the remaining numbered payment documents as a range of payments.

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.

Tip: The Terminate Payment Process action doesn't appear on any page where printed payments appear as confirmed.

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