What is being tested
Did two bank receipts represent split settlement of one remittance rather than duplicate payment? The boundary for this investigation is customer duplicate remittance split-bank receipts. Begin with the disputed transaction or population, then identify which customer remittance establishes the observed position and which two bank receipts supports the comparison. A difference in totals should not replace this question.
Evidence: customer remittance
For customer duplicate remittance split-bank receipts, customer remittance must be linked to two bank receipts. Trace the financial reference to the original obligation and final application or cash settlement. Approval is not the same as receipt of money. Preserve partial amounts, currency and reversals so one adjustment cannot be counted at several stages as separate financial benefit.
Evidence: two bank receipts
For customer duplicate remittance split-bank receipts, two bank receipts must be linked to invoice allocation. Preserve the transaction identity, measured or accepted quantity and who confirmed the event. Distinguish physical evidence from later system posting. Where condition affects acceptance, retain the authorized disposition instead of using a raw observation as an automatic commercial conclusion.
Evidence: invoice allocation
For customer duplicate remittance split-bank receipts, invoice allocation must be linked to cash ledger. Keep the issued document version and line-level quantity, currency and service period. A header total cannot establish which component is being tested. Retain later corrections as linked versions, so a replacement does not create a second liability.
Evidence: cash ledger
For customer duplicate remittance split-bank receipts, cash ledger must be linked to customer remittance. Use the opening position, dated movements and closing position together. Preserve the distinction between requested, authorized and posted changes. The reconciliation should explain how the source item moved through the account, not simply assert that the final total agrees.
Reconciliation logic
Reconcile total cash and designated invoices across receipts without applying the full remittance to each bank entry. Build the comparison at the level identified by customer remittance and retain the governing version from two bank receipts. Show intermediate classifications and excluded items separately; a net total can hide an unsupported component or a correctly offset correction.
Exception conditions
A customer may legitimately pay one remittance through several accounts. Treat the item as an unresolved exception only when the comparison described here cannot be supported by the linked customer remittance, two bank receipts, invoice allocation, cash ledger. Document the conflicting input or rule. A plausible operational explanation requires validation, but it should not be discarded to maximize an apparent financial difference.
Human review and outcome
Cash application validates payer identity and receipt amounts. Return a receipt-to-remittance bridge with duplicated allocation isolated. Keep the reviewer's reason and source references with that disposition. A supported correction should be followed to the revised record or settlement; an accepted explanation can close the question with no adjustment. Missing authority or evidence should remain an open task rather than a confirmed recovery.
Limitations and processing boundary
No message, payment demand or cash application should be triggered solely by an unresolved comparison. The native full finding producer is not complete. Receipt ownership, settlement authority and the final ledger state require human validation. In this scenario, absence of customer remittance or two bank receipts limits whether the comparison can be completed. The review method describes what people should validate, not a promise that AuditRes automatically detects or executes this specific outcome.
AuditRes pathway
Discuss customer duplicate remittance split-bank receipts in the AR/Collections workspace. Review current plans, the shared platform and secure evidence requirements; use the existing contact path to confirm the sources and validation this scope requires.
AuditRes AR/Collections: Available for onboarding. Public previews use synthetic demonstration data; production processing remains gated until applicable customer sources and authoritative processors are connected and validated.
Neighboring financial questions
- Payment processor net settlement and AR clearing
- Customer advance transferred between projects
- Customer payment sender differs from contracted debtor
- Receivables credit issued after customer settlement
AR/Collections resource hub · All guides in this evidence collection