Lockbox reconciliation proves that the payments in the bank's lockbox file add up to the lockbox deposit on the bank statement, and that every one of those payments was applied to the right customer invoice in receivables. Payments nobody can identify go to unapplied cash, short payments stay open as deductions, and the unexplained difference should be zero.
What the bank's lockbox file contains
A lockbox is a service in which customers mail checks to a post office box the bank controls. The bank opens the mail, deposits the checks and sends the business a file describing each payment. That file is the source document for the whole reconciliation, so it pays to know which fields it carries.
Banks format lockbox files differently, and many offer a standard layout or a spreadsheet export alongside a web portal with images. Most include, for each processing day:
- Deposit or processing date, which may differ from the date the credit posts.
- Batch number and batch total, because the bank works through the mail in batches.
- Item detail: check number, check amount, the payer's bank routing and account number, and the remitter name.
- Remittance data: invoice numbers, customer account numbers or amounts the bank read from the coupon or stub sent with the check.
- Images of the check, the envelope and the remittance document, in the portal or as attachments.
Remittance data is where quality varies. Payments with a clean coupon arrive with the invoice number filled in. Payments with a handwritten note, no stub, or a check from a third party arrive with little more than an amount and a name. Those items take most of the reconciler's time, so the images matter as much as the data.
Some lockbox services also accept card or electronic payments alongside checks. If yours does, confirm whether they are in the same file and the same deposit, or arrive separately.
Tying the lockbox file total to the lockbox deposit
The first test is arithmetic: the sum of items in the lockbox file, for each processing day, should equal the lockbox credit on the bank statement for that day. Foot the file by batch, foot the batches to the day, and match the day's total to the bank line. Do this before applying any cash.
Footing the file catches errors that would otherwise surface weeks later as a customer dispute. A batch total that does not agree with its items means an item was dropped or keyed twice. A daily total that does not match the bank credit can mean a check was returned before posting, a late batch was moved to the next day, or the bank split the deposit into two credits.
Timing needs a convention. Banks may process mail received late in the day as the next business day, and a lockbox credit can post a day after the file is released. Match file to credit on the bank's processing date, and at month-end list any file whose credit had not posted by the statement date.
The day-level match to the bank is one strand of the wider receipts tie-out. The post on reconciling cash receipts to bank deposits sets out how lockbox, counter deposits, card batches and electronic payments fit into one daily receipts log.
Applying lockbox payments to open receivables
Applying cash means recording each lockbox payment against the specific customer invoices it pays, so that the receivables ledger shows which invoices are closed. The total applied, plus unapplied cash, should equal the lockbox file. Good remittance data lets most of this happen automatically; the rest is done by hand from images.
Many accounting and ERP systems can import a lockbox file and match payments to invoices by invoice number, customer number and amount. Items that match exactly are applied. Items that match the customer but not the amount, or an invoice number that does not exist, drop into an exception list. Working that list every day keeps it small. Leaving it for month-end turns a short list into a research project.
The checks to run once application is complete:
- Total applied payments for the day, plus unapplied cash, equals the lockbox file total.
- No invoice has been overpaid by the application. A negative open balance on an invoice is an application error, unless the customer genuinely overpaid.
- The receivables ledger total falls by the applied amount.
That last check links the daily work to the month-end receivables tie-out. The accounts receivable reconciliation template shows how unapplied cash and credits are presented when the aging is tied to the ledger balance.
Where do unidentified lockbox payments go?
An unidentified lockbox payment is a check the business cannot place on any customer or invoice. It goes to an unapplied cash account, a liability-side holding account, not to revenue and not to a guess at the customer. It stays there, with a note of the research done, until the payer is found or the money is returned.
Research usually works through a short sequence:
- Read the check image for the payer's name and memo line, and the envelope for a return address.
- Search the customer master for the remitter name, the bank account on the check, or a parent company name.
- Look for open invoices of exactly that amount, or for combinations of invoices that sum to it.
- Ask the sales team whether a customer recently said they had paid.
- If the payer is found but owes nothing, treat the money as an overpayment or a misdirected check.
Age the unapplied cash account each month, with each item's receipt date and what has been tried. Items older than a set period should go to a reviewer. An unapplied balance that only grows usually means the research is not being done, not that the payers are untraceable.
How should short-paid invoices from the lockbox be handled?
A short payment is a check that pays less than the invoice it names. Apply the payment to that invoice and leave the unpaid remainder open, with a reason code, so the customer's balance stays correct. Do not write off the difference on the spot, and do not hold the whole check in unapplied cash.
Short payments have common causes: an early-payment discount the customer took, a pricing dispute, a damaged-goods claim, a freight deduction, or a simple mistake. The remittance often says which. Each cause has a different owner. Discounts within terms are accounting's call. Disputes and claims belong to sales or customer service, who decide whether to accept the deduction and issue a credit memo, or to collect.
Keep a deductions list with the customer, invoice, amount, reason and owner. Close each item with a credit memo or a collected payment, not with a write-off nobody approved. A customer whose deductions recur on every payment is a pricing or contract issue to raise with the account owner.
The opposite case, a check for more than the invoice, needs a credit balance and a decision about refunding or applying the excess.
Lockbox receipts that are not invoice payments
Not every check in the lockbox pays an invoice. Customer deposits on future orders, payments for gift cards or prepaid services, vendor refunds and checks meant for a related company all arrive through the same box. Each belongs in a specific account other than receivables, and the reconciliation should show where each one went.
A short list of the usual cases:
| Receipt type (example) | Where it belongs |
|---|---|
| Customer deposit on an order not yet invoiced | Customer deposits liability |
| Corporate order for gift cards | Gift card liability until redeemed |
| Vendor refund or rebate check | Accounts payable or the expense it reverses |
| Insurance or legal settlement | The account named in the agreement |
| Check payable to an affiliated company | Due to affiliate, then forward the funds |
A corporate order for gift cards is the case most often posted to sales by mistake. The guide to gift card liability reconciliation covers how those receipts are tracked until the cards are redeemed.
The worksheet below reconciles one example day of lockbox activity. All values are made up for illustration.
| Line (example) | Amount |
|---|---|
| Lockbox file total, 2 batches, 37 items | 48,216.40 |
| Applied to invoices in receivables, 31 items | 44,980.15 |
| Short payments left open on 2 invoices (applied portion included above) | 0.00 |
| Customer deposit on order, 1 item | 1,500.00 |
| Gift card order, 1 item | 750.00 |
| Unapplied cash, unidentified, 2 items | 986.25 |
| Total accounted for | 48,216.40 |
| Lockbox credit on bank statement | 48,216.40 |
| Unexplained difference | 0.00 |
Mistake: posting the lockbox deposit to receivables as one lump
Posting each lockbox deposit as a single credit to the receivables control account, and applying the detail later, is the shortcut that breaks lockbox reconciliation. The control account looks right, but the customer ledger does not: invoices that were paid still show as open, and the aging no longer agrees with the total.
The damage shows up in three places. Collectors chase customers who have paid. Customer statements show balances that are already settled. And the month-end aging does not tie to the receivables ledger, because the lump sum sits on no customer. Someone then has to rebuild the application from old lockbox files, often under deadline.
If the full detail cannot be applied on the day, post the unapplied part of the deposit to the unapplied cash account instead of the receivables control account, and clear it within a day or two as the detail is worked. That keeps the receivables total honest and leaves a visible queue.
For the bank side of the tie-out across many months, PreciseBankFlow reads each statement, checks that it foots, and lists credits that match no ledger entry, so a lockbox day that was never posted stands out.