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 Expert'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 CICC. The only exception are related to controls "Review of receivables not assigned to CICC" and "Monthly review of system replication to ensure that receivables in WARP = receivables in local system" in which we analyze all Regions (EMEA, NAFTA and ASIA) in the first one and EMEA and Asia in the second one.
2. Definitions
- SBS: In the current document, "Solvay Business Services" will be replaced by its abbreviation "SBS".
- OTC BO AR: Order to cash Back Office Accounts Receivable
- OTC BO CM: Order to cash Back Office Credit Management
- OP: 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
Scope
Frequency
References
Attachments
xx
In PI1:
Open FEBA transaction and choose the following criteria's:
Company code: WARP
Statement date: Statement date of the payments
Statement status: 7
Execute 
Afterwards, 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 (automatic postings during the bank statements upload). Therefore RtR should forward a case to OTC in case of unallocated payment in which they are sure it is customer related. Regarding Poland, as the cash allocation is all manual, a case in Salesforce should be created to justify a possible unallocated.
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:
All cases should be justified with the reason and mention to whom it was escalated as below |
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 Expert, 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 IS.
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).
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 customers. Therefore, enter in FBL5N and choose the following variant for 7531 and ZFR3 in WP1 and 0005 in PF1.
For each of the unmatched amounts, the AR Specialist should update the file below and describe the reason of non-allocation and mention to whom it was escalated:
It should be done a print screen of the file and the image added to the email.
Example:
3.3 Monthly review of receivables not assigned to CICC
The principle of the WISE model is to have all customers/receivables from a company with convention with CICC assigned to CICC. 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 in the three systems assigning to CICC: PF1, 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 showned:
We can see a line per customer and in the "Long text" field it should be inserted the reason of not assignment to WARP. The valid and justified reasons are:
- Public institutions
- Legal purposes
- 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 system
The 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.
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. |
3.6 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 received the request to post a customer into doubtful status only if requested by Audit company. In this case, we should search in Salesforce the request case and send it to the requester.
4. Reporting controls
The email should be send to the following addresses:
Process Expert Accounts Receivables | Claudrik.darnet@solvay.com |
OTC BO Manager | diogo.paiva@solvay.com |
Accounts Receivable team leader: | Paula.simoes@solvay.com |
Cash Collection team leader: | ana.cabecas@solvay.com, who will deploy to Cash Collections team |
Accounts Receivables team mailbox | general.3s-ar@solvay.com |