How to apply cash receipts to open invoices with an AI agent

The agent reads each receipt from the bank feed, gathers the remittance and the customer's open invoices, and proposes a match. Exact matches, and multi-invoice matches the remittance confirms, are applied at depth 3, because an application can be reversed. Short payments, overpayments and receipts it cannot identify go to a named person. The bank line, never the remittance, decides the amount.

What is cash application, and who owns it?

Cash application is the step in order-to-cash where money received is matched to the invoices it pays. Until it happens, invoices look overdue, customers get chased for bills they have paid, and credit limits are wrong. It is high-volume, rule-heavy work, which is why it suits an agent, and it is easy to get subtly wrong, which is why the bounds matter.

The accounts receivable lead owns the process and the matching rules. The financial controller sets the tolerance for small differences and approves anything that touches the general ledger beyond the application itself. Credit control owns the customer conversation about short payments. The wider position on finance agents is in AI agents for finance: books you can audit.

How does the agent apply cash, step by step?

1. Agent, depth 1: reads the receipt from the bank feed. Amount, date, payer name, reference. The bank feed is sealed: it is the authority on how much arrived.
2. Agent, depth 1: gathers the remittance. From the payment reference, an emailed remittance advice, or a customer portal. A remittance is the customer's statement of what they meant to pay; an emailed one is external.
3. Agent, depth 1: identifies the customer. By payer name, bank details on file and reference. If two customers are plausible, it stops here and holds.
4. Agent, depth 2: proposes a match. One invoice, several invoices, or a part of one. It records which evidence supports each pairing.
5. Platform: tests the match against the rules. Exact amount and reference; multi-invoice match confirmed by the remittance; difference within tolerance. The verdict names the rule that applied.
6. Agent, depth 3: applies allowed matches in the receivables sub-ledger and posts any within-tolerance difference to the variance account the controller named.
7. Agent, depth 2: prepares held receipts. Short payments, overpayments, unidentified payers, and differences above tolerance, each with a proposed treatment.
8. Person, accounts receivable lead: decides held receipts. Applies, splits, raises a query with the customer, or moves the receipt to unapplied cash.

Why does the bank line, not the remittance, decide?

Because the remittance can be wrong and the bank line cannot. Customers send advices listing invoices they meant to pay, then pay a different total. Bank charges are deducted in transit. Foreign currency payments arrive at a different amount. If the agent trusted the remittance, it would mark invoices as paid in full when they were not.

The agent therefore applies only what arrived. Where the remittance lists more than the bank line covers, the match is a short payment and is held. The same principle explains why an emailed remittance can never redirect money or change bank details: it is external information and can only support a match, not create one. The question of how far an agent should go here is discussed in can an AI agent apply cash receipts to invoices.

Which controls matter, and what evidence do they leave?

Applications are reversible; the agent does nothing that is not. It does not issue credit notes, write off balances above tolerance, or refund overpayments. Evidence: refused verdicts on any attempt.

Tolerance set by the controller. A small fixed amount, per receipt. Evidence: the tolerance version cited on each variance posting.

One customer per receipt unless confirmed. Evidence: the customer identification and the evidence used.

Daily tie-out. Total applied plus total unapplied equals total received. Evidence: the daily reconciliation, signed off by the accounts receivable lead.

What should you measure?

• Receipts applied at depth 3, as a share of all receipts.
• Misapplications reversed later. The quality number that earns or loses depth.
• Time from receipt to application.
• Unapplied cash balance, and how old it is. What happens to receipts that end up there is covered in clearing unapplied cash.
• Customers chased for invoices they had already paid. Should fall sharply.

Faster application also improves the cash figures treasury relies on each morning; how an agent might help there is discussed in can an AI agent manage daily cash positioning.

Where does it usually go wrong?

Oldest-first matching. When a payment has no reference, the agent applies it to the oldest invoices. That is a common rule, but it can hide a dispute on an old invoice the customer deliberately left unpaid. Hold unreferenced receipts that would clear a disputed invoice.

Customer groups confuse identification. A parent company pays for its subsidiaries from one account. The agent needs the group structure from the customer master, or it will apply to the wrong entity.

Short payments are treated as tolerance. A deduction of a few hundred is not a rounding difference. Keep the tolerance small and treat anything above it as a deduction with a reason to find.

Foreign currency gains and losses go to the variance account. They belong elsewhere and should be posted by your currency process, not by the cash application rule.

Where Pryme fits

In Pryme, the bank feed arrives as sealed and an emailed remittance as external, so the amount applied always comes from the bank line. Applying a matched receipt can be certified at depth 3; credit notes, write-offs above tolerance and refunds are separate capabilities that stay held.