This month’s article is a continuation of the lockbox payment lifecycle. When we last left our lockbox payment, it had been delivered to the lockbox processing facility, removed from its envelope, and batched with other payments in preparation for high speed scanning.
Transaction Scanning
Before the batch is scanned it’s jogged once again. This time, the jogger helps to align document edges and essentially reduce the risk of paper jams and piggybacks. Once the scanning operator has jogged the batch, the documents are ready to be scanned. We scan the items through a high-speed item processing transport, connected to a desktop terminal. On the scanning application interface, the operator selects the biller whose payments are being scanned. The operator also selects the type of transactions in the batch. This is important because different transaction types have different validations specific to each type, and selecting the correct transaction type ensures the processing platform routes the transactions through the appropriate validation checks farther along in the process.
At this point, the transport begins the scanning process. During this process there are sensors throughout the document track that ensures every payment is scanned properly, and that there are no document jams or piggybacked documents (two documents pulled into the scanner simultaneously). Additionally, as each document is scanned, front and back images of that document flash on the display for the operator to review. If anything looks awry, the operator can discard individual documents or the entire batch and scan them again. Once every document is scanned, a batch header is printed. The batch is then submitted to the processing platform for validation and (if necessary) repair. The batch header is banded together with its scanned batch. The header is useful to operators in case they need to refer to an original transaction for any reason. It prominently displays the customer name, batch ID, and scanning date.
Transaction Repair
At this point, every transaction is digitized, and the digitized images are now the focal point of the process. The paper documents, having served their purpose, are cataloged and securely stored. A series of validation checks are systematically applied to each digitized transaction to ensure it is adequately identified, quantified and processed. Each scanned image is categorized as either a check, a statement, or as correspondence. This helps to encapsulate the range of images into disparate transactions. Scanlines are read and transactions are balanced to ensure accurate processing.
Quite frequently, this series of validations on the batch, on the scanned documents, and on each transaction require the assistance of a human operator. Operators might assist with the identification of the MICR line on a check, might data enter fields on a scanline because that scanline couldn’t be read, or perhaps the biller wants data points that can’t be automatically captured converted to machine-encoded text, like check maker name or any verbiage on a check memo line.
At Lighthouse, we even have an exception module. If we aren’t able to reconcile a transaction even after manual review (say for a check without any identifying biller account information), we can trigger an email notification to the lockbox biller. The biller can then log in to our web interface and add the required customer/account/invoice information, effectively repairing the transaction.
Regardless of the repair reason, each transaction is checked in a variety of ways to ensure accuracy and completeness. Whenever the system can’t fully perform the underlying check on its own, it enlists a human for assistance. Only after all fully and semi-automated checks are performed can we transmit to the bank and to the lockbox customer.
Lockbox Settlement
Once all transactions for a biller have been extracted from their envelopes, scanned, and repaired, we begin the settlement process. A variety of things occur when settlement is triggered for a particular lockbox. All the underlying checks are embedded into an Image Cash Letter, which will be transmitted to the bank or core provider for deposit into the biller’s operating account. Also, now that every transaction has been authenticated, quantified and documented, they can be accurately measured and reported. Any reports the biller might have signed up for are generated and transmitted to the biller. If applicable, the AR extract, having the benefit of fully documented transactions thanks to the transaction repair step, is also generated and transmitted as wellr.
These three outputs: monetary (the image cash letter), reconciliation (the AR extract) and informative (reporting) should always foot. Their alignment serve as yet another check and balance to the lockbox biller. From an operational cash flow standpoint, the biller knows how much money has been deposited into their account. From a balance sheet standpoint, the biller knows the specific accounts receivable that realized a payment. At this point, the life cycle concludes, only to start up again on the very next processing day.
There you have it! This end to end process might not strike you as particularly exciting, but hopefully you have some newfound appreciation for the various steps involved with how Lighthouse Payment Services processes our customers’ mail-based payments. If you’re a bank that doesn’t offer lockbox to your cash management customers, or a lockbox customer yourself, please give us a call and we’d love to present how Lighthouse Payment Services can add value for you.