2Payments

This chapter contains the following:

Prepare and Record Payments

Payment Process Request Template

Video

Watch video

Watch: This video tutorial shows you how to create a payment process request template, which is a predefined configuration of selection criteria, payment attributes, and payment processing options. The content of this video is also covered in text topics.

Overview

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.

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

Payment Process Requests: How They're Processed

When you submit a payment process request, the request passes through various stages of processing. Within each stage, a request can have a different status. Some statuses require that you take action. You can use the Payments Overview page to view and act on payment process requests.

Settings That Affect Payment Process Request Processing

You can control the level of automation of a payment process request by setting the following options on the Submit Payment Process Request and the Create Payment Process Request Template pages:

  • Apply credits up to zero amount payment

  • Review installments

  • Review proposed payments

  • Create payment files immediately

  • Handle document and payment validation failures

Depending on how you set these options, a payment process request might require your input before processing can complete. Issues that arise during payment processing might also require your input, regardless of how these options are set.

How Payment Process Requests Are Processed

This table describes the stages and statuses that a payment process request can have and indicates whether user action is required.

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 are not 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 an additional round of 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 for an additional round of 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

Early Payment Discount Offers: Explained

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.

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:

  • Navigate to the Setup and Maintenance work area.

    1. Select Financials in the drop down list at the top of the page.

    2. Click Change Feature Opt In.

    3. On the Opt In: Financials page, click the Features icon for Payables.

    4. On the Edit Features: Payables page, select the Dynamic Offers for Early Payment Offers.

    5. Click Done to go back to the Setup: Financials page.

      Note: There is 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 is accepted and combined with the days paid early, determines the various discount amounts and payment amounts.

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

Reviewing Early Payment Discount Offers: Examples

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

  1. 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 is recommended to have a payment term without discount rates.

  2. 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 have not 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.

  3. Reviewing the discount offer:

    • If you do not review or choose not to accept the discount offer, the invoice is paid according to the payment terms.

  4. Fixed discount amount:

    • The discount amount varies based on the rate and days of advanced payment.

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

  6. Changing the invoice process:

    • You do not 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: Explained

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.

Payables Cash Requirement 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.

Payment File Creation: Points to Consider

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.

Applying Credits Up to Zero Amount Payments: Examples

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

The Maximize Credits Option: How It 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: Examples

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.

Date Basis in Payment Process Requests: Examples

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.

Payment Types: Points to Consider

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.

Making a Single Payment

Video

Watch video

Watch: This tutorial shows you how to create a single payment for a supplier. The content of this video is also covered in text topics.

Overview

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.

Payment Statuses: How They 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.

Payment status flow

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

Disbursement Bank Accounts and Payment Process Profiles: How They 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:

  1. You select a disbursement bank account and a payment process profile when submitting a payment process request.

  2. 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:

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

  2. If you do not 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 cannot 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 cannot 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.

  3. 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 is possible to cycle through some combination of steps 2 or 3 for documents payable missing disbursement bank accounts or payment process profiles. Similarly, it is also possible to obtain a missing disbursement bank account or a payment process profile using different steps for any one document payable.

Resolving Payment Validation Errors: Points to Consider

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 are not 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 is included in the payment process request. Payments removes them from the payment process request and informs the source product that the documents payable are not 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 cannot 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: Explained

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.

Interest on Overdue Invoices: How It's 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 is not 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 is, number of days less than a 30-day period divided by 360

Document Sequencing in Payables: Explained

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.

Cross-Currency Payments: Explained

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.

Setting Up Third-Party Payments: Procedure

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

  1. In the Suppliers work area, click Create Supplier.

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

  1. In the Suppliers work area, click Manage Suppliers.

  2. Search for the supplier on whose behalf the third party receives payment.

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

  1. In the Setup and Maintenance work area, search for the Define General Payables Options task list.

  2. Set the scope for the Manage Invoice Options task.

  3. Click Apply and Go to Task.

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

  1. In the Setup and Maintenance work area, search for the Define General Payables Options task list.

  2. Set the scope for the Manage Payment Options task.

  3. Click Apply and Go to Task.

  4. Select the Allow payee override for third-party payments option to allow override of the payee on the payment.

Adding Cross-Currency User Rates to a Payment: Worked Example

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

  1. On the Payments Overview page, click Create Payment to open the Create Payment page.

  2. On the Payment Details tab, complete the required fields.

  3. On the Advanced tab, complete the fields as shown in this table.

    Field Value

    Payment Conversion Rate Type

    Corporate

    Cross-Currency Rate Type

    User

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

  5. In the Add Cross-Currency User Rates dialog box, click the Create icon.

  6. Select a value for the From Currency field.

  7. Enter the conversion rate.

  8. Click OK.

  9. In the Invoices to Pay section, select the action Select and Add: Invoices to Pay.

  10. In the Select and Add: Invoice to Pay dialog box, select the invoice.

  11. Click OK.

  12. Click Save and Close.

  13. Click OK to acknowledge the payment confirmation message.

Centralized Payment Processing Across Business Units: Explained

Centralized payment processing enables you to implement a shared payment service model.

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

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

Self-service payment service 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.

Payment Approval: How It Is Processed

The payment approval process allows management to control payments by prioritizing available funds. Payment approval allows you to 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:

  1. A supplier tells you that they didn't receive a payment.

  2. You ask the bank to stop the payment.

  3. You record a stop payment request using the Manage Payments task.

  4. If the bank confirms the payment was stopped, you void the payment.

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

Example of third-party payment.

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 is 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:

  1. Click Social to open Oracle Social Network.

  2. Click Share.

  3. Create a related conversation.

  4. Invite your manager to join the conversation.

The details of your conversation are recorded within the context of the payment process request. Your manager can review the details on the payment process request wall. The recorded conversation acts as an approval for adding these installments to the existing payment process request.

Why do I get a permissions error when I click on an invoice number link from the Manage Payments page?

The business unit for the invoice is different from the business unit for the payment and you don't have access to that invoice business unit. You can view general invoice information on the Paid Invoices tab, but you can't drill down to view the invoice details.

What are the changes in the payment attributes flow when I create third-party payment?

The payee is the party who receives payment. Whether the payee is a third-party or the invoicing supplier, the payment attributes flow the same way.

The following attributes default on the invoice from the payee setup:

  • Payment method

  • Remit-to account

  • Pay each document alone

  • Bank charge bearer

  • Payment reason

  • Payment reason comments

  • Settlement priority

  • Delivery channel

The following attributes pull from the payee setup when you make a third-party payment or any payment.

  • Bank Instruction 1

  • Bank Instruction 2

  • Bank Instruction Details

  • Payment Text Message 1

  • Payment Text Message 2

  • Payment Text Message 3

  • Service Level

  • Separate Remittance Advice

Why do I see different names for the Payee and the Supplier or Party on payment process request pages?

The names are different because you're making a third-party payment. The Supplier or Party column displays the invoicing supplier. The Payee column displays the third-party that receives payment on behalf of the invoicing supplier.

What happens to payment validations when I create a third-party payment?

The payee is the party who receives payment. Whether the payee is a third-party or the invoicing supplier, validations on payee attributes perform the same way.

What's the impact on grouping of installments for third-party payments?

Installments are grouped first by the invoicing supplier and then by the third-party payee.

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.

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

Accounting for Invoices and Payments: Explained

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

Missing Conversion Rates: How They're 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.

Cross-Currency Payments: How They're 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

Video

Watch video

Watch: This video tutorial shows you how to set up and make electronic payments. The content of this video is also covered in text topics.

Procedure

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:

  1. Sign in as a setup user.

  2. Click Navigator > Setup and Maintenance.

  3. In the Search field, enter Manage Payment Process Profiles and click Search.

    The Search page appears.

  4. Click the Manage Payment Process Profiles link.

  5. On the Manage Payment Process Profiles page, in the Search Results section, click Add.

  6. On the Create Payment Process Profile page in the Name field, enter ISO_PPP_XXX.

  7. In the Code field, enter ISO_Code_XXX.

    Tip: In place of XXX, enter the appropriate number.
  8. In the From Date field, accept the default setting of today's date.

  9. From the Payment File Format choice list, search and select the ISO20022 Common Global Implementation Format.

  10. From the Processing Type choice list, select Electronic.

  11. From the Payment Confirmation Point choice list, select When the payment file is transmitted.

  12. Select the Usage Rules tab.

  13. 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.
  14. 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 (UCM) folder after the payment file is transmitted.

  15. From the Payment System choice list, select ISO20022 Payment System.

  16. Select the Automatically transmit payment file after formatting check box.

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

  18. For the payment system account of Settings_SEPA, enter today's date in the To Date field.

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

  20. In the Document Grouping Rules section, select these check boxes: Due date, Settlement priority, and Delivery channel.

  21. Select the Payment File tab.

    On the Payment File tab, you can specify rules for grouping payments into payment files.

  22. In the Overrides section, from the Service Level choice list, select the type of payment.

  23. From the Delivery Channel choice list, select the delivery type.

  24. Select the Grouping tab.

    Since you are 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.

  25. In the Transaction Grouping Rules section, select these check boxes: Payment Date, Disbursement Bank Account, Service Level and Delivery Channel.

  26. Select the Reporting tab.

    On the Reporting tab, you can specify the timing and types of reports to generate.

  27. In the Payment File Register section, from the Format choice list, select Payment File Register Format with Document Detail.

  28. Select the Automatically submit when payments are confirmed check box.

  29. In the Separate Remittance Advice section, from the Format choice list, select Separate Remittance Advice Format.

  30. Select these check boxes: Automatically submit when payments are confirmed and Allow multiple copies for payment file.

  31. From the Condition choice list, select All payments.

  32. From the Delivery Method choice list, select E-Mail.

  33. Click Save and Close. A Confirmation message appears.

  34. Click OK.

  35. Click Done.

  36. 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:

  1. Sign in as a transaction user.

  2. On the Home page, click Payables > Payments.

  3. On the Overview page, click the Tasks icon and then click the Submit Payment Process Request link.

  4. On the Submit Payment Process Request page, select the Selection Criteria tab.

  5. In the Name field, enter ISO_PPRXXX.

  6. From the Invoice Group choice list, search and select 129Group.

    Tip: In place of XXX, enter the appropriate number.
  7. 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.

  8. 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.
  9. From the Payment Process Profile choice list, search on ISO and select ISO_PPP Settings_CGI .

  10. From the Payment Conversion Rate Type choice list, select Corporate.

  11. In the Processing Options subsection, select these check boxes: Review installments, Review proposed payments, and Create payment files immediately.

  12. In the Validation Failure Handling subsection, from the Document choice list, select Stop process for review.

  13. From the Payment choice list, select Stop process for review.

  14. Click Submit.

    A Confirmation message appears with the process number.

  15. Click OK.

  16. Scroll down to the Schedule Requests section to check the status of the request.

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

  18. On the Overview page, click the Tasks icon.

  19. Click the Manage Payment Process Requests link.

  20. On the Manage Payment Process Requests page, enter ISO_PPRXXX in the Name field.

    Note: In place of XXX, enter the appropriate number.
  21. Click Search.

    Note: The payment process request shows a Status of Pending installment review.
  22. 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:

  1. On the Review Installments page, click Submit.

    A Confirmation message appears that states your process ID.

  2. Click OK.

  3. Expand the Search section.

  4. The Name field contains the name of the payment process request, ISO_PPRXXX.

  5. Click Search.

    Note: The status of the payment process request changes to Pending proposed payment review.
  6. Click the Action icon.

Reviewing Proposed Payments

The fourth step is to review proposed payments.

To review proposed payments, complete these steps:

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

  2. 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:

  1. Expand the Search section.

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

  3. In the Name field, enter the payment process request name, ISO_PPR_XXX.

    Note: In place of XXX, enter the appropriate number.
  4. Click the payment file number.

    The Payment File page appears.

  5. 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:

  1. On the Manage Payment Process Requests page, click the payment file number link.

  2. Scroll down the Payment File page to the Payments section.

    The Payments section contains two payments.

  3. Click the Eye Glasses icon for the $800.00 USD payment.

  4. On the Payment page, select the Documents Payable tab.

    The two invoices within Payment XXX are visible.

  5. Click Done.

Check Payments

Video

Watch video

Watch: This video tutorial shows you how to set up and make check payments. The content of this video is also covered in text topics.

Procedure

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:

  1. Sign in as a Cash manager.

  2. Click Navigator > Setup and Maintenance.

  3. In the Search field, enter Manage Bank Accounts and click Search.

    The Search page appears.

  4. Click the Manage Bank Accounts link.

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

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

  7. On the Edit Bank Account page, Payment Documents section, click Create.

  8. In the Create Payment Document dialog box, in the Payment Document field, enter Payments Numbered Check Stock.

  9. From the Paper Stock Type choice list, select Numbered Stock.

  10. From the Format choice list, search and select Standard Check Format (Stub after Payment).

  11. In the First Available Document Number field, enter 373001.

  12. In the Last Available Document Number field, enter 373100.

  13. Click OK.

  14. Click Save and Close.

    An Information message is displayed.

  15. Click OK.

  16. Click Done.

  17. Click Done.

  18. 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:

  1. Sign in as a setup user.

  2. Click Navigator > Setup and Maintenance.

  3. In the Search field, enter Manage Payment Process Profiles and click the Search icon.

    The Search page appears.

  4. Click the Manage Payment Process Profiles link.

  5. On the Manage Payment Process Profile page in the Search results section, click the Add icon.

  6. On the Create Payment Process Profile page, in the Name field, enter PPP_XXX.

  7. In the Code field, enter PPP_XXX_Code.

    Note: In place of XXX, enter the appropriate number.
  8. In the From Date field, accept the default setting of today's date.

  9. From the Payment File Format choice list, search and select Standard Check Format (Stub after Payment).

  10. From the Processing Type choice list, select Printed.

  11. For the Pay File option, accept Send to printer.

  12. Select the Usage Rules tab.

  13. 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.
  14. 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.

  15. From the Payment System choice list, select BofA File System.

  16. From the Payment File Transmission Configuration choice list, select UCMPut.

  17. In the From Date field, accept the default value of today's date.

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

  19. In the Document Grouping Rules section, select the Due date check box.

  20. In the Document Limits section, in the Maximum Documents per Payment field, enter 5.

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

  22. In the Positive Pay section, from the Format choice list, select Positive Pay File Format.

  23. Select the Automatically transmit file check box.

  24. Click Save and Close.

    A Confirmation message appears.

  25. Click OK.

  26. Click Done.

  27. Click Done.

  28. 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:

  1. Sign in as a transaction user.

  2. Click the Payables icon and select Payments.

  3. On the Overview page, click the Tasks icon and select Submit Payment Process Request.

  4. On the Submit Payment Process Request page in the Name field, enter PPR_XXX.

  5. Select the Selection Criteria tab.

  6. From the Invoice Group choice list, search and select XXXGroup.

    Tip: In place of XXX, enter the appropriate number.
  7. 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.

  8. From the Disbursement Bank Account choice list, search and select BofA-XXX.

  9. From the Payment Document choice list, select Payments Numbered Stock.

  10. From the Payment Process Profile choice list, select PPP_XXX Positive Pay.

  11. From the Payment Conversion Rate Type choice list, accept Corporate.

  12. In the Processing Options subsection, select these check boxes: Review installments, Review proposed payments, and Create payment files immediately.

  13. In the Validation Failure Handling subsection, from the Document choice list, accept Stop process for review.

  14. From the Payment choice list, accept Stop process for review.

  15. Click Submit.

    A Confirmation message with the process number of the payment process request is displayed.

  16. Click OK.

  17. Scroll down to the Schedule Requests section to check the status of the payment process request.

  18. 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:

  1. 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.
  2. Click the Action icon.

  3. On the Review Installments page, review the invoices.

  4. Click Submit.

    A Confirmation message is displayed.

  5. Click OK.

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

  8. On the Review Proposed Payments page, click Resume Payment Process.

    A Confirmation message is displayed.

  9. 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:

  1. On the Overview page, Requiring Attention tab, expand the payment process request icon to display the payment file.

  2. 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.
  3. Click the Action icon.

  4. On the Print Payment Documents page, from the Printer choice list, select PO 407.

  5. Click Print.

    A Confirmation message is displayed.

  6. Click OK.

  7. On the Overview page, Requiring Attention tab, click Refresh to requery the payment process request.

    The payment file status changes to Submitted for printing.

  8. Click the Action icon.

Recording the Print Status

After you print checks, you must examine the printed checks to confirm that they are not spoiled or skipped. If a check is spoiled or skipped, you record the print status.

To record the print status, complete these steps:

  1. On the Payment File page, review the payments and their check numbers. If your checks look fine, click Record Print Status.

  2. On the Record Print Status: Payment File page, click Submit.

    A Warning message is displayed.

  3. Click Record the Print Status.

    A Confirmation message is displayed.

  4. Click OK.

  5. 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.
  6. Click Done.

    The Overview page appears.

Reviewing a Check

After printing checks, you can review them.

To review a check, complete these steps:

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

  2. Click Refresh.

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

  4. Click the ESS link.

    A .txt of the positive pay report is displayed.

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

  6. Click the ESS link.

    A .pdf of the check is displayed.

Disbursements: How They 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.

Separate Remittance Advice Report: How It 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

Positive Pay File: How It 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 are not listed on the positive pay report.

You can run the positive pay file report as follows:

  • Manually run the report from the Payments Tasks pane by clicking the Create Positive Pay File link.

  • 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. Any required parameter values are known by Oracle Fusion Payments without your intervention. 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.

The following 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

To manually run the report, navigate to: Navigator > Payables > Payments link > Create Positive Pay File link.

To automatically run the report, navigate to the Reporting tab on the Payment Process Profile page and select the Automatically transmit file check box. 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 > Reporting tab

Parameters That Affect a Positive Pay Report

The parameters listed in the following 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

How a Positive Pay Report File Is Generated

The following 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

Depending on how the payment process profile is set up, Payments may have the capability to transmit the positive pay file to your payment system or bank.

The following table describes the flow of the automatic Create Positive Pay File process.

Action Description

The Create Positive Pay File automatically runs after you select the Automatically Transmit File check box on the Reporting tab of the Payment Process Profile page.

The Create Positive Pay File process automatically runs and creates the Positive Pay report. Payments submits the process as soon as the payments in the payment file are confirmed.

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.

Confirming Electronic Payment Files: Explained

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.

  1. Select the applicable payment file row from the search results.

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

Printed Payment File Statuses: How They 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.

Electronic Payment File Statuses: How They 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
  1. The payment file was created and validated, but failed validation.

  2. You must take remedial action.

Failed validation and pending action

  1. You reviewed a payment file that failed validation.

  2. You removed payments or overrode errors.

  3. This status prompts Payments to validate the payment file again.

Retry payment file validation

  1. The payment file passed validation.

  2. This status prompts Payments to start the formatting process.

Created

  1. The payment file was terminated.

  2. The documents payable were returned to the source product.

Terminated

  1. The payment file failed formatting

  2. You are prompted to take remedial action.

Failed formatting and pending action

  1. The payment file was formatted.

  2. No further action is needed.

Formatted

  1. The payment file was formatted.

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

  1. You ignored a transmission failure after confirming transmission outside Payments.

  2. You overrode it on the Resolve Payment File Transmission Failure page.

  3. The payment file was successfully transmitted to the payment system or financial institution.

Transmitted

  1. You voided a payment.

  2. No valid payments remain in the payment file, which causes the payment file to be automatically terminated.

Terminated

Skipped and Spoiled Payment Documents: Explained

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:

  1. Reprint the payment onto a new numbered payment document on the Reprint Payment Documents page.

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

Resolving Payment File Transmission Failures: Critical Choices

When a payment file transmission failure occurs, you can choose from the following options:

  • Retransmit the file.

  • Ignore the transmission failure.

  • Stop the payment process.

Retransmitting the File

Retransmitting the file 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.

Resolving Payment File Validation Errors: Critical Choices

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.

Payment Document Number Generation of Electronic Payments: How They 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..

  1. From the Processing Type choice list, select Electronic.

  2. 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:

  1. The first payment file refers to the applicable payment document. Payment document numbering values are generated.

  2. When the first payment file is completed, the status of other payment files are Created - Ready for Formatting.

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

Grouping in ISO 20022 SEPA and CGI Credit Transfer Messages: Explained

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: Explained

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.

  1. Click the Schedule New Process button.

  2. Search on the Process Name.

  3. Enter the applicable parameters.

  4. Enter the applicable process options and schedule.

  5. 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 Report: Explained

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:

  1. Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Disbursement System Options > Go to Task > Manage Disbursement System Options page.

  2. 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:

  1. Navigate: Navigator > Payables > Payments link.

  2. In the Payments Tasks pane, click the Submit Payment Process Request link to open the Submit Payment Process Request page.

  3. Select the Payment and Processing Options tab.

  4. In the Processing Options section, select the Create payment files immediately check box.

  5. Navigate: Navigator > Tools > Scheduled Processes link. The Scheduled Processes page appears.

  6. Click the Schedule New Process button. The Schedule New Process dialog box appears.

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

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

  9. Select the resulting row and click OK.

  10. In the Schedule New Process dialog box, click OK. The Process Details dialog box appears.

  11. Select the applicable parameters and click Submit. A confirmation message displays with a process ID.

    Tip: Write down or remember the process ID.
  12. In the Process ID field on the Scheduled Processes page, enter the process ID and click Search.

  13. Click the Refresh icon until the result displays in the Search Results section.

  14. Select the resulting row in the Search Results section to display additional details on the Scheduled Processes page.

  15. 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 Report: Explained

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:

  1. Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Payment Process Profiles > Go to Task > Manage Payment Process Profiles page > Create button.

  2. On the Create Payment Process Profile page, Reporting tab, select the Automatically submit when payments are confirmed check box.

  3. Navigate: Navigator > Tools > Scheduled Processes link. The Scheduled Processes page appears.

  4. Click the Schedule New Process button. The Schedule New Process dialog box appears.

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

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

  7. Select the resulting row and click OK.

  8. In the Schedule New Process dialog box, click OK. The Process Details dialog box appears.

  9. From the Payment File choice list, select the applicable payment file.

  10. 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.
  11. 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

  12. Select the resulting row in the Search Results section to display additional details on the page.

  13. 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 Report: Explained

This topic includes details about the Separate Remittance Advice report.

Overview

The Separate Remittance Advice report is a predefined disbursement report that is faxed, E-Mailed, or printed and mailed to a supplier, which lists the invoices you paid.

The following figure illustrates an example of the Separate Remittance Advice report.

This figure illustrates an example of the Separate
Remittance Advice report.

Key Insights

The following table lists the difference 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

.PDF file or .HTML file if E-Mailed.

Automatic Generation of the Separate Remittance Advice Report

To automatically generate the Separate Remittance Advice report, perform the following steps:

Before you can automatically generate a Separate Remittance Advice report, you must set up a payment process profile. Navigate to: Navigator > Tools > Setup and Maintenance > All Tasks tab > Name field: Payments > Search button > Define Invoicing and Payments Configuration > Define Disbursements > Manage Payment Process Profiles > Go to Task > Manage Payment Process Profiles page > Create button > Create Payment Process Profiles page.

  1. Navigate to: Navigator > Procurement > Suppliers link > Manage Suppliers link > Search for applicable supplier > Supplier link > Sites tab > Site link > Edit Site page.

  2. Select the Payments tab.

  3. Select the Payment Attributes tab.

  4. Select the Separate Remittance Advice Delivery tab.

    1. From the Delivery Method choice list, select E-Mail.

    2. In the E-Mail field, you can enter single or multiple E-Mails. If you enter multiple E-Mails, separate them by a comma.

Generation of the Separate Remittance Advice Report

To manually generate the Separate Remittance Advice report, perform the following steps:

  1. Navigate to: Navigator > Tools > Setup and Maintenance > All Tasks tab > Name field: Payments > Search button > Define Invoicing and Payments Configuration > Define Disbursements > Manage Payment Process Profiles > Go to Task > Manage Payment Process Profiles page > Create button > Create Payment Process Profiles page.

  2. On the Create Payment Process Profile page, Reporting tab, Separate Remittance Advice section, from the Format choice list, select Separate Remittance Advice Format.

  3. Optionally, select the Allow multiple copies for payment file check box to generate multiple copies of the Separate Remittance Advice report.

  4. Optionally, select a condition for which the Separate Remittance Advice report is generated.

  5. Select how you want the Separate Remittance Advice report delivered to the supplier, whether by E-Mail, fax, or printed and sent by the postal service.

  6. Navigate to: Navigator > Payables > Payments link.

  7. In the Payments Tasks pane, click the Send Separate Remittance Advice link. The parameters page for the Separate Remittance Advice report appears.

  8. 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.
  9. Navigate to: Navigator > Tools > Scheduled Processes link.

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

  11. Select the resulting row in the Search Results section to display additional details on the page.

  12. 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 are generating the Separate Remittance Advice report.

Format

Name of the applicable format, which is Separate Remittance Advice Format.

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 E-Mail, postal service, or fax.

What type of report is this?

Oracle Business Intelligence Publisher

Positive Pay Report: Explained

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 are not 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

eText file

Generation of the Positive Pay Report

To generate the Positive Pay report, perform the following steps:

Note: To receive the Positive Pay report in the form of a .PDF output file, you must perform step 2 in the following procedure.
  1. Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Payment Process Profiles > Go to Task > Manage Payment Process Profiles page > Create button.

  2. On the Create Payment Process Profiles page, Reporting tab, select the Automatically transmit file check box.

    Note: Performing this step results in automatic generation of the Positive Pay report when you use this payment process profile. To create a single payment, however, the Positive Pay report is not generated automatically and you will need to manually generate it.
  3. Navigate: Navigator > Payables > Payments link.

  4. In the Payments Tasks pane, click the Create Positive Pay File link. The parameters page for the Positive Pay report appears.

  5. 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.
  6. Navigate: Navigator > Tools > Scheduled Processes link.

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

  8. Select the resulting row in the Search Results section to display additional details on the page.

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

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?

As soon as payments in a payment file are confirmed, Payments submits the Create Positive Pay File process. When payments files are transmitted to your payment system or bank, the Positive Pay report file is included in the transmission.

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 Letter: Explained

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:

  1. Navigate: Navigator > Payables > Payments link.

  2. In the Payments Tasks pane, click the Payment File Accompanying Letter link. The parameters page for the Create Payment File Accompanying Letter appears.

  3. 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
  4. Navigate: Navigator > Tools > Scheduled Processes link.

  5. In the Process ID field on the Scheduled Processes page, enter the process ID and click Search

  6. Click the Refresh icon until the result displays in the Search Results section.

  7. Select the resulting row in the Search Results section to display additional details on the Scheduled Processes page.

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

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