AutoLockbox: 318,000 Unapplied, 41,500 Unidentified, 96,000 Duplicated
Pinewood Distribution applies customer payments through AutoLockbox in the Pinewood US business unit. The bank sends a daily BAI2 file; yesterday's transmission held 3,200 payments worth 4.6 million USD. Results: 2,911 receipts applied automatically; 240 receipts totaling 318,000 USD were created but left unapplied because the remittance advice carried no invoice number; 37 receipts totaling 41,500 USD became unidentified because the customer reference in the file matched no account, one legacy customer number having been retired last quarter; and 12 receipts totaling 96,000 USD were created twice because the bank retransmitted the file after a timeout and the operator also reran the lockbox job. The lockbox is configured with an application rule that applies each receipt to the customer's oldest open invoice. All receipts from the transmission were accounted and posted to the general ledger before anyone reviewed the results.
1. Evaluate the oldest-open-invoice application rule for this business and recommend what to change plus what to do now about the 318,000 USD of unapplied cash.
Read the worked answer
The rule is the wrong default for this customer base. Applying cash to the oldest open invoice is only safe when payments are exact and reference-free. Pinewood's customers pay multiple invoices, deduct freight claims and pay partial amounts, so the rule guarantees misapplication: cash intended for one invoice settles another, disputes get cleared that should not be, and the error only surfaces when the customer calls about a dunning letter on an invoice they paid.
Recommended configuration: set the lockbox so receipts are applied only to invoices explicitly identified in the remittance. Cash without a usable reference then lands in unapplied, where the cash application team can see it, instead of silently settling the wrong item. Where a customer segment pays consistently by amount, evaluate a matching rule with a tolerance instead of the blanket oldest-invoice rule.
Immediate action on the 318,000 USD: the receipts are posted, but application is not blocked by posting - apply them now against the correct invoices using the bank file and customer remittance detail. For the subset with no usable advice, contact the customer rather than guessing; the cost of a phone call is far below the cost of two correcting adjustments and a credit memo. Track the balance in the unapplied receipts account daily and set a target of near-zero at week end.
2. What is the correct accounting and remediation for the 37 unidentified receipts, and why does the distinction between unidentified and unapplied matter?
Read the worked answer
Accounting. An unidentified receipt has no known customer, so it cannot be credited to a customer account; it posts to the unidentified receipts account. An unapplied receipt belongs to a known customer but has not been matched to an invoice, so it posts to the unapplied receipts account and reduces that customer's balance. Both are clearing or liability balances - neither is revenue - but they sit in different accounts, which is exactly why the distinction is tested.
Remediation. Correct the customer reference for the retired legacy number, re-identify the 37 receipts so they move from unidentified to unapplied against the right accounts, then apply them to open invoices. Update the customer cross-reference at the bank or in the lockbox mapping so the retired number stops appearing in tomorrow's file.
Why it matters. Unidentified cash cannot be offset against a customer's statement, so the customer keeps receiving dunning letters while their money is on your balance sheet. That is a collections and relationship problem, not just an accounting one. Both accounts also need a defined aging and escalation: any receipt unidentified for more than a few days should be assigned to a named person, because unclaimed cash is exactly the kind of balance that external audit samples.
3. How should the 96,000 USD of duplicated receipts be corrected, and what control changes would have prevented the duplicate posting?
Read the worked answer
Correction. The duplicates are posted, so they cannot be voided and must be reversed. Reversing the 12 duplicate receipts removes 96,000 USD of cash that never arrived and reverses the applications they created, which reopens the affected invoices. Then reconcile to the bank statement to confirm the bank transmitted and debited only once, so the fix does not create a new cash difference. Flag the affected customers so the reopened invoices are not dunned during the correction window.
What failed. The control sequence was inverted: accounting ran before review. Three changes would have prevented this:
- Make the load idempotent by using the bank transmission identifier and receipt reference as a duplicate key, so a retransmitted file is rejected at import rather than creating second receipts.
- Require review of the AutoLockbox execution output - applied, unapplied, unidentified, rejected and duplicate counts - before Create Accounting is run for the day. Unaccounted receipts can be deleted; accounted and posted ones can only be reversed.
- Operational discipline on reruns: one owner per day's transmission, and a check of the transmission status before resubmitting after a timeout.
The 96,000 USD reached the GL only because review happened after posting, which is the real process defect.