Orbian Supply Chain Finance Solution

Buyer Implementation Overview

Document Version 1.7

This document forms part of Orbian’s policies and procedures. All defined terms used in this document shall have the meanings given to them in
the Buyer Contract, except where they are re-defined in this document or where their meanings must, necessarily, be varied by the context in
which they arise in this document. In the event of conflict between this document and the Buyer Contract, the Buyer Contract shall control.

Except as permitted by the Buyer Contract, this document must not be disclosed outside of your organization and you are not authorized to
duplicate or distribute it (whether electronically or otherwise) in whole or in part.

© ORBIAN 2000 - 2009. Confidential and Proprietary. All rights reserved. Page 1 of 26
 TABLE OF CONTENTS

Page
1 INTRODUCTION ______________________________________________________________________________ 4

1.1 PURPOSE AND OBJECTIVES ------------------------------------------------------------------------------------------------------------ 4

1.2 OVERVIEW OF THE ORBIAN SUPPLY CHAIN FINANCE SOLUTION ---------------------------------------------------------------- 5

1.3 PROJECT KICK-OFF --------------------------------------------------------------------------------------------------------------------- 7

2 INTEGRATION OVERVIEW _____________________________________________________________________ 8

3 STRAIGHT THROUGH PROCESSING (STP) _______________________________________________________ 8

3.1 STP FILE FORMATS --------------------------------------------------------------------------------------------------------------------- 8

3.1.1 ORBIAN PROPRIETARY FORMAT (OPF) 8

3.1.2 ANSI FORMAT 9

3.2 STP COMMUNICATION PROTOCOLS------------------------------------------------------------------------------------------ 9

4 MANUAL PROCESSING_______________________________________________________________________ 10

5 ERP / LEGACY SYSTEM CONFIGURATION_______________________________________________________ 11

5.1 GENERAL ---------------------------------------------------------------------------------------------------------------------------------11

5.2 FOR BUYERS WHO RUN SAP ---------------------------------------------------------------------------------------------------------12

6 ACCOUNTING PROCESS _____________________________________________________________________ 13

6.1 INTRODUCTION --------------------------------------------------------------------------------------------------------------------------13

6.2 ACCOUNTS SET-UP ---------------------------------------------------------------------------------------------------------------------13

6.3 RECONCILIATION OF THE ORBIAN PI CONTROL ACCOUNT-----------------------------------------------------------------------14

6.4 RECONCILIATION OF THE VENDOR ACCOUNTS PAYABLE – ORBIAN ACCOUNT ----------------------------------------------14

6.5 AN EXAMPLE OF THE ACCOUNTING STEPS FOR A BUYER ------------------------------------------------------------------------14

7 OTHER PROCESS CONSIDERATIONS___________________________________________________________ 15

7.1 INTRODUCTION --------------------------------------------------------------------------------------------------------------------------15

7.2 AGGREGATION OF SUPPLIER INVOICES AND CREDIT MEMOS -------------------------------------------------------------------15

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 2 of 26

 7.3 REMITTANCE INFORMATION FOR SUPPLIERS ---------------------------------------------------------------------------------------15

7.4 ORBIAN DAY ROLL CONVENTION ----------------------------------------------------------------------------------------------------16

7.5 MAXIMUM PAYMENT PERIODS --------------------------------------------------------------------------------------------------------16

7.6 PAYMENT INSTRUCTIONS – OVERPAYMENTS ---------------------------------------------------------------------------------------16

7.7 ORBIAN EXCEPTIONS ------------------------------------------------------------------------------------------------------------------16

7.8 ORBIAN BUSINESS PARTNER AND ACCOUNT STRUCTURES ---------------------------------------------------------------------17

7.9 MULTIPLE LEDGERS/ COMPANY DIVISIONS-----------------------------------------------------------------------------------------17

7.10 FREQUENCY OF ORBIAN PAYMENT RUNS ------------------------------------------------------------------------------------------17

7.11 STATEMENT PERIODS ------------------------------------------------------------------------------------------------------------------18

7.12 BUYER DISCOUNT LIMIT ---------------------------------------------------------------------------------------------------------------18

7.13 BUYER CASH SETTLEMENT OF PAYMENT INSTRUCTIONS ON DUE DATE -------------------------------------------------------18

8 BUYER TESTING ____________________________________________________________________________ 19

8.1 INTRODUCTION --------------------------------------------------------------------------------------------------------------------------19

8.2 TESTING STRATEGY AND APPROACH -----------------------------------------------------------------------------------------------19

8.2.1 UNIT TESTING 19

8.2.2 INTEGRATION TESTING VIA STP 20
8.2.3 USER ACCEPTANCE TESTING 20

APPENDIX 1: OVERVIEW DIAGRAM________________________________________________________________ 21

APPENDIX 2: ACCOUNTING EXAMPLE _____________________________________________________________ 22

APPENDIX 3: ORBIAN SYSTEM SECURITY __________________________________________________________ 24

APPENDIX 4: PROJECT PLAN EXAMPLE ___________________________________________________________ 25

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 3 of 26

 1 INTRODUCTION
1.1 Purpose and Objectives

The purpose of this document is to provide a high level overview of the implementation areas that need to be considered
when integrating a Buyer’s ERP/Legacy system with Orbian’s Supply Chain Finance Solution. As far as possible, it has
been written in non technical terms so that the concepts can be understood by all participating parties in the Buyer
organisation. It is therefore advisable that the document is read by all those involved in the implementation process.

Usually the following functions within the Buyer organization are involved:-

 Accounts Payable;
 Financial Accounting;
 Treasury;
 Procurement;
 IT – ERP/Legacy System;
 IT - Communications; and
 IT - Security.

The high level information contained within this document is supported by additional detailed guides and supporting
materials as outlined in the following tables:

Name of Guide Purpose Audience

Orbian Payment File format guide Details the format and content of the: ERP/Legacy configuration /
 Orbian Payment File coding
 Transaction Results Report
Orbian MT940 Statement File format guide Details the format and content of the ERP/Legacy configuration /
Orbian modified MT940 statement file. coding
STP communications guide Details the communication protocols, IT Security &
encryption and non-repudiation communications
mechanism necessary to support
automated file exchange with Orbian
SAP configuration guide Details the configuration of the Buyer ERP configuration / coding
SAP ERP system for the Orbian
solution.
SAP accounting process example Provides an example of how the Buyer Accounts Payable,
SAP accounting and reconciliation Financial Accounting and
process could be configured to integrate Treasury operations
with the Orbian solution.
ANSI 820 guide – Payment Request Details the format and content of the ERP configuration / coding
ANSI 820 Payment Request file
ANSI 997 guide – Functional Details the format and content of the ERP configuration / coding
Acknowledgement ANSI 997 Functional Acknowledgement
file
ANSI 824 guide – Transaction Results Details the format and content of the ERP configuration / coding
ANSI 824 Transaction Results file
ANSI 821 guide - Statement Details the format and content of the ERP configuration / coding
ANSI 821 Statement file

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 4 of 26

A Buyer Implementation project has five broad phases:

 Project initiation
 Agree business processes
 Configure / code ERP/Legacy system
 Test & Validation
 Go Live

Other elements of the Buyer implementation outside the scope of this Guide include the following:

 Program Initiation/ Corporate acceptance

 Legal
 Treasury Funding
 Supplier Onboarding

1.2 Overview of the Orbian Supply Chain Finance Solution

Prior to the implementation of the Orbian Supply Chain Finance solution, Buyers typically run the following Accounts
Payable process. An established invoice approval procedure is usually in place such as a two or three-way match. Once
an invoice is approved, it effectively ages in the Buyer’s Accounts Payable system until it becomes due for payment, after
which it is paid by one of a number of payment methods (check, wire transfer ACH credit etc.). Remittance information
relating to the payment is usually provided via a paper remittance advice or, in some cases, electronically transmitted /
uploaded via a supplier network or web portal.

When making payments via Orbian, the Buyer’s existing invoice approval and exception handling procedures remain
unchanged. However, rather than waiting until the expiration of the payment terms triggering a payment to the Supplier,
the following process takes place:-

1. After invoice approval, the Buyer creates a Payment Instruction Request which is sent to the Orbian system as
part of the standard payment run process The Payment Instruction Request includes attributes such as the
Supplier details, amount payable, Currency, the future Due Date (calculated from the invoice date and applicable
payment terms), and related remittance information;
2. Upon acceptance of the Payment Instruction Request, the Orbian system will immediately:
 Update the Suppliers Orbian account with the details of the Payment Instruction, including the amount, due
date and the accompanying remittance information.
 Send a response file to the Buyer showing the results of the transaction processing, for exception processing
purposes.
 Generate an email notification to the Supplier’s designated contacts, advising them that there has been
activity on their Orbian account;
3. Supplier’s have the right, but not the obligation, to discount the Buyer receivables at a rate that is a function of the
Buyers’ credit rating and cost of funding and, in doing so, assign the receivable to Orbian. In the event that the
Supplier elects not to discount a Payment Instruction, Orbian will pass on the funds collected from the Buyer to
the Supplier.
4. At the start of the following day, the Orbian system automatically sends a Statement file for each Orbian Buyer
account for accounting and reconciliation purposes.
5. On the due date of the Payment Instruction, the Buyer is required to credit the designated Orbian bank account
for the full value of the Payment Instruction. It is critical that this payment be made on the designated due date as
this underpins the operation and efficiency of Orbian’s unique financing structure.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 5 of 26

Please see Appendix 1 for a diagram showing an example of the flows of information and cash between the Buyer,
Supplier and the Orbian system for the Orbian Supply Chain Finance Solution.

The benefits of the Orbian Supply Chain Finance solution are as follows:

 Working Capital Optimization

o Buyer
 Efficient cash generation through terms extension, versus tapping volatile debt markets or bank
borrowings
 Increase Days Payable Outstanding, matching cash outflows with cash inflows, improve financial
metrics
 Improve cash management and streamline payment processes. Treasury now knows exactly when
and how much cash needs will be paid.
o Supplier
 Non-recourse, non-debt source of working capital at attractive rates based on Buyers cost of credit
 Get paid faster, reduces Days Sales Outstanding, improves financial metrics
 Electronic transfer of remittance information streamlines Accounts Payable reconciliation
 Improve cash management. Supplier now knows exactly when and how much cash will come in.
 Supply Chain Risk Mitigation
o Buyer grants access to non-debt liquidity to assist suppliers solvency
o Buyer retains/obtains preferred customer status
o Payment automation and supplier KYC increases contract compliance and reduces risk of fraud and error
 Cost Reduction
o Reduced latency in invoice approval process
o Streamlined payment processes
o Buyer reduces overhead in non-core activities
 Visibility to approved payments eliminates supplier calls to Accounts Payable department
o Suppliers eliminate carrying costs associated with Buyer receivables
o Buyer reduces payment transaction costs

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 6 of 26

1.3 Project Kick-Off

Orbian will designate a Project Manager to manage and coordinate interaction between the Buyer and Orbian throughout
the Buyer Implementation process.

Following corporate stakeholder acceptance, a project kick-off meeting will be scheduled to review and discuss the steps
needed to ensure a controlled and efficient implementation. Please note this Buyer implementation guide should be
read by all attendees prior to the kick-off meeting.

Topics addressed in the project kick-off meeting and key outcomes include:

 Overview of the Orbian product (including a brief system demonstration)

 Identification of key implementation considerations and dependencies
 Review and discussion of the high level business processes for the Orbian Supply Chain Finance Solution
 Review of the critical success factors for the Buyer implementation of the Supply Chain Finance Solution
 Discussion of the desired project timelines and identification of any potential project issues or constraints
 Identification of key contacts within both organizations
 Discussion and agreement of the project management approach and governance framework

It is critical that the project kick-off meeting is attended by key stakeholders (or appropriate designee’s), and subject
matter experts from within the Buyer’s Accounting; Accounts Payable, Treasury, Procurement, Technology/ERP System,
Communications and IT Security functions. This is to ensure that all relevant departments have a sound understanding of
the Orbian solution and implementation approach, and to allow any potential conflicts, issues or concerns to be identified
and resolved at an early stage.

It is also critical that a Project Manager from within the Buyer organization is identified and empowered to manage all
elements of the project following corporate acceptance. This includes system and business integration, Legal, Treasury,
and supplier on boarding activities.

An example high-level project plan covering key business and process integration tasks is attached as Appendix 4. This
is provided as a guide to the tasks that should be included in the detailed project plan.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 7 of 26

 2 Integration overview
The integration between the Buyer and Orbian may be summarized as the following high level business events:

 Buyer creates Payment Instruction Request file and securely transmits this to Orbian for processing.
 Buyer receives the Transaction Results file containing results of validation and processing success/exceptions
 Buyer receives Statement files of activity on the Buyers Orbian account; for financial accounting and reconciliation
between the Buyer GL system and the Orbian system.

These business events are implemented either via Straight Through Processing (STP) or Manual Processing. These two
processing methods are described in more detail in subsequent sections.

The Buyer is required to select one of these methods of processing as part of the integration approach. However Orbian
recommends the implementation of STP as it is more efficient, secure and scalable than manual processing, especially for
processing high volumes of transactions.

3 Straight Through Processing (STP)

STP allows a Buyer to, securely transmit and receive files containing Payment Instruction Requests, Transaction results
and Statement to the Orbian system using industry standard communications protocols and encryption technologies.

3.1 STP File formats

Orbian supports two file formats for STP integration, the Orbian proprietary format (OPF) and the ANSI format. The files
that make up each format are listed below; and detailed technical guides for each file can be provided by Orbian on
request.

The Buyer is required to select one of these two formats, for their integration with Orbian. Orbian provides experienced
resources to assist with the selection and implementation of a format, and its associated processes.

3.1.1 ORBIAN PROPRIETARY FORMAT (OPF)

The suite of files making up the Orbian proprietary format were developed in conjunction with SAP, and are included in
the SAP ERP system; therefore the Orbian OPF format should be considered as the default choice for SAP users. The
format is also recommended for most other Buyers as it has a more simplified structure compared to the ANSI format.
The Orbian format is composed of the following files:
From Buyer to Orbian:
 Orbian Payment File
o A tab delimited file (Orbian modified SWIFT MT100 file format) containing Payment Instruction
Requests and associated remittance information;

From Orbian to Buyer:

 Orbian Transaction Results Report
o An HTML report showing the results of validating and processing an Orbian Payment File. This file is
used for exception handling by the Buyer as it includes the identification of any failed transaction
requests and the reason for the rejection,
 Orbian MT940 statement

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 8 of 26

 o An Orbian modified SWIFT MT940 account statement format showing opening and closing balances,
and transaction detail, on the Buyers’ Orbian account.

3.1.2 ANSI FORMAT

The ANSI format is only recommended for Buyers who already make extensive use of ANSI as their default EDI format,
as it is more complex to implement than the Orbian OPF format.
Orbian supports the following suite of ANSI files, which are derived from ANSI X12 version 4010:
From Buyer to Orbian:
 ANSI 820 Payment Order/Remittance Advice
o Contains Payment Instruction Requests and associated remittance information;

From Orbian to Buyer:

 ANSI 997 Functional Acknowledgement
o Contains the results of the file format and structure validation carried out on the 820 Payment
Order/Remittance Advice;
 ANSI 824 Application Advice
o Details the results of processing an 820 Payment Order / Remittance Advice in the Orbian system;
 ANSI 821 Financial Information Reporting
o An account statement containing opening and closing balances and transaction detail on the Buyers’
Orbian account.

3.2 STP COMMUNICATION PROTOCOLS

The Buyer is required to select one of the following industry standard communications protocols for the STP transfer of
files

 AS2 (Applicability Statement 2)

 FTP with PGP

AS2 is the recommended choice as it provides a standards accredited EDI protocol with built in encryption and non-
repudiation functions using HTTP(S).

Security and non-repudiation is provided using the following technologies:

 Communication channel encryption using Transport Layer Security (TLS) and Socket Layer Security (SSL) protocols
(HTTPS)
 Pretty Good Privacy (PGP) used for file encryption and signature validation (non-repudiation)
 X509 certificates used for file encryption and signature validation (non-repudiation)

A detailed “Straight Through Processing communications” guide is available from Orbian, and will be provided on request,
to assist the Buyer with the implementation of the chosen protocol. .

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 9 of 26

 4 Manual processing
A Buyer may decide to manually perform the processing of Orbian Supply Chain Finance transactions, despite the fact
that it is less efficient and scalable than STP. Manual processing can only be performed via the Orbian internet portal
(there is no paper based or telephone method of passing Payment Instruction Requests to Orbian). Manual processing
can include remittance information as well as Payment Instruction Requests.

Manual processing of Payment Instruction Requests, via the Orbian internet portal, may be performed by one of two
methods:

 Manual input of individual Payment Instruction Requests and related remittance information
o This method is very time consuming and carries a high risk of input error.
o This method is sometimes used for a “Pilot project”, prior to the implementation of an STP processing
solution
 Manual upload of Payment File
o The Orbian Payment File format is the only file format that can be uploaded through the Orbian internet
portal.
o This approach is less secure, efficient and scalable than STP.

Both manual processing methods automatically trigger an Orbian Transaction Results Report that is available through
the Orbian internet portal, after processing is complete. The Orbian Transaction Results Report shows the results of
validating and processing an Orbian Payment File, including any exceptions of failed transaction requests and the reason
for rejection.

An Orbian Account Statement may be accessed, by the Buyer, through the Orbian internet portal. The Orbian Account
Statement shows opening and closing balances, and transaction detail, on the Buyers’ Orbian account. The Orbian
statement may be downloaded from the Orbian internet portal in Excel, text, pdf or MT940 formats.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 10 of 26

 5 ERP / Legacy system configuration
5.1 General

The Orbian Supply Chain Finance solution has been successfully integrated with a wide-range of Buyers’ general ledger
and accounts payable systems; including SAP, Oracle, PeopleSoft, JD Edwards, BPCS and a number of bespoke in-
house systems.

For an STP processing model, The Buyers’ ERP/Legacy system is generally required to be configured to allow the
following business events to take place:-

 Clear Accounts Payable invoices and Credit Memos

 Create Payment Instruction Requests in the selected file format
 Perform the necessary financial accounting entries from a Buyers Orbian statement
 Reconcile Buyers GL balances to the Buyers Orbian statement

In order to implement these business events, the Buyer is usually required to make changes in the following configuration
areas of their ERP system. Please note that this is not a prescriptive set of actions but illustrates the types of changes that
will need to be done. This area typically is discussed in more detail as part of the technical workshops undertaken with
Orbian during the stages of the implementation.

Configuration Reason
1. Create Orbian as a “Bank” entity. All bank accounts need to be assigned to a bank entity.
2. Create General Ledger Accounts for the In order to control the Orbian transaction process
Orbian process:
- Orbian PI control account
- Vendor Accounts Payable Orbian
3. Create a “Bank Account” for the Buyers To use Payment Method functionality
Orbian account.
4. Configure an Orbian Payment Method This enables the payment program to automatically generate
Orbian Payment Requests with the required attributes.
5. Define automated accounting entries For efficiency and control
created by the Orbian Payment Method
6. Create the selected electronic payment Automate Payment File creation. Remittance enables the
file format and remittance information suppliers to receive the required remittance information
structure
7. Assign selected payment file format to the In order that Orbian Payment Method creates the correct
Orbian Payment Method. payment file format
8. Generate electronic Payment File For security and efficiency
associated with the Orbian Payment
Method for secure transmission to Orbian
9. Define the automated method of To reduce risk of error.
assignment of the Orbian Payment
Method to Accounts Payable invoices
10. Configure system to process Statement For efficiency and control
files transmitted from Orbian, to
automatically update the required
accounting entries.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 11 of 26

5.2 For Buyers who run SAP

The Orbian Supply Chain Finance functionality is already included in the SAP Finance ERP software, for the following
releases, which greatly simplifies the implementation process:

 Release 4.0B: as of Support Package 79

 Release 4.5B: as of Support Package 57
 Release 4.6B: as of Support Package 45
 Release 4.6C: as of Support Package 20
 Release 4.7: as of Support Package 01
 Standard delivery for all releases after 4.7

SAP supports the Orbian Payment File format (OPF) for Payment Instruction Requests and the MT940 statement format
for accounting and reconciliation. Therefore a Buyer can quickly utilize this functionality to configure and automate the
generation of Orbian payment Files from a Payment Run and perform automated accounting from the Statement returned
from Orbian.

Orbian provides a detailed “SAP Configuration Guide”, and technical support, to assist the Buyer in the configuration of
their SAP system. SAP also supports the configuration of Orbian functionality, via its standard support process.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 12 of 26

 6 Accounting Process
6.1 Introduction

This section provides an overview of an approach that has successfully been applied in multiple Buyers’ accounting
systems to record and reconcile Orbian transactions and associated accounting events. It is important to note that Orbian
does not provide accounting advice or opinions, and moreover does not present itself as necessarily qualified to provide
such advice. Accordingly, the Buyer should undertake an independent review and due diligence process before
determining the appropriate accounting principles and procedures which will be applied in relation to Orbian transactions.

The high-level Orbian business events that may need to be accounted for are as follows:
 The performance of Orbian payment runs and generation of Payment Instruction files containing one or more
Payment Instruction Requests and associated remittance information
 The receipt and processing of an Orbian statement identifying transaction activity (Payment Instructions and
settlements) on your Orbian account(s).

These business events should, in turn, create accounting events required to record and/or reconcile:
 The payment of approved invoices via Orbian
 The recording and reconciliation of the Supplier Vendor Payable due to be settled via the Orbian system on a future
date
 The cash settlement and clearing of the Supplier Vendor Payable liability once the Payment Instruction has been
settled on the due date and reconciled by Orbian.

6.2 Accounts Set-up

The following new Orbian related General Ledger accounts are usually required to be configured in the Buyers General
Ledger System:

 Orbian PI Control Account (Balance Sheet): records individual Orbian Payment Instruction requests from the time
of the Orbian payment run until processing of the Orbian statement on the following business day. Any items in this
account that are not cleared following processing of the Orbian statement represent items that have not been
accepted for processing, and are exceptions that require investigation and corrective action by the Buyer. Such
exceptions may occur where Payment Instructions contain incorrect Buyer or Supplier account details, where a
duplicate transaction is suspected, or where a pre-set transaction limit has been breached.
 Vendor Accounts Payable Orbian (Balance Sheet): used to record the Supplier Vendor Payable liability relating to
Payment Instructions which have been issued and remain outstanding on the Orbian System.

In addition to the new General Accounts set-out above, it will be necessary to update the configuration of vendor accounts
in the Buyers’ Accounts Payable sub-ledger for those suppliers that are to be paid via Orbian. This will include updating
the payment method as “Orbian” and maintaining the relevant Orbian Business Partner and Account Number for each
supplier.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 13 of 26

6.3 Reconciliation of the Orbian PI Control Account

As noted in section 3.2, it is recommended that the Buyer establish an Orbian PI Control Account in its General Ledger.
The purpose of this account is to record Payment Instruction Requests until Orbian has confirmed that the request has
been successful via inclusion in an Orbian statement, or advised that the request was rejected via the HTML Transaction
Results Report.

As Payment Instruction Requests can fail for a number of reasons (see Orbian Exceptions section for examples), the
Orbian PI Control Account plays an important role in the identification and handling of exceptions. Accordingly, it is
important that this account be established, reconciled and reviewed on a regular basis. The procedures for reconciling
the Buyers bank and intercompany account should remain largely unchanged following the implementation of Orbian.

6.4 Reconciliation of the Vendor Accounts Payable – Orbian Account

It is also recommended that the Buyer clears the open items in the Vendor Accounts Payable Orbian account using Value
Date equal to the Due Date being processed on a regular basis (i.e. at least weekly or monthly). This will reduce the
number of open items in the account and should simplify its reconciliation. In addition, the Buyer should periodically
reconcile the balance in this account to the closing balance in the Orbian statement for the relevant cut-off date.

6.5 An example of the Accounting steps for a Buyer

Please see Appendix 2 for an example of the accounting steps for a Buyer using the Orbian Supply Chain Finance
solution.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 14 of 26

 7 Other Process Considerations
7.1 Introduction

The following sections identify other process considerations that need to be reviewed and understood by key stakeholders
and members of the Buyer team prior to the commencement of the implementation project. These items arise in almost
every implementation and so are best raised in advance.

7.2 Aggregation of Supplier Invoices and Credit Memos

Buyers are required to designate the due date on each Payment Instruction Request sent to Orbian. This due date is
usually calculated from the invoice date and the payment terms for the Supplier.

When creating Payment Instruction Requests, the recommended approach is to aggregate invoices by Supplier and due
date, deduct Credit Memos for the Supplier and due date, and issue a single Payment Instruction Request for the Due
date and aggregate amount. Details relating to all invoices and Credit Memos should be included in the remittance
information attached to the Payment Instruction Request, to facilitate reconciliation and clearing of the relevant receivable
items by the Supplier in their AR system. So long as sufficient remittance information is attached to each aggregated
Payment Instruction Request issued by the Buyer, Suppliers should not have any difficulty clearing their associated
receivables balances.

Credit Memos must be offset against invoices of a greater amount in the Orbian payment run; as Orbian cannot process a
“net credit” or zero credit amount for a Payment Instruction Request.

If required, it is possible for the Buyer to issue one Payment Instruction Requests for each invoice (i.e. no aggregation).
However, this approach would result in considerably higher transaction volumes and also makes it complex for the Buyer
to apply Credit Memos.

7.3 Remittance Information for Suppliers

Buyers should ensure that their Suppliers receive similar or improved levels of remittance information associated with the
Orbian Payment Instructions, as compared to the current payment method. Examples of remittance information typically
provided by Buyers include invoice number, invoice date, invoice amount and purchase order number. Where applicable,
credit/debit note details, and any other relevant adjustments, should also be included in the remittance information
provided with the relevant Payment Instruction.

Suppliers are able to view, print and download the remittance information provided by the Buyer using statements and
reports accessible via the Orbian Internet Portal.

The configuration of the remittance information for inclusion in the Orbian Payment Instruction Files is part of the Buyers’
ERP system configuration tasks. In addition, it is possible to manually enter remittance information, when manually
creating Payment Instructions via the Orbian Internet Portal.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 15 of 26

7.4 Orbian Day Roll Convention

Orbian applies the following business day day-roll convention:

 If the due date of the Payment Instruction Request, received from the Buyer, falls on a day that is not a business day
in a particular currency then the Orbian System will set the Due date of the Payment Instruction to be the first
business day following the requested due date, for that currency.
 If the Due date of the Payment Instruction Request, received from the Buyer, is less than two business days after the
date that the Payment Instruction Request is accepted by the Orbian System, (or is a date in the past); then the
Orbian System will set the Due Date of the Payment Instruction to be two business days after the date the Payment
Instruction is accepted by the Orbian System, for the currency concerned.

Example: Requested PI Due Date Actual PI Due Date

Saturday, November 22 Monday, November 24

7.5 Maximum Payment Periods

The maximum period between the Due Date of the Payment Instruction Request, and the date it is accepted by the
Orbian System, must be no more than 360 calendar days (before the Orbian day-roll convention is applied). `

7.6 Payment Instructions – Overpayments

Once a Payment Instruction has been issued by the Buyer and accepted by Orbian, it cannot be amended or revoked.
Any credit/debit memos or adjustments, relating to approved invoices already sent to Orbian in a Payment Instruction,
should be entered into the Buyers’ Accounts Payable System, offset against other future invoices from that Supplier, and
therefore included in future Payment Instructions. The Orbian system is capable of handling remittance information
relating to credit/debit memos and adjustments in addition to invoice, purchase order and associated information.

Depending on the size or nature of any disputes, the Buyer may elect to contact the Supplier and agree to handle any
required adjustments or settlements outside the Orbian system.

7.7 Orbian Exceptions

Payment Instruction Requests, raised by a Buyer, may be rejected by the Orbian system for one (or more) of the following
reasons:

 Invalid and/or omitted Buyer or Supplier details (Business Partner or Account Numbers), provided in relation to a
Payment Instruction Request;
 Insufficient available Buyer Credit Limit exists to issue the requested Payment Instruction;
 Negative or zero Payment Instruction Request amounts;
 The amount of a Payment Instruction Request exceeds the transaction limit assigned to the User that initiated the
request;
 The due date of the Payment Instruction Request exceeds the permitted maximum maturity period (before application
of the day-roll convention);
 The Payment Instruction Request has the same Request ID as that used for a recent Payment Instruction, indicating
the probability of a duplicate transaction.
 Invalid characters in the remittance of the Payment Instruction Request, there is a set of defined characters that are
not accepted by the system in the remittance of the Payment Instruction Request.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 16 of 26

7.8 Orbian Business Partner and Account Structures

Buyers and Suppliers are required to be set-up with Business Partner and Account numbers in the Orbian System. A
unique Business Partner number will be assigned to the legal entity that is the primary counterpart to the Orbian Buyer
contract. Account Numbers will then be assigned to each subsidiary, department or division that is authorized to issue
Payment Instructions. Outstanding Payment Instructions are reported at the Orbian Account level.

Orbian Business Partner and Account numbers will be notified as part of the implementation and go-live process, and
facilitate the proper processing, reconciliation and reporting of Orbian transactions. It should be noted that Buyers and
Suppliers are not required to change their bank accounts in order to transact on the Orbian platform.

The Buyers structure for the Buyer Business Partner and Accounts set-up on the Orbian System, depends on the
following key factors:

 The legal entity that is the primary counterparty to the Orbian Buyer Contract and therefore, is ultimately responsible
for settling the Payment Instructions accepted by Orbian
 The corporate, legal, accounting and operating structure of the Buyer organization (including the existence of a
“Shared Services” or similar processing functions).

Examples of potential Orbian Business Partner and Account structures include:

 One legal entity/Orbian Business Partner at the group or consolidated level, with many Orbian Accounts established
for operating subsidiaries, departments or divisions;
 Separate Orbian Business Partner and Account structures for each legal entity within a group of companies; and
 One legal entity/Orbian Business Partner, with many departments or divisions sending Payment Instruction files out of
a single Orbian Account. This may be appropriate where the Buyer has a centralized Accounts Payable and
Accounting functions, but only where all of the departments or divisions are part of the same legal entity.

The appropriate Orbian Business Partner and Account structure will be analysed and agreed as part of the Buyer
implementation project.

7.9 Multiple Ledgers/ Company Divisions

An Orbian statement (similar to a bank statement) will be produced for each Orbian Account held by a Buyer. It is
therefore important that separate Orbian Accounts are opened for each ledger or subsidiary that will be using Orbian to
pay its suppliers. This is because each Orbian statement can only be processed against a single accounting ledger.

7.10 Frequency of Orbian Payment Runs

There is no technical limit to the number of Orbian payment runs and associated Payment Instruction files that can be
generated and sent to Orbian. Most Buyer organizations follow a routine of performing at least weekly payment runs
however, the timing and extent of Orbian payment runs should be determined after consideration of your existing invoice
approval and payment processes.

When determining the frequency of Orbian payment runs, it should also be noted that the quicker that invoices are
approved, and the Payment Instruction sent to Orbian, then the greater the potential working capital benefit will
materialize for Suppliers looking to discount their receivables.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 17 of 26

7.11 Statement Periods

The Orbian system supports the following Orbian account statement frequencies:

 Daily (recommended for automated integration)

 Weekly (Monday to Sunday)
 Calendar monthly

It is strongly recommended that Buyers who perform automated Orbian Statement reconciliation, and those that plan to
perform multiple payment runs per week, elect to receive Orbian statements on a daily basis. This will enable timely
reconciliation of the Orbian PI Control Account and identification and corrections of any exceptions.

7.12 Buyer Discount Limit

Orbian will establish a Buyer Discount Limit on the Orbian System for each Buyer currency that will be used to transact.
The limit will usually be set according to the funding lines that have been established for each Buyer after also considering
the anticipated ramp-up of the Buyer program.

The Buyer Discount Limit refers to the total value of discounted Payment Instructions that a Buyer can have outstanding in
the Orbian system at a point in time. Utilization of the Buyer Credit Limit is increased as Suppliers discount Payment
Instructions issued by the Buyer, and reduced as Buyers cash settle their Payment Instruction obligations to Orbian on the
PI due dates.

7.13 Buyer cash settlement of Payment Instructions on Due date

The Currency amounts, in relation to Payment Instructions due on a certain date, are required to be deposited by the
Buyer into the designated Orbian bank account, in immediately available funds, by 2pm New York time on the due date.

Before the start of business on the business day immediately prior to the due date of one or more Payment Instructions,
the Orbian Operations department will email the designated contacts at the Buyer to confirm the aggregate settlement due
and the designated Orbian bank account into which the funds should be deposited.

If required, prior to initiating the settlement to Orbian, the Buyer may reconcile the Payment Instructions due for
settlement, with the balance recorded in its “Vendor Accounts Payable – Orbian” General Ledger Account for the same
value date. In addition, the Buyer can monitor the funding profile of its Payment Instructions, via the Current and Future
Funding Reports available on the Orbian Portal,

Therefore, the Buyer’s Treasury and Finance Departments will have at least 24 hours notice of the amount due to be
settled.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 18 of 26

 8 Buyer Testing
8.1 Introduction

It is important that a test validation schedule is performed before “Going Live” with the Orbian Supply Chain Finance
solution.

Orbian maintains a dedicated Customer Integration Testing Environment (CITE), which is an identical mirror image of the
Orbian Production System. The CITE system is maintained by Orbian on a daily basis and will be available to Buyers for
testing and training purposes throughout the Buyer implementation process. Orbian will provide the necessary
information and support to enable integration testing and training to take place including:

 The set-up and maintenance of Buyer test accounts and associated information in the CITE system
 Coordination of a testing kick-off meeting
 Assistance in defining a testing strategy and plan
 Attending daily/weekly testing meetings for progress updates and issue resolution

8.2 Testing Strategy and Approach

Orbian will work with the Buyer to agree a testing strategy tailored to the Buyers’ integration approach. Orbian
recommends that Buyer integration testing should be performed in three stages; Unit testing, Integration testing and User
Acceptance testing.

The following sections assume that the Buyer is following the standard STP approach and using Orbian statements for
automated accounting. It is recommended that each stage is concluded by signed-off, before commencement of the next
stage.

8.2.1 UNIT TESTING

Unit testing involves testing each element of the transaction process, transmitting test files via email. Each element may
be tested when it is ready, in parallel, and not necessarily in the order defined below. Example test cases are as follows:

1. Produce a valid Payment Instruction File in the agreed format.

2. Generate remittance information, in a Payment Instruction File, as per the agreed specification.
3. Upload an Orbian account statement into the Buyers’ General Ledger system and generate, review and validate
the associated automated accounting entries.
4. Pass dummy files between the Buyer and Orbian via the established STP communications link.

Test cases 1 – 3 should be performed firstly for normal transaction scenarios, and then exception transaction scenarios,
as follows:

 Normal transaction scenarios: Single invoice, multiple invoices on same Supplier, multiple invoices on multiple
Suppliers, multiple invoices with same Due date
 Exception transaction scenarios: Due date on weekend, Credit Memos, invoice due date in past, negative or zero
amounts, transaction failure and file failure

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 19 of 26

8.2.2 INTEGRATION TESTING VIA STP

Integration testing involves performing the same test cases from Unit testing above, but using the STP communications
link with Orbian, for the transfer of all files.

If possible, the GL accounts used in this test should have zero balances prior to the start of this test cycle, in order that the
following tests can be easily carried out:

 Reconcile balance on "Orbian PI Control"

 Reconcile balance on "Vendor Accounts Payable - Orbian" GL account to Orbian statement
 Review Orbian Current and Future Funding Reports for Treasury Purposes, and reconcile to Buyer system

8.2.3 USER ACCEPTANCE TESTING

User Acceptance Testing involves performing a number of full test cycles validating end-to-end processing, using key
users such as, Accounts payable, Financial Accounting and Treasury staff. Each full-cycle test usually takes 4 – 5
working days duration. It is up to the Buyer to determine how many cycles of UAT will be performed prior to sign-off, but
at least one error free cycle is usually required.

Whilst not intended to be an exhaustive list, the following activities should be included in the User Acceptance Testing
cycle:

 Accounts Payable:
o Set up the master data for a number of Orbian Suppliers and enter a range of invoice and associated
remittance information (including credit memos);
o Perform a number of Orbian payment runs and generate Payment Instruction Files, which are sent to Orbian
via STP (Normal scenarios);
o Produce a series of Payment Instruction Files which include exceptions as set out in Unit Testing Of Payment
Files, Statements and Communications section and errors as set out in Orbian exceptions section;
o Review the Transaction Results files produced by Orbian;
o Correct the Buyer system, for any errors shown in the Transaction Results file and re-process rejected
Payment Instructions Requests;
o Review the remittance information on the accepted Payment Instructions, via the Orbian Portal.
o Document test results and update Operational procedures, including exception handling;
 Financial Accounting:
o Receive and process Orbian account statements;
o Review the accounting entries automatically raised by the generation of the Payment Instruction File and on
processing of Orbian statements;
o Review and reconcile the balance in the Orbian Control Account;
o Reconcile the balance in the Vendor AP Orbian GL account to Orbian System reports;
o Document test results and update Accounting procedures as appropriate.
 Treasury:
o Review the maturity ladder set out in the Orbian Current and Future Funding Reports on the Orbian Portal;
o Receive and process the confirmation email from Orbian Operations advising of Payment Instruction
Maturities;
o Reconcile Payment Instruction Maturities from Orbian email to Buyers accounting system (Recommended)
o Process a small value payment into Orbian’s designated bank account after setting up the required standing
data for future production payments;
o Document test results and update Treasury procedures as appropriate.

Following successful completion of the UAT phase, formal sign-off should be provided by each of the relevant
departments as a pre-requisite to go-live.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 20 of 26

 Appendix 1: Overview Diagram
The following diagram shows an example of the flows of information and cash between the Buyer, Supplier and the
Orbian system for the Orbian Supply Chain Finance Solution:

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 21 of 26

 Appendix 2: Accounting Example
This Appendix sets out an example of a production accounting process that we have seen effectively applied to record
and reconcile Orbian transactions and associated business events, in order that both accountants and non-accountants
can obtain a general understanding of the process. The accounting entries are displayed in “T” account format, with debits
on the left hand side and credits on the right hand side.

Step 1: Buyer approves and processes invoices from Supplier:

Vendor Accounts Payable

1a 100
1b 200

Vendor invoices are posted into the Accounts Payable sub-ledger in the usual way, following approval. It is assumed the
invoice is ‘good to pay’, ie necessary buyer controls have been performed (eg 3 way match).

The resultant vendor payable liability will have a due date equal to the invoice date plus the relevant payment terms which
is tracked within the Account Payable sub-ledger.

Step 2: Buyer performs an Orbian Payment Run – Clear Vendor Accounts Payable open items and
raise corresponding open items in the Orbian Control Account

Vendor Accounts Payable Orbian Control Account

2a 100 1a 100 2a 100
2b 200 1b 200 2b 200

The Orbian payment run should collect all "open" (i.e. not yet cleared) approved invoices and credit memos on vendor
accounts, with the Orbian payment method, irrespective of the associated due dates.

The payment run should also automatically create an Orbian Payment File containing one, or many, Payment Instruction
Request(s) which is then securely transmitted to Orbian. The accounting entries 2a and 2b above should be generated by
the Orbian payment run:

Debit the relevant Vendor Accounts Payable supplier account to clear the liability;

Credit the Orbian Control Account in the General Ledger, pending confirmation that the requested
transaction has been accepted and processed by Orbian. Following the processing of the Payment File,
the Orbian system will automatically generate and return a Transaction Results Report which confirms
that the file has been processed and identifies any rejected Payment Instruction Requests, and the
associated reason for rejection. This acts as an early warning that there has been a problem with one or
more Payment Instruction Requests and appropriate follow up action should be initiated at the Buyer.
Where PI requests are rejected by Orbian (for example, incorrect Orbian Account Number), Buyer resets
and reverses the related open item on the Orbian PI Control Account thereby the original invoices will be
returned to the status of open in the Vendor Account on AP. This open item can then be included in the
next Orbian payment run

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 22 of 26

 Step 3: Process Orbian statement on the business day following the Orbian Payment Run – Clear
Orbian Control Account item and record liability in the Vendor AP Orbian GL Account

Orbian Control Account Vendor AP Orbian Account

3a 100 2a 100 3a 100
3b 200 2b 200 3b 200

The Buyer receives and processes the Orbian statement, on the business day following the Payment Run, which includes
confirmation of the Payment Instructions accepted by Orbian.

The accounting entries 3a and 3b should be posted as follows:

 Debit - the Orbian Control Account for each Payment Instruction accepted by Orbian
 Credit - the Vendor AP Orbian Account

The Balance on the Vendor AP Orbian account after the upload of the Orbian statement represents the payable from the
Buyer to Orbian. This should be equal to the closing balance on the Orbian statement and these balances should be
reconciled periodically. Furthermore, if no Payment Instruction Requests were rejected and no other payment runs have
been performed prior to processing of the Orbian statement, the balance in the Orbian PI Control Account should be zero.

Step 4: Process Orbian statement containing settlement of Payment Instruction –.

Two business days after the Buyer settles its obligations under maturing Payment Instructions to Orbian, the settlement of
each Payment Instruction will appear on the Buyers’ Orbian statement, allowing the Buyer to clear the liabilities in the
Vendor AP Orbian account.

The following accounting entries should be made on processing of the statement:

 Debit the Vendor AP Orbian Account (for each Payment Instruction settled)
 Credit the relevant General Ledger Cash or Cash Clearing Account

Thereby closing the liability to the supplier and showing the movement of cash on settlement.

Step 5: Perform periodic reconciliation of the General Ledger Cash Account or Cash Clearing against
the Bank statement

On receipt of the Buyer’s bank statement, the usual cash reconciliation procedures should be performed between the
General Ledger Cash Account or Cash Clearing Account and the Buyer’s Bank statement.

This step in the process is not part of the Orbian specific process, but is assumed and shown here for clarity and
completeness.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 23 of 26

 Appendix 3: Orbian System Security
The Orbian System is a custom built application designed and developed to securely manage the straight-through-
processing of high volumes of Payment Instructions.

Buyer’s accounting and accounts payable systems can communicate on-line and in real-time with the Orbian System
through secure, encrypted internet connections which enable automated file handling, transaction processing, event
notification and accounting/reconciliation procedures. Transactions can be processed and reconciled with minimal or no
manual intervention.

The Orbian production environment is built on resilient, high-performance servers housed in two secure data centers
providing 24x7 operations and continuation of business in the event of emergency. The technical environment and
support procedures adhere to ISO 17799 and meet the strict demands of internal information security standards.

System security is an integral part of Orbian's systems and development process. Orbian employs the following
protections to ensure that the Orbian System remains secure:

 Security layers between the Internet, the application and the data store comprising resilient multiple-layer, multiple
firewall infrastructures and a segmentation of servers with strict control over connections between servers;
 Regular internal and external security scans executed on the Orbian network to check for any vulnerability;
 PKI and PGP technologies used to secure and authenticate(non-repudiation) file based communications;
 128-bit encryption and 2-factor authentication used to establish connection from a Buyer’s browser to the Orbian
environment;
 All security mechanisms provide a high level of confidentiality, integrity and authorization. Where a Buyer is initiating a
payment transaction, the security mechanism also provides for non-repudiation;
 Documented security procedures are audited for compliance on an annual basis.

The following table summarizes the security mechanism for the access types currently in use.

Access type Security Mechanism

 Password authentication for supplier reporting activities
Suppliers
 Non-invasive two factor authentication for manual discount Suppliers
Buyers – via internet portal  Two-factor authentication for Payment Instruction issuance
 Single factor authentication for reporting
 Digitally signed batch of transactions that can be processed in real
Buyers – via Straight Through Processing (STP) time
 Uses X.509 Certificates over AS2
 Uses PGP technology over FTP

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 24 of 26

 Appendix 4: Project Plan Example

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 25 of 26

The Excel file of the high-level project plan example above is also embedded in the following icon:

O:\Product
Management\Impleme

Please double click on the icon to open the file in Excel.

© Orbian 2000-2009. Confidential and Proprietary. All rights reserved. Page 26 of 26