More about The World of Payments,

Ledgers , Operating Units in an European Implementation

Session ID: 10149

Prepared by:
Frans van den Berg
Celantra Systems

Frans van den Berg

Oracle EBS expert since 1993

Implementations in Netherlands, Germany, Belgium, U.K, Italy, Ireland,
France, Norway, Sweden, Spain, Austria, Switzerland, U.S.A., Brazil,
Thailand, Vietnam, Malaysia, India, Japan, China, Singapore, India,
Poland
Project Management and EBS Expertise
Special areas : Payments and Bank statements in a multi-country
environment

Objectives
Objective 1: Show how to implement Oracle EBS in a
company with many small business units in multiple
European countries.
Objective 2: What OU/LE/Ledger structures are
possible and what are advantages and disadvantages?
Objective 3: What solutions are possible for bank
payments and bank statement processing in multiple
countries or can we use just one bank account across
Europe?
Objective 4: How to handle localizations? Are they
really required? Can we really just ignore them?
Objective 5: What other legal requirements are coming
up ? - e.g. privacy ; automatic filing of tax-statement to
tax authorities.
3

Agenda
1.
2.
3.
4.

Introduction
The world of payments
Ledgers, OU-s
Questions - Answers

The world of Payments and

Bankstatements in a European roll-out
When implementing Oracle in multiple countries in
Europe Payments and Bank statements require a
lot of attention. When doing the proper thing it
should become a 98% fully automated process.

Internal Bank Accounts

Payments
Direct Debits
Bank Statements
What about treasury integration?

Bank Accounts
Keep the number of internal bank accounts reduced

Considerations when opening a new internal

Bankaccount at your Bank
Tax, Legal
Split of activities
Commercial

Costs
Direct costs to pay to the bank
Internal costs having proper accounting and
reconciliation around it.

Bank Accounts
Do we need bankaccounts in each country in Europe?

One of the SEPA objectives:

Handle all euro payments from a single bank
account: if your business regularly buys or sells crossborder, you often need to set up bank accounts in the
different euro area countries where you do business.
This leads to extra costs, payment delays, and general
inefficiency. With SEPA, you will be able to organise all
your euro payments from a single euro account in the
country of your choice.

Some considerations about single

bankaccount
Oracle EBS can handle it based on specific
configuration
Customers will not always like it (yet) to pay to an
account in other country. But this is changing rapidly!
Tax authorities do want want to see the real and full
bankstatement (even when the bankaccount is in other
country/Legal Entity)

Anyhow: Simplifications of internal bank accounts is a

must , however:
It is easier and faster to open a bankaccount than closing
one
So start now.
8

Payments
The payment batch generated in Payments Manager
should be transferred in a bank-specific file-layout
SEPA did bring a lot of standarization but still smaller
differences per bank/country (still over 500 different
formats in Europe)
Payments files containing payments to non-sepa
countries still very different
It should be uploaded to the bank (without having
situation that someone can change the content)

encryption/protected directories or point to point connection to the

bank
9

Payments
Challenges
o How to make available all required Payment file
formats used in countries which will be included in
Oracle EBS?
Customizations or a third party solution?
o How to accomplish an efficient and secure payment
process which starts in Oracle Payment Manager
and ends when the file arrives safely at the bank?
Secure directories
Hashing and scrambling
Point to point connection to the bank

10

Bank Statement processing

Every day that days statement should be processed
The balance on the Statement should be reflected
in the Acocunting system
All statement entries should be reconciled in AP (for
payments) or AR (for receipts) or GL (for other
payments/receipts not reflected in AR/AP).
And do this all with Cash Management
Blood , sweat and

even sometimes tears!!!!

11

Bank Statements
Challenges:
o How to load all bank statements with different
formats in Cash Management and Accounts
receivables every day for all internal bankaccounts
in all relevant countries?
o How to accomplish an efficient and secure bank
statement process which starts when the file arrives
safely from the bank and ends when all statement
lines are processed and reconciled in Oracle?
Money-receipts on AR Invoices:
Create and Match/Receipt in AR
Process Bank Statement and reconcile with
receipt just created
Payment of AP invoices
Process bank statement and Clear
payment batch or individual payments

12

Direct Debit
Company has open AR invoice to customer
Company sends a file to the bank based on which
the bank takes the money from the customers
bankaccount and transfers it to the companies bank
account.
Of course a prerequisite is that the customers signs
a documen where it approves the company and
bank to handle as such. (Mandates)
File format is different per bank
Partly standard Oracle Functionality

13

Treasury Integration- This happens more

and more
External Bank
One bankaccount
Bank Statement
Payment file

Treasure/ Internal Banking/Cash

pooling
(e.g TRAx, Portfolioplus)
Bank Statement
Bank Statement
Payment file
Bank Statement
Payment file
Payment file

Oracle
With multiple LE/Countries

14

Drivers and Goals for Oracle Multi-Org

Simplification

Reduce IT implementation time, configuration, testing, and complexity of support

Model the legal structure independently of operational structure and accounting

structure

Reduce time to integrate acquisitions and roll-out new modules and

functionality

Ensure global processes by reducing number of configurations and

synchronizations challenges

Simplify and speed up monthly closing

15

Silo Model (Ledger and OU)

1 Ledger-1 Legal Entity-1 Operating Unit
Secondary
L
PrimLaerd
Ledger
yger

Secondary
PrimLaerdy
Ledger
ger

Secondary
PrimLaerdy
Ledger
ger

Secondary
PrimaLryedg
Ledger
er

Secondary
PrimaLryedg
Ledger
er

L
E

L
E

L
E

L
E

L
E

OU

OU

OU

OU

OU

16

Partial Silo Model (OU)

1 Ledger-n Legal Entities-n Operating
Units
Secondary
Secondary
SecondaryLedger
Ledger
PrimaryLedger
Ledger

L
E

L
E

L
E

L
E

L
E

OU

OU

OU

OU

OU

17

Cross Legal Entity Operating Unit (CLEO)

1 Ledger many Legal Entities - 1 Operating Unit

Secondary
Secondary
PrimaryLedger
Ledger Ledger

L
E

L
E

L
E

L
E

L
E

OU

18

Key Assumptions and Challenges

Multi-Org Simplification must serve the business: Operational and business

drivers overrule any of these configurations. If business need separate processes
and management structures, they should be separated into separated Operating
Units and/or ledgers. We are discussing the what are the Oracle technical or
external legal constraints? And how do we deal with them?

Drivers / Challenges need to be addressed

Accounting Defaults
E-Bus-Tax VAT, Sales Tax Integration
Sequencing in Sub-Ledgers & GL journals drives separate ledgers
(not just OUs).
External Document Print Programs
User Access and Risks of User Error (Defaulting and Security Rules)
Shipment & Project based Intercompany
IT interfaces and Programs may need to be adjusted
Local and Functional currency
Country Localizations where needed and used
Business Processes mapping / may need adjustments

19

Primary and Secondary Ledgers

Primary ledger should be used for US GAAP and secondary ledger will be used for
statutory reporting.
This approach was chosen for two main reasons:

1. Statutory audits, in general, are annual while our US GAAP financials are reviewed
and reported on a quarterly basis
2. The timing requirements for close are more stringent for SEC reporting than for
STAT reporting. Example many times we request extensions for STAT but this is
never done for US GAAP.

20

Thank you Questions and

Suggestions, please

Contact:
Frans.van.den.berg@celantrasystems.com

21