1.Objective and Scope

The fields and general procedures on bank accounts are described.

This operating procedure (OP) applies to all vendors in PRS (PF1-050) for systems PF1, WP1 and PI1.

2.Procedure 

The suppliers (exception: chartering/maritime freighting, see below) must be required to send their bank data for payment to SBS BO directly, instead of sending them to the purchasing and accounting network.

The electronic mailbox PaymentSecurityProcess@solvay.com  must be used by vendors to send their SBI with the document attached.

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

3.General Principles

A bank account is required for paying a Supplier through a bank transfer, usually from a bank account held by CICC. It is not used in case of payment through direct debit (see specific documentation on this payment process).

This document contains:

A description of the fields associated to bank data – bank data are initially recorded in PRS (PF1-050), then automatically transferred into the operational systems PF1, or WP1, or both, and into PI1 (CICC).

The detailed description of the procedures on handling a new bank account – including erasing a bank account.

The structure of the bank data, according to the country of the bank.

4.Bank Data Description

4.1 Bank details

Bank identification

The bank identification is composed of 2 fields:

Bank country = ISO code of the country the bank is located in.

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

Bank account

The bank account is composed of 2 fields:

Bank account

Bank account of the business partner, with a specific format for each country. For some countries, the system checks the bank account format.

Bank account with more than 18 characters

The field bank account has only 18 characters but in some countries the bank account is longer. For these countries, the bank account must be entered as described below:

Australia; China; Greece; Romania; Slovakia; Tunisia; Venezuela

The first 18 characters in the "bank account" field, others characters in the "Reference detail" field.

Czech Republic

The structure of the bank account is:

xxxxx-xxxxx-xx-xx- xxxxxxx

The first 18 characters (including hyphens) must be entered in the "bank account" field, other characters in the "Reference detail" field

Slovenia

The structure of the bank account is:

xxxxx-xxx-xxx-xxxx x-xxxxxx/x

The first 18 characters (including hyphens) must be entered in the "bank account" field, other characters in the "Reference detail"

Macedonia

The structure of the bank account is:

xxxxx-xxx-xx- xxxxxxx-xxxx

The first 13 characters (including hyphens) must be entered in the "bank account" field, other characters in the "Reference detail"

Poland

The structure of the bank account is:

-xxxxxxxx-xxxx-xxxxx-xxx-xxxx 

The first 15 characters (including hyphens) must be entered in the “bank account” field, other characters in the “Reference detail”

Russia; Uzbekistan

Bank accounts have 20 characters, the first 2 are the control key. The 2 first characters must be entered in the "Control key" field and the others in the "bank account" field.

For example, if the bank account starts with 70*, the control key usually is 40

If the 40 is in the beginning of the bank account number, then these digits should be moved to the control key (ctrl Key – 40 ; bk acc – 7028…)

Used in some countries such as Brazil, France, Italy, Portugal, Russia and Spain, this field contains a key for checking the combination of bank number and bank account number.

Other data

Account holder

Name that the payment program can use if the name of the account holder is different from the one of the customer or supplier.

This field can be used for entering the name of the account holder or the permitted payee when needed.

Reference details

Free comment, without specific codification.

For vendors used as "permitted payee" (such as factoring companies), it can be used for entering the name of the final beneficiary of the payment.

For countries where bank account has more than 18 characters, this field is reserved to the last characters of the bank account.

Collection authorization

Indicator which allows the bank to collect payment from the partner if there is an agreement with him that he pays by bank collection.

Mainly used in Italy, this field must only be updated if it is requested by the user or if it corresponds to a local use.

Bank type

The bank type 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.

4.2 IBAN

Definition

IBAN = International Bank Account Number

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 ECBS web site: http://www.ecbs.org/iban.htm.

Use

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.

The IBAN is also mandatory for Italy, where it must be used for payments by the bank (e.g. RIBA).

The list of countries concerned can be consulted on the ECBS website.

Even if the IBAN is generally not used for domestic payments, the IBAN is strictly mandatory for all the countries where it exists.

Update

The IBAN code may be entered by clicking the arrow in the IBAN column.

Depending on the countries, the IBAN code may be entered before or after having entered the bank co-ordinates and for some countries it may be determined automatically by the system.

In the workflows, the requester can enter the bank details and generate the IBAN, or enter the IBAN and generate the Bank details.

Irrespective of the process he uses, he must check the validity between the bank details and the bank account, according to the information provided by the partner.

IBAN validity

The validity of the IBAN code can be checked on the ECBS website: http://www.ecbs.org/iban-checker.htm.

Other websites provide tools for the IBAN validation.

A simple tool can be easily downloaded from the Swiss Interbank website: http://www.sic.ch/fr/tkicch_financialinstitutions_ibanipi.htm.

5.Rules and Organization

Environment

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

For partners maintained at client level in PRS, bank details must never be maintained in the operational systems (PF1_020 , PI1_020, WP1_400).

Maintenance by Workflows

Bank details must always be maintained by the vendors workflows.

The maintenance of bank details follows the general process of the workflows.

Vendor Workflow

The bank data can be entered directly by supplier at creation level, when the requester sends the VWF to be filled in by supplier;

Or after the supplier creation, when requested by D&A Team via Vendor Workflow (The only exception is when supplier doesn't have email address, in these cases a ticket should be created to PTP HD)

The D&A Team checks that data respects the Data & Analysis rules

The D&A Team checks that the bank account is not already assigned to another vendor.

Direct maintenance

Performed by Data & Analysis team based on specific requests, where the WF tool cannot be applied

The mass maintenance can be also done by D&A.

5.1.Rules for Vendors Bank Details

Requester

The requester can be anyone who is authorized to create requests in the vendors workflow.

He is responsible for the content of the request.

His role consists in:

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

SBS HELPDESK

On request of D&A Team, PTP HD directly contacts the vendors in order to ask them the bank account which must be used for the payment.

If other bank accounts have been previously recorded in the vendors bank details, PTP HD 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), PTP HD asks the vendor which ones have to be recorded in our database.

Data & Analysis team

Role:

• • checking if the data management rules described in  Bank details and  IBAN are correctly applied.
  • check veracity of the request, if is being sent from a reliable e-mail ID
  • checking the data entered according to the evidence (attached).

If the bank details are not correct, he must return the request.

When a request is in status "Error", Data & Analysis must process it manually. If the technical error concerns the bank account, Data & Analysis can do the necessary changes

Permitted payee

Bank details must always be entered in the bank data of the vendor who is the real bank account holder.

The account holder may be the vendor himself or another subsidiary of the company, or a factoring company.

If the account holder is the vendor himself, the bank details must be entered in the vendors data.

If the account holder is another subsidiary or a factoring company, bank details must not be entered in the vendor data. They must be entered in the bank data of the account holder, who must be registered as a vendor, and assigned as "permitted payee" of the initial vendor.

Bank details changes

When SBS receives the information from a vendor that he has changed its bank account(s), the PTP HD must:

• check (possibly with the vendor if it is not clearly explained on the document) if the existing bank account(s) must be kept or removed
• Transfer the  request to  D&A Team

Even, if the vendors have been advised to send this kind of information to SBS, it may occur that they send it to the buyer. In that case, the buyer deals with this request himself (including in holding the evidence), or can decide to forward it to PTP HD.

SBS or the buyer must check (possibly with the vendor if it is not clearly explained on the document) if the existing bank account(s) must be kept or removed.

5.2 Current Overall Process

1 - If supplier sends an e-mail spontaneously

If e-mail termination (@xxxxxx.xx) matches the one in the Master Data, no outbound should be made and Bank Data should be updated

If not, outbound process must be followed

2 - If Invoice Posted and no Bank Data in system or Invoice.

Outbound procedure to be made

3- If Invoice Posted and Bank Data in System Different from Document or is Empty in SAP (New outbound procedure)

Help Desk starts the outbound (until script is created) and performs 2 attempts.

If outbound is not successful, Bank Data is updated when SAP is empty and Data & Analysis will inform Panel Manager and Buyers (or equivalent) that Bank Data was inserted without validation from supplier. For the case when we have Bank Data in system, no update will be made.

The feedback from Data & Analysis to the Panel Manager or Buyer(s) that the bank data was inserted without confirmation is done by the D&A Internal Requester, following the script text below:

"Dear colleague,

Vendor XXXXXXX 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. "

Whenever the bank account mentioned in the invoice differs from vendor's master data, as long as this new bank account is for a different currency than master data, we can apply New Outbound Procedure.

Example:
In system we have Bnkt GBP1, If we receive an invoice with EUR bank account, we should be able to introduce a new bank account for EUR without confirmation from supplier.

So in system we would have GBP1 and EUR1.

Note: This does not apply to Factoring cases.

How to detect 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

If new contacts are obtained to reach the supplier, then Help Desk will re-start the outbound attempts

5.3 Check Duplicate Bank Accounts

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).

This task will be processed for each request containing a new bank account.

The search of existing bank account is done by the data controller through a query in PRS (ZZ-VEN-BNK-ACC for vendors and ZZ-BA-SEARCH-C for customers). 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.

If it can't be accepted (when it's not possible to determine relation between vendors): 

1. 1. If case belongs to AP (when an invoice exists) – AP advised in WF communication area and/or Freshdesk ticket that the issue should be clarified with locals and/or may ask HD to confirm if there is any kind of relation between vendors so that they share same bank details.
   2. If it is under D&A responsibility (no other case with an invoice / case started by D&A team) – clarification from locals should be requested or HD might be asked to contact supplier to confirm relation between "different" vendors.

5.4 Update of Bank account

SBS SC AP is able to ask to update vendor's bank accounts in 2 cases:

• • When they notice that the bank account indicated on the invoice doesn't match the bank account in masterdata.
  • When there are no bank accounts, neither on the invoice, nor in master data.

Case 1:

SBS SC AP notices that the bank account indicated on the invoice doesn't match the bank account in the master data (or that no bank account exists in the masterdata)

SBS HD asks the vendor to provide them with a valid SBI (or equivalent) or performs a Soft-Outbound. They must send the reference of the invoice.

If another bank account exists in the masterdata, they must ask if it can be removed.

When they receive the SBI or confirm bank details through the Soft-Outbound (and bank details match the ones on invoice), D&A proceed with the update of Bank Account, checking if the outbound was done according to procedures (checking if contacts used are valid and if nothing is missing in the outbound) and crosscheck data (document/master data/outbound).

Case 2:

SBS SC AP notices that there are no bank accounts, neither on the invoice nor in the masterdata.

In this case, HD might send a copy of the invoice and asks vendor to provide them with a valid SBI (or equivalent).

When they receive the SBI (or equivalent), D&A proceed with the update of Bank Account, checking if the outbound was done according to procedures (checking if contacts used are valid and if nothing is missing in the outbound) and crosscheck data (document/master data/outbound).

6.Erasing a bank account

Erasing an existing bank account may be done under conditions:

1. the supplier mentions explicitly that the existing bank account is obsolete and replaced by a new one,
2. 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.

7.Bank DATA Webform

Key points when asking for bank data modification with NEW webform:

• SBS Data PtP submits request for bank detail confirmation via Vendor webform (T-Code Z1S_VWF_REQUEST)
  
  

• SBS Data PtP monitoring in place and contact with the supplier is done by SPOC (Freshdesk)
• Once webform is fulfilled, SBS D&A PtP verified it and approves

Note: With NEW webform SBS will be able to also make a selective confirmation of bank details in case of Fraud suspicion (buy following daily bank modification report).

8. Particular Situations

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

These cases relate to:

8.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.

8.2 Chartering / Shipping (maritime freighting)

Suppliers for chartering are asked to send their SBI to SBS D&A BO (PaymentSecurityProcess@solvay.com). Requesters for new suppliers always indicate the bank account, mention “chartering” in the Communication area, and attach a copy of the SBI if available. In case the request is mentioned as urgent in the communication area, SBS D&A BO accepts the request without asking a proof of bank identity, but proceeds with a soft outbound by contacting CPN - Logistics - Air and Ocean, requiring confirmation by e-mail to be sent to PaymentSecurityProcess@solvay.com. The confirmation has to be given by a different person than the initial requesterand has to mention the workflow request in the "subject" field. (see list of contact persons)

8.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.

8.4 Correction of a bank account at the request of 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.

8.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 analyzes the request to confirm that no duplication exists and all required information was inserted.No outbound procedure will be followed.

8.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) 

9.Appendix

9.1 Structure of IBANs

9.2 Links

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

9.3 Documents