Lockbox service is used to facilitate collection and processing of payments of a company’s customers. Any duplicate files sent to the from the bank could cause change in company’s cash balances. Though each company has their own cash team to monitor the incoming payments, there could be instances where certain duplicate files might go unnoticed.Each company has a different way to handle such duplicate files, I am just sharing a small summary something that we designed.
Systems: SAP ECC 6.0
Standard Lockbox file processing through FLB2 has a duplicate check based on the Deposit date and time stamp. But if the bank sends the same file again with a different time stamp or a different deposit date file will be processed and the payment will be applied on account for the customer.
We designed a Duplicate file validation program to identify any duplicate lockbox file based on different layers of validation steps. All the required data for this
validation checks are maintained in a custom table. This table is the database of all the previous lockbox files received. The 3 layers of duplicate checks are
- 1. check for duplicate file by lock box number field, deposit date, file creation date and the file creation time
- 2. check for duplication by lock box number, deposit date, lock box total amount and lockbox record count
- 3. checks duplication by first 5 checks, lock box number, deposit date, MICR check number and the check amount
If any incoming lockbox file fails in the above checks a workflow event will be triggered to inform the treasury team about the duplicate file. Treasury team can then go through the file details and decide if it is a duplicate file or not. If the treasury team decides a file is not duplicate, the file will be processed directly through FLB2
and ignoring the duplication checks, else if they decide that the file is a duplicate, the file will be archived and will not be processed.