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. 

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. 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.2. Freshdesk ticket

The update of the bank data can be also triggered by the buyer or from a SBS team colleague 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 on tool inside the Group D&A EMEA (PTP Process: Data &amp Analysis ;  PTP-Subprocess: Vendor Master Data).

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

DATA role:

• Confirm the vendors number;
• Analyse recent tickets;
• Check possible bank data duplication (SQ00 transaction);
• 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."
    • 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 the update all new accounts must be updated.

GCC role:

• Perform the outbound;
• 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 Help Desk will re-start the outbound attempts

3.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. 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.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.3. Bank account 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 account deletion

3.6. Particular situations

4. Bank data Structure

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

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

4.1.1. Bank Keys

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

4.3 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.4. 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

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.

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

10. Useful links

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