Introduction

The aim of this document is to provide you with a process overview and inform you of the standards and requirements for the CSV files to be sent to Corporate LinX (CLX) by our customers. This is typically as a scheduled over-night task.

It is of the utmost importance that the unique references are specified. In your accounting/ERP system, the standard practice may be to reset the transaction references within each instance each year. This means that a unique identifier for a transaction typically consists of 3 sections. For example, “5100001320FR012020”, the 3 sections are:

• Number (the number for the transaction), in the example above, this would be “5100001320”,
• Instance (the instance name/code), in the example above, this would be “”FR01”,
• Fiscal Year (the accounting year for the transaction), in the example above, this would be “2020”.

In this situation, please compute and send us the unique references in the daily feed, if this is something you wish for us to do for you, please let us know.

Terminology

The following terms are used all over our portal, this table helps define this terminology.

Process Overview

At a scheduled time (to be agreed upon), each day the client will create and send us CSV files, in most cases, a master data file and a transactions data file. This is uploaded to the CLX hosted Document Management System (DMS) within your portal site.

Upon specific request, we can provide a SFTP drop folder if this is preferred. However, our DMS ensures that you can put the new data directly in to your client portal and is easy to work with, so this tends to be our preference.

It is recommended that the following file naming conventions are used:

• MasterData_YYYYMMDD-hhmmss.csv:
  • MasterData – this is the file type,
  • YYMMDD – this is the date of the file’s creation,
    • YYYY – Year, e.g., 2021,
    • MM – Month, e.g., 01 for January,
    • DD – Date, e.g., 07 for the 7th.
  • hhmmss – this is the time of the file’s creation,
    • hh – Hour (24-hour format), e.g., 23 for 11pm,
    • mm – Minutes,
    • ss – Seconds.
  • For Example: MasterData_20211203-132800.csv

It is important to note here that, if you have multiple Source Systems, then the preferred naming method would be: SourceSystem_MasterData_YYYYMMDD-hhmmss.csv.

• Transactions_YYYYMMDD-hhmmss.csv
• Transactions – this is the file type,
• YYMMSDD – this is the date of the file’s creation,
  • YYYY – Year, e.g., 2021,
  • MM – Month, e.g., 01 for January,
  • DD – Date, e.g., 07 for the 7th.
• hhmmss – this is the time of the file’s creation.
  • hh – Hour (24-hour format), e.g., 23 for 11pm,
  • mm – Minutes,
  • ss – Seconds.
• For example: Transactions_YYYYMMDD-hhmmss.csv

Customers may also integrate companies and transactions from other IT systems, at which time, another pair of files as detailed above will be required to be sent to CLX for data consolidation purposes in the portal.

Something that may make it a little easier for a customer, is to create multiple files (for example, an Open Items/OI file and a Closed Items/CI file for items that are being paid). The system can handle this and will process files in the order that they are named.

CLX will monitor the agreed pickup directory and will process files placed there, once processed, they are moved to the Processed subdirectory

CLX may further be working with funders to offer Reverse Factoring solutions to our customer’s suppliers. What this means is:

• The customer will amend the payee for suppliers that sign up with funders, and this information will be included as the FunderRef element in transactions.

Process Notes

Key Assumptions

Please note: these assumptions are related to the first phase of the project, where they may change in later phases.

• Basic Assumptions:
  • The customer has one system that will be the source of master data and transactions data (e.g., a SAP instance),
  • All transactions will be sent each day at an agreed time,
  • Payments will not be changed after being sent, e.g., adding/removing invoices to a payment reference that already exists.
• Funding Assumptions:
  • Approved Invoices in the funding process will not be changed,
    • Approved state cannot be changed to blocked or rejected,
    • Credit notes cannot be attached to them,
    • Key details must not change o Will be paid according to the agreed payment calendar rules.

Although, we don’t enforce this, as our duty is to serve up to your partners what you give us, the issue is that breaking this rule it creates funding calculations.

Company Synchronisation

The customer will send a master data file which should contain all active master data. It should contain all suppliers, buyers and funders from their system that are in the related transactions files that will be sent daily.

The system will extract any new companies from this file and add them to the portal and use the references given to identify companies on each transaction.

For a company to participate in the funding process, at least one VAT reference must be provided for them. This VAT reference will be used as the primary identifier for a company in the UI when and when sending the data to funders.

A customer will also be required to send their own system identifier for the company, it is important to note that:

• A single company may have ore than one VAT reference,
• A single company may have more than one internal identifier.

Transactions

The transactions file will need to contain all changes that you wish to apply to your data in the portal. For example, if you wish to update the state of your transaction from “Approved” to “Paid” it would need to be sent with this field updated. It is recommended that all unpaid transactions plus all paid transactions where the payment info is being added today are included within the transactions file.

The system will reflect any changes or updates to the transaction unless a prior agreed business rule is broken. Following our standards when producing your transaction files will ensure that the portal is correct. It means that we can take data as is without any customisation/rules on top of that.

CSV Row Definitions

This next section covers our expected CSV data format. It will cover which elements are required and which ones are optional. If required fields are not populated, then the data will not go into our system correctly.