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 AR: Order to cash Accounts Receivable
  • OTC CM: Order to cash Credit Management
  • OP: Operating procedure
  • SOLVAY SA: 
  • CICC: Coordination Internationale des Crédits Commerciaux
  • CM : Credit Management team
  • DZ: customer payment
  • TI: Transfer IN
  • TO: Transfer OUT
  • DT: Misdirected payment
  • GBU: Global business unit

Scope

ERP

References

Attachments

5. Add the link to attachments (to be stored in AODocs or GDrive) or external links 

4. Reversals 

  • 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 (I think this part is not needed anymore).

  • 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, 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.

 

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…).

pen 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: 

 

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 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 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 there is an example of a payment which was left by RtR in a G/L account and OtC has cleared it with customer invoices (Procter and Gamble):

In the case above the payment was allocated by RtR 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

 

 

4.3 Partial payment reversal

 

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 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).

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 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.

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

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 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 Cash Collections team request
  • During sub-accounts reconciliation detecting a debit

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.

 

 

 

 

 

 

  • After the clearings are done a dispute to Cash Collections with reason "Unpaid" and status "Call by collector" should be created in order to ask customer the reason of the unpaid and to agree about the new payment
  •  The changes in mandate and consequently in the direct debit will be made automaticaly by the system.

 

 

 

 

 

 

 

 

 

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 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 7630000683) 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 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 .

 

  • After the transaction runs, payment method of the invoice will be automatically changed to "A" and a dispute to Cash Collections with reason "Unpaid" and status "Call by collector" will be created in order to ask customer the reason of the unpaid and to agree about the new payment
  •  The changes in mandate and consequently in the direct debit will be made automaticaly by the system.

 

 

 

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 both generated documents 76600..., 76400.... and 76100....

4.9 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 to several reasons: customer didn't agree with the debit for some reason; a credit note was created after the amount 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.

 

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 Freshdesk case 698973:

If all the documents have ✔ it means that the reversal was done successfully and nothing needs to be done further by OTC AR team.