Project plan Status Based Receivables Finance 2016

Sharing invoice statuses to improve cash flow of Sellers -‐ Project plan 1 of 14 15/02/16 – 1.0 15/02/16 – 1.0

PROJECT PLAN Improving the cash position of the Seller by exchanging the invoice status Continuing the exploration of Status Based Receivables Finance

Project Management & Author Innopay Pepijn Groen

Commissioned by Fraunhofer IML Dortmund, Supply Chain Finance community

Release Version 1.0


MANAGEMENT SUMMARY ............................................................................................................. 3

1 INTRODUCTION ........................................................................................................................ 4

1.1 INTRODUCTION TO STATUS BASED RECEIVABLES FINANCING (SBRF) .................................................... 4 1.2 HISTORY OF SBRF CONCEPT DEVELOPMENT .................................................................................... 5 1.3 SETTING-‐UP MORE POCS IS THE NEXT STEP ...................................................................................... 6 1.4 GENERIC POC SET-‐UP ................................................................................................................. 7

2 DETAILED PROJECT APPROACH AND ORGANISATION ............................................................... 8

2.1 PROJECT GOAL .......................................................................................................................... 8 2.2 FIVE ITERATIONS APPROACH TO ACHIEVE PROJECT GOAL ..................................................................... 8 2.3 THREE-‐TRACK APPROACH FOR ITERATION #2 ................................................................................. 10 2.4 PROJECT ORGANISATION FOR ITERATION #2 .................................................................................. 11

APPENDIX A. DETAILED PLANNING FOR PROOF OF CONCEPT ....................................................... 12

APPENDIX B – GLOSSARY .............................................................................................................. 13


Management summary

This project plan is a follow up of two parallel projects (October 2015 – January 2016) that assessed whether Sellers could improve cash visibility and financeability of their receivables, through (community based) agreements on formats and means for exchange of invoice status information between Seller, Buyers and Financiers. This is also referred to as ‘Status Based Receivables Finance’ (i.e. SBRF). The first project was commissioned by the Supply Chain Finance Community (with Fraunhofer IML in the lead on the topic of ‘standardisation’) and focused on: 1. developing the scope for future standardisation of exchanging invoice status information; and 2. finding a ‘coalition of ṭhe willing’, i.e. a number of parties in Europe that are active in invoicing

and financing, and that are willing to contribute to developing a standard for exchanging invoice status information.

A second and tightly related project, commissioned by Connekt, concerns a Proof of Concept (PoC) to investigate specifications for invoice status information and learn from ‘live’ exchange of the invoice status in a small Dutch community. The first project of creating a pan-‐European scope for standardisation and a first ‘coalition of the willing’ turned out to be too ambitious. The readiness for such concept is very different per community, where the NL community seems more ready than the German and Italian community. Therefore, scoping towards standardisation will take a longer period of time, only after small groups of players have successfully investigated common specifications through PoCs in various communities. The experiences with the Dutch PoC have shown that a PoC is a good instrument for exploring and communicating about this innovative concept. Also a PoC leads to practical input for the future standardisation (e.g. in ISO20022) of invoice statuses and the exchange thereof. By executing multiple PoCs in multiple communities, a good basis could be created for the formalisation into a standard, to be used by providers of receivable financing, ERP systems and invoicing solutions worldwide. In order to proceed towards developing a standard for the exchange of invoice statuses, the next steps to be undertaken would be: 1. Setting-‐up similar PoC communities in Germany and Italy; 2. Extending the Dutch PoC by involving more Buyers, Sellers and Financiers; 3. Consolidating the specifications for exchanging invoice status information derived from the

different PoCs in preparation for future standardisation.

This three track PoC approach is the foundation for this project plan and is explained in more detail in the following chapters.


1 Introduction

This chapter provides an introduction to this project plan and future steps by • Introduction to Status Based Receivables Financing (i.e. SBRF) concept and its benefits; • Providing a history overview of SBRF concept development; • Discussing the next step to test the SBRF concept with (more) PoCs; • Describing the PoC set-‐up that was used in the Netherlands.

1.1 Introduction to Status Based Receivables Financing (SBRF) Improving access to finance for European SMEs is at the top of the political agenda. Access to finance is important for the cash flow and working capital position (i.e. cash position) of SMEs. A type of financing to help SMEs improve their cash position is receivables1 financing. However, SMEs have limited access to Financier’s receivables finance offerings, due to high process -‐ and costs for the financeability of receivabes. The concept of Status Based Receivables Finance (SBRF) is based on the idea that financeability of receivables could be optimised through standardisation2 of invoice status information and sharing it in a chain of Sellers, Buyers and Financiers. Receivables finance is not optimised for several reasons, including: 1. Limited visibility on invoice statuses (i.e. no track & trace); 2. Unpredictability of if and when the Buyer will actually pay the invoice; 3. Other associated risks that are part of the trade and goods of invoices (e.g. disputes,

performance issues, fake invoices).

Figure 1: Unpredictability leads to challenges for selling parties in managing their cash positions

1 Definition is included in Glossary of Appendix B. 2 Definition is included in Glossary of Appendix B.

•  Cash%flow%forecas-ng%can’t%be%op-mized%due%to%limited'visibility%on%invoice%status%and%payments%

•  Restric/ons'on'working'capital'reserves%to%deal%with%trading%risks%(e.g.%non?payment,%disputes,%performance)%

•  The%asymmetry%between%the%flow%of%cash%and%the%flow%of%invoice%informa-on%(e.g.%payment%terms)%%between%Seller%and%Buyer%lead%to%uncertain'financing'possibili/es%

•  Limited'access'to%financiers%receivables%financing%offerings%(e.g.%reverse%factoring,%asset?based%financing)%%due%to%high%process%and%financing%cost%as%well%as%dependency%from%coopera-on%from%buyers%

Invoice%sent%

Cash%

Invoice%sent%

Cash%

Financier% Financier% Financier%

Buy$ Sell$

En*ty$

ERP$solu*on$

Buy$ Sell$

En*ty$

ERP$solu*on$

Buy$ Sell$

En*ty$

ERP$solu*on$

Unpredictable'when/if'cash'will'

come!'

Unpredictable'when/if'cash'will'

come!'


Assessing risks and coping with uncertainties of invoice payments cause high process -‐ and financing costs for Financiers. Making invoice status information (e.g. received, approved, paid) transparent and sharing it with Sellers and Financiers will improve predictability of invoice payments and process efficiency. There are several benefits to the SBRF concept. In the table below benefits are listed for Financiers, Sellers and Buyer where it is assumed that benefits apply to all types of Financiers (i.e. banks and non-‐banks) and Sellers and Buyers (i.e. large and small). Financiers Sellers Buyers 1. Lower risks 1. Better cash flow forecasting 1. Less operation creditor

handling 2. Process efficiency 2. Less operational debtor

handling 2. Strengthening of entity’s

Supply Chain 3. Ability to address lower ticket

mass market 3. Better access to financing

instruments: faster, more choice, easier

3. Optimise internal procurement and invoice approval processes

4. Invoice discounting opportunities

5. Potential to extend payment deadlines

Table 1: Benefits of exchanging invoice status information for Financiers, Sellers and Buyers

1.2 History of SBRF concept development In a feasibility study executed by Innopay between September and December 20143, a varied group of market actors were interviewed to assess the SBRF concept and its benefits. These included parties throughout the financing and e-‐invoicing value chain, such as e-‐invoicing service providers, ERP solution providers, technology & reverse factoring, platforms, corporate buyers, banks and other type of Financiers. The overall research results indicate that standardised exchange of invoice status information could improve the financeability of receivables for Sellers and Financiers, as a result of lower associated risks of receivables and more possibilities for Straight Through Processing (STP). Four key outcomes of the assessment and interviews are: 1. Benefits are recognized, but need be further assessed. 2. Buyers incentives for exchanging invoice status information with Sellers and Financiers is key. 3. Invoice status information requires a level of assurance for Financiers (e.g. from self-‐declared by

Buyer -‐ to guaranteed by a third party). 4. Governance for trust is needed for the rights and obligations on sharing invoice status

information.

3 The initiative builds upon a qualitative feasibility study that was part of a comprehensive action plan from the Dutch Ministry of Economic Affairs to improve access to finance for SME’s. The study that has been executed by Innopay on behalf of the Dutch Ministry of Economic Affairs in close collaboration with Fraunhofer IML Dortmund, the Supply Chain Finance Community and Windesheim University.


A key recommendation from this study was to develop a project plan with clear ‘go / no go’ decision points in order to advance the SBRF concept with a standard for exchanging invoice status information within a coalition of market actors. Furthermore, it was recommended to test the SBRF within a small community of a Seller, its Buyers and his Financier as input for the standardisation of exchanging invoice status information. This resulted in two follow-‐up projects executed between November 2015 and January 2016: 1. A project to develop the scope for standardisation of exchanging invoice status information and

creating a pan-‐European coalition of the willing; 2. A second and tightly related project, commissioned by Connekt, concerning a Proof of Concept

(PoC) to investigate specifications for invoice status information and learn from ‘live’ exchange of the invoice status in a small Dutch community.

The readiness for the SBRF concept turned out to be very different per community: the Dutch community seems more ready than other European communities. Therefore, scoping towards standardisation will take a longer period of time, and can only take place after small groups of players have successfully investigated common specifications through PoCs in various communities. The experiences with the Dutch PoC have shown that a small community set-‐up of a Financier and its customer base works well to develop the first set of specifications and learn from the SBRF concept. After specifications and requirements were set, a separate invoice status platform was built to exchange the invoice status information in a live setting. Working with the small community proved to illustrate and create readiness for the SBRF concept. The results can become practical input for the future standardisation of invoice statuses and the exchange thereof. As part of the standardisation effort, the Dutch PoC was demonstrated in Frankfurt in January 2016.

1.3 Setting-‐up more PoCs is the next step During the presentation of the Dutch PoC, it turned out that there is enough interest in Germany and Italy to set-‐up similar PoCs to the one executed in the Netherlands. Therefore, it is proposed to advance the SBRF concept and further define the scope for invoice status standardisation by executing PoCs in Germany and Italy, while at the same time extending the Dutch PoC with additional market actors. Subsequently, consolidation of the PoCs results could form a solid basis for the creation of an invoice status information standard to be integrated by market actors of financing, ERP systems and invoicing solutions. This approach results in a three-‐track set-‐up: 1. PoCs. Similar PoCs as in the Netherlands will be set-‐up for Germany and Italy, while at the same

time the Dutch PoC will be extended by involving more parties; 2. Consolidation of specifications. From the PoCs, new specifications and lessons learned are

gathered and observed in terms of legal, operational, functional and technical (LOFT) dimensions;

3. Overall project management, in support of setting-‐up PoCs, facilitates knowledge sharing and communication to market actors.


When setting-‐up new PoCs, it is suggested to work with a variety of use-‐case configurations of Sellers, Buyers and Financiers (e.g. small Sellers, large Buyers and commercial banks).

1.4 Generic PoC set-‐up This paragraph explains how a PoC can be set-‐up. This is illustrated by recent experiences from the Dutch PoC, other communities may require different set-‐ups. For the Dutch PoC, a community of a Seller, his Buyers and his preferred Financier were selected to exchange the status of invoices in real-‐life. Buyers are key actors, because they are the only party that have the invoice statuses and are requested (by the Seller) to share this with the Seller’s preferred Financier. In order to relieve the Buyer as much as possible from the Seller’s financing activities, a platform was developed to exchange the invoice status from the Buyer’s ERP solution directly to the Financier in a fully automated way. Special attention was given to the permission protocol, through which Buyers can grant permission to (Seller’s) Financiers (initiated by the Seller) to have access to the status of a specific set -‐ or all invoices. In the below image the Dutch PoC set-‐up is illustrated and further explained.

Figure 2: Proof of Concept set-‐up in the Netherlands In the next chapter the the total project approach, organisation and activities is elaborated on in more detail.

Goods,&Invoice&

Buying'en)ty'gives'permission'on'Selling'en)ty’s'request'

Share&status&Buy$ Sell$

En*ty$

ERP$solu*on$

Buy$ Sell$

En*ty$

ERP$solu*on$

Status&pla)orm&

Financier&

Invoicepermissions.com'

voldaan'factoring'B.V.'

Permission&protocol&Invoice&status&exchange&

Buyers&•  Customers&of&

homecareinnova<on.nl&•  Status&pla>orm&has&API&

access&to&Buyers&=ExactOnline&soBware,&which&is&a&cloud&solu<on&and&popular&in&the&Netherlands&amongst&Seller&(SMEs)&

&

Status&pla)orm&•  Facilitates&access&for&voldaan&factoring&

B.V.&to&access&Buyer’s&ERP&solu<on&via&permission&protocol&&

•  Consolidates&invoice&statuses&from&Exact&into&one&standard&format&to&voldaan&factoring&B.V.&

•  Faciltates&automa<c&and&direct&exchange&of&invoice&statuses&between&Buyer&and&voldaan&factoring&&B.V.&

&&voldaan&factoring&B.V.&&A&nonMbanking&factoring&company&in&the&role&of&Financier&that&is&directly&connected&to&status&pla>orm&to&receive&the&invoice&status.&&&

&&&&Homecareinnova>on.nl&Client&of&voldaan&factoring&B.V.&in&the&role&of&Seller.&&&

&&


2 Detailed project approach and organisation

This chapter provides the reader more information of the project approach and organisation by • Explaining the project goals and what should be achieved; • Considering possible re-‐use of market standards in invoicing and financing; • Introducing overall 4-‐iteration project approach to achieve a standard; • Discussing the next steps in extending PoCs in more detail; • Showing the project organisation to facilitate the next iteration.

2.1 Project goal The goal of this project is to improve the receivables (i.e. invoices) finance propositions for European Sellers by creating a standard for invoice status information and its exchange in a chain of Sellers, Buyers and Financiers. This project goal can be achieved by: 1. Developing specifications to release the invoices status information from the Buyer’s

administration and, by doing so, allowing Financiers to operate more efficiently and more effectively;

2. Consolidating specifications into a standard, including a governance framework. It is expected that existing standards, such as UBL, PEPPOL and/or ISO20022 can be re-‐used as much as possible, and can be integrated in today’s ERP systems or other invoicing and financing solutions to create reach;

3. Ensuring that a wide range of Buyers, Sellers and Financiers could use future standards for exchanging of invoice status information.

In order to achieve the project goals, particularly with regard to the wide range of parties involved, standardisation is of paramount importance. To achieve standardisation, an iterative approach in four stages has been embarked upon. With the realisation of the PoC in the Netherlands, the first stage has been concluded.

2.2 Five iterations approach to achieve project goal To achieve the defined project goals a 5-‐stage iterative approach is proposed, as illustrated in the below figure.


Figure 3: A 5-‐stage iterative approach is proposed to achieve the project goals Below is a description of the 5-‐stage iterative approach and (expected) lead times: 1. The first iteration (November ’15 – January ’16), commissioned by Connekt, was concluded

when the Dutch PoC was presented in Frankfurt. 2. In the second iteration, (March ’16 – June ’16), new PoC communities in Germany and Italy will

be set-‐up and the Dutch PoC will be extended by involving other Financiers and its customer base (i.e. Sellers and Buyers). This will result in the development of more specifications and lessons learned. All together, these PoCs have an anticipated lead time of 4 months. It is important to note that a group of willing Financiers per community must be identified and signed with an agreement to participate in the PoCs. This is expected to take four weeks.

3. In a third iteration (lead-‐time to be specified), specifications and lessons learned from new PoCs will be consolidated in preparation for standardisation of invoice status information.

4. In a fourth iteration (lead-‐time to be specified), a standard and governance framework will be developed and prepared for implementation by the participants of the different PoCs.

5. In a fifth iteration (lead-‐time to be specified), implementation of the standards by the PoC participants will take place within their existing ERP solutions. Furthermore, activation campaigns will be set-‐up to persuade other market actors to integrate the standard in order to increase reach and adoption.

All iterations are finalised by a Gate Review. In the Gate Reviews, PoCs results are evaluated and a follow-‐up plan for the next iteration is reviewed by the project’s Steering Group (more details in paragraph 2.4) and the PoC participants. Together they will decide if and when the next iteration will start.

6

Stan

dardisa

)on+maturity+

Gate%review%to%next%itera-on%

Timelines%yet%TBA%

#1%PoC%NL%

#3%Consolida-on%

Purpose(•  Lessons%learned%•  Scoping%LOFT%

dimensions%•  First%specs%invoice%

status%info%%

Mrch%‘16% Jun%%‘16%Nov%‘16%

Project%plan%scope%

Turning%point%to%standardisa-on%

Specifica-ons%

Standardisa-on%

Purpose(•  Extend%PoC%Netherlands%•  SetMup%PoCs%in%Germany,%

Italy%•  Document%lessons%learned%

on%LOFT%items%•  Develop%more%specs%for%

invoice%status%info%and%its%exchange%

%

Purpose(•  SetMup%more%PoCs%•  Extend%exis-ng%PoCs%%•  Consolida-on%of%(API)%specs%•  Consolida-on%of%lessons%learned%

#2%PoC%extended%

#4%%Standardisa-on%

Purpose(•  Develop%invoice%status%info%standard%

and%governance%framework%setMup%(i.e.%LOFT%documenta-ons)%

•  PoCs%par-pants%prepare%for%implemementa-on%

•  Plan%for%external%communica-on%%

5#%Implementa-on%

Purpose(•  Implementa-on%of%

standards%among%PoCs%own%solu-ons%

•  Campaign%to%achieve%growth%of%standard%usage%

Sharing invoice statuses to improve cash flow of Sellers -‐ Project plan 10 of 14 15/02/16 – 1.0

2.3 Three-‐track approach for iteration #2 Iteration #2 further elaborates on the results of the Dutch PoC and standardisation effort, resulting in a three-‐track approach (i.e. standardization, Proof of Concept and overarching Project management) as depicted in the below image. The PoCs in The Netherlands will be extended with other Financiers and their customer base, but will also act as a template for the other PoCs in Germany and Italy.

Figure 4: Three-‐track approach for iteration #2 The project results of iteration #2 can be summarized as follows: • Execution of a PoC with local communities in Germany and Italy: similar communities as in the

Netherlands will be set-‐up for Germany and Italy. It is proposed to set-‐up communities with a larger variety of participating Sellers, Buyers (e.g. large corporates) and Financiers (e.g. Commercial banks);

• Extending the Dutch PoC community by involving new types of Financiers and their customer base, so that new Sellers, Buyers and other ERP solutions will be connected to the invoice status platform. Not only will this result in more API specifications and improvement of the concept, but will also contribute to overall exposure of this innovation;

• Specifications for invoice status information and its exchange; by connecting the Buyer's ERP system to the Financier (via the invoice status platform), API specifications are developed;

• Lessons learned documented; more lessons learned are documented and will be converted to legal, operational, functional and technical (LOFT) challenges for the next two iterations;

• Project plan for iteration #3; a follow-‐up approach is required for the next iteration. Progress in developing this plan depends on the results of the PoCs of iteration #2;

• PoC reports and presentations per community, including the overall results and efforts taken by the Dutch, German and Italian communities. These reports are in such a format so they can be published to a wide audience of actors in invoicing and financing.

Nov$2015$ Dec$2015$ Jan$2016$ Onwards$>>$

Track$3:$$

Project=

mgm

t$

MeeAngs$&$regular$touch$points$

Track$2:$

Proo

f$of$C

oncept$

Track$1:$$

ConsolidaA

on$

IteraAon$#1$ IteraAon$#2$ Further$iteraAons$>>$

Mar$–$Apr$–$May=$Jun$2016$

Workshop$17$Nov$

Webinar$10$Dec$

PoC$report$

Working$PoC$

plaSorm$

PoC$NL$PreparaAon$ PoC$NL$ImplementaAon$ PoC$NL$PublicaAons$

PoC$presentaAon$

New$PoC$GE$

SpecificaAon$&$design$PoC$

PoC$live$

Gate$review$Gate$review$$

Project$plan$iteraAon$#3$$

Lessons$learned$Docs$

New$PoC$IT$

Extend$NL$PoC$$

Harmonise$$lessons$learned$

Repor&ng)

Workshop$15$Jan$

Project$plan$

PoC$reports$

Working$PoCs$

PoC$presentaAons$


The Dutch PoC approach will be re-‐used to achieve these results in Germany and Italy. A detailed project planning with deliverables for this PoC is included in Chapter 3.

2.4 Project organisation for iteration #2 The organisational structure of iteration #2 is proposed below. It has a clear distinction between the reporting and process facilitation and PoCs execution as depicted on the left. PoCs planning exectution and deliverables are based on three-‐phased Dutch PoC approach: 1. Preparation & scoping; 2. Implementation; and 3. Publication (for more details, please refer to Appendix A).

Figuur 1: Project organisation for iteration #2 The project manager in the Project Management Office (PMO) and Support are the overall process lead and responsible for the PoCs’ progress and outputs, informing and reporting to the Steering Group (SG) and communicating to industry stakeholders. A representative of the Financier leads PoCs, who is responsible for involving its own customer base. The SG is composed of representatives of Fraunhofer IML, the Supply Chain Finance community, Politecnico di Milano: Versione Italiana (i.e. Polimi) and standardisation expert(s). As during the first iteration, the SG will review the project deliverables and safeguard overall consistency.

1.#Scoping#

2.#Implementa2on#

3.#Publica2ons#

Community#NL# Community#GE# Community#IT#

Market##Stakeh

olde

rs##Informed#

Project(organisa.on(for(itera.on(#2(

Proof#of#Concept#execu2on#

Steering#Group#

Representa2ve# Representa2ve# Representa2ve#

Support#PMO#

Report#and#process#


Appendix A. Detailed planning for Proof of Concept

Based on the Dutch PoC experiences, PoC planning including a set of deliverables is presented in the Figure below.

Figure 5: PoC planning in The Netherlands

Example(Proof(of(Concept(planning Febuary6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Deliverables PrioOverall:project:management

1 Internal(meetings((bi8weekly) N/A2 Steering(Group(updates N/A3 Community(meetings N/A4 Inform(market(actors N/A Continuous

5 Agile(hearbeat((i.e.(weekly('live(update'(&(demonstration) N/A Wed Wed Wed Wed Wed Wed Wed Wed Wed Wed Wed Wed Wed

6 Customer(base(selection((Buyer/Seller) N/A Deadline

Phase:I Preperation:&:Scoping:0 Financier(and(community(set8up(in(GE,(IT,(NL Must Deadline

Set$approach$for$Financiers$and$its$customer$baseMarket$consultations$Information$and$presentationsProof$of$Concept$selection$(Buyer$/$Seller)

1 Project(initial(scope(&(planning Must Deadline

2 Research(questions(and(hypothesis Must Deadline

3 Market(research( Must Deadline

Buyer's$ERP$solution$connectivity$possibilities4 User(stories,(non(exhaustive(list(could(include:( Must Deadline

Invoice$status$information$exchange$flowsPermissions,$rights$and$obligations$Organisation$and$GovernanceFrauds$and$errors

5 Functional(&(technical(scoping Must Deadline

Architectural$principlesInquiry$new$or$innovative$technologIies$(e.g.$Blockchain)Functional$requirements$for$invoice$status$platformInquiry$used$data$formats$and$API$specs$Digital$ID$requirements$Security$measures$(e.g.$linux$stack,$laravel,$SSL)

6 Information(anaylsis(and(specification(development Must Deadline

API$specifications$for$invoice$status$information$exchangeSet$permissions$protocolTerms$and$conditions$for$participation

Phase:II Implementation1 Invoice(status(platform(development Must Deadline

UI$DesignsData(base)$model$and$other$backend$setPupProtocol$/$API$Connectivity$Proof$of$Concept$testing$with$virtual$account

2 Testing(with(Buyer's(and(Financier Must Deadline

Use$cases$and$test$scripts3 Final(implementation(of(invoice(status(platform(community Must Deadline

4 Evaluation(of(Buyers(and(Financiers(feedback( Must Deadline

Questionnaires5 Gate(Review((i.e.(Evaluation(and(discuss(next(project(steps) Must Deadline

Phase:III Publications1 Proof(of(Concept(report Must Deadline

2 PoC(presentations Must Deadline

3 Project(plan(for(next(iterations Must Deadline

March April May


Appendix B – Glossary

Application Programming Access to software functionalities in the form of instruction routines Interface (API): and protocols, enabling software components to interact without

human intervention. Enterprise Resource Planning (ERP): The process by which a company manages and integrates the

important parts of its business. An ERP management information system integrates areas such as planning, purchasing, inventory, sales, marketing, finance, human resources, etc.

Financier: All types of providers offering financing options: banks (cf. reverse

factoring) and non-‐bank parties (e.g. invoice Financiers, asset lenders, peer-‐to-‐peer lending clubs, trade Financiers, private investment companies, commercial debt funds, companies with excess cash).

ISO20022: An International Organisation for Standardisation (ISO) standard for

the electronic exchange of financial data. ISO20022 is widely used, amongst others as a basis for the SEPA Credit Transfer and SEPA Direct Debit.

LOFT: Legal, Operational, Functional and Technical (i.e. LOFT) items are

required to organise trust for the use and exchange of invoice status information. It involves tools and techniques for adherence (e.g. licenses, certificates, regulation) installation of operation management and governance, a functional scope and technical building blocks of the invoice status information exchange (e.g. protocols, messaging standards, securities and API specifications).

Pan-‐European Public A solution that enables Suppliers to securely exchange cross-‐ Procurement (PEPPOL): border electronic invoices with their buyers within Europe. PEPPOL

uses UBL as standard format. Receivables Finance: Receivables (i.e. invoices) finance is based on a financial

arrangement between a Seller and a Financier in which the Seller either sells one or more invoices to the Financier, or uses his invoices as collateral for a loan. Sellers use these instruments to get quick access to cash by avoiding long payment deadlines imposed by their Buyers, and improve their working capital position.


Reverse factoring: With reverse factoring, a (large) buyer set ups the financing program and enables its strategic Suppliers to gain attractive funding based on the buyer's (better) creditworthiness. This means that the Supplier is paid earlier at a discount, while the buyer typically extends the payment date of the invoice. The bank funds the program and receives a spread without much risk, since the creditworthy buyer backs the invoices.

Small and Medium Sized Defined by number of employees and either turnover or balance Enterprises: sheet total. Refers to all companies with less than 250 employees

and €50 M turnover or €43 M balance sheet total. Standard: In the context of information exchange, a standard provides a

reliable basis for entities to share information to enhance interoperability in a trusted manner.

Standardisation: In the context of information exchange, standardisation refers to the

process of developing technical standards for entity’s business processes using specific formal languages. The process of standardisation is often executed on voluntary consensus by a neutral standardisation body.

Status Based Receivables Refers to financing based on the actual invoice status information of Finance: the buyer. This status can take three levels of assurance: 1) Self-‐

declared, 2) verified, 3) guaranteed. These address the risks involved in differing degrees for Financiers.

Straight Through Processing: An initiative used by companies in the financial world to optimize the

speed at which transactions are processed. This is performed by allowing information that has been electronically entered to be transferred from one party to another in the process without manually re-‐entering the same pieces of information repeatedly over the entire sequence of events.

Supply Chain Finance: Sometimes refers to an umbrella term for a whole range of financial

instruments and sometimes denotes a specific technique or component of the SCF portfolio, i.e. reverse factoring.

Universal Business Language: Defines a royalty-‐free library of standard electronic XML business (UBL) documents such as purchase orders and invoices. UBL is already the

foundation for a number of European public procurement frameworks (e.g. ePrior and PEPPOL) and for e-‐invoicing frameworks (e.g. Turkish e-‐Fatura, Dutch Simplerinvoicing and Tradeshift);

Project plan Status Based Receivables Finance 2016

Economy & Finance