Cash Application
The process of matching incoming customer payments to the specific open invoices they settle, so the AR ledger stays accurate.
Cash application is the matching of incoming payments, checks, ACH, wires, card settlements, to the specific open invoices they pay. It sounds clerical and is actually foundational: every downstream AR activity depends on it. Collectors dunning invoices the customer already paid burn credibility; credit holds triggered by misapplied cash block good customers; aging reports built on unapplied payments misstate the portfolio.
The difficulty is that payment and remittance detail travel separately and imperfectly. A customer pays 47 invoices with one ACH, takes three deductions, and emails the remittance advice to a shared inbox, or sends it via their AP portal, or does not send it at all. Checks arrive at a bank lockbox whose data file lists MICR and amount but not invoice numbers. The cash application team reconstructs intent: matching amounts, parsing remittances, contacting customers, and coding the residuals (short pays, overpays, unidentified payments) for follow-up.
Performance is measured by auto-match or hit rate (the share of payments applied without human touch), same-day application rate, and the size and age of unapplied cash. Modern practice pushes the hit rate up with remittance capture from every channel (email parsing, portal retrieval, EDI 820), tolerant matching rules for small discrepancies, and machine-learning matching for the rest. Whatever cannot be applied should land in a workflow with an owner and a clock, because unapplied cash is both a customer-experience defect and, for auditors, a control concern.
See SCREDIT on your own workflows.
A 30-minute walkthrough with the team that built it — using scenarios from your credit operation, not canned demo data.