Scope


 

ERP


References


Attachments


5. Add the link to attachments (to be stored in AODocs or GDrive) or external links 

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"  :


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.


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.

  • 3.3 Bank key


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

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

These cases relate to:

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

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

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

  • 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 analyzes 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


 

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



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