Skip Headers

Oracle Payments User's Guide
Release 12.1
Part Number E13415-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Funds Disbursement Process Home Pages

Payment Process Overview

To present a simplified overview of the Oracle Payments payment process, the process begins when a source product, such as Oracle Payables, needs to pay documents payable, such as invoices. Oracle Payables groups the documents payable into a payment process request and submits it to Oracle Payments. Within Oracle Payments, the Build Payments program groups documents payable into groups known as payments, which represent individual checks or electronic deposits. The Create Payment Instructions program groups payments into payment instructions. Payment instructions are then printed or submitted electronically to payment systems or banks.

Managing the Payment Process

You can manage the payment process from the Oracle Payments Funds Disbursement Process Home Page or from the Payment Manager Dashboard in Oracle Payables. Your choice depends on:

Oracle Payments Funds Disbursement Process Home Page

The Funds Disbursement Process Home Page should be used when the deploying company uses a centralized payment processing system. Centralized payment processing is where one person or team is dedicated to payment processing, but not to Oracle Payables functions such as invoice selection and payment process request submission. It is that person's or team’s responsibility to ensure that the payments are paid. In this scenario, a user who is responsible for the payment process only, and not the Oracle Payables payment functions of entering invoices and submitting payment process requests, may decide to use the Funds Disbursement Process Home Page, but he has a choice.

If the deploying company sets up Oracle Payments so that the Create Payment Instructions program is run separately from the Build Payments program, then payments from different payment process requests are mixed together when creating payment instructions, and it is more difficult to follow the payment process from the perspective of the payment process requests. In this case, users are advised to use the Funds Disbursement Process Home Page.

Oracle Payables Payments Dashboard

The Oracle Payables Payments Dashboard should be used when the deploying company uses a decentralized payment processing system. Decentralized payment processing is where more than person or team performs multiple payment functions, such as selecting the invoices to be paid, making the payments, and remedying any problems that occur with the payment process. In this scenario, a user who is responsible for invoice selection and the submission of payment process requests, as well following the payment process, may decide to use the Oracle Payables Payments Dashboard.

Overview of the Funds Disbursement Process Home Pages

The Funds Disbursement Process Home page is the first page the Payment Administrator sees after logging in. This page and its subsidiary pages enable the Payment Administrator to monitor and manage the payment process described in the previous section.

The Funds Disbursement Process Home page is a read-only page that includes a Pending Actions region that displays the current status of payment process requests and payment instructions that are in-process. The Pending Actions region contains links to detailed views of these entities, as well as Take Action links to pages that enable the Payment Administrator to take the next step in the payment process. The Funds Disbursement Process Home page also contains links to other pages that are relevant to, but not necessarily part of, the payment process.

During the payment process, the Payment Administrator uses the Funds Disbursement Process Home page to:

Submitting and Monitoring Funds Disbursement Concurrent Requests

The Concurrent Requests subregion of the side navigation bar enables the Payment Administrator to quickly submit and monitor any concurrent requests. Like the links in the Shortcuts subregion, these links enables the Payment Administrator to specify applicable parameters, schedule the concurrent request, and then monitor the submission.

The table below describes the funds disbursement concurrent programs provided by Oracle Payments.

Funds Disbursement Concurrent Programs
Funds Disbursement Concurrent Programs Description
Create Electronic Payment Instructions Selects electronic payments and groups them into payment instructions.
Create Printed Payment Instructions Selects printed payments and groups them into payment instructions.
Create Regulatory Reporting of Payments Creates regulatory reports or central bank reports.
Format Payment Instructions Uses XML Publisher templates to format payment instructions into payment files.
Payment File Accompanying Letter Creates an accompanying letter for a payment instruction file.
Payment Instruction Register Creates a report, displaying the contents of a payment instruction.
Payment Process Request Status Report Displays the contents and status of a payment process request.
Positive Pay File Creates a positive pay file for each payment instruction the concurrent program is run against.

Note: If you run this program using the SRS functionality, the list of values for the Payment Process Profile field in the Schedule Request: Parameters page displays only payment process profiles that are limited to one or more internal bank accounts. Payment process profiles that can be used with all bank accounts do not appear in this list of values.

Reset Periodic Sequence Value Resets periodic sequences to a specified number or letter. Periodic sequences can be specified in the payment process profile setup entity.
Send Separate Remittance Advices Creates remittance advices that notify payees that payments have been made to them.

Actions the Payment Administrator Performs from the Funds Disbursement Process Home Page, Pending Actions Region

The table below describes actions the Payment Administrator can perform from the Funds Disbursement Process Home page, Pending Actions region. Note that the actions described in the table below do not always need to be invoked; only when necessary and/or required by Oracle Payments settings.

Actions the Payment Administrator Performs from the Funds Disbursement Process Home Page
Payment Process Type Status of Payment Process Type Clicking Take Action Icon Opens Action Payment Administrator Performs
Payment Process Request Information Required - Pending Action Complete Document Assignments page Enables the Payment Administrator to assign internal bank accounts and payment process profiles to documents payable. Only used if the source product administrator does not provide this information.
Payment Process Request Document Validation Errors - Pending Action Resolve Document Validation Errors page Enables the Payment Administrator to review and resolve document-level validation errors by dismissing individual documents payable from the payment process and/or by modifying Oracle Payments setup. Only used if Oracle Payments settings require document-level validation errors to be reviewed by a user.
Payment Process Request Payment Validation Errors - Pending Action Resolve Payment Validation Errors page Enables the Payment Administrator to review and resolve payment-level validation errors by dismissing individual payments or documents payable from the payment process and/or by modifying Oracle Payments setup. Only used if Oracle Payments settings require payment-level validation errors to be reviewed by a user.
Payment Process Request Pending Proposed Payments Review Review Proposed Payments page Enables the Payment Administrator to review and approve or remove proposed payments after the Build Payments program has created them and before the payments are grouped into payment instructions. Only used if Oracle Payment settings require the review of proposed payments.
Payment Instruction Failed Validation Errors - Pending Action Resolve Payment Instruction Validation Errors page Enables the Payment Administrator to review and resolve payment instruction-level validation errors by dismissing individual payments from the payment process, by modifying Oracle Payments setup, or by choosing to override certain errors. Always used for payment instruction-level validation errors.
Payment Instruction Formatted - Ready for Transmission Transmit Payment Instruction page Enables the Payment Administrator to initiate payment instruction transmission. Only used for those payment instructions that are not transmitted to the payment system automatically, based on Oracle Payments settings.
Payment Instruction Transmission Failed Resolve Payment Instruction Transmission Failure page Enables the Payment Administrator to respond to a transmission failure by retransmitting the file or by ignoring the failure by recording that the transmission was successful. Always used for failed payment instruction transmission.
Payment Instruction Formatted - Ready for Printing Print Payment Documents page Enables the Payment Administrator to initiate payment document printing within Oracle Payments. Only used for those payment instructions that are not submitted for printing automatically, based on Oracle Payments settings.
Payment Instruction Created - Ready for Printing Print Payment Documents page Enables the Payment Administrator to initiate payment document printing within Oracle Payments. Always used for payment instructions for which formatting and printing are deferred due to another payment instruction locking the payment document needed to print the payments.
Payment Instruction Created - Ready for Formatting Print Payment Documents page Enables the Payment Administrator to initiate payment document printing outside Oracle Payments, that is, initiate printing to file. Always used for payment instructions for which formatting and printing are deferred due to another payment instruction locking the payment document needed to print the payments.
Payment Instruction Submitted for Printing Payment Instruction page with a choice of navigating to the Record Print Status page or the Reprint Payment Documents page The Reprint Payment Documents page enables the Payment Administrator to reprint spoiled payment documents. Always available for payment instructions printed within Oracle Payments. The Record Print Status page enables the Payment Administrator to record the status of printed payment documents, including spoiled payment documents that should not be reprinted and skipped documents. This action also marks payments complete. Recording print status is a required action for printed payment instructions. This method of recording is always available for payment instructions printed within Oracle Payments.
Payment Instruction Formatted - Ready for Recording Record Print Status page Enables the Payment Administrator to record the status of printed payment documents. This action also marks payments complete. Recording print status is a required action for printed payment instructions. This method of recording is always available for payment instructions printed outside Oracle Payments, that is, printed to file.
Stop Payment Request Printed Resolve Stop Payment Request page Enables the Payment Administrator to confirm or release a stop. Always used for payments that have a previous stop request placed on them.

Note: The following sections describe actions that the Payment Administrator performs from the Funds Disbursement Process Home page. These actions are not presented in any particular order.

Completing Assignments

Source products are allowed to submit documents payable to Oracle Payments without assigning an internal bank account or a payment process profile to them. The Complete Assignments page and its subsidiary pages are used to assign required entities to documents payable, so that Oracle Payments has the necessary information to continue with the payment process. This page enables Payment Administrators to perform the first action that they can take during the payment process, which is to assign internal bank accounts and payment process profiles to documents payable. While providing this information, Payment Administrators can also change the assignments of documents that already have this information.

Important: Once internal bank account and/or payment process profile information has been supplied for all documents and the payment process restarted, no assignments can be changed.

Resolving Document Validation Errors

Once all documents payable have been assigned all required attributes, the Build Payments program validates them, based on applicable validations assigned in Oracle Payments setup. When submitting the payment process request, the source product specifies whether documents that fail this document validation are rejected or whether the Build Payments program simply stops the payment process for review by the Payment Administrator.

If review is required for failed documents, the Payment Administrator navigates to the Resolve Document Validation Errors page to review the validation errors, dismiss individual documents payable from the payment process, if necessary, and restart the Build Payments process when the errors have been resolved.

The Payment Administrator can also leave the Funds Disbursement Process pages altogether in order to change setup or third party payee data that may have caused the error, and then return to the Resolve Document Validation Errors page to restart the Build Payments process.

Resolving Payment Validation Errors

The Resolve Payment Validation Errors page enables the Payment Administrator to resolve validation errors at the payment level. This page displays the proposed payments and validation errors, as well as the documents payable that comprise each proposed payment.

Once payments have been built from documents payable, the Build Payments program validates them, based on applicable validations assigned in Oracle Payments setup. When submitting the payment process request, the source product specifies whether payments that fail this validation are rejected or whether the Build Payments program simply stops the payment process for review by the Payment Administrator.

If review is required for payments that fail validation, the Payment Administrator navigates to the Resolve Payment Validation Errors page to review the validation errors, remove documents payable or entire payments, if necessary, and restart the Build Payments process when the errors have been resolved. The Payment Administrator can also leave the Funds Disbursement Process pages altogether to change setup or third party payee data that may have caused the error, and then return to the Resolve Payment Validation Errors page to restart the Build Payments process.

Reviewing Proposed Payments

The Review Proposed Payments page enables the Payment Administrator to review and approve proposed payments after the Build Payments program has created them. This page displays all proposed payments after they have passed validation, as well as the documents that comprise each proposed payment.

When submitting the payment process request, the source product specifies whether the Build Payments process is stopped for payment review once the proposed payments are built. If review is required for proposed payments, the Payment Administrator navigates to the Review Proposed Payments page to review payments, remove payments or individual documents, if necessary, and then restarts the Build Payments process.

Resolving Payment Instruction Validation Errors

Once payment instructions have been built from payments, the Create Payment Instructions program validates them, based on applicable validations assigned in Oracle Payments setup. If a payment instruction fails validation, it is always stopped for review. The Resolve Payment Instruction Validation Errors page enables the Payment Administrator to review, resolve, or override validation errors found by the Create Payment Instructions program. This page displays the following:

The Payment Administrator can remove payments, if necessary, leave the Funds Disbursement Process pages altogether to change setup or third party payee data, or, in the case of some errors, override the validation errors. If the validation errors are overridden or resolved, the payment process proceeds to formatting and then printing or transmitting the payment instruction.

Note: At this action step, the Payment Administrator does not have the option of removing individual documents payable.

Payment Instruction Status of Created

If you notice that the Create Payment Instructions program has stopped, leaving a payment instruction with a status of Created, as seen in the Status column under the Pending Actions region of the Funds Disbursement Process Home page, or on the Payment Instruction Search page, you can move the Created status to a formatting phase by running the Format Payment Instruction program.

To run the Format Payment Instruction program, perform either of the following steps:

Note: The preceding actions are error-recovery procedures only. Normally, when a payment instruction successfully finishes validation, the Format Payment Instruction program is run automatically, moving the payment instruction beyond the Created status.

Transmitting Payment Instructions

Payment instructions that are electronic, as opposed to printed checks, must be transmitted to a payment system. This transmission occurs automatically or is deferred, based on Payments setup. If Oracle Payments is set up to defer payment instruction transmission, the Payment Administrator navigates to this page to manually initiate the transmission.

The Transmit Payment Instruction page enables the Payment Administrator to initiate payment instruction transmission for those payment instructions that are not transmitted to the payment system automatically. This page enables the Payment Administrator to review payment instruction and transmission details before transmitting the instruction.

Note: This action step is the Payment Administrator’s final opportunity to terminate a payment instruction.

Resolving Payment Instruction Transmission Failure

Occasionally, a transmission fails. The Resolve Payment Instruction Transmission Failure page enables the Payment Administrator to respond to a transmission failure by taking one of the following actions:

The Resolve Payment Instruction Transmission Failure page displays an overview of the payment instruction, along with transmission details.

Printing Payment Documents

Oracle Payments setup enables the Payment Administrator to choose whether payment instructions are printed immediately after a payment instruction is formatted. For those payment instructions that are not printed immediately, the Payment Administrator must manually submit them for printing.

Manual submission occurs in the Print Payment Documents page. This page enables the Payment Administrator to initiate payment document printing for those payment instructions that are submitted manually for printing, rather than automatically. The Print Payment Documents page enables the Administrator to review basic details of a payment document and to override the default printer before submitting the payment instruction for printing.

In the case where a payment instruction is not formatted and printed because another payment instruction has locked the payment document (see below), this page is used to initiate both formatting and printing. In the case where a payment instruction is supposed to be printed outside Oracle Payments, that is, printed to file, this page is used to initiate formatting.

The Print Payment Documents page prints both prenumbered and non-prenumbered payment documents. Behind the scenes, the print program invokes Oracle XML Publisher to print the payment instruction onto checks or into a payment file that is transmitted to a payment system for further processing and disbursement.

Note: This action step is the Payment Administrator’s final opportunity to terminate the payment instruction.

Locking and Numbering Payment Documents

This section discusses printing in general, not just printing that is manually initiated by the Payment Administrator.

Note: The term payment instruction refers to a collection of payments, as built by the Create Payment Instructions program. The term payment document can refer to the stock of paper that is used to print payments onto, such as check stock or a check book. Alternately, payment document can also refer to a physical payment, such as a printed check, which is printed onto a single piece of check stock.

Payment document printing can occur immediately after payment instruction creation or later at the Payment Administrator’s request. Both the Print Payment Documents page and the Create Payment Instructions Program use the Format Payment Instructions program to perform the necessary print tasks. This program initiates payment document printing by internally tracking the numbering of the payment documents and locking the payment documents. For each payment instruction, Oracle Payments performs the following steps:

  1. The system checks whether the required payment document is available for printing. If the payment document is unavailable, printing cannot continue:

  2. Oracle Payments internally tracks the numbering of all the payments contained in a payment instruction, including the setup and overflow documents.

    Setup documents are occasionally required by older printing systems. These prenumbered setup checks are discarded after the print run, but the system tracks their numbers.

    Overflow documents are checks that are voided due to a continuation of descriptive text on more than one check stub. This occurs when the number of lines of descriptive text printed per check stub exceeds the maximum allowed.

  3. The Format Payment Instructions program sends the payment instruction to Oracle XML Publisher for printing.

Reprinting Payment Documents

The Reprint Payment Documents page is optional. If a Payment Administrator finds no problems with the initial print run or does not need to reprint, he can navigate directly to the Record Print Status page. The Reprint Payment Documents page can be used if, after printing has been submitted, the Payment Administrator discovers printing problems and wishes to reprint particular payment documents or the complete payment instruction. This page enables the Payment Administrator to reprint individual payment documents, ranges of payment documents, or the complete payment instruction, and then submit those payment documents for printing.

Note: The Payment Administrator must visually inspect whether the checks printed. He can reprint the complete payment instruction only if the initial print run has not started.

The Reprint Payment Documents page enables the Payment Administrator to:

Note: The Reprint button is available only after Oracle Payments attempts to print a payment document. In the reprint scenario, the payment document is still locked from the initial printing attempt.

Warning: Do not reprint the complete payment instruction if the initial printing attempt resulted in one or more checks printing successfully. If you reprint the entire payment instruction after successfully printing one or more payment documents, the numbering on the prenumbered payment documents may be incorrect. If printing did commence, but you need to reprint every payment document in the payment instruction, choose to reprint a range of payment documents and enter the first and last documents in the payment instruction as the range.

Those payment documents that are selected for reprint are automatically marked as Spoiled. Because payment document numbers cannot be reused for prenumbered payment documents, reprinting on prenumbered payment documents requires the Payment Administrator to provide the first document number for the reprints. Oracle Payments can then correctly renumber the payments.

Recording the Print Status of Prenumbered Payment Documents

Since the actual printing occurs outside of Oracle Applications and has many potential failure points, Oracle Payments does not know the outcome of printing or reprinting payment documents. Consequently, the Payment Administrator needs to provide that information to Oracle Payments through the Record Print Status page. This page enables the Payment Administrator to:

By default, payment documents that have been marked spoiled during the reprinting process are displayed as Spoiled in the Record Print Status page, but all other payment documents are initially displayed as Printed. For those payment documents that actually are spoiled or skipped, the Payment Administrator must enter applicable documents in the Record Spoiled Payment Documents region or the Enter Skipped Payment Documents region of the Record Print Status page.

The Record Print Status page also enables the Payment Administrator to choose whether to submit the Positive Pay program immediately after he finishes recording the print status, if the applicable setup enables the choice. The program creates a positive pay file, formats it, and transmits it electronically to your bank. This prevents check fraud by informing the bank which payment documents are issued and for what amount.

Important: Do not commit all print statuses unless you are sure that all documents with the status of Printed were successfully printed. If you click the Apply button, the payments are marked as complete and the payment documents are recorded as Printed. If you complete this action and discover printing errors, you will need to void the payment and select the documents to be paid in a new payment process.

Recording the Print Status of Non-Prenumbered Documents

When a payment document is not prenumbered, no renumbering needs to be done when payment documents are skipped. This is because the skipped document is simply a blank piece of paper that can be used in a new print run.

Spoiled payment documents that have not been reprinted and that you wish to remove, rather than reprint, do need to be marked, so that Oracle Payments can consider those payments failed and notify source products appropriately.

As with prenumbering, the Record Print Status page displays the Printed status by default. Since reprinting non-prenumbered documents involves using the same document number, rather than renumbering, all payment documents are shown with the status of Printed when the Payment Administrator first enters the Record Print Status page.

Marking payment documents as Spoiled in the Record Spoiled Payment Documents Region, and later committing them through the Review Record Print Status page, results in the removal of the associated payments from the payment instruction and informs the relevant source products that the documents payable have not been paid.

Marking Payments Complete

Oracle Payments must notify source products when payments are complete, so that the source products can perform any necessary actions, such as accounting. Printed payments are considered complete when the payment documents are recorded as Printed. For electronic payments, however, determining the point at which a payment is considered complete is more complex and depends on the first party payer’s business practices, as well as on what notification (acknowledgement and clearing) the payer’s payment system supports. An electronic payment can be considered complete any time after formatting.

In general, electronic payments in a payment instruction are automatically marked complete at some point chosen during the setup of payment process profiles. However, Oracle Payments also enables Payment Administrators to manually mark payments complete, before they are marked automatically. For information on setting up completion behavior, see Setting Up Payment Process Profiles., Oracle Payments Implementation Guide.

To mark payments complete manually, the Payment Administrator navigates to the Mark Payments Complete page from the Funds Disbursement Process Home page by first selecting the Electronic Payment Instructions Not Marked Complete View under the Payment Processes region, clicking the Go button, and then clicking the Mark Payments Complete icon for an electronic payment instruction with a status of Formatted, Formatted - Ready for Transmission, Transmitted, or Transmission Failed. This view only shows payment instructions whose payment process profiles have the Allow Manual Setting of Payment Completion check box selected.

Once the payments in a payment instruction have been marked complete by clicking the Apply button in the Mark Payments Complete page, the source product is notified that the payments are complete. Simultaneously, the payment instruction can no longer be terminated. Instead, if there are any problems with the payments, they must be voided. The Terminate Payment Process action, therefore, does not appear on any page that displays in the context of a payment instruction whose payments have been marked complete.

Note: The Payment Administrator must mark all the payments in a payment instruction as complete. Oracle Payments does not support partial marking of payments as complete in a payment instruction.

Recording Stop Payments Requests

When the Payment Administrator determines that a payment needs to be stopped, he contacts the payer bank and requests a stop payment.

Note: Payments does not support communication with payment systems regarding stop payments.

The Payment Administrator then records the stop payment request in the Record Stop Payment Request page. To navigate to the Record Stop Payment Request page, he uses one of the following:

If the Payment Administrator navigates to the Record Stop Payment Request page from the Funds Disbursement Process Home page, he enters a paper document number in the Paper Document Number field or a payment reference number in the Payment Reference field for the payment for which he wishes to record a stop payment request and then presses the Tab key on the keyboard. Information populates the Payee, Payment Date, and Amount fields. He then enters a stop request date, reason, and reference.

To navigate to the Record Stop Payment Request page from the Payments Search page, the Payment Administrator performs a simple search. When the results display, he clicks the Stop Actions icon for the applicable payee, and information displays in the payee, payment date, and amount fields. He then enters a stop request date, reason, and reference. The reference is provided by the bank.

Resolving Stop Payments Requests

After a stop payment request has been made, the bank checks that the payment has not already been made and then confirms or denies the stop payment request. The Payment Administrator then uses the Resolve Stop Payment Request page to enter the confirmation or release of the stop payment request. This includes recording the confirmation or release date, reason, and reference. The reference is provided by the bank.

Confirming a stop payment request causes Oracle Payments to automatically perform one of the following steps:

Releasing a stop payment request causes Oracle Payments to record the release, but no other change occurs. The system continues to treat the payment normally.

The Payment Administrator navigates to the Resolve Stop Payment Request page by using the Payments Search page to search for a payment with a stop request placed on it and then clicks the Stop Actions icon. Alternatively, he can click the Views button in the Payments Simple Search page, select the Resolve Stop Payment Requests View, and click the Stop Actions icon for the applicable payee.

Voiding Payments

Voiding a payment by specifying a void date and reason causes both Oracle Payments and the payment’s source product to reverse the payment.

To void a payment, the Payment Administrator navigates to the Void Payment page in one of the following two ways:

Note: A check should only be voided if it is in your physical possession or has been successfully stopped by your bank. A Payment Administrator cannot void a payment that has an unconfirmed stop payment request placed on it.

Source products may restrict whether and when a payment can be voided. Consequently, when the Payment Administrator attempts to void a payment on the Void Payment page, Oracle Payments contacts the source product to check whether the payment can be voided. If the payment cannot be voided, the system displays an error message. When the Payment Administrator uses the Payment Search page, Oracle Payments automatically checks whether the payments in the results region can be voided and displays the Void icon only for those payments that can be voided.

Voids are allowed on payments that have been transmitted to the payment instruction. However, if the payment system has already made the payment, this can cause a discrepancy between Oracle Payments and the real world. It is therefore best to check whether your payment system has actually made a transmitted payment before attempting to void it.

Voiding all Payments

Once the payments in a payment instruction are marked complete, a Payment Administrator cannot terminate the payment instruction. The only way to recover from an error or problem with the payment instruction, as a whole, is to void all the payments in the instruction. Because voiding all payments in a payment instruction is indicative of a serious payment-related problem, this action is intended only as an extreme error recovery procedure and should be invoked only when absolutely necessary. In addition, this page is disabled by default and can only be enabled through function security. Oracle Payments enables the Payment Administrator to void each payment individually, if necessary

Voiding payments causes both Oracle Payments and the payment’s source product to reverse those payments. Source products may restrict whether and when payments can be voided. Therefore, when the Payment Administrator attempts to void all payments, Oracle Payments checks whether each payment can be voided. If all payments cannot be voided, Oracle Payments displays an error message.

To void all payments in a payment instruction, the Payment Administrator must use the Payment Instructions Search page to navigate to the Void All Payments page. From the Payment Instructions Search page, the Payment Administrator searches on one or more variables, views the results, and then clicks the Void All Payments icon for the applicable payment instruction. In the Void All Payments page, the Payment Administrator enters a void date and reason that is applied to all payments in the payment instruction.

Supporting SEPA Credit Transfer

The European Payments Council (EPC) is the governing and coordination body of the European banking industry in relation to payments. It was established in the year 2002 and its purpose is to support and promote the creation of the Single European Payments Area (SEPA). The SEPA initiative involves creation of a zone for European countries (in 2008 the SEPA zone includes 31 countries) in which all payments in Euro are considered domestic even payment crossing borders. SEPA aims at improving the efficiency of cross border payments by developing common standards, procedures, and infrastructure to improve the economics of scale. The introduction of SEPA increases the intensity of competition amongst banks and corporations for customers across borders within Europe. SEPA provides cheaper, efficient, and faster payments within the SEPA zone to consumers, merchants, corporates and public administrations (Customers).

SEPA introduces a new Pan-European payment scheme for payments, both credit transfers and direct debits. The SEPA implementation guidelines for credit transfers are based on the adoption of the ISO20022 (a UNIFI standard). The implementation guidelines issued by the governing body, the European Payments Council, prescribe specific ISO20022 messages to be used to initiate SEPA payments.

SEPA implementation is important for the following reasons:

A SEPA Credit Transfer (SCT) is a payment instrument for the execution of credit transfers in Euro between Customers located in the SEPA zone. The SEPA Credit Transfer is executed on behalf of an Originator. The payment is transferred from the Originator’s Bank account to the Beneficiary’s bank account.

The following parties are involved in the process:

the picture is described in the document text

Credit Transfer Initiation Messaging

The SEPA credit transfer initiation messaging includes the various components associated with the payment process. In this process, functional mapping of the attributes in Oracle Application to the SCT messaging elements in accordance to the SEPA implementation guidelines is provided. The SEPA messaging format is XML. The concept of Grouping modes and Batch Booking for SEPA payment formatting is introduced. The grouping modes describe the way in which the payments are grouped in the file, which is sent to the bank. Batch booking defines how the entry appears in the bank statement. If enabled, the Bank sends a single line for all the transactions under one group.

To support SEPA implementation, Oracle Payments include the following components:

Seeding XML Template and Mapping the Attributes for SEPA Messaging

Oracle Payment now includes an XML template for specifying the SEPA payment format. All the attributes of Oracle Payments disbursement are mapped to the messaging elements as per SEPA format.

This template is seeded and is used for creating the SEPA payment file.

Payment Process Profiles

The Payment Process Profiles for the SEPA Credit Transfer Initiation are seeded in Oracle Payments. The payment instruction grouping depends on the grouping mode selected in the Payment Process Profile.

Three Payment Process Profiles are seeded representing each of the grouping mode, Single, Grouped, and Mixed.

Capturing Batch Booking flag and Grouping mode in the Payment Process Profile Setup

Grouping and Batch Booking are supported as per the ISO20022 guidelines. The Payment Process Profile includes the Grouping Mode and Batch Booking indicators.

A Grouping mode field with a dropdown list is added in the Payment Process Profile setup window. The list has the following values, Single, Grouped, and Mixed. Based on the Grouping Mode selected the payment initiation message format differs. The default value is Grouped.

The Payment Instruction grouping parameters for Grouped is:

In the Payment Process Profiles window these fields are displayed as checked. You can change the default selection.

A checkbox, Batch booking, is added in the Payment Process Profile setup window. It is unchecked by default. It indicates whether the bank should book transactions individually or per payment group. When payments are batch booked, they will generate a single bank statement line entry per group. This is optional.

The company can have agreements with the bank to batch book certain transactions (usually ACH transactions) of similar characteristics. This is done outside the system.

The batch booking checkbox is added to the Create Payment Process Profile window.

Payment Method

For SEPA transactions the payment method must be Electronic.

Message Structure

The SCT message structure consists of the following blocks:

Group Header

This is the first block in the SCT message. The Group Header consists of the following elements: SCT Message Identification, CreationDateTime, BatchBooking, NumberOfTransactions, Grouping, Initiating Party etc.

Payment Information Block

This block consists of a set of parameters, which apply to the debit side of the payment transaction. These include information like: Payment Information Identification, PaymentMethod, Payment Type Information, Requested Execution Date, Debtor, Debtor Account, Debtor Agent, Bank Charges Bearer etc.

Credit Transfer Transaction Information Block

This block consists of a set of elements providing information specific to the individual payments included in the SCT message. This consists of the following elements: Payment Identification, Amount, Instructed Amount, Creditor Agent, Creditor Agent Account, Creditor, Creditor Account, Payment Purpose and Remittance Information etc.

Validation Sets for Checking the IBAN, BIC, Bank Charge Bearer and Legal entity Address

For a payment to be sent to a bank in SEPA format there are some basic conditions and validations that must be met. The validation architecture in Oracle Payments is used to ensure a payment included in the SEPA format satisfies the conditions. This in turn ensures Straight Through Processing (STP).

The following conditions must be met:

These details are validated at the format level and at invoice validation levels. In this component the validations at format level are explained. The validations at invoice validation are discussed in a separate section. You have to setup the invoice related validations.

When bank charge bearer setting is changed in the site level, the invoices that were created before the bearer is changed still continue to hold the old value. This change reflects only for the newly created invoices for this site and supplier.

Supporting SEPA Credit Transfer Enhancement in Oracle Payments

SEPA Credit Transfer feature introduced in Release 12 is based on SEPA Rule Book and SEPA implementation guidelines V2.3.The European Payments Council (EPC) recently published the new guidelines version V3.3 of these documents. There are changes prescribed in the usage rules of various message elements. The existing messaging structure must incorporate these changes to ensure that the message sent to banks is in accordance with the prescribed format.

This topic describes the changes to the existing solution to comply with the latest SEPA guidelines including the mapping changes of various messaging elements of SEPA core payments.

Mapping the Attributes for SEPA Messaging

All the attributes of Payments disbursement are mapped to the messaging elements as per SEPA format. The existing functionality provides the mapping of the SEPA core elements. However, there are changes in the usage rules of various messaging elements in the latest SEPA guidelines and the mapping for those messaging elements are provided.

In the latest version of SEPA guidelines, the mapping for the following new elements is supported:

The mapping for the following elements is changed in accordance with the change in usage rules described in SEPA implementation guidelines V3.3:

The mapping of these elements is supported as part of SEPA core payments. The mapping remains unchanged for the remaining elements.

The SEPA guidelines are revised to support only ‘Mixed’ grouping mode for SEPA payment format. The grouping mode list of values now include only ‘Mixed’ or ‘None’ values. The seeded Payment Process Profiles (PPPs) values of Single and Grouped grouping are removed.

Predefined Validations attached to SEPA Credit Transfer Payment Format

SEPA credit transfer initiation message initiates credit transfers. The messages sent to bank must satisfy all the validations. The validation architecture in the Oracle Payments ensures that a payment included in the SEPA format satisfies the conditions. This ensures Straight Through processing (STP) and make sure that the file has no errors when being processed with bank. For SEPA payment format validations are added the check that the required information of various messaging elements is provided. Validation sets are provided to optimize the Straight Through Processing (STP).

New validations sets are introduced to validate the initiating party name and identification of initiating party, debtor and ultimate debtor.

New Attributes in Logical Grouping of Payments

The payment information block in the SEPA message structure contains the attributes of logical grouping. The SEPA payments are grouped using the following attributes of the payment information block:

With the changes in the usage rules, new elements, Instruction Priority and Category Purpose, are supported in the payment information block. These elements are included as attributes for logical grouping of payments. The invoice legal entity is added in the payment extract.

Impact on Existing Users