1. Table of contents
Table of Contents maxLevel 3 minLevel 2
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 Cash Collections and/or 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 CCT AR: Order to cash Customer Credit & Trade Accounts ReceivableOTC BO
- CCT CM: Order to cash Customer Credit & Trade Credit Management
- OP: Operating procedure
- WARP: PI system for Worldwide Accounts Receivable and Payable
- CICC: Coordination Internationale des Crédits Commerciaux
- C;M : CM : 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 | ||
|---|---|---|
| ||
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
|
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 |
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-opened, having 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 50533EUR16):
The document to be reversed is the one underlined (doc. 8701919848). 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 
and Execute
After this, the DZ is cancelled and the TI will open back in bank sub-account. See example below:
| 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 can 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 297674)
- Memo record number: The last digits that identifies the payment's line (in this case 04)
Leave the "Test" box ticked and view the payment to be sure that it is the correct one (click on the 
icon).
When you are sure of the payment, remove the tick from the "Test" box and click on the 
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 in local bank accounts. In this case, there are three situations of local cash application which can trigger a reversal:
- Finance team download the bank statements and leave the payment open on customer account or clear it with the invoice
- AR team does a manual posting in customer account following information in Bank site
- Finance team inform us that a payment was received and we clear the bank account with customer account (ex. Procter and Gamble)
In all of these 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 there is an example of a payment which was left by Finance team in a G/L account and AR team has cleared it with customer invoices (Procter and Gamble):
In the case above, the payment was allocated by Finance team in G/L account 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 to 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 have been assigned after and that the system cleared the wrong documents.
In 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 8701913831) 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 to 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 7000008681 in FB08 transaction and
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 bank 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 document in customer account |
4.5 Misdirected payment reversal
A misdirected payment is a payment received in local bank accounts for a customer assigned to SOLVAY SA (CC 0231) or Solvay Finance America (Cc 4044).
In case of a wrong clearing, we might need to reverse the document. The reversal that needs to be done depends on the necessary correction:
- The customer's account is correct, just the wrong invoice was cleared, we should make a reset only using FBRA transaction and then clear the DT document that became open on the customer's account with the correct invoice using transaction F-32.
2. The clearing was done on the wrong customer's account, the reversal to be done is different (the example below):
First of all using transaction FBRA we should reset the 7000029074 document that is clearing these items:
The document that needs to be reset can be found as follows:
Double click on the DT document, press 
button and double click on the first line:
In this window you can see the document that needs to be reset:
After the document is reset, the next step is to fully reverse the clearing on customer's account. It can be done using transaction FB08. The document to be reversed is 7000029073:
The next step is to go to transaction FB05 and make the posting between the correct customer's account and G/L account of misdirect payments:
Once this is done, we should clear the item that was reset in the first place with the new item generated on the G/L account 5080930000.
4.6 Direct debit reversal
For direct debits there is an automatic job through F110 transaction which clears the invoices which are due and create a file which is then handled by IHB team (bo.ihb@solvay.com). 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 transaction
- Credit Manager/ Business or Cash Collections team request
- During sub-accounts reconciliation detecting a debit movement
| Warning | ||
|---|---|---|
| ||
Even if we are informed by someone that customer will refuse a direct debit, we should always 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 document that needs to be reversed.
In this case we need only to reset the original DZ document using FBRA transaction:
After that payment method of invoice should be changed to "A".
With transaction FB05, we should make the following posting:
Document type: DZ
01 - Customer's account - Amount of unpaid
50 - Subaccount - Amount of unpaid
Clear DZ (original) with DZ (created) using F-32 transaction.
Then go to F-03 to clear the G/L account: TO with DZ.
| Warning | ||
|---|---|---|
| ||
|
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 | ||
|---|---|---|
| ||
|
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
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 to several reasons: customer didn't agree with the debit for some reason; a credit note was created after the amount be sent amount was 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 76300140377630000683) 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 |
For drafts (except Pagarés) we should use transaction Z3F_FA_RFBITB01_BOE in order to re-open the invoice:
When the window opens, please insert the Customer number and the Document Type:
and press 
.
Select the line related to unpaid and press 
.
| Warning |
|---|
|
4.8 Pagarés reversal
The reversal related to unpaid of pagarés depends on the fact if we receive a TO on G/L account or not:
- If we receive a TO document, we should only reset the DE document using FBRA transaction.
- If we do not receive a TO or TI document, we should reverse all generated documents 76600..., 76400... and 76100... using FBRA and FB08 transactions.
4.9
4.8RIBA 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 to several reasons: customer didn't agree with the debit for some reason; a credit note was created after the amount be being 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:
| Warning |
|---|
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 is created to Cash Collections team informing about the unpaid. Cash 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 3657863Freshdesk ticket number 698973:
If all the documents have ✔ it means that the reversal was done successfully and nothing needs to be done further by AR team.