Cash application automation: a worked example for AR

Cash application automation means a program reads the customer's remittance, matches each paid line to an open invoice, and hands you a file of applications, so you only look at the lines that did not match. The part worth automating first is the keying, not the decision about what to do with a short-pay.

Below is what that looks like on one remittance, using the sample from the free run: a 14-line remittance paying 12 open invoices, with one short-pay and one invoice the open-invoice file does not list.

What is automated and what stays with you?

Reading the remittance and matching its lines are automated. Reviewing and approving are yours. Remit Reader extracts the payer, payment reference, date, total and lines, then waits: nothing reaches the export until you approve the remittance.

If the extracted lines do not sum to the printed total within $1, it flags the remittance. The model reads the document, but it never matches or classifies lines; plain code does that.

How does the matching work?

It runs in passes, and the first that finds a single answer wins.

1. Exact number. Invoice numbers are normalized: uppercase, prefixes such as INV and # removed, leading zeros, spaces and punctuation stripped. In the sample, the customer printed INV-104511 and the export holds 104511, and they match.
2. Near number. A number one edit away matches only if exactly one open invoice is that close and the payer agrees. This catches a swapped digit.
3. No number. For a line without a number, a unique open invoice for that payer with the same amount.

Anything else is not guessed.

What does each line become?

Every line gets one of six outcomes: applied in full, short-pay, overpay, invoice not found, already paid or not open, or ambiguous (more than one candidate, so you pick).

Applied lines, short-pays and overpays go in the application CSV. The rest go in a second file for a person. In the sample that means the unlisted invoice appears in the exceptions file, not in the application file.

What file comes out?

One CSV per approved batch, one row per applied line. The columns, in this fixed order: customer_id, customer_name, payment_reference, payment_date, invoice_number, open_amount, amount_applied, short_pay_amount, unapplied_amount, deduction_reason, status.

It is a generic layout, not a named ERP's import format. You map it in your import tool or key from it. There is no direct connection to your accounting system.

What does it not automate?

Scanned remittances are not read automatically: with no text to read, they go to manual entry. It also does not post to the ledger, write off differences or chase the customer.

Bank and routing details are stripped from the extracted text and lines. The original file is kept as uploaded.

See also the cash application process step by step and how to treat a short-pay.

How do you test automation before you trust it?

Run it on remittances you have already applied by hand. Pick five from different customers, including one with a short-pay and one with an odd layout, and compare the output with what you posted.

Look at three numbers: lines read correctly, lines matched correctly, and lines flagged that did not need to be. A tool that flags too much saves little time; one that flags too little is dangerous. That is why every extracted line is shown beside the PDF and nothing is exported until you approve.

Start with the free run, which takes one remittance PDF and an open-invoice file, or sample files, with no card. The files are deleted after 24 hours.

What should the open-invoice file contain?

Customer ID or name, invoice number, invoice date and open amount, plus a PO number if you have one. The matcher compares each remittance line with this list, so a stale export gives wrong flags. Load a fresh one before each day's batch: a new upload replaces the previous set, and the page shows its date and row count.

A ledger over 5,000 open invoices goes in as parts, using "add to the invoices loaded now", up to 20,000 open invoices.

What does the summary tell you?

After each batch you get four numbers: payments read, dollars applied, short-pays and their total, and lines needing a person. Compare dollars applied plus the exceptions with the deposit total. If those agree, the batch is complete; if not, one remittance was missed or misread, and the flagged lines tell you where to look first.

FAQ

Do I need to change how customers send remittances?

No. It reads text PDFs, Excel and CSV remittances as they arrive.

How is my open-invoice list loaded?

You upload your ERP's open receivables export as CSV or Excel and map the columns once. The mapping is remembered.

How long are files kept?

On the free run, 24 hours. On a paid account, remittance files and extracted rows are kept 13 months, then deleted.