Browser version scriptSkip Headers

Oracle® Fusion Applications Procurement, Payables, Payments, and Cash Guide
11g Release 6 (11.1.6)
Part Number E22897-06
Go to Documentation Home
Home
Go to contents  page
Contents
Book<br />List
Book
List
Go to Feedback page
Contact
Us

Go to previous page
Previous
Go to previous page
Next
PDF

2 Manage Payments

This chapter contains the following:

Prepare and Record Payments

Record Accounting for Payments

Process Payment Files

Prepare and Record Payments

Payment Process Requests: Explained

A payment process request is a grouping of installments that are processed for payment. For each request, you can specify selection criteria, payment attributes, and processing options.

You can create and submit a payment process request on the Submit Payment Process Request page, or you can create a payment process request template and submit the template for processing.

Specifying Selection Criteria

Selection criteria, such as business unit and payment priority, determine which installments are selected for payment.

Specifying Payment Attributes

Payment attributes, such as payment date and payment process profile, identify payment details.

Note

Payment attributes do not affect installment selection.

Specifying Processing Options

Processing options determine the level of automation for the payment process request. For example, you can set processing options that submit the request through to completion without stopping, or you can specify that the request stop for installment review.

This table lists the processing options that you can set to control the level of automation.


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

Review installments

Stops the payment process request after installment selection. You can review installments, add or remove installments from the request, edit payment and discount amounts, specify conversion rates for the conversion rate type of User, and 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 payment process request instead of waiting to combine payments from other payment process 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.

Creating Payment Process Request Templates

A payment process request template is a configuration of selection criteria, payment attributes, and processing options that you predefine.

Payment process request templates enable you to:

Tip

Schedule the Payables Cash Requirement Report to run before you submit a template for processing.

Monitoring Payment Process Requests

When you submit a payment process request, the request passes through stages of processing, such as installment selection and payment validation. Take action on requests that require your attention in the Payments work area and on the Payables dashboard.

Payment Process Requests: How They Are Processed

When you submit a payment process request, it passes through various processing stages. Within each stage, the payment process request can have a different status. Depending on the processing options you specify, a payment process request may require your input before processing can complete. Issues that arise during payment processing may also require your input, regardless of how the processing options are set.

Settings That Affect Payment Process Request Processing

You can specify processing options on a payment process request to control the level of automation associated with the request. The processing options are as follows:

How Payment Process Requests Are Processed

When you submit a payment process request for processing, the request passes through the following processing stages:

Within a stage, a payment process request has a status, such as Pending installments review. Some statuses require you to take action before the payment process request can complete. You can view payment process requests that require your attention and take action on them on the Payments Overview page.

This table lists and describes the stages and statuses of a payment process request and indicates whether action is required.

Note

The table does not list transitional statuses, such as Terminating.


Payment Process Request Stage

Payment Process Request Status

Status Description

Requires Action by the Payables Supervisor?

Installment selection

Pending

The payment process request is waiting to process. Processing will begin automatically as soon as system resources are available.

No

Installment selection

Pending installments review

The processing option Review installments is enabled and manual review is required.

Yes

Installment selection

Missing payment conversion rates

The conversion rate type is User and conversion rates are missing.

Yes

Installment selection

Installments selected

The payment process request selected installments to process for payment.

No

Document validation

Pending action to complete information required

The payment process request contains documents that are missing required information, such as disbursement bank account or payment process profile.

Yes

Document validation

Assignment complete

The payment process request contains no documents that are missing required information.

No

Document validation

Pending action to address document validation errors

Some installments within the payment process request failed validation and the processing 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 to undergo an additional round of validation.

No

Document validation

Documents validated

Documents within the payment process request 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 within the payment process request failed validation and the processing option for handling payment validation failures is set to Stop process for review. Manual review is required.

Yes

Payment validation

Retry payment creation

The payment process request is ready to undergo an additional round of payment creation and validation.

No

Payment validation

Pending proposed payment review

Payments were created. The processing option Review proposed payments is enabled and manual review is required.

Yes

Payment file build

Waiting for payment file processing

Payments in the payment process request are either included in one or more payment files or are waiting to be picked up, such as when the Create Payment Files process is scheduled, but not yet started. This status will remain unchanged until every valid payment in an active payment process request is completed.

Depends on the status of the payment file. Monitor payment files requiring attention on the Payments Overview page.

Terminated

Terminated

The payment process request was terminated.

No

Terminated

No available installments

There are no installments available for payment that meet the selection criteria in the payment process request.

No

Terminated

Failed document validation

One or more documents payable have failed validation, and processing options are set to reject the entire payment process request, or, all documents payable have failed validation and processing options are set to anything other than Stop process for review.

No

Terminated

Failed payment validation

One or more payments have failed validation, and processing options are set to reject the entire payment process request, or, all payments have failed validation and processing options are set to anything other than Stop process for review.

No

Payables Cash Requirement Report

Forecast your immediate cash needs for invoice payments. You can submit this report before every payment process request to determine your cash requirements for the request. You can also submit this report for the next two or three payment process requests to forecast your cash requirements for the future and improve your cash management.

Run the report from the Reports and Analytics work area or the following pages: Manage Scheduled Processes, Manage Payment Process Requests, Create Payment Process Request Template, and Edit Payment Process Request Template.

Parameters

Business Unit

Specify the name of a business unit.

Template

Select the name of a payment process request template to forecast cash requirements for.

Pay Through Date

Enter a date used to determine which invoices to select for payment.

Payment Date

Enter a date used to determine the discount to be taken and to calculate interest.

Note

The report may include invoices that you plan to pay with a bill payable. If the payment date you specify is before the expected maturity date, you will not require immediate cash to pay those invoices.

Summary Option

Select the level of invoice information to report.

Include Unvalidated Invoices

Select whether to include unvalidated invoices. When you include invoices that are not validated, the amount of the invoice may change before payment. For example, invoice validation has not 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 are not approved.

Included Selected Invoices

Select whether to include invoices selected by other payment process requests.

Tip

If you use the Cash Requirement Report to predict cash needs for a payment process request that you plan to submit, it is best to exclude unvalidated invoices, unapproved invoices, and selected invoices, since the application excludes them when processing payment process requests.

Creating Payment Files Immediately: Points to Consider

You can select to create payment files immediately after a payment process request reaches a status of Waiting for payment file processing, or you can schedule the Create Printed Payment Files and Create Electronic Payment Files programs to run periodically at a specified time or frequency.

Immediate Payment File Creation

To specify immediate payment file processing, select the Create payment files immediately option on the Payment and Processing Options tab on the Submit Payment Process Request and the Create or Edit Payment Process Request Template pages. When the payment process request completes, the create payment files program runs immediately and creates payment files.

Enabling this option is convenient for a spontaneous payment run because the entire process can be completed without having to set up or wait for a process that is scheduled for a later time, but it may lead to the creation of more payment files than is necessary. It precludes grouping like payments that originated in different payment process requests into a single payment file.

Note

If you select the Create payment files immediately option, you must also specify a payment process profile in the Payment Attributes region on the Payment and Processing Options tab.

Scheduled Payment File Creation

Alternatively, you can accept the default setting for the Create payment files immediately option, which defers payment file creation.

In this scenario, an enterprise typically schedules the Create Printed Payment Files and Create Electronic Payment Files programs to run periodically. This option is especially beneficial as part of a business process where payment selection is local or decentralized, but payment processing is centralized, because payments can be built into the fewest number of payment files, without being limited by which payment process request they were created in.

Another advantage of this approach is that, when you do not select a value for payment process profile when submitting the payment process request, you allow for Oracle Fusion Payments to default one onto each document payable separately, based on the attributes of that document payable. This allows the decision of which invoices to pay to be made entirely on business needs, such as cash flow and discounts, instead of on payment method and processing needs.

Applying Credits Up to Zero Amount Payments: Examples

One of the payment processing options that you can set for a payment process request is Apply credits up to zero amount payment. This option determines whether to apply credits when credits reduce a payment amount below zero.

The following scenarios illustrate the impact of this option when credits exist in a payment process request.

Invoice Amount Greater Than Credit Amount

An invoice for 200 USD and a credit memo for 125 USD are due for payment. Regardless of how the option is set, both the invoice and credit memo are paid because the payment amount with the credit applied is greater than zero. The payment amount is 75 USD.

Credit Amount Greater Than Invoice Amount

An invoice for 200 USD and a credit memo for 225 USD are due for payment. If the option Apply credits up to zero amount payment is:

Pay Through Dates and Payment Dates in Payment Process Requests: Examples

Pay Through Date and Payment Date are among the selection criteria that a payment process request uses to determine whether to select an installment for payment and take a discount.

The following scenario illustrates the effect of Pay Through Date and Payment Date 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 is ready for payment has an installment with the following information:

The Date Basis on the payment process request is Pay date, and the Pay Date Basis on the supplier site is Discount.

This table lists examples of different Pay Through Date, Payment Date, and Always take discount option 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, 2011

July 17, 2011

Enabled or disabled

No. The Pay Through Date is before the first discount date.

None. The installment is not selected.

2

July 15, 2011

July 17, 2011

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, 2011

July 31, 2011

Disabled

Yes

None. The Payment Date is after the discount dates and the option Always take discount is disabled.

4

July 15, 2011

July 31, 2011

Enabled

Yes

150 USD. Although the Payment Date is after the discount dates, the first discount is taken because the option Always take discount is enabled.

5

July 15, 2011

August 31, 2011

Disabled

Yes

None. The Payment Date is after the due date and the option Always take discount is disabled.

Note

Interest may be calculated depending on your settings.

6

July 15, 2011

August 31, 2011

Enabled

Yes

150 USD. Although the Payment Date is after the due date, the first discount is taken because the option Always take discount is enabled.

Note

Interest may be calculated depending on your settings.

Note

In this scenario, the Date Basis on the payment process request is Pay date and the Pay Date Basis on the supplier is Discount.

If the Date Basis on the payment process request is Due date, or if the Date Basis on the payment process request is Pay date and the Pay Date Basis on the supplier is Due, 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

Date basis is one of the selection criteria that a payment process request uses to determine whether to select an installment for payment and whether to take a discount. The date basis is either Pay date or Due date.

The following scenarios illustrate the effect of the Date Basis setting in a payment process request.

Pay Date

An installment for 3,000 USD is due for payment on March 31, 2011. The installment has two discounts. The first discount date is February 15, 2011, for 150 USD. The second discount date is February 28, 2011, for 100 USD.

You submit a payment process request with the following data:

The Pay Date Basis setting on the supplier site determines whether the installment is selected for payment and whether a discount is taken.

If the supplier site Pay Date Basis is set to Discount, the installment is selected for payment because the Pay Through Date of March 30, 2011, is later than at least one of the discount dates. The first discount for 150 USD is taken because the Payment Date of February 8, 2011, is before the first discount date of February 15, 2011. If the Payment Date was after February 15, 2011, but before February 28, 2011, the second discount of 100 USD would be taken. The Payment Date determines the discount.

If the supplier site Pay Date Basis is set to Due, the installment is not selected for payment because the installment due date of March 31, 2011, is later than the Pay Through Date of March 30, 2011. The Pay Through Date determines the installment selection.

Due Date

An installment for 3,000 USD is due for payment on March 31, 2011. The installment has two discounts. The first discount date is February 15, 2011, for 150 USD. The second discount date is February 28, 2011, for 100 USD.

You submit a payment process request with the following data:

The installment is not selected for payment because the installment due date of March 31, 2011, is later than the Pay Through Date of March 30, 2011. The Pay Through Date determines the installment selection.

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 of a specific payment type. When you create a single payment, you must specify the payment type.

Payment Types

This table lists the payment types used in Payables along with their descriptions.


Payment Type

Description

Payment Process Request

A payment for one or more invoices that is processed through a payment process request.

Quick

A single payment that you create for one more invoices without submitting a payment process request.

Manual

A payment created outside of Oracle Fusion Payables, but recorded in the application.

Refund

A payment for a negative amount that closes out an outstanding credit balance.

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 actions that affect payment status.

Payment status flow

This table describes how the actions you take on a payment affect its status.


Action Taken

Status of the Payment

A payment is created and can be cashed by a supplier, a request to stop a payment is canceled, or a bill payable matured and you updated the payment status from Issued to Negotiable by submitting the Update Matured Bills Payable Status program.

Negotiable

A bill payable payment is created and has not yet matured, or a bill payable matured and you have not updated the status from Issued to Negotiable.

Issued

A stop payment request is initiated for a payment.

Stop initiated

A payment is voided and no longer valid for payment.

Voided

A payment is reconciled to a bank statement in Oracle Fusion Cash Management.

Cleared

Payment Process Attributes: How They are Assigned

Each document payable in a payment process request must be assigned a disbursement bank account and a payment process profile so it can proceed to the document validation phase of the payment process. Oracle Fusion Payments takes several steps to ensure their assignment.

Settings That Affect Payment Process Attributes

The following options affect payment processing:

How Payment Process Attributes are Assigned

Disbursement bank accounts and payment process profiles are assigned to documents payable in the following sequence of steps:

  1. You can assign the disbursement bank account and the payment process profile to all documents payable in the payment process request during the Submit Payment Process Request process. If you use a payment process request template, a disbursement bank account and a payment process profile default from the template.

  2. If you do not assign both values during payment process request submission, Payments derives missing disbursement bank accounts or payment process profiles by looking at the usage rules, by business unit, and comparing them to the attributes of each document payable in the payment process request.

    For each document payable in the payment process request, Payments selects the business unit and the payment currency from the document payable and calls an API provided by Oracle Fusion Cash Management. The payment currency is provided to ensure that the bank account is valid for the payment currency on the document payable. The API returns a list of disbursement bank accounts associated with this business unit.

    If there is only one disbursement bank account associated with a particular business unit, then Payments assigns this disbursement bank account to the document payable. Otherwise, the bank account cannot default on to the document payable and Payments sets the document payable status to Missing Account.

    For each document payable in the payment process request, Payments also selects the payment method from the document payable and attempts to derive the payment process profile associated with this payment method.

    If there is only one payment process profile associated with a particular payment method, then Payments assigns this payment process profile to the document payable. Otherwise, the payment process profile cannot default onto the document payable and Payments sets the document payable status to Missing Profile.

  3. Payments provides a code hook that, if implemented by the source product, can access the source product's custom code, which assigns missing disbursement bank accounts or payment process profiles to applicable documents payable.

    If the source product does not implement the hook, then Payments sets the payment process request to a Status of Information Required.

  4. Payments stops the payment process and you must assign missing disbursement bank accounts or payment process profiles to groups of documents payable or to individual documents payable in the Assign Payment Process Attributes and Assign Attributes at Document Payable Level pages respectively.

Note

Within a single payment process request, it is possible to cycle through some combination of steps 2, 3, or 4 on 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:

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

Oracle Fusion Payables automatically creates invoices to pay interest for overdue invoices if you enable automatic interest calculation for a supplier, and if you pay an overdue invoice in a payment process request or with a Quick payment. The interest invoice is automatically paid along with the overdue invoice.

To use automatic interest rate calculation, define the interest rates and enable the Allow interest invoices option on the Manage Invoice Options page and the Allow interest invoices option for the supplier. You can add, change, or delete a rate at any time. If a rate is not defined, a zero rate is used.

Note

Payables does not create interest invoices when you pay overdue invoices with a Manual payment.

Interest invoices have the following components:

Number

The interest invoice number is the same as the overdue invoice number, but with the suffix -INTx, where x is the count of interest invoices that were created for the overdue invoice. For example, the third interest invoice created for an overdue invoice has the suffix -INT3.

Terms

The payment terms on an interest invoice are Immediate. If you do not have Immediate terms defined, the interest invoice payment terms are the same as the overdue invoice.

Amount

The amount of the interest invoice is the interest amount owed. Payables calculates interest based on the rate you enter on the Manage Interest Rates page in accordance with the United States Prompt Payment Act. The formula used compounds monthly, up to a maximum of 365 days interest.

Currency

Interest invoices have the same invoice currency and payment currency as the overdue invoice.

Interest on Overdue Invoices: How It Is Calculated

Oracle Fusion Payables calculates interest owed to suppliers for overdue invoices.

Settings That Affect Interest Calculation

Set the Minimum interest amount invoice option and define the interest rates that are in effect.

How Interest Is Calculated

When you pay an overdue invoice, Payables uses the following information to calculate interest:

Note

Payables calculates interest in accordance with the US Prompt Payment Act, and is not an effective yearly rate. Interest is compounded monthly. For example, the interest rate on a 100 USD invoice is 7 percent. After a year, you would owe 7.23 USD in interest.

This figure shows the formula for calculating interest.

The interest formula is I equals 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:

Document Sequences in Payables: Explained

You can assign a unique voucher number to each invoice and payment document in Oracle Fusion Payables so you have a unique identifier for each document. For example, you may get two invoices with identical invoice numbers from two different suppliers. If you assign a voucher number to each, you can locate each invoice based on its unique voucher number.

Voucher numbers provide proof of completeness. If you use sequential voucher numbers, you can confirm that no document was lost.

Document Sequencing

Assigning unique voucher numbers to documents is called document sequencing.

Audit Table

When defining a new sequence, you must enter the name of the table that stores sequence audit information. For document sequences used by Payables, the audit table name is AP_DOC_SEQUENCE_AUDIT.

Document Categories

You can set up document sequencing for different types of documents or document sequence categories. For example, you may decide to assign the sequence of numbers to the Payables document category Credit Memo Invoices. Then, each credit memo you create will have a unique voucher number.

Following are some of the predefined categories that Payables provides:

FAQs for Prepare and Record Payments

What happens if no interest rate is defined for an overdue invoice?

If you enable the invoice option Create interest invoices, but do not define a rate for the day after the invoice is due, no interest is calculated and no interest invoice is 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:

In addition, when you void a payment, you can select the action you want to take on the invoices that were paid. You can cancel the invoices, place a hold on the invoices, or leave the invoices available for payment.

Can I void any type of payment?

Yes. However there are restrictions. The actions you can take on a payment depend on the type and status of the payment.

This table lists each payment action, along with the types and statuses the payment must have before you can perform that action.


Payment Action

Payment Type

Payment Status

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

Restriction

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. If, for example, a supplier tells you that they did not receive a payment that you sent them, first contact the bank and ask whether the payment was received and cleared. If it did not clear, ask the bank to initiate a stop payment and then record a stop payment request in Oracle Fusion Payables.

You can initiate a stop payment request for quick payments, refunds, and payment process requests if the payment status is Negotiable, or for bills payable if the payment status is Issued. If the bank confirms that the payment has not cleared and was stopped, you can void the payment to reverse the accounting and payment records. If the bank notifies you that the payment has cleared, you can cancel the stop payment request to reset the payment status to Negotiable or Issued.

This figure shows the life cycle of a stop payment request from when you contact the bank to when you void the payment or cancel the stop request.

Stop payment request flow

Why didn't an installment get selected for payment?

An installment can meet the selection criteria of a payment process request, yet not get selected for payment for one or more reasons.

You can review installments that were not selected for payment, along with the reasons they were not selected, on the Not Selected tab of the Review Installments page.

The reasons are as follows:

Why did the payment require a conversion rate when the conversion rate entry option is disabled?

Even if the option Require conversion rate entry is not enabled, a payment requires a conversion rate if the payment is in a foreign currency, has an invoice that is subject to automatic withholding, and automatic withholding is set at payment time. Invoices for automatically withheld taxes are always created in the ledger currency.

Record Accounting for Payments

Accounting for Invoices and Payments: Explained

You can create accounting entries for invoice and payment transactions in Oracle Fusion Payables using Oracle Fusion Subledger Accounting. Subledger Accounting creates the final accounting for subledger journal entries and transfers the accounting to General Ledger.

Payables includes a set of predefined account rules that Subledger Accounting uses to create accounting, but you can define your own detailed accounting rules in Subledger Accounting.

Payables Event Classes and Types

Payables predefines accounting event classes and accounting event types that are used by Subledger Accounting. You can modify the accounting setup to create accounting for some events and not for others.

This table describes the event classes and types that Payables predefines for invoices and payments.


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 Are Applied to Invoices

The Apply Missing Conversion Rate process automatically applies conversion rates to foreign currency invoices or payments that have no conversion rate and a conversion rate type other than User. If a foreign currency invoice is missing a conversion rate, then when you validate the invoice, the validation process applies a No rate hold, which prevents payment and accounting of the invoice.

Settings That Affect Applying Missing Conversion Rates

Run the Apply Missing Conversion Rates process if the option Require conversion rate entry is disabled.

How Missing Conversion Rates Are Applied to Invoices

The Apply Missing Conversion Rates process uses conversion rate information in the Oracle Fusion General Ledger Daily Rates table to enter conversion rates for any foreign currency invoices or payments that have no conversion rates. The next time you validate the invoice, the No rate hold is automatically removed.

Process Payment Files

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 involves the creation of a payment file that is transmitted to a financial institution. The file contains instructions that tell the 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 financial institution to issue a check for payment.

Settings That Affect Disbursements

The following settings in header region on the Create Payment Process Profile page impact electronic disbursements:

The following settings in header region on the Create Payment Process Profile page impact printed disbursements:

How Disbursements Are Processed

The following diagram shows the flow of the disbursement process:



The following table describes the action steps performed by the disbursement process:


Action

Description

Document Creation

The source product creates documents payable, such as invoices, for which it needs to make payment.

Document Selection

The source product performs a document selection process. The selected documents are grouped into a payment process request.

Payment Process Request Submission

The payment process request is submitted to Payments for processing.

Account and Profile Assignment

Disbursement bank accounts, which are the deploying company's bank accounts, and payment process profiles are assigned to documents payable within the payment process request. Payments assigns these values automatically when possible. When not possible, the user is asked to supply the values in the Assign Payment Process Attributes page.

Document Validation

Payments executes any document level validations set up on the payment method or format. Documents payable that fail validation can be automatically removed and sent back to the source product, allowing the valid documents payable to continue in the disbursement process, or the entire payment process request be stopped for resolution, depending on options set during the submission of the payment process request.

Payment Creation and Validation

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 be automatically removed and the constituent documents payable sent back to the source product, allowing the valid payments to continue in the disbursement process, or the entire payment process request be stopped for resolution, depending on options set during the submission of the payment process request.

Review and Modification

When the payment process 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 any modifications are made during the review, validations are executed again.

Payment File Creation

Payments processes payments within each payment process request and groups them according to their internal bank accounts, payment process profiles, and other grouping rules to create payment files. This processing result in payment process requests being split into different payment files or combined together into payment files.

Payment File Validation

Payments executes any payment file level validations set up on the format. Payment files that fail validation be corrected by removing payments or the validation be overridden.

Extraction and Formatting

An extract is created. This extract is an XML file that contains the superset of data relevant to the payment file. BI Publisher applies a format template to the data in the extract and the result is a formatted file which contains the subset of data specified by the format.

Transmission

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 money from the disbursement bank account to the payee bank account.

Payment Document Printing

If the payment process profile for a formatted payment file specifies printed processing, the payment file is printed onto payment documents (checks). If any checks are printed incorrectly, they can be reprinted. Once printed successfully, you can record the print status, which allows Payables to account for the payments and any other further processing.

Post-processing

After creating payments, you can optionally report on them in various ways. Separate remittance advices can be sent to suppliers, positive pay reports can be sent to bank-printed payments to prevent fraud, regulatory reports can be sent to statutory organizations, and a payment file register can be created for internal use.

Submit Separate Remittance Advice: How It Is Processed

The Submit Separate Remittance Advice is an Enterprise Scheduler Service (ESS) process that creates a report that is sent to a payee (supplier). The report lists the invoices paid with each payment by the deploying company. Oracle Fusion Payments works with Oracle BI Publisher to support separate remittance advice creation and delivery. This is an optional feature initiated by the deploying company.

Settings That Affect Submit Separate Remittance Advice

The following payment process profile setup settings affect the Separate Remittance Advice report:

Note

A delivery method is set on both the payment process profile and optionally on each supplier site. The delivery channel on the supplier site takes precedence unless the Override Payee Delivery Method Preference check box is selected on the payment process profile.

How the Submit Separate Remittance Advice Report Is Processed

The following table describes the flow of events associated with the Submit Separate Remittance Advice report:


Action

Description

The application reads the separate remittance advice setup from 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.

Is separate remittance advice requested?

If the payment process profile indicates that no separate remittance advice is required, then this flow is complete.

If a separate advice is required, then the flow continues.

The application reads the delivery method.

The payment process profile also contains the remittance delivery method. The delivery method specifies how the formatted data is to be delivered to the payee. Delivery methods supported by Payments include E-Mail, print, and facsimile.

Note

Delivery of the actual payment file occurs outside Oracle BI Publisher and is managed as a completely separate process.

The application reads the delivery address from Trading Community Architecture (TCA).

Once the delivery method is determined, then the delivery address, whether an E-Mail address, fax number, or mailing address, is read from the TCA model.

The application passes the extract XML message to Oracle BI Publisher.

The extract XML message is sent to Oracle BI Publisher for formatting of the remittance advice.

Oracle BI Publisher applies the applicable format template to the XML message.

Oracle BI Publisher uses templates to format an XML message. Payments tells Oracle BI Publisher which format template to apply to the XML message.

Oracle BI Publisher formats the remittance advice, stores the output, and delivers the Separate Remittance Advice report.

Oracle BI Publisher formats the remittance advice and stores the output. It then delivers the advice to the third-party payee using the specified delivery method.

Positive Pay File: How It Is Generated

When you navigate to the Oracle Enterprise Scheduler submission page, you can manually run a report process called Create Positive Pay File. This process, in turn, invokes the Disbursement Positive Pay File Formats report. Alternatively, you can automatically generate the report by selecting an option during setup of the payment process profile. The report process, Create Positive Pay File, creates a positive pay file, formats it, and then transmits it electronically to your payment system or bank. A positive pay file is a security measure that prevents check fraud by informing your payment system or bank which payment documents are issued and for what amounts. The positive pay file prevents the payment system or bank from paying fraudulent checks, since unauthorized payments are not listed on the positive pay file.

Parameters That Affect a Positive Pay File

The following parameters affect the output of the positive pay file report when it is manually run from the Oracle Enterprise Scheduler submission page:

During set up of the payment process profile, you can optionally choose to enable automatic generation of the Create Positive Pay File process by selecting the Automatically transmit file check box on the Create Payment Process Profile page, Reporting tab, Positive Pay region. Additional parameters located in the Positive Pay region, for which you either select an option or enter data, include the following:

How a Positive Pay File Is Generated

The manual process for generating a positive pay file is as follows:

  1. Run the Create Positive Pay File Oracle Enterprise Scheduler process with appropriate parameters.

  2. The Oracle Enterprise Scheduler process selects payments that have a status of Completed and which have a payment process profile with a positive pay format specified.

  3. Payments invokes Oracle Business Intelligence Publisher (BI Publisher), which takes Payments data and generates the positive pay file for each payment file.

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

The automatic process for generating a positive pay file is as follows:

  1. On the Create Payment Process Profile page, on the Reporting tab in the Positive Pay region, select the Automatically transmit file check box.

  2. The Create Positive Pay File process automatically runs and creates a positive pay file for each payment file the report is run against

  3. Payments submits the positive pay file process as soon as the payments in the payment file are confirmed.

    Note

    No user input is required since Payments has the payment file information and it has the positive pay format to use from the payment process profile.

Confirming Electronic Payment Files: Explained

A confirmed electronic payment file is one that is complete and considered done. Oracle Fusion Payments must notify source products when payments are confirmed, so the source products can perform necessary actions, such as accounting. The point at which an electronic payment is considered confirmed depends on the deploying company's business practices, as well as on what notification the payer's payment system supports, such as acknowledgment and clearing.

Electronic payment files can be confirmed by:

Specifying an Automatic Payment File Confirmation Point

When creating a payment process profile during setup, you can specify the point at which an electronic payment file is automatically confirmed. This confirmation point can be either when the payment file is formatted, or when it is transmitted to the payment system.

Manually Confirming Payment Files

When creating a payment process profile during setup, you can also specify whether you want to enable manual confirmation of the payment file. Payments enables you to manually confirm payment files before they are confirmed automatically. You may need this option available for timing reasons. You can make manual confirmations of electronic payment files from the Manage Payment Files page by selecting the applicable payment file row from the search results and then selecting the applicable option from the Actions menu. Similarly, you can also manually confirm a payment file directly on the applicable Payment File page using the Actions menu.

Important

Once the payments in a payment file are confirmed, the source product is notified. Simultaneously, you can no longer terminate the payment file. Instead, if there are 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 the payment administrator.

Settings That Affect Printed Payment Files Statuses

The following settings in the header region on the Create Payment Process Profile page impact printed payment file statuses:

If you choose not to print payment files immediately, thereby deferring the printing process, you must submit the payment file for printing manually. This manual submission is done on the Print Payment Documents page.

How Printed Payment Files Statuses Are Impacted

This figure shows the flow of statuses associated with the creation of printed payment files, which includes printing to a file as well as to a printer.

Flow of statuses associated with the
creation of printed payment files

The following table describes how actions performed by Payments or the payment administrator change the status of the printed payment file.


Action Taken by Payments or the Administrator

Status of the Printed Payment File

The payment file has been created and validated, but has failed validation and is waiting for the administrator to take remedial action.

Failed validation and pending action

The administrator has reviewed a payment file that has failed validation and removed payments or overridden errors. This is a transient status which prompts Payments to validate the payment file again.

Retry payment file validation

The payment file has passed validation. This is a transient status which prompts Payments to start the formatting process.

Created

The payment file has been terminated and the documents payable have been returned to the source product.

Terminated

The payment file has failed formatting and the administrator has been prompted to take remedial action.

Failed formatting and pending action

Payments has been set up to allow printing outside the application rather than within it. The data extract has been created and formatting has been completed. The payment file has been created and formatted, and is ready to be recorded.

Formatted and ready for recording

Payments has been set up to allow printing outside the application rather than within it. Creation of the data extract and formatting are incomplete for a printed payment file because another payment file has locked the payment document. The payment file has been created and is ready to be formatted.

Created and ready for formatting

Creation of the data extract and formatting are incomplete for a printed payment file because another payment file has locked the payment document. The payment file has been created and is ready to be printed.

Created and ready for printing

Creation of the data extract and formatting has been completed for a printed payment file. Payments has been set up to print immediately, but the print program has not yet submitted the file to Business Intelligence Publisher (BI Publisher). The payment file has been created and formatted. Note that this is a very short-lived status and is rarely seen by administrators.

Formatted

Creation of the data extract and formatting has been completed for a printed payment file. Payments has been set up for deferred printing. The payment file has been created and formatted and is ready to be printed.

Formatted and ready for printing

The administrator has initiated the print run on the Print Payment Documents page or the Reprint Payment Documents page. The payment file has been sent to the printer and is ready for you to reprint payments or record print status.

Submitted for printing

The administrator has recorded the final print status on the Record Print Status page.

Printed

The administrator has voided a payment. There are no valid payments left in the payment file, causing the payment file to be automatically terminated.

Terminated, if the payment was the last in the file; otherwise no change.

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 the payment administrator. An electronic payment file is transmitted to a payment system or financial institution for further processing and disbursement.

Settings That Affect Electronic Payment File Statuses

The following settings in the header region on the Create Payment Process Profile page affect electronic payment file statuses:

How Electronic Payment File Statuses Are Impacted

This figure shows the flow of statuses associated with the creation of electronic payment files.

The creation of electronic payment
files

The following table describes how actions performed by Payments or the payment administrator change the status of the electronic payment file:


Action Taken by Payments or the Administrator

Status of the Electronic Payment File

The payment file has been created and validated, but has failed validation and is waiting for the administrator to take remedial action.

Failed validation and pending action

The administrator has reviewed a payment file that has failed validation and removed payments or overridden errors. This is a transient status which prompts Payments to validate the payment file again.

Retry payment file validation

The payment file has passed validation. This is a transient status which prompts Payments to start the formatting process.

Created

The payment file has been terminated and the documents payable have been returned to the source product.

Terminated

The payment file has failed formatting and the administrator has been prompted to take remedial action.

Failed formatting and pending action

The payment file has been formatted. Per the setup in the payment process profile, transmission will be completed external to Payments, so no further action is expected.

Formatted

The payment file has been formatted and is ready for transmission to the payment system or financial institution.

Formatted and ready for transmission

Payments has successfully transmitted an electronic payment file to the payment system or financial institution.

Transmitted

Payments has failed to transmit an electronic payment file to the payment system or financial institution.

Transmission failed

The administrator has ignored a transmission failure after confirming transmission outside Payments and has overridden it on the Resolve Payment File Transmission Failure page. The payment file has been successfully transmitted to the payment system or financial institution.

Transmitted

The administrator has voided a payment. There are no valid payments left in the payment file, causing the payment file to be automatically terminated.

Terminated

Skipped and Spoiled Payment Documents: Explained

A skipped prenumbered payment document is one where the payment was printed onto a payment document with a different number. A spoiled prenumbered payment document is one that is ruined and that you do not intend to reprint.

The following scenarios can occur with skipped or spoiled payment documents:

Skipped Prenumbered Payment Document

Prenumbered payment documents are those that have the document or check number already printed on them.

If your printer skips a prenumbered 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 save the skipped prenumbered payment document for use in a future single payment or a manual payment, or you can manually destroy the paper document and void it in Oracle Fusion Cash Management on the Edit Bank Account page.

Spoiled Prenumbered Payment Document

A spoiled payment document is one that was ruined during printing and cannot be used. Prenumbered payment documents are those that have the document or check number already printed on them.

If you choose to reprint, perform both of the following steps:

  1. Reprint the spoiled prenumbered payment onto a new prenumbered 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 prenumbered payment document, associates the new number with that payment, and reprints the new prenumbered payment document.

If you choose not to reprint, mark the prenumbered payment document as spoiled on the Record Print Status page and then manually destroy the paper document.

Tip

Click the Mark as Spoiled button only if you are not going to reprint the spoiled prenumbered payment document.

Spoiled Blank Payment Document

A spoiled payment document is one that cannot be used. Blank payment documents are those that do not 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 manually destroy the spoiled blank payment document.

The application takes no action.

If you choose to reprint, perform both of the following steps:

1. Reprint the spoiled blank payment 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 the spoiled blank payment 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:

Retransmitting the File

Retransmitting the file assumes that any previous transmission failure was the result of a transient problem or that setup has been corrected since the original attempt to transmit. This action initiates transmission again and attempts to retransmit the payment file.

Ignoring the Transmission Failure

Ignore the transmission failure when you need to force the payment file status to Transmitted after successfully transmitting the file outside the application or confirming 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

You can decide to terminate the payment file. When you take this action, the application sets the status of the payment file to Terminated. Oracle Fusion Payments informs the source product of the terminated documents payable. Then for each payment in the payment file, Payments sets the status to Canceled. The source product unlocks the documents and resets their status so that the documents are available for future selection.

Resolving Payment File Validation Errors: Critical Choices

In payment processing, it is 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 payments or 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 options:

Overriding the Validation Error

To resolve payment file validation errors, you can override certain validation 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 resolution, the payment process proceeds to formatting and then printing or transmitting 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, then the validation error is no longer applicable. For example, suppose a deploying company has a payment file validation that specifies that the total amount of a payment file cannot be more than 1 million USD and the payment file is comprised of 12 payments. This validation error can be remedied 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, the payment administrator does not have the option of removing individual documents payable from a payment.

Changing the Payment Method Setup or Format Setup

You can assign seeded validations or create user-defined validations when you create a payment method during setup. You can also assign seeded validations to payment formats during setup. One way to resolve an unwanted payment file validation is to modify or remove it from the applicable payment method or payment format.

Payment Document Number Generation for Electronic Payments: How They Are Processed

Oracle Fusion Payments enables you to generate paper document numbers for electronic payments. The paper document numbers can be sent to your payment system or bank so they can be printed on your outsourced checks. To achieve this, you assign paper document numbering values, which are check numbers, to electronic formats. This enables the application to generate a paper document number for electronic payments. Additionally, Payments generates a unique number, known as a payment reference number, that identifies each payment record. This identifier is also transmitted to your payment system or bank.

If you do not enable paper document numbering for electronic payments, then the application-generated payment reference numbers are stamped on electronic payments and passed to Oracle Fusion Payables as the reference numbers.

If you do enable payment document numbering for electronic payment files, then payment document numbering values are stamped on electronic payments, in addition to the application-generated payment reference numbers. The payment document numbering values are passed to Payables as the reference numbers.

Settings That Affect Payment Document Number Generation for Electronic Payments

The following settings on two user interface pages and on two Oracle Enterprise Scheduler submission pages affect payment numbering of electronic payments:

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:

Values displayed in the Payment Document choice list on the preceding submission pages, depend on options selected from other choice lists on these same pages, as described in the following table.


Submission Pages

Choice List Selections that Affect Payment Document Options Displayed

Create Electronic Payment File

Selection of an option from the Payment Document choice list is optional.

If you select an option only from the Disbursement Bank Account choice list as a parameter, then the Payment Document choice list displays all payment documents created for the selected internal bank account.

If you select an option only from the Payment Process Profile choice list as a parameter, then the Payment Document choice list displays all payment documents associated with the payment file format selected on the payment process profile.

If you select options from both the Disbursement Bank Account choice list and the Payment Process Profile choice list as parameters, then the Payment Document choice list displays 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

Selection of an option from the Payment Document choice list is optional.

If you select an option only from the Disbursement Bank Account choice list as a parameter, then the Payment Document choice list displays all payment documents created for the selected internal bank account.

If you select options from both the Disbursement Bank Account choice list and the Payment Process Profile choice list as parameters, then the Payment Document choice list displays 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 may result in multiple payment files. When this occurs, the following behavior applies:

  1. The first payment file refers to the applicable payment document and 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. Once the first payment file is transmitted, the applicable payment document is released and you can assign it to another payment file.

    Note

    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 cannot assign your payment document to the applicable payment file because it is already in use by another payment file.

FAQs for Process Payment Files

What's a payment validation?

Payment validations are rules that ensure that 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 keep costs down by preventing invalid data from getting to 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 which object they are attached to:

If the validation is attached to a payment method, it:

If the validation is attached to a format, it:

Validations can be predefined or user-defined. Predefined validations are seeded, and are complex groupings of validations that can conveniently be assigned to payment methods or formats. Oracle Fusion Payments associates some predefined validations to seeded payment formats by default. User-defined validations, on the other hand, are completely granular. During implementation, they can be specified one attribute at a time. Any combination of predefined and user-defined validation can be assigned.

What happens if I terminate the payment process?

You can decide to terminate the payment process by terminating the payment file. When you take this action, the application sets the status of the payment file to Terminated and informs the source product of the terminated documents payable. Then, for each payment in the payment file, the application sets the status to Canceled. The source product unlocks the documents and resets their status so that they are available for future selection.

How can I unlock the payment document locked by another payment file?

Before you can format and print a payment file, you must ensure that the payment document you are printing onto is available. For example, if the payment documents or check stock are being used to print onto by Payment File 1, they are unavailable and considered locked. To make the locked payment documents available, you must first record the print status for Payment File 1 before you can print Payment File 2 onto payment documents.

What happens to payment numbering if I reprint a range of prenumbered payment documents?

You can reprint documents that have been damaged during the initial printing. To do this, the application marks the original payment documents as void and assigns new payment document numbers to each payment. The payment administrator specifies the range or ranges of documents that were spoiled, and specifies the payment document number on which to start the reprint. The application then renumbers and reprints the spoiled payments. The range allows the same number to be entered in the Document Number From field and the Document Number To field so a single document payable can be reprinted.

Reprinting allows affected documents payable to be successfully paid, despite initial printing issues, and is 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 prenumbered payment documents?

The application retains the original numbering when reprinting the entire file. This option is intended only for cases where no printing was started. If you reprint the entire payment file after successfully printing one or more prenumbered payment documents, the numbering on the prenumbered payment documents will be incorrect.

Warning

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

Why did the payment file transmission fail?

Occasionally, a payment file transmission fails.

Transmission failures occur for the following reasons:

What's a confirmed printed payment?

Printed payments are considered confirmed when the payment documents are recorded as printed on the Record Print Status page.

Once the payments in a payment file are confirmed, the source product is notified. Simultaneously, you can no longer terminate the payment file. Instead, you must void any payments with issues. The Terminate Payment Process action, therefore, does not appear on any page that appears in the context of a payment file whose payments were confirmed.

When does the payment administrator manually confirm electronic payment files instead of letting them be automatically confirmed?

The payment administrator confirms electronic payment files manually because the timing of the confirmation point relies on an external event, such as a notification from a bank that the payment file has been processed. Manual confirmation occurs when all of the following conditions are met: