1. Objective and Scope

The object of this procedure is to describe the flow of the bank data update and how is formed the european bank accounts. 

2. General Principles

The suppliers must be required to send their bank data for payment to SBS directly. There are 2 ways to request the update of this data: through the tool Vendor Workflow Request (SAP system) or by sending an email to the Paymentsecurityprocess@solvay.com (Freshdesk ticket).

Buyers (and accountants) are authorised to send bank statements to this electronic mailbox, when they receive documents from suppliers directly. SBS will then perform a check directly to the supplier. 

Bank details are exclusively maintained in the system where the client level of vendors is maintained. 

2.1 IBAN structure

IBAN stands for International Bank Account Number.

It is the Bank codification used for the international payments in Occidental Europe. This codification is using the ISO code of the country, a 2 characters check digit and the bank account identification. Detailed structure and validation rules are depending on each country. All information concerning IBAN (rules, structure, list of countries concerned, etc) can be found on the IBAN site https://www.iban.com .

IBAN code is mandatory for all the trans-border payments in the Western Europe countries which have set up a management of IBAN codes. These payments are generally made via Solvay CICC. 

An IBAN consists of a two-digit country code, two check digits, and a Basic Bank Account Number (BBAN) that contains specific bank and account details. Each country is responsible for its own BBAN structure and SWIFT is the official registrar of the national IBAN formats. Example:

2.2 Countries without IBAN 

For the countries without IBAN the bank data is inserted column by column and the operator needs to confirm the Bank Key. The Bank Key is different depending on the country.

When not provided by the requester it can be used the SWIFT code.

3. Bank data maintenance

The requester of a bank account update can be anyone from the SOLVAY company or the supplier. He is responsible for the content of the request.

His role consist in:

• Collecting information and evidence;
• If available, the physical evidence must be attached.

3.1 Request tools

3.1.1 Vendor Workflow Request

The update of the bank data can be triggered by the buyer (vendor creation request) or by the DATA team (vendor modification request) using the Vendor Workflow Request. 

Concerning the DATA team the Vendor option on the Vendor Workflow is - Request bank data:

Then, the operator will insert the suppliers contacts (Name, Email and Language):

The vendor is called to fill a file with the bank details. For that he will receive 2 emails:   

• Mail with the link to webform:

• Mail with the pin code:

The outbound performed by the Contact Center team is not needed in this situations.

3.1.2 Freshdesk ticket

The update of the bank data can be also triggered by the buyer, from a SBS team colleague or from the Data team using the Freshdesk ticketing tool.

The ticket can be generated by sending an email (to ptp-data.analysis@support.solvay.com or payment.securityprocess@support.solvay.com) or creating directly on the tool.

The vendors team will see this tickets inside the Group D&A EMEA (PTP Process: Data &amp Analysis ;  PTP-Subprocess: Vendor Master Data).

3.1.2.1 Request from Buyer/Accountant/ Other SBS team with suppliers document.

DATA role:

• Check veracity of the request, if is being sent from a reliable e-mail ID;
• Confirm the vendors number;
• Analyse recent tickets;
• Check possible bank data duplication (SQ00 transaction);
• Inform the buyer/accountant of the next step (outbound);
• Provide contacts (master data plus official web page).
  
  

The ticket is sent to the GCC (when requested by a local the outbound is performed internally -  Portuguese, Spanish, Italian, English, French) requesting the outbound and a SBI if needed (standard bank info). 

The GCC will call and if no success an email will be sent. If necessary there will be a second outbound (2 days) and a third (last contact - 3 days).

• If the outbound was not achieved at the end of the attempts DATA team will proceed according to whether or not there is a bank account on the invoice. 
  • If not, then the team will check if a bank account already exists in the vendors master data. 
    • If not, new contacts must be requested to the locals explaining that we have done all the attempts without success and that we will wait until supplier complaints about the payment. 
    • If yes, these bank accounts must be used.
  • If yes, then the team will check if a bank account already exists in the vendors master data.
    • If not, the update will be performed and an email will be sent to the requester and to the Panel manager informing of the incident: "Vendor XXX has been updated with bank details, as in attached document, without succeeding in an outbound validation with the supplier."
      NOTE 1: If the invoice mention more then one bank account it should be inserted the first bank account.
      NOTE 2: If the invoice mention one bank account per currency it should be inserted the bank account correspondent to the currency of the invoice.
      
      
    • If yes, the team will check if they are for the same currency.
      • If yes, it will be used the one already in the system;
      • If not, the update will be performed and an email will be sent to the requester and to the Panel manager informing of the incident: "Vendor XXX has been updated with bank details, as in attached document, without succeeding in an outbound validation with the supplier. The Outbound process consist in our Contact Center contacts by e-mail or Phone number (from Vendor Master Data) and request supplier to provide Bank details, when not available or to confirm the Bank Data when available. Contact Center will perform 2 attempts to obtain the information from the supplier, during a total of 6 working days. "
• If the outbound was achieved then the update can be performed. A new check of bank data duplication should be performed.

In the situation where the confirmed account is different from that given to us in the initial order, a new outbound should be performed to clarify the situation.

When confirmed more than one bank account all new accounts must be updated.

GCC role:

• Perform the outbound (to ask them the bank account which must be used for the payment);
• Request a SBI when needed;
• Provide the Name and Phone number of the person contacted;
• Not send the supplier an invoice with bank account;
• Advise to correct the invoice image when the bank account confirmed doesn’t match with the one on the invoice;
• If new contacts are obtained to reach the supplier, then GCC will re-start the outbound attempts;
• If other bank accounts have been previously recorded in the vendors bank details, GCC asks which ones are still actives or can be removed.
• If there are more than one bank account on the invoice (or on another document), GCC asks the vendor which ones have to be recorded in our database;
• Assign the ticket to the DATA team.

The Data team will reply to the Buyer/Accountant informing of the update. If requested by other SBS team it must be passed to the correspondent Agent and Group.

3.1.2.2 Request from Buyer/Accountant/ Other SBS team without suppliers document.

A request of bank data update without document oblige the request of a SBI (document with the suppliers Name, Address, VAT ID and bank account). When received the data controller will need to check if the Name, address and VAT match with information on the vendors master data.

The roles of the Data and GCC teams remain the same.

3.1.2.3 Request from Supplier

When received bank details directly from the supplier the update can be performed. In this situations the extension of the email received must match with the extension of the email available in the vendors master data. If not an outbound is required.

In cases where it is not possible to identify the vendor number the Data controller must send the ticket to the GCC team requesting to start an outbound to confirm the suppliers Purchase Order number.

The roles of the Data and GCC teams remain the same.

3.2 Bank data update

The bank data can be inserted in two different ways: column by column or using the button "IBAN Maintained"  :

• Column by column - used when the country do not have an IBAN:

It is inserted the Country of the Bank account, then the Bank key (for RU is called BIK), The Account holder (when applicable), then the bank account, the Account Key (when applicable) and the Bank Type.

• Inserting the IBAN (by clicking in the field ) :

• Bank type: it is mandatory, even if the vendors has only one bank.

The standard codification is 4 characters alphanumeric with specific meaning: EUR1, CNY2, USD3…

For multi-currency, the correct format should be: ZZZ1

When a new bank account is added or updated it should be assigned the Partner Bank Type number 1 of the list, i.e. becomes EUR1 or GBP1 or USD1 etct, changing also the available ones with the subsequent numbers (EUR1 will be EUR2 ...)

This change will allow the payment of invoice to the most accurate Bank Account and a more efficient Automation on the Automatic Postings.

3.3 Bank key

Bank key = unique identification code of a bank in a country. 

This field is maintained in the PF1_050. Key users located in countries using a non latin alphabet are authorised to enter the local version of name and address in their own alphabet (Cyrillic, Chinese, Kanji, Thaï, …). 

The transactions used to maintain the bank data file:

During the introduction of a bank account in the vendors master data the system can request the Bank Key. If not yet created you should leave the vendor and go to the FI01 to create it. 

It is mandatory to have the following fields when processing this task:

• Bank Name (Name of the bank);
• Bank Number (Bank identification used in the IBAN codification);

• SWIFT Code (International bank code that identifies particular banks worldwide. It’s also known as a Bank Identifier Code (BIC) - consists of 8 or 11 characters).

Format: Bank code (4) + Country Code (2) + Location code (2) + Branch code (optional + 3). 

The code must be confirmed using the website - https://www2.swift.com/bsl/index.faces .

Concerning duplicates the same SWIFT code can be assigned to more than one bank. But the system only accepts one Bank Key.

3.4 Bank data duplication

To check if a bank account required in a request is not already assigned to another third party (to avoid that a fraudulent bank account would be assigned to several third parties) it is used the transaction SQ00.

The search of existing bank account is done by the data controller through a query in PRS (ZZ-VEN-BNK-ACC).

If the query displays one or several third parties with the required bank account, the Data controller determines if the situation can be accepted or not, according to data management rules.

It can be accepted when confirmed that the companies belong to the same group.

It can't be accepted when it's not possible to determine relation between vendors. In this situation the a Freshdesk ticket needs to be created to the GCC team asked to contact supplier to confirm relation between "different" vendors for a local to request more info.

3.5. Bank data deletion

Erasing an existing bank account may be done under conditions:

• • the supplier mentions explicitly that the existing bank account is obsolete and replaced by a new one,
  • the supplier explicitly ensures that, in case of pending payments, an agreement exists with its bank for an automatic refund from the old bank account to the new one,

Erasing a bank account is usually performed by SBS upon receiving this information from the supplier, including after confirmation of a new bank account.

When vendors are marked for deletion, their bank details must be removed.

3.6 Particular situations

The general procedure may be adapted to particular situations where the update of the bank account must be done quickly.

3.6.1 Intragroup

For PF1 and WP1 companies it has to be checked if the bank account exists in:

• CICC online -  http://solia.solvay.com/irj/portal/Services/CICCOnline_AboutUs or/and  CICC bank accounts
• Nafta online -  http://solia.solvay.com/irj/portal/Services/NaftaOnline_AboutUs

If the required bank details match the data in the online data, then the bank details can be inserted without further confirmation. 

If not, it must be approved by the Company Accounting Manager concerned. Therefore, there is no soft outbound in such cases.

3.6.2 Chartering / Shipping (maritime freighting)

A Chartering/Shipping vendor can be identified through the field Search Term 2 on vendors master data:

Suppliers for chartering/shipping are asked to send their SBI to SBS D&A BO (PaymentSecurityProcess@solvay.com).

Requesters for new suppliers mentioning “chartering” or "shipping" in the Communication area with a copy of the SBI compel the creation of a Freshdesk ticket. An email will then be sent to a Logistic Manager requesting the approval for this update:

The confirmation has to be given by a different person than the initial requester and has to mention the workflow request in the "subject" field.

• • Logistic Managers:

3.6.3 Re-introduction of a previously bank account that was removed after data cleaning

Bank accounts removed as a consequence of a data cleaning can be re-introduced when there is a request stating that this account is still valid.

3.6.4 Correction of a bank account

• Our banks - BNP-Paribas-Fortis; JP Morgan

Letters or e-mails received from our banks, informing us about a change of a bank account belonging to a vendor, are sufficient proofs to proceed with the change without additional controls. The proof should be attached in the request.

NOTE: An e-mail can be attached once it is saved as RTF or MSG document.

• Treasury Suppliers (Procedure - EMEA - Treasury Suppliers & Bank Data Outbound Process )
  

If Data Operations - Vendors Team receives a request to change the bank data for this vendors, the normal outbound procedure should be skipped and the Treasury Team should be contacted:

• • 102119422 HSBC FRANCE, 702720262 - CREDIT AGRICOLE CIB BELGIUM BRANCH, 2818370 - HSBC BANK PLC, 2812853 - BNP PARIBAS LONDON BRANCH, 2824121 - CITIBANK N.A.

3.6.5 Rusvinyl exception

D&A accepts that all requested created by RU users for All suppliers are approved without any intervention, if related with Rusvinyl.

All Bank Data for RU will be maintained by RU users and approved by where the team just analyses the request to confirm that no duplication exists and all required information was inserted. No outbound procedure will be followed.

3.6.6  Bankruptcy

Reference "BANKRUPTCY" should be added in "Ref. Details" field when updating a bank account which belongs to a Lawyer, Fiscal Entity, etc which is authorized to receive the payments on behalf of a specific supplier with financial issues (the same is applied in case of use of a permitted payee) Complete procedure under Accounts Payable's responsibility: (http://teamsites.solvay.com/sites/FinOpProc/APProcess/AP-SOP_10.02.03_Bankruptcy,Garnishment_or_Black_list.doc) 

4. Useful websites

• Bank data

http://www.ecbs.org/iban.htm

http://www.iban-rechner.de/

http://fxtop.com/en/countries-currencies.php

https://www2.swift.com/bsl/index.faces

• LPRs and Panel Managers:

LPR: https://docs.google.com/spreadsheets/d/17c-tc2yRUjd9zZ5-owO-PBrBqeWpBzJI7pU7hWnD0Rw/edit?ts=560e4e5e#gid=924946904 

Panel Managers: https://sites.google.com/a/solvay.com/sbs-procure-to-pay-portal/table-of-approval---master-data-vendor-management

5. Attachments