agent split one bank deposit across three invoices that summed to the total by coincidence and closed invoices that...
Fixes an agent that split one bank deposit across three invoices summing to the total by coincidence and closed unpaid invoices: reopen the wrongly closed invoices, reapply the deposit from remittance evidence, and require reference-based matching before amount-only matching. Use for agent cash application runs. Not for a human cash applicator's one-off error.
TL;DR
An amount-only matcher will eventually find a coincidental combination: three open invoices happened to sum to one deposit, so the agent closed all three while the deposit actually settled different invoices that stay open. Undo from the evidence, not from the agent's log: retrieve the real remittance or bank detail for the deposit, reopen the three wrongly closed invoices, reverse the false applications, and apply the deposit to the invoices the payer actually specified. Then change the matcher's rules so amount combinations alone can never close an invoice: require a payer reference, invoice number in the bank detail, or customer confirmation for any split application, and route multi-invoice splits without references to human review. A coincidental exact match is still a coincidence, and the control has to treat it that way.
agent split one bank deposit across three invoices that summed to the total by coincidence and closed invoices that were still unpaidUse this when
- An agent applied a deposit across several invoices purely because the amounts summed to the deposit total.
- Customers report invoices closed that they never paid, while invoices they did pay remain open.
- The agent's match report shows no reference or remittance evidence for the application.
Not for this skill when
- The payer genuinely paid those three invoices and the remittance confirms it. The application is correct; leave it closed.
- A human made the same error once. Correct it as a normal cash application fix without redesigning agent rules.
Steps
- Freeze further agent applications for the affected customer until the deposit is reapplied correctly. Verify: no new applications compound the error while you investigate
- Obtain the authoritative allocation evidence: remittance advice, bank deposit detail or payer confirmation for the deposit. Verify: the intended invoices and amounts are established from payer evidence
- Reverse the agent's applications and reopen the three wrongly closed invoices, restoring their balances and ageing. Verify: the invoices show open again with correct amounts and dates
- Apply the deposit to the evidenced invoices and confirm the customer's statement position afterwards. Verify: the customer balance reflects the payer's actual intent
- Update the agent's matching policy: split applications require reference evidence, amount-only combinations go to review, and log the incident in the agent's exception record. Verify: the policy change is active and the next test deposit without references is routed to review
Variant phrasings
agent split deposit across invoices by coincidence closed unpaid invoices
The coincidental match symptom.
amount only matching false positive cash application agent control
The control-design phrasing.
agent cash application requires remittance reference split payment fix
The preventive rule search.
Compatibility: Agent and RPA cash application workflows over SAP, NetSuite, Oracle and QuickBooks AR, with bank feeds from lockbox, BAI2 or open banking.
Why it happens
Subset-sum matching is seductive for agents: with enough open invoices, some combination almost always sums exactly to a deposit, so an amount-only search nearly guarantees a confident, wrong answer on large ledgers. Human cash applicators instinctively distrust a match with no reference; an agent optimising for closure rate does not. The failure is therefore a policy failure encoded in the matching objective, not a random slip, and it recurs until the objective requires evidence beyond arithmetic.
Edge cases / pitfalls
- The risk grows with invoice count and round amounts; set stricter evidence rules for high-volume customers.
- Reversing applications changes customer ageing and possibly dunning history; notify the credit team of the correction.
- Audit other amount-only applications the agent made in the same run; coincidence rarely strikes exactly once.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_QLT9-7TO9XcP6u28jsISbQ