White Paper

SEPA Credit Transfer V3.3 support in Oracle Payables

for Oracle Applications Release 11i

See Change Record

This white paper describes the SEPA Credit Transfer V3.3 support in Oracle Payables.

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

1. Overview
2. SEPA Credit Transfer initiation
3. Validation of SEPA Core elements
4. Logical grouping of payments
5. Change Record

Overview
A SEPA Credit Transfer (SCT) is a payment instrument for the execution of credit transfers in Euro between customer
payment accounts located in the SEPA zone. The SEPA Credit Transfer is executed on behalf of an Originator holding
a payment account with an Originator Bank in favor of a Beneficiary holding a payment account at a Beneficiary
Bank.

The original SEPA credit transfer implementation in Oracle Payables was based on Version 2.3 of ‘SEPA CREDIT
TRANSFER SCHEME CUSTOMER-TO-BANK IMPLEMENTATION GUIDELINES’ and ‘SEPA Credit Transfer
Scheme Rulebook’ issued by the European Payments Council (EPC). These guidelines define the rules to be applied to
the UNIFI (ISO20022) XML message standards for the implementation of the SEPA Credit Transfers in the customer-
to-bank space.

EPC has released Version 3.3 of these guidelines replacing the existing guidelines. There are changes prescribed in
the usage rules for various data elements in the new guidelines. In addition, some new data elements are also
prescribed to be supported as part of SEPA core payments.
SEPA Credit Transfer updates in Release 11i are handled in Oracle Payables. It covers the changes prescribed for the
SEPA core elements as per the latest guidelines. The existing messaging structure is modified to support the various
data elements forming part of SEPA core payments as per the new guidelines.

SEPA Credit Transfer initiation

SEPA Implementation Guidelines provide the guidance on the usage of the payment initiation UNIFI (ISO 20022)
XML standards (the ‘pain.001.001.02 message) in initiating SEPA core payments. In the guidelines, the elements
forming the SEPA core payments are shaded in yellow. There are certain other elements that are categorized as AOS
(additional optional services). The E-Business Suite SEPA implementation covers the data elements required for
SEPA core payments. This section describes the mapping of various elements forming part of SEPA core payments as
per V3.3 of the SEPA guidelines.

The SCT message structure consists of the following blocks:

 Group Header

 Payment Information Block

 Credit Transfer Transaction Information Block

Group Header

This is the first block in the SCT message. The Group Header consists of the following elements:


  SCT Message Identification – The Batch Name is mapped to this data element.

 Creation Date and Time – This is the system generated date and time stamp.

 Batch Booking – Batch booking value True or False based on the value entered in the payment format.

 Number of Transactions – This is mapped to the Count of Number of Payments in the output file.

 Control Sum – This is a new element required as per V3.3 of SEPA guidelines. The Absolute Total of
payment amounts.

 Grouping – As per V3.3 of SEPA guidelines, only Mixed grouping is supported. Therefore, in the message the
value ‘MIXD’ will be passed.

 Initiating Party – The name and identification of the initiating party are required as per V3.3 of the SEPA
guidelines.

The Legal Entity is mapped to the Name.

VAT Registration Number is mapped to the Tax Identification Number under the Organization Identification.

Payment Information Block

This block consists of a set of parameters, which apply to the debit side of the payment transaction. It consists of the
following elements:

 Payment Information Identification – The AP Batch Name is mapped to this data element.

 Payment Method – The value TRF is passed during payment formatting.

 Payment Type information – contains the following sub elements:

o Instruction Priority – This element is required in V3.3 of SEPA guidelines. The value NORM is passed for this
element.
o Service Level – The value SEPA is passed as required in SEPA guidelines.
o Category Purpose – This element is required in V3.3 of SEPA guidelines. The value SUPP is passed for this
element.
o Requested Execution Date – The Payment Date is passed for this element.

 Debtor –

o The name, address and identification of the debtor are required elements for SEPA core payments.
o The Legal Entity is mapped to the Name.
o The Legal Entity Address is mapped to the Address.
o VAT Registration Number is passed in the tag Tax Identification Number under the Organisation
Identification.

 Debtor Account

o The IBAN of the internal bank account used for payment is passed for this element.
o The Bank Account Currency of the internal bank account is also mapped to this element.

In V3.3 of SEPA guidelines, the currency of the debtor bank account is also required as part of SEPA core
messaging requirements.
  Debtor Agent – The BIC of the bank branch of the internal bank account is mapped to this element.

 Ultimate Debtor –The mapping is the same as for Initiating Party.

 Charges Bearer – The value SLEV is passed for this data element. This is as per the requirement of the SEPA
guidelines.

Credit Transfer Transaction Information Block “ CdtTrfTxInf “

6 payments transactions

This block consists of a set of elements providing information specific to the individual payments
included in the message.

 Payment Identification – The Instruction Identification and End to End identification are required as part of
SEPA core payments.
 - <PmtId>
<InstrId>18</InstrId>
<EndToEndId>18</EndToEndId>
</PmtId>

The Payment Document Number is mapped to both Instruction Identification and End to End Identification.

 Payment Type Information – This data element is populated in the payment information block as described in
the usage rules of the SEPA guidelines.

 Instructed Amount – The Payment Amount and Payment Currency are mapped to this field.

- <Amt>
<InstdAmt Ccy="EUR">1000.00</InstdAmt>
</Amt>

 Charge Bearer – This data element is populated in the Payment Information Block as described in the usage
rules of the SEPA guidelines.

 Ultimate Debtor - This data element is populated in the Payment Information Block as described in the usage
rules of the SEPA guidelines.

 Creditor Agent – The BIC of the creditor bank branch is populated for this data element.

- <CdtrAgt>
- <FinInstnId>
<BIC>BOFAGB22</BIC>
</FinInstnId>
</CdtrAgt>

 Creditor – The Name, Address and Identification are required for the creditor.

- <Cdtr>
<Nm>Advanced Network Devices</Nm>
- <PstlAdr>
<AdrLine>5600 Independence Ave</AdrLine>
<Ctry>US</Ctry>
</PstlAdr>
- <Id>
- <OrgId>
- <PrtryId>
<Id>1013</Id>
</PrtryId>
</OrgId>
</Id>
</Cdtr>

Name – This is mapped to Supplier Name.

Address – This is mapped to Address of Supplier Site.

Identification - The Identification of the supplier is provided in the following order:

1. If Tax Registration Number is available it is populated in the tag <TaxIdNb> under Organisation
Identification.
 2. Else Supplier Number is populated under the tag <PrtryId> under Organisation Identification.

 Creditor Account – The Name and Identification of Ultimate Creditor are required for SEPA core payments.
The mapping for these data elements is the same as that for Creditor.

- <CdtrAcct>
- <Id>
<IBAN>GB29NWBK60161331926819</IBAN>
</Id>
</CdtrAcct>

- <UltmtCdtr>
<Nm>Advanced Network Devices</Nm>
- <Id>
- <OrgId>
- <PrtryId>
<Id>1013</Id>
</PrtryId>
</OrgId>
</Id>
</UltmtCdtr>
</CdtTrfTxInf>

 Payment Purpose – The value SUPP is passed for this data element.

- <Purp>
<Cd>SUPP</Cd>
</Purp>

 Remittance information – The remittance information can be either ‘Structured remittance’ or ‘Unstructured
remittance’. SEPA guidelines prescribe a 140 characters limit for the remittance information including the tag
size. In E-Business Suite SEPA implementation the remittance information will be truncated to 140
characters.

- <RmtInf>
- <Strd>
- <CdtrRefInf>
- <CdtrRefTp>
<Cd>SCOR</Cd>
<Issr>Advanced Network Devices</Issr>
</CdtrRefTp>
<CdtrRef>BP 3 sep si 1</CdtrRef>
</CdtrRefInf>
</Strd>
</RmtInf>

 Structured remittance –
  The Creditor reference, Creditor reference type and Issuer are required as part of SEPA core payments
according to V3.3 of the SEPA guidelines.

The Invoice Number is passed for Creditor Reference.

SCOR (Structured Communication Reference) is the value prescribed to be passed for this data
element. Therefore the value SCOR is passed for this field.

The Supplier Name is passed for Issuer.

 Unstructured remittance –

– The following elements are supported in the unstructured remittance:

Invoice Number

Invoice Date

Invoice Amount

Remitted amount

Comma (,) is used as the separator for the elements and semicolon (;) is used as the separator for
invoices.

Validations for SEPA core elements

The following validations are applied for SEPA payments:

1. The BIC must be present for the internal and supplier bank branches

2. The IBAN must be present for the internal and supplier bank accounts

3. The Payment Currency must be in Euro.

4. The Payment Method must be Electronic.

5. The Legal Entity Address must be present.

6. The VAT Registration Number of the Legal Entity must be entered.

There are two payment formats seeded for SEPA implementation. One for SEPA structured remittance and another for
SEPA unstructured remittance. Only the invoices matching the above validations are selected if a payment is
generated using the SEPA payment format.

Logical grouping of payments

The payment information is a logical level that groups the payments by some common attributes. This level is useful
for functions such as batch booking. It contains the debit side information. The information is present on the grouping
level only and is shared by the child payments. These attributes are:

 Payment method
 Requested execution date (Payment date)
 Debtor (Legal entity)
 Debtor account (IBAN of internal bank account)
 Debtor agent (BIC of the internal bank branch)
 Organisation (Operating unit)

The V3.3 of SEPA guidelines have prescribed certain additional elements to be supported in the payment information
block. These are:

 Instruction Priority
 Category Purpose

These attributes are also included in the logical grouping of the payments.
Change Record
Date
September 27, 2010
November 2, 2010
February 17, 2011
Description of Change Who Changed
Created document. Patruni Suresh
Added XML Examples Wael Dawood
Removed reference to Single or Grouped Binyamin Kamilar
values in Grouping element.

Oracle Corporation
Author and Date
Patruni Suresh, September 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.