Skip to main content
Version: 8.3

EBICS

Introduction

EBICS (Electronic Banking Internet Communication Standard) is a secure communication protocol designed to facilitate file exchange between businesses and banking institutions.

This multi-bank protocol allows a business to communicate with all European banks that have adopted this standard, without depending on a provider or solution specific to a single institution.

Data exchanges are carried out in XML format, ensuring a standardized structure that is readable by different information systems.

Before using EBICS, the company must enter into a contract with the concerned bank(s). This document specifies the types of authorized transactions, the levels of access, and the rights assigned to each user. It also contains detailed information on the associated bank accounts, thus ensuring a clear and secure framework for all transactions carried out via the protocol.

The main flows of the EBICS protocol

With the EBICS protocol, all transactions are initiated by the customer. This applies both to exchanges made from the customer to the bank (e.g., sending transfer or direct debit orders) and to those made from the bank to the customer (e.g., sending account statements).

Retrieving statements: EBICS offers the option of automatically retrieving bank statements made available by the bank. This feature facilitates the tracking of transactions and the integration of banking data into the company's accounting or management systems.

Sending bank orders: The protocol also allows bank orders (transfers, direct debits, etc.) to be sent from the customer's system to the bank.

When these orders are signed electronically, the bank then executes them, ensuring the security, traceability, and compliance of the transaction.

The different EBICS protocol requests

The different EBICS requests available on AOS:

INI: allows the public key of the signature certificate to be sent to the bank. This certificate can be self-signed and allows the user to be identified by the bank.

HIA: allows the public keys of the authentication and encryption certificates to be sent to the bank. These certificates enable transactions to be carried out with the bank.

HPB: allows the public keys of the bank's certificates to be retrieved. These certificates enable exchanges with the bank.

FDL: this request allows files made available by the bank to be retrieved. This request is used in particular to receive bank statements or acknowledgments of receipt.

FUL: this request allows a file to be sent to the bank. This request is used in particular to send bank orders.

HTD: allows user information to be retrieved.

PTK: allows user logs to be retrieved.

The difference between EBICS T and TS

EBICS T (Transport): EBICS T (Transport) mode is used for the secure exchange of files between the customer and the bank. In this mode, the transmitted files are first received and stored by the bank, then placed on hold until they are validated by electronic signature.

Each transfer requires a unique transport signature, thus ensuring the integrity of the data exchanged. The use of self-signed signature certificates is permitted, which simplifies the implementation of the protocol while maintaining an appropriate level of security.

However, it is important to note that the EBICS T signature has no enforcement value. The transmitted order must be confirmed by another communication channel before it can be processed.

Thus, the files remain pending validation until a confirmation signed by an authorized person within the organization is received. Only this confirmation, transmitted via a separate channel, triggers the actual execution of the order by the bank.

EBICS TS: the EBICS TS (Transport + Signature) mode is intended for the validation and secure execution of payment and collection orders. It enables the complete automation of banking exchanges while guaranteeing a high level of security. Each transfer includes a transport signature associated with one or two TS (Transport + Signature) signatures. These signatures are created using signature certificates stored on a physical medium, such as a USB token, thus ensuring the authenticity and integrity of the orders transmitted.

In this mode, the signature has execution power: the electronically signed order is processed directly by the bank upon receipt, without the need for additional confirmation. This mechanism, also known as “joint validation,” enables fast and reliable execution of transactions.

The EBICS TS protocol thus represents the highest level of security in the EBICS standard. On the other hand, its implementation is more complex and requires the user entity to have a certificate issued by a recognized certification authority, guaranteeing the compliance and reliability of the electronic signature process.

Bank and contract configuration

Configure the application

From version 8.0 onwards: Application config → Apps management → EBICS

For earlier versions: Application config → Apps management → Bank payment → activate the EBICS option Once EBICS is activated, a new menu entry will appear in the Accounting module.

Prerequisites

Access: Accounting → Configuration → EBICS

In order to use EBICS, the following prerequisites must be met:

  • The customer must have an EBICS contract with their bank.

  • EBICS TS: signature certificates on physical media (USB token)

Configure a bank

Access: Accounting → Configuration → EBICS → EBICS Banks

In the general information section, enter the following information:

  1. Bank: the bank allows you to establish a link between the EBICS account and the bank configured in Axelor Open Suite (AOS), in order to facilitate and secure the automated exchange of banking data.

  2. Host ID: the host ID generally corresponds to the bank's BIC (Bank Identifier Code) and is provided directly by the bank. This code uniquely identifies the bank within the EBICS protocol.

  3. Protocol: this refers to the type of security protocol used for exchanges. There are two options: SSL or TLS. Today, most banks use the TLS protocol, which guarantees a higher level of security.

  4. URL: this is the address of the bank's EBICS server, to which requests are sent to carry out transactions and file exchanges.

  5. Language: this parameter is only used for communication with foreign EBICS servers to define the language of exchange.

  6. Fax, email, and certificate validity period: this information is purely indicative and is used to document the configuration of the bank link.

  7. X509 extensions: these options concern the configuration of self-signed certificates used for authentication and exchange signing. The associated settings depend on the bank's requirements and can, in most cases, be left at their default values.

Configure a contract

Access: Accounting → Configuration → EBICS → EBICS partners

When configuring an EBICS contract in Axelor Open Suite (AOS), several parameters must be defined in the partner file to ensure correct and secure communication with the bank.

  1. Partner ID: this is the bank account code assigned by the bank when the EBICS contract is signed. This code identifies the client company in EBICS exchanges.

  2. EBICS bank: this field refers to the bank previously configured in AOS, to which the EBICS contract is linked.

  3. Mode: this parameter indicates the type of EBICS protocol subscribed to with the bank, namely EBICS T (Transport) or EBICS TS (Transport + Signature), depending on the desired level of security and automation.

  4. Test mode: some banks offer a test EBICS mode, allowing orders to be simulated before they go into production. Check with the bank to see if this option is available.

  5. EBICS transport user: this field designates the EBICS user responsible for transporting orders. It must be filled in once the transport user is activated, bearing in mind that only one transport user is authorized per EBICS partner. Please note that a user can only be activated if the partner has been created. So first you have to create the partner, then the user, and then select the user on the partner.

  6. Default signatory: this corresponds to the EBICS user designated to sign bank orders by default. Several signatory users can be associated with the same contract, each with specific signature rights according to the company's internal policy.

Configure a partner - Bank statement

Access: Accounting → Configuration → EBICS → EBICS partner

Still on the Ebics partner file, configure the services.

  1. Bank statements services & EBICS codification: the services allow you to choose and filter the file formats used for bank statements. You must check that the Ebics codification corresponds to the coding provided by the bank.

  2. Get mode: the retrieval mode determines how bank statements are downloaded from the bank. Please note that there is no control, and retrieval modes can be retrieved multiple times. You can select an automatic or period-based (manual) retrieval mode.

  • Automatic: for automatic retrieval, you need to create a batch and a scheduler in AOS.

  • Period: It is also possible to perform a manual retrieval for a given period. However, caution should be exercised: if existing statements are retrieved again, duplicates will be created, as previously downloaded documents are neither overwritten nor replaced.

  • Date of last execution: the last execution date is indicative information, allowing you to know the last time the bank statements were retrieved. This facilitates the monitoring and planning of operations.

  1. Available actions:
  • Get the bank statements: the “Get bank statements” button allows you to manually start the process of retrieving statements from the bank.

  • Show the bank statements: the “Show bank statements” button gives you access to the complete list of bank statements associated with the account in question, for consultation or verification.

caution

In order to retrieve or view bank statements, you must have an EBICS transport user already defined. Before this step, it is impossible to retrieve/view bank statements.

Configure a partner - Bank orders

Access: Accounting → Configuration → EBICS → EBICS partner

Still on the EBICS partner file, configure the information concerning bank orders.

  1. Filter receiver bank details: this feature allows you to restrict the use of the EBICS protocol to a specific type of bank order and to define the bank details authorized for the execution of these orders. Example: a user may be restricted to issuing domestic cash transfer orders only between accounts belonging to the French subsidiaries of a company.

  2. Enable PSR: the Payment Status Report (PSR) offers the option of selecting the file format used for history reports, which confirm the successful execution of bank orders. By default, this option is disabled. If necessary, it is recommended that you contact your bank to define the activation terms.

  3. Bank accounts: this section allows you to select the bank account(s) associated with the EBICS contract. It is important to note that the accounts added must belong to the same bank as the one referenced in the EBICS contract.

  4. Services: Services allow you to define and filter the file formats used for bank orders. Before use, you should check that the EBICS codification corresponds to that provided by the bank to ensure compliance and proper processing of exchanges.

Transport user configuration

Creating the transport user

Access: Accounting → Configuration → EBICS → EBICS users

There can only be one transport user per partner. This user allows orders to be sent to the bank (statement retrieval orders and bank orders).

The status indicates the current stage of the user configuration process. It can have the following values:

  • Waiting for certificates to be configured

  • Waiting for the signature certificate to be sent to the bank

  • Waiting for the authentication and encryption certificates to be sent to the bank

  • Active connection

  • Certificates must be renewed

info

Administration mode: the “Administration mode” button allows you to change the status without following the user configuration order. This is why it must be used with caution.

  1. Status: the first status is “Waiting for certificates to be configured” and allows the user to be created.

  2. Name: enter the name. The name is indicative and allows the user to be recognized. Recommended nomenclature: “Bank acronym” - “User ID”, example: BNP - CORP123456789.

  3. User ID: the user ID is provided by the bank when signing an Ebics contract.

  4. EBICS partner: enter the EBICS partner (which you have previously created).

  5. Security medium: the security method is “0000” by default if it has not been provided by the bank.

  6. User type: set the user type as Transport.

  7. Generate certificates: click on the button to start generating the certificates. The certificates will be generated automatically and will be found in the Certificates table. The order id is generated. It will be incremented as exchanges with the bank take place. The Ebics transport refers to the partner mentioned above. The mode and bank correspond to those in the Ebics partner file and are filled in automatically.

info

Saving the Ebics partner results in the creation of a DN.

For transport users, all certificates are self-signed certificates, generated directly by the solution.

Sending certificates

Access: Accounting → Configuration → EBICS → EBICS Users

Still on the user's file, proceed to send the certificates.

  1. Waiting for signature certificate to be sent: once the certificates have been generated, the following status is “Waiting for signature certificate to be sent” and allows the user to be initialized with the bank via the INI request.

  2. Sending the signature certificate: click on the button to start sending the certificate. -Request log: once the certificate has been sent, the “Request log” table will be filled in. You can find the history of all requests in the request log. This log records all files exchanged with the bank.

  3. Waiting for authentication and encryption certificates to be sent to the bank: once the user has been initialized, the next status is “Waiting for authentication and encryption certificates to be sent to the bank,” which allows them to be sent to the bank via the HIA request.

  4. Sending authentication and encryption certificates: click on the button to start sending the authentication and encryption certificates.

Activation

Access: Accounting → Configuration → EBICS → EBICS users

Once the certificates have been sent, the user must be activated.

  1. Active connection: once the certificates have been sent to the bank, the user's status changes to “Active connection”. However, the user is not yet active with the bank.

  2. Print initialization letter: click on the button to activate the user. You must print the initialization letter, sign it, and send it to the bank by mail.

info

Once the user has been activated with the bank, you must execute the HPB request in order to retrieve the certificates from the bank server.

  1. Retrieve certificates from the bank server (HPB): the HPB request is a mandatory step in order to:
  • Retrieve bank statements,

  • Transmit payment orders.

It also allows you to verify that the user is recognized and active with the bank.

The HPB request can be re-launched several times without any negative impact on the functioning of the service. It can also be used for signatory users as part of their authorization process.

Other EBICS requests: the other available requests are specific and should only be executed when necessary, depending on the bank's requirements or the context of use.

info

Access: Accounting → Configuration → EBICS → EBICS Bank

After completing the steps described above, return to the bank file and refresh the page. The “Certificates” table will be filled in because the certificates have been imported.

Signatory User Configuration

Create the signatory user

Access: Accounting → Configuration → EBICS → EBICS Users

A single partner can have several signatory users.

These users are responsible for signing bank orders directly from the solution so that they are immediately taken into account by the bank.

Creating a signatory user is similar to creating a transport user. Simply:

  1. Select “Signatory” as the user type,

  2. Select associate the corresponding Axelor user. It must be the one who will log in to the solution to sign bank orders.

  3. Once the user has been created, however, the certificate generation process differs from that applied to transport users, due to the specific role of the signatory user in the bank validation process.

Loading the signature certificate

In EBICS TS mode, certificate generation allows you to automatically create encryption and authentication certificates. However, the signature certificate is not generated by the solution: it must be retrieved from the physical USB token provided by the bank.

To load the signature certificate into AOS:

  1. Certificate: select the corresponding file in the “Certificate” field.

  2. Load certificate: then click on the “Load certificate” button.

caution

It is essential to select the file beforehand before clicking on the load button, otherwise the operation will fail.

Signatory and EBICS T mode

In EBICS T mode, there are no signatory users in the strict sense, as bank orders are transmitted without an electronic signature. However, it is still possible to send unsigned orders to the bank.

In order to introduce an internal validation step before sending bank orders, the Axelor Open Suite (AOS) solution allows you to create signatory users in EBICS T mode.

This option aims to establish an additional control within the internal process, although it does not confer any banking execution power—remember that in EBICS T mode, only transport operations are performed.

To activate a signatory user in EBICS T mode:

  1. Switch to Administration mode;

  2. Change the status of the signatory user to active;

  3. This activation is carried out without sending a certificate to the bank.

Signing bank orders

When a bank order is issued via EBICS and a payment method is associated with it, it automatically goes through the “Pending signature” status. The signature procedure then differs depending on the EBICS mode used.

In EBICS T mode: in this mode, the signature is made directly from the solution. The signatory user simply has to:

  1. Click on the “Sign” button.

  2. Then enter the password associated with their EBICS user.

This action validates the order within the platform, without transmitting the electronic signature to the bank.

In EBICS TS mode:

In EBICS TS mode, the signature is based on the use of the physical token provided by the bank. The signing user must:

  1. Have the Swift 3SKey plugin installed on their browser.

  2. Be in possession of their USB token.

  3. Click on the “Sign” button.

  4. A Swift window (pop-up) will then open, allowing the user to select their token and sign the order using their secret code.

caution

Please note: the signing user configured in EBICS must correspond to the user currently logged in to the Axelor platform, otherwise the signature will fail.