Implementation of a lock box for a special customer use case

Goal: In this article, we describe how the Lockbox functionality is implemented and used.

Lockbox implementation for incoming check payments is necessary for business.

• Removal of manual processing that results in processing errors and delays for incoming checks and manual scanning
• Manually reversing dishonoured or voided checks takes time, requires a lot of manpower, and results in overhead costs from the bank demanding more money.
• Not being able to clearly see the liquidity’s availability
• Unable to efficiently handle more incoming checks in a timely manner
• Manual chargeback processing was used.
• Automatic chargeback recording is not possible, and chargeback accounting and reconciliation take more time than necessary.

Special client needs / use case:

The client was managing numerous manual processes in the current process, including scanning, publishing, clearing, and reversing in the event that a check was returned.

In the absence of a system mechanism, charge backs were handled manually and occasionally missed.

Picture 1: Process flow diagram

Business Method

Situation 1:

Distinct chargebacks with different reason codes included in a single Lockbox file—integration with dispute management, with multiple dispute cases established for each each reason code

In this case, a single consumer will write us a single check to cover several invoices. For a short payment, the customer uses numerous external charge back codes. The receiving (payment) AR document is filled out using internal reason codes that have been generated from the external reason/chargeback codes. For each chargeback code, the system adds a distinct line item to the AR document, and for each reason code, it pulls reference data from the lockbox file and enters it in the text field of the incoming AR payment document. For each reason code, disputes are created in the FSCM dispute management system. The incoming check number is recorded in the title of each disagreement case, and the internal reason codes in AR are transformed to reason codes established in dispute management when the conflicts are created.

Updated MICR data for the Customer master and Business Partner (Transaction code: XD02/BP).

It is crucial to update the customer master/BP with MICR data. The system will post it to the customer account based on the MICR information if the incoming lockbox file is unable to locate the open invoice match.

The system will set up a batch input session to add the MICR data to the customer master/BP if the arriving lockbox file contains a customer invoice match and has the MICR information filled in as well. BP – Refer to Image

Image 2

BP modified with cause code conversion and transaction code

In customising to handle chargebacks, the reason code conversion is utilised to connect external reason codes with internal reason codes. Observe Image 3

Image 3

Postings for customer invoices 1: Transaction code FB70

For outbound sales, the client invoice can either be started in sales & distribution or submitted in accounts receivable. We posted the invoice using FB7O in the AR module to show how the lockbox process works. – See Image 4.

Instance #4

Posting 2 of customer invoices; transaction code: FB70

Once more, a client invoice has been posted to the AR.

To demonstrate the process of multiple chargebacks with multiple client invoices, we have submitted multiple customer invoices.

Image 5

Lockbox file example with various chargeback codes.

This is the bank’s lockbox incoming file. Incoming funds for the above-mentioned invoices are contained in this file. The short payments on those invoices with numerous reason codes are also included in this file. Observe Image 6

Image 6

Lockbox file processing log: Transaction FLB2 shows a partial settlement of the outstanding invoices.

The system was able to locate open invoices, apply partial payments, and post the GL and AR documents (see Figure 7).

7th picture

Multiple chargebacks are displayed in the lockbox’s log of imported checks.

Added lockbox processing log evidence demonstrates that the system recognised the invoices based on the reference numbers recorded on the invoices. The customer changebacks with the check amount displaying the net payment after deducting the charge back amounts are the items that are indicated as papers not found. Observe Image 8

Process Checks for the Lockbox GL document is displayed in posting area 1 on FLB1, and AR document is displayed under incoming customer payments. The posting to the bank clearing account is represented by the GL document, and the posting to the customer’s account is represented by the AR document. Observe Image 9

Image 9

GL document for transaction FB03, a bank clearing.

This is a representation of a GL document that was posted in posting area 1; it debits the accounts of banks and credits the accounts of banks clearing banks. Please see Image 10

Image 10

AR document with lockbox file references and cause codes captured in the text field.

The AR document created credits the bank clearing account, clearing the open item, posting the shot payments with the appropriate reason codes recorded in the reason code field, and bringing the balance to zero. The “reason code conv” version filled out in the BP master data is used to map the external reason codes to create the internal reason codes (see Figure 11).

Image 11

For three different charge back codes, three separate disputes were created.

For the three short payments, the system generated three distinct dispute cases for dispute management. The disputes can be formed by manually completing the transaction or by setting up a batch task to do so. Refer to Image 12.

Images 12

Disputes in the transaction are shown in UDM DISPUTE. Internal disagreement codes were created from the reason codes.

The display transaction code can be used to display each of the disputes that were established above separately. The internal dispute codes are created from the AR cause codes when a disagreement is created. Refer to Image 13.

Refer to Image 13.

Three internal conflict management codes were used to establish three distinct disputes. The dispute cases that are produced will include the disputed amount as well as the coordinator and case manager, as well as the case type, case ID allocated, and priority designated as High, Medium, or Low. Refer to Image 14. (3 images)

The image 14

The customer line-item display includes all connected line items together with the references taken from the lockbox file and the dispute case IDs in the text field. The open items represent short payments, whereas the cleared items reflect the bills cleared by the incoming lockbox file. The system will clear the original invoices for the entire amount even though there were short payments, and it then creates the open items for short payments. Refer to Image 15

Instance 15

Situation 2:

One check can be used for many customers. invoices from numerous clients

To support credit management at the brand level, different customer numbers were generated to represent customers per brand.

Description of the Case: For several client bills from various customers, we will receive a single check payment in this scenario. The system will apply the incoming payments and remove the open invoices after reading the Legacy invoice numbers from the reference file captured in SAP AR invoices.

Updating master data:

Customer1 has had their MICR information updated for transaction XD02/BP.

Updated MICR data for the Customer master and Business Partner (Transaction code: XD02/BP).

It is crucial to update the customer master/BP with MICR data. The system will post it to the customer account based on the MICR information if the incoming lockbox file is unable to locate the open invoice match.

The system will set up a batch input session to update the customer master/BP with the MICR information if the arriving lockbox file contains a customer invoice match and has the MICR information filled in as well (Picture 16).

Instance 16

Updated Business Partner with reason code conversion-BP for the transaction code.

In order to process chargebacks in a customised manner, the external reason codes are mapped to the internal reason codes using the reason code conversion (see Picture 17).

Instance 17

Customer2: Transaction code: XD02/BP; Customer master updated with MICR information.

It is crucial to update the customer master/BP with MICR data. The system will post it to the customer account based on the MICR information if the incoming lockbox file is unable to locate the open invoice match.

The system will set up a batch input session to update the customer master/BP with the MICR information if the receiving lockbox file contains a customer invoice match and has the MICR information filled in as well.2 – Picture 18

Image 18

Lockbox reason code conversion in Customer2 BP updated in Transaction BP

In order to process chargebacks in a customised manner, the external reason codes are mapped to the internal reason codes using the reason code conversion (see Picture 19).

Image 19

Customer Invoice Posting with Legacy Reference Number: Transaction FB70 for Customer Number

For outbound sales, the client invoice can either be started in sales & distribution or submitted in accounts receivable. For the purpose of illustrating the lockbox procedure, we posted the invoice using FB7O in the AR module (Picture 20).

Imagine 20

Posting of a customer invoice on customer2 with the transaction reference number “FB70”

To show how a single incoming check can be used to pay open invoices from these customers, we have placed many invoices on various customers inside the same business code. Imagine 21

Imagine 21

A sample lockbox file with the two customers’ invoice amounts and reference numbers that were uploaded in the previous steps is shown in Picture 22.

Instance 22

Picture 23 saved as a.txt file

Observe Image 23.

Processing of Lockboxes: Transaction FLB2.

To manually import the lockbox file into the system for processing, this operation is carried out. This can also be scheduled as a job to have the computer read and process it from the ftp folder – Image 24

Instance 24

The processing log for the lockbox is shown here. Once the file has been processed, the system generates a log to document the creation of the GL and AR documents, the total amount handled, the check number, and the payment advice number. Instance 25

Instance 25

Documents were applied when we pushed the back button on the previous stage and references on AR invoices were used to find them. The system will display the amount applied’s specifics along with the phrase “document located” (Picture 26).

Instance 26

Processing Lockbox Data—FLB1 after

Picture 27 shows the post-processing page where the GL document prepared under “Incoming Customer Payments” and the AR document shown in posting area 1 are both listed.

Instance 27

Bank clearing account GL Document posted in Posting Area 1 with Transaction FB03

The GL document displayed here debits the bank accounts and credits the bank clearing account. It was posted in posting area 1. Instance 28

Instance 28

Customer payments that are coming in are recorded in the AR document. Multiple consumers were paid with a single check—Transaction FB03

In order to balance to zero and close the open item, the AR document created credits the bank clearing account (Picture 29).

Image 29

Report on customer line items, transaction FBL5N

Display of customer line items that includes all associated line items. the created clearing document, incoming funds, and open bills. Picture 30 shows that the check number has been entered into the text area.

Imagine 30

Business advantages from putting the aforementioned situations into practise:

• Since there is no longer a need for manual intervention to process incoming checks, user error is eliminated. The client can now manage a higher volume and multiple brands centrally thanks to the automatic processing.
• The adoption of Lockbox has reduced processing times and reconciliation concerns, enabling “Fast Close” for the Accounts Receivable process. Prior to Lockbox, incoming checks and customer chargebacks were processed manually.
• All lockbox-related transactions in EBS can be quickly found and compared to the posts from the bank statement.
• Chargebacks are immediately issued when Lockbox and dispute management are integrated, and this leads to the creation of dispute cases in dispute management.
• Accounts Receivable personnel may concentrate on other crucial responsibilities and customer service-related activities thanks to Lockbox automation.