4. Cash allocation
4.1. Print bank statements
On a daily basis, the “Coda files” which are the Bank electronic files with information about the amounts received on SOLVAY SA bank accounts are uploaded into SAP. The system does the first sorting and processes the payments in which there is some valid and correct information displayed on the bank statement. Therefore, all the payments that could not be processed by the system have to be allocated manually by OTC AR.
The first thing to do is to print the Coda files as soon as the files are available in SAP coda transaction.
Remark : Not all the files arrive at the same time. OTC AR should check it regularly and after 10:00 (PT time) if some file is missing, OTC AR should send an email to CICC BO (bo.cicc@solvay.com)
4.2. Feba transaction
After printing all bank statement files, payments have to be posted on customer accounts using FEBA transaction.
Warning
- In case we are missing details to perform the payment reconciliation, we should send an email from Freshdesk to the customer asking more details. Please check file attached to this OP with the templates with several languages. There is then a daily task performed by the team to send a reminder to the customer after 2 working days and to transfer to collections team in case of no answer received after 4 working days. The case should be closed and a dispute should be created in the unmatched with AR user and Open as status.
- If we receive a payment for an invoice that is already cleared against a credit note, we should re-open the credit note and clear the invoice with the payment. The credit note can be deducted by the customer on the next payment.
- In case we have more than one invoice with the same amount on customer account and no information is given on the bank statement, we should send an email to customer to ask payment details. It might be that a credit note is expected or that the oldest invoice has a due date issue.
To process a payment, click twice on the concerned line and afterwards on the floppy disk . This will have to be done for each red item.
At this stage, 5 possibilities can occur:
- the customer account was automatically found by the system
- the system finds a customer account which is wrong
- the system doesn’t find the customer account
- The system opens more than one customer account
- The system opens only some items
1. Customer account was automatically found by the system
2. Wrong customer account
It might happen that due to wrong information on bank statement, system will open a wrong customer account. We should always confirm if the account opened by the system is the correct one checking the information available on bank statement as customer name, address or some invoice numbers. Thus, a new search should be executed. Please refer to “Account not found” chapter, where all the possibilities of finding a customer are described.
3. Account not found
In case system cannot identify customer account due to lack of information, there are several possibilities to find it but the most common one is searching:
Sometimes a part of the invoice is missing or a number is wrong. However, we can try to focus the search on the document using * and trying different numbers in order to find the correct customer
Open items= list of invoices not yet paid in the customer account
d. Search using “Customers and Regions specificities” Database
All specificities regarding customer and Regions can be found in the Google drive or in the following link:
Warning
This database should be consulted before any dispute creation so that we can assure all specificities are taken into account.
4. The system opens more than one customer account
4.3. Posting a payment as DZ on customer account
4.4. Payment in Advance procedure
Sometimes we receive payments made by customers before the goods are shipped and invoice sent and assigned to SOLVAY SA. Therefore, we receive the payment and the invoice isn’t yet available on customer account.
There are three steps that should be considered when recording a payment in advance:
- The customer must be identified
- Check whether there is an invoice open in that account, and if not, consult the various systems to determine if an advanced payment is expected
- If the order, customer and amount are identical of what is stated on bank statement, we are authorized to process the E5 (payment in advance). If not a dispute should be created requesting confirmation to Credit Manager.
4.4.1 Check local system
This gives the invoice numbers sent to the customer “6111143015” and “6111343018” which should be found on customer account in 0231 (PI1). In case the information is not enough or in case you are not sure of the correct invoices, you can try to find them by the order number that is mentioned in the assignment field in PI1.
In case of having an order with “Payment terms”: “Payment in advance”, we should check if the customer name and the amount of the order are the same as mentioned on the bank statement. If yes, we can post the payment in advance on customer account and a dispute will be automatically created informing Credit Manager. If not, we should create a dispute and ask confirmation from Credit Manager/ Credit Analyst regarding the order number.
Then, check the last order and in case of non-conformity create a dispute.
There can be more than one proforma document mentioned in the bank statement and the numbers of the proforma documents can start with different numbers as 77… or 922… or 925... or 200... The proforma references are different depending on the company that issues the document.
If there is more than one proforma document, all of them should be checked and orders found. The sum of all orders should be equal to the total amount of the payment. If the amount is not the same always create a dispute asking for the confirmation of the orders and the amounts related to each of them. Check also if the difference is banking fees through customer masterdata.
Warning
If no useful information can be found or if there is the slightest doubt, create a dispute asking for details to the Credit Manager.
The example described is related to PF1 system, however the same procedure should be executed for WP1.
4.4.2 Process a Payment in advance
The first thing to do is to post the payment on customer account as a “DZ” document type entry (see paragraph 4.3 of this procedure).
Remark: If the original payment was made via check, the document type entry recorded is “DK”. It may also happen that the document type entry recorded is “AB”, as a reconciliation resulting from using transaction F-32. This procedure only mentions document type “DZ”, but it applies exactly the same way for document types “AB” and “DK”.
After this posting, a job will run automatically and will create an E5 document on customer account. See below an example:
A dispute will be automatically created informing Credit Manager of the posting.
When the invoice is assigned and there is no difference or the difference is on the customer master data tolerance, an automatic job runs every day and clears the E5 with the invoice (s). If there is a difference which is above the tolerance, the job will not clear and we should ask information to the responsible CSR and Credit Manager.
As soon as the invoice is cleared, the posting on customer account is as below:
Warning
To add another order for this payment, we should select and fill with the information regarding the other order.
Then, we should click on so that automatically the Net value field is updated (Sales order amounts) as below:
Finally, insert the correct amount on “PayAdvAmnt” field according to the orders
and press Save . In case there are banking fees, the amount inserted should be changed so that the total amount of the orders is the same as the payment amount. Please note that BusA field must be filled in, otherwise payment in advance will not be processed.
Choose Yes
and the following message appears:
After this posting, a job will run automatically and will create two E5 documents on customer account. See below:
Disputes will be automatically created informing Credit Manager of the posting.
When the invoices are assigned and there is no difference or the difference is on the customer master data tolerance, an automatic job runs every day and clears the E5 with the invoice (s). If there is a difference which is above the tolerance, the job will not clear and we should ask information to the related CSR/ Credit Manager.
As soon as the invoices are cleared, the posting on customer account is as below:
Warning
4.4.3 Release the Order related to payment in advance
After processing a Payment in advance, we should click on , then go to the "Status tab" in VA02 transaction and check in the "Credit Status" line if the order wasn't released yet (The status needs to be "Not approved"):
If the "Credit Status" is "Not approved"; the payment received corresponds to the payment terms of the order and the amount of the payment and the order is the same, check if the Deliver block field in the main screen is
. If it is the case please remove it choosing the option which is empty (see below):
Afterwards, we should go to VKM3 transaction, insert the order number and press Execute button :
Then select the line, click on button and press Save . The following message will appear:
4.5. Customer blocked for posting
When processing cash allocation, it might happen we find a customer that is blocked. Therefore, the system will give an error message stating that the customer account is blocked for posting. Find below how this situation should be handled.
In this situation, OTC AR should analyse if the customer account suggested by the system is the correct one (in transaction FBL5N confirm if there is an open invoice, if there is another customer account with the same/ similar name or if there are Freshdesk cases with the same issue) and in case of doubts contact Credit Manager before requesting the unblocking.
In case the blocked customer is the correct one, OTC AR will need to create a case and transfer it to Data Management team (Queue “PtP D&A EMEA”) asking to unblock the customer account. When Data Management team will transfer back the case to OTC AR queue saying that the account was unblocked, we should post the payment on the account and after we should return the case to them so that they can block the customer account again.
Warning
In order to register this payment as unallocated, we should create a case and classify it with status “Need for more information” and OTC-Subprocess “Unallocated payment”
4.6. Customer not created in Cc 0231
4.7. Payment to be transferred by IBA to other company
For all cases in which we receive a payment in SOLVAY SA which should be transferred to other Solvay company, we should follow the described procedure.
Warning
- If the payment is already allocated, you should reverse it before starting this procedure
- For payments received in SOLVAY SA Cc 0231/ SOLVAY FINANCE AMERICA Cc 4044 for companies/ documents not assigned, we should transfer the payment by IBA (as explained below). Once the IBAs run (it can take one day or more), the clearing in local system between the G/L account (5080900000 in case of PF1 or 58999920 in case of WP1) and customer's account should be done using transaction FB05.
- When processing an IBA movement with exchange, always inform treso.cicc@solvay.com in case the payment currency is not the same as the Affiliate's main currency.
The posting executed will clear the TI document in 0231:
Warnings
- Change the flag of the payment in Z_FLAG_CODA transaction
- Use transaction Z3F_FA_AFF_INFO to understand if an IBA is created and weather it is available or blocked for posting. In case the IBA doesn’t exist or it is blocked, we should search if there is a vendor account for that company and if it has a bank account. If not, please send an email to treso.cicc@solvay.com
4.8. Payment to be transferred to vendor account
We might have the need to allocate a payment received in SOLVAY SA in a vendor account. There are two possibilities in the Z3F_FA_TRANS_AR_AP transaction:
Warning
If the payment is already allocated, you should reverse before starting this procedure
4.9. Negative amount in Feba
Every time there is a return of a payment, a credit note, banking fees or a cancellation of a payment, we receive a negative amount on the CODA files.
When a negative amount arrives in FEBA statement list, the way to proceed depends on the subaccount on which the amount is posted. This chapter describes how to handle these transfers.
Warning
Before asking details to Credit Manager/ CICC BO, we should first analyse the bank statement and the Sub-account related looking for a document number or customer number that could lead us to the Country/ Region related. Then, we should also try to see if it is related to banking fees or to a payment to customer, which could be already executed by OTC AR.
4.10. Unallocated payments
For all payments that OTC AR is not able to find the correct customer account, some steps need to be followed:
- Search overdue invoices with Promise to Pay, Dunning block “F” or “B” fields by Region or country
- Search similar bank statements in the correspondent sub-account (search in the text field)
- Check transaction ZPVK in PF1 and in WP1 systems to verify if there is a blocked order with a similar amount and check customer account to confirm if it is the correct customer (payment history, bank statements...)
- Check with Collections team (Lisbon, Curitiba and Bangkok) if they are waiting for a payment with that amount through a case in Freshdesk. Other details (other phone number) can also be retrieved from internet and Collections will contact to confirm
- Request to the "SOLVAY SA" bank contact more information regarding the bank transfer namely the payer information (name, bank account, VAT...). We should send an email to the following contacts with CICC BO team (bo.cicc@solvay.com) in copy:
- BBVA: globalesbarna@bbva.com. Before sending email, a search should be done in the Bank website (chapter 2.2.1.2. Access to payment details of previous days)
- BNP: ccs@bnpparibas.com
- SOCIETE GENERALE: marie-pascale.a.beaupere@socgen.com and mathieu.martinez@socgen.com
- ING BANK N.V.: Ivan.Keranov@ingbank.com and Maya.Geonova@ingbank.com
- RHODIA CALYON: jocelyne.allix@ca-cib.com, chantal.clichy@ca-cib.com, evelyne.hurel@ca-cib.com and alain.c.robert@ca-cib.com
- RHODIA CIC: francisco.centeno@cmcic.com and flora.fortucci@cmcic.com
Warning
SOLVAY SA/ RHODIA bank account should be mentioned on the email as well as payment amount/ date and bank statement.
- If the Bank is not able to give us additional information which can help us to trace the payment, we should escalate the situation to Credit Managers mailboxes (the general mailbox used for that is Europe.CreditManagement@solvay.com)
Then, order by amount on “Net value” column and try to find a similar amount with the payment amount we have received. After go to VA03 transaction with the order number to retrieve more details and finally go to customer account and analyse payment history and previous bank statements to confirm it is the correct one.
Afterwards, whenever the payment remains unallocated and we are waiting for information we should create a note with Freshdesk case number in SAP PI1 entry document (900…), as follows:
4.11. Payments not for Solvay
In this case, we have mistakenly received a payment from other which is not a Solvay customer. Therefore the payment should be rejected. If we received that payment on a BNP bank account, it is possible to ask the transfer back asking it to bo.cicc@solvay.com. If not BNP, we should try to find a contact of the entity which made the payment so that we can request bank details and proceed with a manual reimbursement.
4.12. Solvay SA (Cc 0231) closure
This section describes the main principle which must be respected concerning the monthly closing and explains how to proceed when an answer is received for a payment when the corresponding accounting period is already closed.
Warning
For clearings on F-32 transaction we should ALWAYS use payment date (see value date of DZ document) on the “Clearing date” field. In case the period is already closed, we should use first day of the current month.
0231 closure starts on D-1 (last working day of the month). See below the impact of the closure on OtC AR postings:
Customers clearings: The last day to perform with current month date is on D+1 (until 15h Portugal time)
IBA movements: The last day to perform with current month date is on D-1
Posting a payment in a closed period:
Sometimes we have to post a payment when the period is already closed. Please see below how to proceed:





















































































































