This page is intended to explain the basic characteristics of Lockbox
A company can create accounts called 'lockbox' at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers' remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two standard banking industry transmission formats: BAI, BAI2 (Bank Administration Institute).
Advantages of Lockbox
Following are some of the advantages of using the lockbox:
Manual Handling of checks can be avoided
Checks can be processed in time.
Clearing Errors can be avoided
Difference between BAI and BAI2
BAI and BAI2 formats differ in their level of information detail. BAI does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as:
an "On account" posting (if the payment and invoice totals don't match), or An "Unprocessed" posting (if no customer account and documents could be identified from the transmission).
In these scenarios, your Accounts Receivable cash application clerks will have to perform manual application to clear payments against open items on the proper accounts.
Conversely, BAI2 splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a "Partially applied" status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your 'hit rate' percentage of payment-invoice matching from each transmission is likely to be higher when using BAI2 rather than BAI formats.
- What Bank will do?
Bank Receives the payments, create a data file of the customer remittance information and payment amounts, and deposit the checks into client bank account. On regular basis, Client company receives this data file for processing to update in their accounts.
- What lockbox data file contain?
Depending upon the choice of services with the Bank, the lock box file will contain information viz., Customer name, Customer Number, Customer MICR number ( Bank routing and Account Number), Check amount, Invoice number, Payment date, Payment amounts and other information.
- What is the Lockbox Data Flow?
Customers send their payments to a lockbox. Then bank collects the data and sends (either through EDI 820 and 823 formats) to R/3 users EDI server (standard Process). The server translates the message using as standard EDI interface into an IDOC (Intermediary documents) and sends it to the SAP Server.
- What happens in SAP server?
Once the message is received and stored in SAP table, a program is clicked (RFEBLB30 or FLBP transaction) to check the information stored in bank statement tables and create payment advices with Payment amount, invoice numbers and customer number.
Payment advice processing
- Matching of customer open items
The lockbox program uses detailed information from the payment advice to automatically search and match customer open items. The document number on the payment advice is matched against the document number in the customer open item file. Therefore, accurate payment data is necessary for automatic clearing to take place.
- Payment Advice Status
If the checks were applied or partially applied, the advice is deleted from the system after processing. If the check was unprocessed or placed on account of customer, the advice is kept on file for further processing.
- Post Processing
The post process function entails reviewing the status of the checks applied through the lock box function. User must manually clear any checks that were on-account of customer or not applied to customer account.
The Lockbox overview screen details the number of checks in each category. Depending on the status of the check, the user determines what needs to occur to apply checks.
- On account: If the bank keyed in the correct invoice number, the Lockbox Import Program posts the payment on account. In the post processing step, you access the payment advice and correct the document number and upon saving the changes, the post process function clears the open item, deletes the payment advice and sets the check status to applied.
- Partially Applied: Checks that are partially applied may require further processing. Ex: Check may have paid 5 invoices, but one was incorrectly keyed. The first 4 invoices would clear. The payment amount for the 5th invoice would be put on-account and would have to be post processed to clear.
- Unprocessed: Any payment that could not be identified either by customer MICR number (check) or the document number would remain Unprocessed. Once the payment is researched and the customer and invoice is identified, it would be applied during post processing.
1.Define House Banks
SAP IMG -> Financial Accounting -> Bank Accounting -> Bank Accounts -> Define House Banks (Transaction Code: FI12)
2.Define Lockboxes for House Banks
SAP IMG -> Financial Accounting -> Bank Accounting -> Bank accounts -> Define Lockboxes for House Banks
3.Define Control Parameters
SAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment Transactions -> Lockbox -> Define Control Parameters
4.Define Posting data
SAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment Transactions -> Lockbox -> Define Posting data
After preparing the lockbox file (for test purpose) execute the following transaction to test the lockbox configuration:
FLB2: Import Lockbox File
FLB1: Postprocessing Lockbox Data