Design the exception queue behind payment reconciliation

Separate matching from explanation

Stable identifiers, amounts, dates and validated fee rules should handle ordinary matches. Language models may help interpret descriptions but should not decide financial truth. Preserve each source record and make the reason for a proposed match visible.

Give exceptions a clear owner

An exception needs a category, age, evidence and a person responsible for resolution. Distinguish timing differences from missing refunds, fee discrepancies and duplicated events. A single total of unmatched value hides these different operating problems.

Design for corrections

Approving a match, posting an adjustment and issuing a refund are different actions. Define permissions and keep a history of changes. A reviewer should be able to see what happened without reconstructing it from email.

Measure the work the team actually does

Track unresolved value and count, incorrect matches, exception age and reviewer effort. Compare results across ordinary and unusual periods. Faster matching is valuable only when the resulting ledger remains explainable.

Common questions