1. Table of contents
2. Objective and Scope
The purpose of this document is to describe the steps to be followed in order to reverse reconciliations on customer's account and on sub-accounts. The reversals can have several reasons namely wrong automatic matching, human error or under Credit Manager request.
This operating procedure (OP) applies to all postings in customers and on bank accounts
3. Definitions
- SBS: In the current document, "Solvay Business Services" will be replaced by its abbreviation "SBS".
- OTC BO AR: Order to cash Accounts Receivable
- OTC BO CM: Order to cash Credit Management
- OP: Operating procedure
- WARP: PI system for Worldwide Accounts Receivable and Payable
- CICC: Coordination Internationale des Crédits Commerciaux
- C;M : Credit Management team
- DZ: customer payment
- TI: Transfer IN
- TO: Transfer OUT
- DT: Misdirected payment
- GBU: Global business unit
Scope
ERP
References
Attachments
4. Reversals
Warning
- For transition reversals (bank statement received in WARP for an invoice in 5763/5976), please consult the google file below:
https://docs.google.com/spreadsheets/d/17YSvipbEzSPgcNqnOvqtVnIcp5e9621okHWer1chMMQ/edit
This should be very rare and only related old open items in old Factoring Companies – 5763 and 5976
- Before doing a reversal, we should be sure that we really need to reverse especially if the clearing was done in a previous period which is already closed. Reversing a clearing will imply that all documents will be re-open, which will have an impact in the GBU (invoices will appear as overdue as there isn't anymore a payment linked)
Reversals guidelines
There are two cancellation transactions that can be used to reverse the documents:
- FBRA – When the reversal already includes cleared items. Ex: A payment (DZ) was already cleared with invoices
- FB08 – When the reversal does not include cleared items. Ex: An open payment (DZ) on customer's account
There are two reversal reasons depending on the period:
- 01 code – If the document is reversed during the current opened period
- 02 code – If the document is from a period that is already closed
See below an example:
If the reason code is 01, leave the "Posting Date" field blank. If the reason code is 02, fill in the "Posting Date" field with today's date.
Warning
In case a payment was left on customer account and cleared afterwards with invoices using F-32, we should start to reverse this document before the others
4.1 Bank transfer reversal
Due to a wrong clearing between a payment and one or more invoices, sometimes it is needed to cancel a matching on customer's account. In order to reverse the erroneous reconciliation, it is necessary to know the following items:
- Document type «700…. » which corresponds to the reconciliation item on customer's account;
- Document type «870.... » which corresponds to the reconciliation item of the bank sub-accounts ( if the sub-account was reconciled already)
Example:
The first step is to reverse bank sub-account clearing (clearing between the TI with DZ) as below:
Enter on the DZ document and click above the posting in the sub-account (in this case 50514EUR16):
The document to be reversed is the one underline (doc. 8700487443). Use FBRA transaction as below:
After this reversal, reverse DZ document (700…).
Open FBRA in case the DZ is already cleared with invoices and FB08 if not.
In this case FBRA transaction:
Choose "Resetting and revers" and Execute
After this, the DZ is cancelled and the TI will open back in bank sub-account. See example below:
WARP sub-account
In WARP, a new DZ with opposite sign is created and clears the original one
0231 sub-account
In 0231 when we reverse a payment, an U3 is created with an opposite sign.
Warning
In order to post again the payment in FEBA transaction, we should change the flag using transaction Z_FLAG_CODA. After this, the payment will be available again to be posted. See below the steps to be executed:
Open Z_FLAG_CODA transaction. The following screen appears:
It should be filled with the assignment number of the payment that should be consulted on the DZ document, as below:
Double-click on the Sub-account item and the following screen will appear:
- Short Key: The first digits of the assignment field (in this case 260546)
- Memo record number: The last two digits that identifies the payment's line (in this case 05)
Leave the "Test" box ticked and view the payment to be sure that it is the correct one (click on the clock icon).
When you are sure of the payment, remove the tick from the "Test" box and click on the clock icon.
The payment is now available again on FEBA transaction to be posted.
4.1.1 Local Payment reversal
There might be the need to reverse payments which were received locally. In this case there are three situations of local cash application which can trigger a reversal:
- RtR download the bank statements and leave the payment open on customer account or clear it with the invoice
- OtC do a manual posting in customer account following information in Bank site (ex. Poland)
- RtR inform us a payment was received and we clear the bank account with customer account (ex. Procter and Gamble)
In all of the cases, we have to analyze which document needs to be reversed and check if doing the reversal the payment will re-open in customer account (in case it was posted without clearing before) or if it will be cancelled and we have to do the manual posting again (in case we have posted a manual DZ between bank account and customer account). Below an example of a payment which was left by RtR in a g/l account and OtC has clear it with customer invoices (Procter and Gamble):
In the case above the payment was allocated by RtR in g/l 5080900000 and we have cleared the G1 (payment) with the invoices in customer account. In case we need to reverse, we should reverse document 2510139708 in FB08 transaction which will re-open the invoices and the DZ and then it is possible again to clear other invoices. If the wrong clearing is due a clearing in a wrong customer, then we should use FBRA transaction in order to cancel the DZ. In this case, the payment should be allocated again in the correct customer account using FB05 transaction.
4.2 Reconciliation invoice/credit note reversal
There is an automatic job which runs in all customer accounts to clear invoices vs credit notes which have the same assignment. The principle is that all these clearings are correct as based on the assignment number which corresponds to the order number.
Therefore these reversals should be limited to the cases in which the customer pays an invoice which was already cleared by a credit note or if there are more than one invoice or credit note with the same assignment which might be have assigned after and that the system cleared the wrong documents.
In the case customer pays an invoice already cleared by a credit note and in order to have the same open accounting items as the customer for audit purposes, we should reverse this clearing and leave the credit note open to be deducted by the customer in other payment.
This section explains the steps that should be followed to reverse the reconciliation.
Use transaction FBL5N to display the customer's account's items, with variable "All items" so that we can identify the clearing document of the posting.
Example:
In order to reverse this type of reconciliation, clearing document (in this case 8700508244) should be reversed. To do this, we should use always FBRA transaction as below:
Follow the steps below:
- Insert the document number
- Press Save
- Confirm if the items to be reversed are correct
- Click on
The reconciliation has been cancelled
The partial payment should only be done in case we are sure that customer paid a specific invoice partially. However there might be the need to reverse a partial payment due a human error or according Credit Manager request. In this case, we should identify the DZ document and use FB08 transaction. Example:
Insert DZ document 7000238295 in FB08 transaction
Save 
4.4 Cheque reversal
The cases for reversing a clearing with a cheque should be rare as normally we receive the information regarding the invoices in advance. However, in case of insufficient funds on customer account, we should proceed the same way as for bank transfer reversal explained in the chapter related (the only difference is the document type of the cheque is DK).
Warning
After the reversal, FF68 or FB05 transactions should be executed again in order to create a new DK in customer account
4.5 Misdirected payment reversal
A misdirected payment is a payment received in local bank accounts for a customer assigned to CICC or Solvay Finance America.
In case of a wrong clearing, we might need to reverse the document. Therefore, we should use FB08 transaction in the DT document to do the resetting (DZ and invoices will re-open and then it is possible to allocate again the DZ with other invoices) or FBRA transaction if the misdirected payment was allocated in a wrong customer account. In this case, the misdirected payment will be available again in Z3F_FA_MISDIRECT transaction if it wasn't cleared yet in misdirected payment g/l. If it was already cleared, we will need to reverse that clearing before and only then the payment will be again available in the transaction.
Warning
Due to a technical constraint, all the unmatched misdirected payments which were left on customer account due missing details should be reversed and allocated again in case of a clearing which includes leaving a residual. If the unmatched payment will then be cleared totally (no residuals), there is no need to reverse and allocate it again.
4.6 Direct debit reversal
There are direct debits for Switzerland, Germany and UK. In these countries, there is an automatic job through F110 transaction which clears the invoices which are due and create a file which is then handled by CICC BO. In case of unpaid, we would need to make the necessary corrections in customer account.
An unpaid in direct debit can be detected through three ways:
- Negative amount in Feba
- Credit Manager/Business or Collections team request
- During sub-accounts reconciliation detecting a debit
Warning
Even if we are informed by someone that customer will refuse a direct debit, we should always to check if we have received the debit in our bank account (TO)
Example of an unpaid:
Checking the flag we can see the invoice details:
In order to reverse the clearing, go to customer account in FBL5N transaction and identify the following documents:
- Bank sub-accounts clearing
- DZ document
Use transaction FBRA for both documents in order to re-open the invoice.
Warning
- The payment method of the invoice should be changed to "A" and a dispute to Collections with reason "Unpaid" and status "Call by collector" should be created in order to ask customer the reason of the unpaid and agree in a new payment
- Depending on customer/CM feedback, we should assess if it is need to cancel temporarily or permanently the mandate. If the instructions is to cancel the mandate and consequently the direct debit, use transaction FSEPA_M1 in PI1 system, click twice under the mandate, choose
and change the mandate status.
See example below:
Open FSEPA_M1 transaction and insert customer number:
Click on 
and click twice under the mandate
Click on 
and change the mandate status from Active to Canceled
4.7 Draft reversal
We have manual and automatic drafts for France (Traites) and Spain (Pagarés and Recibos). For this payment method, we might receive an unpaid from a customer due several reasons: customer didn't agree with the debit for some reason; a credit note was created after the amount be sent to the Bank; liquidity issues, etc.
In case we receive an unpaid, we should detect it through a debit in our sub-account (TO). In this case, we should check the flag related with the TO. See below an example:
Checking the flag, we can see all the details:
It is possible to retrieve in the bank statement the original document (in this case 7630014037) for which we should check in FB03 transaction:
Click on the second line to retrieve all the details:
Following the confirmation that the amount of the TO is the same of the draft amount, we can proceed with the reversal. For this, use FB08 transaction in 7630014037 document as below:
Save 
This will re-open the original DY and the invoice. We should then create a "false" DY document to clear the original one in the customer account using FB05 transaction as below:
Click on "Choose open items" and select the original DY. Then credit sub-accounts related (in this case 50533EUR17") in order to clear the unpaid (TO).
Click on Enter
Insert the amount of the draft, the value date (today's date) and in the text insert" UNPAID Inoice x".
Click on 
Afterwards , the TO should be cleared with the DY in the sub-account
Warning
The payment method of the invoice should be changed to "A" and a dispute to Collections with reason "Unpaid" and status "Call by collector" should be created in order to ask customer the reason of the unpaid and agree in a new payment
4.8 RIBA reversal
RIBA is a payment method used only for Italian customer for which there is an automatic job running through F110 transaction which will clear in customers' accounts all the invoices due within 1 month. The invoices will be cleared with a DY and a positive DY will stay open until due date of the invoice is reached.
For this payment method, we might receive an unpaid from a customer due several reasons: customer didn't agree with the debit for some reason; a credit note was created after the amount be sent to the
Bank; liquidity issues, etc.
The process of the unpaid in RIBA is fully automatic. There is one file received in SAP with the information of the RIBAs unpaid.
Example case 3657865:
Afterwards, there is an automatic SAP job which will "read" this file and the documents unpaid and will do the resetting of RIBA document in customer account and re-open the invoice and the original DY. Then, it will clear automatically the original DY with another DY which will also credit the sub-account (50513EUR17) to be cleared with the unpaid (TO). The payment method of the invoice is also automatically changed from "B" (RIBA) to "A" (Bank transfer) and a dispute created to Collections team informing about the unpaid. Collections team will then contact the customer to understand the reason of the unpaid and agree in a new payment.
Finally, there is an email, which is sent automatically to AR mailbox, every time there are RIBA unpaids for which we should check if all the items have ✔, meaning that all steps went correctly.
See example below case 3657863:
If all the documents have ✔ it means that the reversal was done successfully and nothing to be done further by AR team.