Table of contents
| Table of Contents | ||||
|---|---|---|---|---|
|
1. Objective and Scope
The purpose of this document is to explain how to perform the internal controls for Accounts Receivable process.
The Internal Controls mentioned in this OP aims to ensure:
- Compliance with AR procedures
- Application of Process ExpertService Owner's instructions and guidelines
- Assure the mitigation of financial risk in key tasks
This operating procedure (OP) applies to all EMEA companies and customer payments for invoices factored to Solvay CICCSA. The only exception are is related to controls control "Review of receivables not assigned to CICC" and "Monthly review of system replication to ensure that receivables in WARP = receivables in local system" in Factoring company" in which we analyze all Regions (EMEA, NAFTA NAM and ASIA) in the first one and EMEA and Asia in the second oneAPAC).
2. Definitions
- SBSGBS: In the current document, "Solvay Global Business Services" will be replaced by its abbreviation "SBSGBS".
- OTC BO AR: Order to cash Back Office Accounts ReceivableOTC BO
- CM: Order to cash Back Office Credit Management
- OPDT: Operating procedure
- WARP: PI system for Worldwide Accounts Receivable and Payable
- CICC: Coordination Internationale des Crédits Commerciaux
- CM: Credit Manager
- DA: Doubtful invoice
- EMEA: Europe, Middle East and Africa
- B0: Back Office EMEA
- F0: Front Office EMEA
- PE: Process Expert
- Digital Technology
Scope
ERP
References
| Expand | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
|
Attachments
xxIn PI1:
Open FEBA transaction and choose the following criteria's:
Company code: WARP
Statement date: Statement date of the payments
Statement status: 7
Execute 
Use FBL3N transaction in PI1 system to check the unallocated payments as below:
Select only the document type "TI" (transfers IN) and then search by "unallocated" in the text field. Example below:
Afterwards, for all the open payments we should do the follow-up by verifying if the item can be cleared, sending reminder or escalating to AR Process Expert if it is blocked for resolutionAfterwards, click on each unallocated (red entries), click on the 900… document, choose 
and go to the "Attachment list" to check the case number. Then, go to Salesforce and check if the case was correctly created and sent to the correct entity (Credit Manager, cash collector or to banks).
For PF1 and WP1, the payments are posted on customer accounts by RtR Finance team (automatic postings during the bank statements upload). Therefore RtR Finance team should forward create a case ticket to OTC Credit Management in case of unallocated payment in which they are sure it is customer related. Regarding Poland, as
| Warning |
|---|
|
|
Then the report "Unallocated" should be retrieved from Salesforce report as below:
Choose "Customize" and exclude Nafta, Asia and Mercosur using "Regions & Domains" field.; additionally exclude today's date using "Date/Time Opened". On a daily basis the following file is updated:
| Warning | ||
|---|---|---|
| ||
|
Example:
3.1.1 Escalation procedure
For unallocated cases for more than three months and if no answer received or if is not enough to allocate the payment, the team member doing the controls should send an email to Accounts Receivables Process ExpertService Owner, explaining the reason why it is being escalated (mention if no answer received, doubts, proposal). In case it is interco related or any technical constraint, a reminder should be sent to the company related or to ISDT.
3.2 Weekly review of Unmatched payments
The objective of this control is to assure that all non-matched payments equal or above 50.000,00 EUR have been analyzed and escalated. Therefore a list with all those items has to be justified by the AR specialist and should be sent to BO Manager, AR Process Expert and to Cash Collector Team Leader (which should deploy to the cash collector if justified).
This weekly control must be done on Thursdays.
In PI1:
Open FBL5N transaction and chose the following variant:
Execute 
The following screen appears
PF1 and WP1
This extraction should also be done for Poland and Reverse Factoring customerscustomers not assigned to Solvay SA. Therefore, enter in FBL5N and choose the following variant for 7531 and ZFR3 in WP1 and 0005 in PF1.the companies according to this file:
| Embedded Google Drive File | ||
|---|---|---|
|
For each of the unmatched amounts, the AR Specialist team should update the file below and describe the reason of non-allocation and mention to whom it was escalated:
https://docsdrive.google.com/spreadsheetsfile/d/1jZ3SPuieMVSzZppGdeZEHPC4JpeEdvGibjJYNP-cGKk/edit#gid=1052285975
It should be done a print screen of the file and the image added to the email.
Example:
| Warning |
|---|
|
3.3 Monthly review
3.3 Monthly reviewof receivables not assigned to
CICCFactoring company
The principle of the WISE model is to have all customers/receivables from a company with convention with CICC Solvay SA/Essential FA assigned to CICCthe Factoring company (Cc 0231/6440). Therefore, the objective of this control is to show evidence that customers not assigned to CICC have a valid reason in the "Long text" field for not assigning its receivables.
This control should be done done once per month on the D+2 in the three two local systems assigning to CICCSolvay SA/Essential FA: PF1 , and WP1 and RHO.
Open Z3F_FA_MD_REPORT transaction in local systems and choose the following variants in all systems:
Execute 
The following result is shownedshowed:
We can see a line per customer and in the "Long text" field it should be inserted the reason of not assignment to WARPcompanies 0231/6440. The valid and justified main reasons are:
- Legal reasons (Ex. Italian law)
- Contract decision to local bank account
- Private persons
- Old doubtful accounts (not new cases)
- Local specificities (it should be detailed the reason)
Other reasons from these ones should be analysed and escalated to Aurelie Mazerot and Hugues Frisque.
Phisicall persons
This result should be extracted to excel as below:
Click on 
Execute 
Save the file in your desktop
Finally, add this excel file to the email with the remaining controls.
Example of the file:
3.
4 Monthly review of system replication to ensure that receivables in WARP = receivables in local systemThe objective of this control is to check if the open receivables in WARP are the same as the ones in local systems: PF1, WP1 and RHO.
Due to various reasons, a clearing done in WARP can be blocked in the affiliate interface and originate a difference in the balance. Running the transaction mentioned below, all the entries which show different balances between WARP and local system customers will appear in the transaction result. All open entries should have a clear justification and to whom it was escalated.
Open transaction Z3F_AP_AR_BALANCE in PI1 system and Execute 
Remark: This transaction can take some minutes to open
The following result appears:
Then, limit the search to customers by selecting "C" in the "Partner Type" as below:
After, the limit should be done in "CM region mgmt" by excluding "Lat" and "NAF" as below:
See below the result:
Remark: The ones without Region in "CM Region mgmt" are the ones which the mapping correspondence was removed, however they should be checked to assess if EMEA and ASIA related and under the scope.
Each line shows a discrepancy of the balance between WARP and local system customer account. The field "Delta" shows the amount of the discrepancy.
Example:
In order to have a detailed view of the discrepancy select the line and click in 
In the image we can see that the difference of 325.606,12 is related to contract 1000827683.
The control of this report is focused in the "Responsible" and "Issue" fields in which we should find the reason of the discrepancy and the entity to whom it was escalated. See examples/
Click in 
and save the file in your desktop.
The report should be extracted to excel and send it in the email.
3.5 Daily Review of Factoring Monitoring
All the assigned Receivables to CICC that do not have all the information or aren't correct can originate errors when are assigned and are displayed in Z3F_FA_OI_MONITOR transaction.
All the contracts assigned to WARP are verified automatically by the system through 24 checkings, described below:
| 101 | OPEN: Check downpayment not yet paid |
| 102 | MD: Check vendor master data payment block (Factoring) |
| 103 | DOC: Document currency not accepted |
| 104 | INTRA: Document belongs to a chained vendor |
| 105 | DOC: Posting date is higher then current date |
| 106 | PAYM: payment method of document is not accepted for this vendor |
| 107 | MD: Partner doesn't exist in the factoring company (general) |
| 108 | MD: Partner doesn't exist in the factoring company (company code) |
| 109 | MD: Partner is blocked for posting in the factoring company |
| 110 | MD: Partner is flagged for deletion in the factoring company |
| 111 | DOC: Document date is higher then current date |
| 112 | DOC: The amount is bigger than the reference amount |
113 | DDEBIT: Vendor with direct debit / Doc with other payment meth. |
| 114 | DDEBIT: Amount over the direct debit limit |
| 115 | DDEBIT: Payment method in doc.(5) different from the one in the vendor |
| 116 | MD: Bank country with embargo |
| 117 | DOC: Document type is not valid for agents |
| 118 | COMPANY: Item belong to invalid company code |
| 119 | PAYM: payment method of document is not accepted for this customer |
| 120 | DOC: Document with factoring but master data in manual exception |
| 121 | DOC: Document with factoring but no factoring in master data |
| 122 | MD: Check vendor master data payment block (Affiliate) |
| 123 | DOC: Amount is bigger than max amount (Incoming cash) |
| 124 | DOC: Amount is bigger than max amount (Outgoing cash) |
The objective of this control is to check that all open entries are already handled and escalated to the proper entity.
Run Z3F_FA_OI_MONITOR in the three local systems transaction:
Select Customers and Execute 
Remark: the US, CA, MX and BR customers should be excluded.
The status of the entries should be yellow and the payment block X, meaning that the situation was already escalated through email. If it is red, it means that is open and it wasn't analysed.
It should be done a print screen of the entries and added to the email.
| Warning | ||
|---|---|---|
| ||
The controller should check all cases pending for more than 15 days and do the follow up, checking if it can be solved and if not, to send a reminder. |
4 Records of doubtful receivables and losses based only on a supporting document communicated by CM
For bad debt customers, we should provide the request in which OTC AR team received the request to post a customer into doubtful status only if requested by Audit company. In this case, we should search in Salesforce BMC the request case and send it to the requester.
4. Reporting controls
The email should be send to the following addresses:
Service Owner Accounts |
Receivable |
| josecarlos. |
| nunes@syensqo.com |
OTC BO Manager
Accounts Receivable team leader:
Cash Collection team leader:
Accounts Receivables team mailbox
Regional Team Leaders | nuno.mendes@syensqo.com; caio.alves@syensqo.com and laddawan.wiboolworakul@syensqo.com |
Accounts Receivable Mailbox | receivables@syensqo.com |