White Paper

SEPA Core Direct Debit in Oracle Payments

for Oracle Applications Release 12

See Change Record

This white paper describes supporting SEPA Core Direct Debit functionality in Oracle Payments
for Oracle Applications Release 12.

TOC/Navigation Title
This white paper contains the following information.

1. Overview
2. Introduction
3. Mandate Setup
4. Mandate Update and Amendment
5. Funds Capture Setup and Transaction Flow
6. SEPA Direct Debit Message
7. Exception Handling
8. Conclusion
9. Change Record

Overview
Direct Debit is a method of payment wherein the debtor (payer) authorizes the creditor (payee) to
collect the payment from his bank account. The payment can be a fixed amount like a mortgage
payment or variable amounts such as those of invoices.

Single Euro Payments Area (SEPA) Direct Debit scheme replaces various country-specific direct
debit schemes currently prevailing within the SEPA zone. SEPA Direct Debit (SDD) is a
payment instrument used for making domestic and cross-border payments across 32 countries
including the European Union as well as Iceland, Liechtenstein, Norway and Switzerland. SDD
is based on the ISO20022 XML messaging standards. The European Payments Council (EPC) is

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 1
the governing body for the SEPA Direct Debit scheme. It has issued SEPA Core Direct Debit
Implementation Guidelines containing the rules for implementing the customer-to-bank direct
debit messaging standard based on version 3.3 of the SEPA Core Direct Debit Scheme
Rulebook.

The SDD core scheme is based on creditor-driven mandate flow. With a mandate the debtor
authorizes the creditor to collect payment by direct debit. In addition, the mandate authorizes the
debtor’s bank to debit the debtor’s account in case a direct debit collection is presented. Under
the SDD Core Scheme, the debtor completes and signs a mandate and sends it directly to the
creditor. The creditor is responsible for storing the original mandate, together with any
information regarding amendments relating to the mandate information or its cancellation.

The Scheme caters for both recurrent and one-off collections. Recurrent direct debits are those
where the authorization by the debtor is used for regular direct debits initiated by the creditor.
One-off direct debits are those where the authorization is given once by the debtor to collect only
one single direct debit, an authorization which cannot be used for any subsequent transactions.
There is no difference in the legal nature of these two types.

Under the SDD scheme, both the debtor and the creditor should have bank accounts to be used
for SEPA transactions in any country within the SEPA zone, and transaction currency should be
Euro. There is no limit on the transaction amount.

Introduction
This whitepaper provides information on various features introduced in the Oracle Payments
module in Oracle E-Business Suite release 12 to support SEPA Direct Debit, and describes user
considerations related to implementing and using these features.

The main feature of the SDD solution in Release 12 is supporting dematerialization of the
mandate in the system and using the same to drive the SEPA Direct Debit transaction initiation
flow. The SEPA Credit Transfer initiation feature is already supported in Release 12. Therefore,
some of the SEPA requirements common for both Credit Transfer initiation and Direct Debit,
like mandatory use of IBAN and BIC, logical grouping of payments and batch booking are
already supported for funds disbursement flow. These features are now also supported for funds
capture flow as a part of the SEPA Direct Debit feature.

The setup and transactions flow of SEPA Direct Debit in EBS R12 using various new and
enhanced features are explained in the subsequent paragraphs.

Mandate Setup

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 2
A mandate is signed by the debtor (payer) to authorize the creditor (payee) to collect a payment
and to allow the debtor bank to pay those collections.

The EBS R12 already supports direct debit authorization (also known as mandate) for bank
accounts assigned to customers in Oracle Receivables. For that purpose, a setup ‘Enter Debit
Authorization’ is available at bank account assignment level in customer account and site setup.
The current mandate setup has been enhanced to support mandate attributes as required by SEPA
guidelines.

The following points should be considered while performing mandate setup:

Only one effective mandate can be present for a bank account assignment at customer
account or site level.

The mandate attributes as per the current setup are stored in
IBY_PMT_INSTR_USES_ALL table. With this enhancement, a new table
IBY_DEBIT_AUTHORIZATIONS now stores all the attributes related to mandate setup.

A mandate can be configured in the context of customer bank account assignment which
can be either at customer account level or at customer bill-to site level.

The inline update icon on customer bank account assignment setup is to be used for
creating a new mandate or updating an existing mandate.

When a mandate is created for the first time, the system opens the ‘Enter Debit
Authorization’ page in Create mode. There are four page level buttons out of which
‘Cancel’ and ‘Apply’ will be active and ‘Create New Authorization’ and ‘Update
Authorization’ will be inactive due to first creation.

Payer name and bank account number are taken from contextual customer bank account
assignment.

Authorization version number is displayed as 1 for first mandate creation. For every
amendment in the mandate, the number will be incremented by 1.

Count of debit transactions would indicate the number of successful direct debit messages
created using that mandate.

To have an active mandate in the system, the checkbox ‘Payer Granted Authorization to
Debit Bank Account’ must be checked, and the ‘Authorization Signing Date’ should be
filled in and shouldn’t be a future date, and ‘Authorization Cancellation Date’ and
‘Authorization Inactive Date’ must not have been passed.

Provide ‘Unique Authorization Reference ID’ as shown on the paper mandate. This is a
required attribute in the SEPA Direct Debit message.

Select a transition type which can be either ‘Recurrent’ or ‘One-off’. A recurrent mandate
can be used for multiple transactions whereas ‘One-off’ can be used only for one
transaction.

The ‘Payee Details’ region captures the information related to the first party payee to
whom the mandate has been issued by the customer. Select the ‘Payee Legal Entity’ from
its LOV. When the legal entity is selected, the legal entity address is automatically
populated in the payee address field.

Enter payee identifier information in its related field. Payee identifier should be in
accordance with the specification of ‘Identifier of Creditor (AT-02)’as provided in the
SEPA Core Direct Debit Scheme Customer-To-Bank Implementation Guidelines Version

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 3
 3.3. As per AT-02, the structure of creditor identifier includes the first two digits (1 – 2)
as ISO country code, the next two digits (3 – 4) as check digits, the next three digits (5 –
7) as creditor business code and the remaining digits (8 – 35) as the national identifier of
the creditor. The number entered in the payee identifier field will be validated as per
above structure. Therefore users must enter a valid value in accordance with SEPA
Rulebook for payee identifier.

The ‘Payer Details’ region captures information related to the customer who issues the
mandate. The customer address can be selected from its LOV.

Customer bank account IBAN and customer bank BIC will be automatically populated if
the values are available in the customer bank account setup. These attributes are required
in SEPA Direct Debit message. Therefore the user should ensure that these fields are
populated in the customer bank account setup.

The mandate setup provides a facility to attach a scanned copy of the mandate or other
documents with the mandate. There is a region ‘Attach Authorization File’ which has an
‘Add’ button to select files from a local directory and attach them to the mandate.

The mandate captures ‘Authorization Inactive Date’ information, which can be either
updated by the user or by the system. If the ‘Authorization Inactive Date’ has passed, the
mandate will become inactive. In the following cases, the ‘Authorization Inactive Date’
will be updated by the system:

o For a one-off mandate, one successful settlement batch is created.

o For a recurrent mandate, Oracle Receivables has passed ‘Final Transaction’
information in the successful settlement batch. For that purpose, the Oracle
Receivables user has to select the checkbox ‘Final Transaction for Direct Debit
Mandate’ in the payment instrument form in the transaction workbench.

Mandate Update and Amendment

The mandate created once can be updated later for various attributes. The system allows
creditors to reflect any changes to the mandates previously signed by the debtor and
dematerialized. As per AT-24 of the SEPA rulebook, update of some of the attributes on the
mandate would constitute amendment of the mandate.

The following are the cases of amendments specified in AT-24 of the SEPA rulebook:

The creditor needs to change the unique Mandate reference of an existing Mandate
because of internal organizational changes (restructuring).

The creditor identity has changed due to the merger, acquisition, spin-off or
organizational changes.

The creditor has changed its name.

The debtor decides to use another account within the same bank or in another bank.

In case of amendment of the mandate, the creditor must follow the procedure laid out in the
SEPA rulebook.

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 4
The following points need to be considered when updating the mandate:

When a mandate is opened for update, it will be visible in read-only mode. There are
four page level buttons out of which ‘Create New Authorization’ and ‘Update
Authorization’ will be active and ‘Cancel’ and ‘Apply’ will be inactive.

The ‘Create New Authorization’ button can be used to create a new mandate which
would replace the existing mandate. If a new mandate needs to be created then the user
has to first make the existing mandate inactive. Only then the user will be able to create a
new mandate.

If the existing mandate needs to be updated then use the ‘Update Authorization’ button
which will make the mandate page active for updating.

All the fields which can be entered while creating the new mandate will be updatable
when updating the mandate except for transaction type.

If a mandate is updated for unique authorization reference ID or payee legal entity or
payee identifier, the system will consider these changes as amendments of the mandate. If
the mandate is updated for any other attribute, the system will not consider such update as
an amendment.

For an amendment of the mandate, it will be mandatory to provide a value in the ‘Reason
for Amendment’ field on the form. The user should select the correct reason code from
the LOV which will display various seeded lookup codes.

For an amendment of the mandate, the system will create a new version of the mandate in
the mandate table. On the mandate form, the ‘Authorization Version Number’ will reflect
the latest version of the mandate.

When a new version of the mandate is created, the unchanged mandate attributes as well
as ‘Count of debit transaction’ information will be inherited from the previous version of
the mandate.

Different versions of a mandate will be linked with the original mandate through a
reference key INITIAL_DEBIT_AUTHORIZATION_ID.

New and previous values of amended attributes will be reported in the next SEPA Direct
Debit instruction.

If the amendment of the paper mandate is due to a change of the debtor’s bank account, then the
user can update this in the system by end dating the current mandate and creating a new mandate
for a different bank account.

Funds Capture Setup and Transaction Flow

Following is the high level incremental setup and transaction flow for SEPA Direct Debit:

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 5
In Oracle Receivables, at bank account assignment level in customer or customer site setup, the
user would setup a mandate in the ‘Enter Debit Authorization’ form. In Oracle Payments, the
user can either create a new Payment Method or use a seeded ‘Bank Account Transfer’ payment
method for SEPA Direct Debit transactions. Apart from regular setup of funds capture, the user
needs to create the routing rules taking the seeded funds capture process profile for SEPA Direct
Debit. In the routing rule setup, the user needs to use ‘Currency’, ‘Payee Bank Country’ and
‘Payer Bank Country’ in the conditions, and select all countries of the SEPA zone for both
‘Payee Bank Country’ and ‘Payer Bank Country’. This would ensure that the mandate is only
used when the direct debit transaction is within the SEPA zone and the transaction currency is
Euro.

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 6
The payment method used in the routing rules will be used in the receipt class for automatic
receipts. Users should select the Receipt Grouping Rule as ‘One Invoice per Receipt’ in order to
conform with SEPA grouping rules.

The SEPA rulebook prescribes requirements for the creditor to send a pre-notification letter to
the debtor within a specified time period. Oracle Receivables has provided a feature for
generating a pre-notification letter which the user needs to use in accordance with the manner
and time line prescribed by the SEPA rulebook. Similarly, according to collection timelines
prescribed by the SEPA rulebook, the Oracle Receivables user needs to create the remittance
batch and the Oracle Payments user needs to follow the same by creating the settlement batch.

Oracle Receivables has provided a new concurrent program ‘Direct Debit Pre-Notification
Letter’ to generate pre-notification letters to inform debtors about transactions that are going to
be settled through Direct Debit. The new program is seeded as an automatic receipt format
program. The new program should be assigned to the automatic receipt method used for creating
the direct debit receipts. Oracle Receivables will automatically launch this program when the
automatic receipt batch is formatted. The report is an Oracle BI Publisher based report and can
be customized.

Funds Capture Setup Considerations

Funds Capture setup should ensure that new and changed features related to SEPA Direct Debit
are properly configured. In addition, setup of transmission configuration, payment system and
payment system account should be as per specification provided by the bank or payment system
to where the direct debit message would be transmitted.

The following points need to be considered while configuring funds capture setup related to
SEPA Direct Debit:

Three new formats have been seeded for SEPA Direct Debit. Out of these three formats,
two are for settlements which are separate for structured and unstructured messages. One
format is for the payer verification process. The purpose of the payer verification format
is only to run certain validations attached to that format.

Two new funds capture process profiles have been seeded for SEPA Direct Debit, which
hold structured and unstructured message formats for settlement.

To support various message attributes, new settings are seeded at payment system level in
the ‘Global Payment System’. Configure these at the settings for the payment system
account used for SEPA Direct Debit transactions.

Following is the list of such settings:

Setting Code Setting Name Data

Type
SEPA_INITIATING_PARTY_ID SEPA Initiating Party Identifier Character
SEPA_INITIATING_PARTY_ID_ISSR SEPA Initiating Party Identifier Character
Issuer

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 7
 SEPA_INITIATING_PARTY_NAME SEPA Initiating Party Name Character
SEPA_BATCH_BOOKING SEPA Batch Booking Option Character

The batch booking option must be configured as ‘True’ or ‘False’.

Oracle Payments provides an online payer verification feature for direct debit
transactions. This verification ensures that the payer’s bank account exists, has a
sufficient balance and there is no fraud alert. For the purpose of SEPA Direct Debit, this
feature has been used for performing validations attached to the payer verification format
in order to ensure the presence of a valid mandate in the system. There will be no
transmission of a message for the purpose of actual payer verification.

Various validation sets are attached with SEPA Direct Debit formats. Following is the list
of such validations:

Validation Set Contents

Name
Active Debit Verify that one active direct debit authorization is present for
Authorization * customer / customer site at bank account assignment level, and its
cancellation date has not yet passed.
SEPA Verify that Unique Authorization Reference ID, Authorization
Authorization Signing Date, Payee Legal Entity, Payee Address, Payee Identifier,
Attributes * Customer Address, Customer Bank Account IBAN and Customer
Bank BIC are present.
SEPA Initiating Verify that Initiating Party ID, Initiating Party ID Issuer and
Party Initiating Party Name are present.
SEPA Batch Verify that batch booking information is present and not invalid.
Booking
Match Debit Verify that Payee Legal Entity Name and Payer Bank Account
Authorization Name are the same as present at their source.
Attributes
* Also attached with SEPA Core Direct Debit Online Payer Verification Format.

Routing rule setup has been enhanced to include a new criterion ‘Payer Bank Country’.
This has been provided since as per SEPA guidelines, in order to qualify a SEPA
transaction, both payer and payee bank should be in the SEPA zone and the currency
should be Euro. Therefore the user may configure a routing rule having 32 countries as
both payer bank country and payee bank country and having currency as Euro. The
routing rule logic has been enhanced whereby the routing rule can have multiple
conditions. As per the enhanced logic, if the same criterion is used multiple times, then it
would have an effect of ‘OR’. If different criteria is used in different conditions, then it
would have an effect of ‘AND’. For example, a user may want to apply a routing rule if
payer bank country is either France or Germany and Payee Bank Country is either Spain
or Italy and currency is Euro. In such a case, the user should create a routing rule which
has ‘Payer Bank Country’ as France and Germany, ‘Payee Bank Country’ as Spain and
Italy and ‘Currency’ as Euro.

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 8
SEPA Direct Debit Message
Following are some important aspects related to the SEPA Direct Debit message:

Mapping of message attributes is based on SEPA Core Direct Debit Scheme Rulebook
Version 3.3, SEPA Core Direct Debit Scheme Customer-To-Bank Implementation
Guidelines Version 3.3 and CustomerDirectDebitInitiationV01 (pain.008.001.01) as per
UNIFI (ISO 20022) Payments Message standards.

SEPA Direct Debit format supports grouping of receipts within a direct debit instruction.
The receipts within a direct debit instruction are divided into logical groups. The
attributes common to the group of payments are stored at the group level.

As per ISO 20022 message guidelines (pain.008.001.01), the customer direct debit
initiation message is composed of 3 building blocks:

o Group Header: This building block is mandatory and present once. It contains
elements such as message identification, creation date and time, batch booking
indicator, grouping indicator, initiating party etc.
o Payment Information: This building block is mandatory and repetitive. It contains,
amongst others, elements related to the credit side of the transaction, such as
payment method, payment type information, collection date, creditor details,
ultimate creditor details etc. Only Mixed grouping is supported as per the SEPA
requirements. The payment grouping will depend on the various elements forming
part of the logical grouping that is mentioned later in this section.
o Direct Debit Transaction Information: This building block is mandatory and
repetitive. It contains, amongst others, elements related to the Debit side of the
transaction, such as payment identification, instructed amount, direct debit
transaction comprised of mandate and creditor details, ultimate creditor details,
debtor details including debtor bank branch and bank account, ultimate debtor
details, remittance information etc. The remittance information can be structured
or unstructured depending upon the format used. This block can be 1 or multiple
per Payment Information block.

Oracle Receivables supports pre-notification letters to inform debtors about transactions
that are going to be settled through direct debit, through a new concurrent program
‘Direct Debit Pre-Notification Letter’.

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 9

Payer verification process will be done prior to settlement batch creation in order to
perform certain pre-defined validations which will ensure presence of a valid mandate
and all required attributes in the message.

A ‘Logical Grouping of Transactions’ feature is available within a settlement batch based
on various parameters as per SEPA message structure and supporting ‘Mixed’ mode of
grouping. The parameters are fixed and not configurable through the User Interface.
Following are the grouping parameters:
o Payment Method - This must always be ‘DD’
o Service Level – This must always be ‘ SEPA’
o Local Instrument – This must always be ‘CORE’
o Charge Bearer – This must always be ‘SLEV’
o Settlement Currency – This must always be ‘EUR’
o Category Purpose – This will be ‘SUPP’
o First party organization
o First party legal entity
o Internal bank account
o Settlement date
o Sequence type

Message attributes will be captured from the mandate, payment system account settings
and transaction data. The following attributes are mapped with mandate:
o Creditor name and address
o ‘Sequence type’ for ‘FRST’, ‘RCUR’ and ‘OOFF’. Oracle Receivables will
provide ‘FNAL’.
o Mandate related information like mandate identification, date of signature,
amendment indicator and amendment information details
o Creditor scheme identification
o Debtor name and debtor address
o Debtor agent and debtor account details

For ‘Sequence type’ attribute, to provide ‘FNAL’ for the last occurrence for recurrent
mandate, the payment instrument form on the transaction workbench in Oracle
Receivables has been enhanced to add a new check box ‘Final Transaction for Direct
Debit Mandate’ that will signify that the transaction is the final transaction to be settled
against the direct debit mandate.

A few other message attributes are mapped as follows:
o Initiating party related attributes and batch booking option are mapped in payment
system account settings as mentioned previously in ‘Funds Capture Setup
Considerations’
o Seeded hardcoded value ‘SUPP’ for ‘Category Purpose’ and ‘Payment Purpose’
o ‘Ultimate Creditor’ is mapped with invoice legal entity and ‘Ultimate Debtor’ is
mapped with ‘Bill-to customer’
o ‘Creditor Reference’ is mapped with invoice number

Exception Handling

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 10
SEPA Direct Debit supports rejection transactions in the manner specified under the SEPA
guidelines.

As per the EPC rulebook, direct debit collections that result in exception processing are referred
to as 'R-transactions'. There are seven types of R-transactions which are rejects, refusals, returns,
reversals, revocations, request for cancellation and refunds. Oracle Payments only supports
rejects from above R-transactions. For refund transactions, there is a workaround available. For
that purpose, when a refund is initiated from Oracle Receivables, an invoice of type ‘Payment
request’ is automatically created in Payables that is paid through Oracle Payments using funds
disbursement flow.

Rejects are Collections that are diverted from normal execution, prior to inter-bank Settlement.
The Payment Status Report is used to report a positive (Received/Accepted/Accepted with
Change), a pending (Pending), a negative (Rejected) or a combination of positive and negative
(Partially Accepted) statuse. Its usage is always governed by a bilateral agreement between the
bank and the payee. For this purpose, Oracle Payments supports processing of the payment status
report as per the structure given in UNIFI (ISO 20022) Payments Message standards for
PaymentStatusReportV02 (pain.002.001.02).

The following business process will be followed for processing the payment status report:

The status of the transactions is obtained by running the ‘Fetch Settlement Batch
Clearing’ concurrent program. This parses the acknowledgement file which updates the
batch status and transactions status. The batch status will be updated based on payment
group status.

If the group status is ‘ACCP’ then the batch status and all the transaction statuses of all
the transactions within this batch will be updated as ‘Succeeded’ (status code 0).

If the group status is ‘REJCT’ then the batch status will be updated with ‘Batch Failed’
(status code 7) and all the transaction statuses of all the transactions within this batch will
be updated as ‘Failed - Transaction Declined’ (status code 20).

If the group status is ‘PART’ then the batch status will be updated as ‘Batch Partially
Succeeded’ (status code 6). The statuses of the individual transactions will be updated by
checking the transaction status of all the transactions within the group.

The status of the transactions will be passed to Oracle Receivables which will update the
receipt status from ‘Remitted’ to ‘Confirmed’ for rejected transactions.

Conclusion
The SEPA Direct Debit feature in EBS R12 is highly flexible and aligned with the core
functionality of Oracle Payments and Oracle Receivables which would help EBS R12 customers
to swiftly adapt SEPA for direct debit transactions. The complex requirements around mandate
dematerialization, amendment and versioning have been supported in a user friendly manner.
The feature is generic enough to address common requirements of the majority of the enterprises.

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 11
Change Record
Date Description of Change
October 25, Created document.
2010
May 31, Removed “and sending” from Receivables Pre-Notification letter
2011 feature in section Funds Capture Setup and Transaction Flow

Oracle Corporation
Author and Date
Mitesh Kumbhat, October 2010

Copyright Information
Copyright © 2004, 2005 Oracle. All rights reserved.

Disclaimer
This document in any form, software or printed matter, contains proprietary information that is
the exclusive property of Oracle. Your access to and use of this confidential material is subject to
the terms and conditions of your Oracle Software License and Service Agreement, which has
been executed and with which you agree to comply. This document and information contained
herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without
prior written consent of Oracle. This document is not part of your license agreement nor can it be
incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

This document is for informational purposes only and is intended solely to assist you in planning
for the implementation and upgrade of the product features described. It is not a commitment to
deliver any material, code, or functionality, and should not be relied upon in making purchasing
decisions. The development, release, and timing of any features or functionality described in this
document remains at the sole discretion of Oracle.

Due to the nature of the product architecture, it may not be possible to safely include all features
described in this document without risking significant destabilization of the code.

Trademark Information
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation
and/or its affiliates. Other names may be trademarks of their respective owners.

Update Date 31-May-2011

Expire Date dd-mon-yyyy (ignore after this date)

SEPA Core Direct Debit in R12 Oracle Payments [Doc ID 1420049.1] Page 12