> ## Content Index > Fetch the complete content index at: https://www.techloy.com/llms.txt > Use this file to discover other available public pages before exploring further. # Cash Application in 2026: How to Automate Matching Payments to Invoices - URL: https://www.techloy.com/cash-application-in-2026-how-to-automate-matching-payments-to-invoices/ - Published: 2026-09-15T19:57:58.000Z - Updated: 2026-09-15T19:57:58.000Z - Description: Pull last month's receipts and record, for each one, how the remittance arrived: attached PDF, email body, customer portal, bank file, EDI, or nothing. - Author: kendall warson - Tags: / Featured, Accounts Receivable, Cash Application Finance teams shopping for accounts receivable automation almost always start with collections. They want fewer reminder emails written by hand and a system that knows which accounts to follow up with to complete payments. Collections tooling has come a long way on that with LLMs, but the part that is often left hanging in a manual workflow is cash application, deciding which invoices an incoming payment match to and posting it to the ledger. Remittance advice is the detail that says what a payment is for, and without that detail, a payment is an amount of money from a name that may or may not correspond to a customer record in your ERP. Most software in this category was designed on the assumption that this detail arrives as structured data attached to a payment, but in business-to-business trade it arrives as a PDF, in the body of an email, inside the buyer's accounts payable portal, or it does not arrive at all. ## What is remittance advice, and what forms does it arrive in? [Remittance advice](https://monk.com/blog/what-is-remittance-matching) is the message from a payer listing which invoices a payment covers and for how much, and in B2B it travels separately from the money far more often than it travels with it. ### **A PDF attached to an email** Sent by the buyer's AP team, usually from a shared mailbox, with the invoice numbers in a table their ERP generated. Some of those tables are rendered as images, so the file has to be read rather than parsed. ### **Text in the body of an email** No attachment and no fixed layout. Invoice numbers sometimes appear wrapped in the buyer's own reference format, so your INV-40118 arrives as 4500912233-40118. ### **A page inside the buyer's AP portal** Coupa, Ariba, SAP Business Network, or one of several hundred customer-specific portals. Someone logs in, finds the payment and reads the detail off the screen. ### **A file from your bank** A BAI2 statement, an EDI 820, or an addenda record travelling inside the ACH payment itself. ### **Nothing** The money lands and the payer sends no explanation. Most teams receive all five in the same month, and the mix shifts with the customer base. A book of large enterprise accounts leans towards portals and EDI. A book of mid-market accounts leans towards PDFs and email text. Count how many of those five a tool reads without a person, because that number is what changes your week. ## What Does a Bank File Carry, and What Does it Leave Out? A bank file tells you an amount, a date and a counterparty, and it carries invoice-level detail only when the payer chose a format with room for that detail. BAI2 is the cash management reporting format most corporate banks use to deliver a prior-day statement. It is assembled from numbered record types: a file header, a group header, an account identifier, transaction detail records, continuation records and trailers. A transaction detail record carries a type code saying what kind of movement occurred, an amount, a bank reference number, a customer reference number and an optional free-form text field. Whatever explanation exists usually sits in that text field, and what goes into it is decided by the originating bank and by the payer. It is often truncated and often empty. An ACH payment can carry its own remittance in an addenda record, and Nacha's developer guide sets the limits plainly. A CCD entry, the standard corporate credit, can contain a single addenda record, and the payment related information field inside that record runs to 80 characters. A CTX entry supports up to 9,999 addenda records, enough to wrap a complete EDI 820 inside the payment. Eighty characters holds roughly three invoice numbers with no amounts against them. Which of the two arrives is a decision made by your customer's treasury team. The EDI 820 is the X12 Payment Order/Remittance Advice transaction set, which X12 describes as something usable to make a payment, to send a remittance advice, or to do both. When a large buyer sends one, it carries invoice-level detail and coded adjustment reasons, and a matching engine can consume it directly. Setting one up takes trading partner work on both sides, so an 820 relationship tends to exist for your twenty largest customers and nowhere else. Summarisation is where the information disappears. If your bank delivers a summary statement instead of a detail file, or a treasury workstation rolls a lockbox deposit into a single line, or a processor nets a day of receipts into one transfer, the invoice-level detail is gone before your AR system ever sees it. No software recovers it afterwards. It has to be requested from the bank as a different report or retrieved from the payer directly. The volume moving through these rails keeps rising. Nacha reported close to 8.1 billion business-to-business ACH payments in 2025, growth of almost 10% on the previous year, and each one needed its explanation to travel by another route or squeeze into an addenda record. ## Which payment shapes break a match even when remittance is present? Four shapes account for most of the exception queue. ### **One payment covering many invoices** A customer settles 43 invoices with a single wire and sends a remittance listing 44 lines, because one of them is a credit note. The engine has to find the subset of open items summing to the payment, apply the credit in the right place, and cope when the list and the amount differ by a rounding difference or a bank charge. ### **A short pay with a deduction** An invoice for $10,000 is paid at $9,240\. The remittance may say "freight" and may say nothing at all. Until someone establishes whether that $760 is a freight charge, a damaged pallet, an unearned early payment discount or a pricing dispute, the invoice cannot be closed and the balance cannot be cleared. Coding the deduction is a separate job, with a separate owner. ### **A payment quoting a purchase order** The buyer's AP system pays against its own PO number and puts that number in the remittance, so your invoice number appears nowhere in the file. Matching depends on a cross-reference between their PO and your invoice, held in the ERP or on the original order, and kept current when one PO covers several deliveries. ### **A parent company paying for a subsidiary** The remitter name on the bank file belongs to a treasury entity in another country. The invoices sit against three subsidiary customer records with different IDs and different terms. Payer identification has to succeed before invoice matching starts, and a group hierarchy that lives in the sales team's memory rather than in the customer master will not carry it. Currency conversion, bank charges deducted in transit and invoice numbers reused across entities after a migration all land in the same place, a queue somebody works line by line at month end. ## Which platforms do cash application, and what is each built around? Cash application is rarely sold on its own. It often sits inside a broader receivables platform, and platforms differ in how they were designed and who they were built for primarily ### **HighRadius** Built around enterprise order-to-cash at high volume, with cash application and deduction management as distinct modules and a large library of ERP connections. Aimed at large finance operations standardising one process across entities. ### **Billtrust** Covers the whole path from invoice delivery through to payment, and drives matching with confidence scoring instead of fixed rules. Its buyer is the B2B seller whose remittance arrives from several sources at once. ### **Versapay** Puts a shared portal at the centre, where the buyer views invoices, pays and manages their own account, with matching and ERP posting attached. It suits mid-market and enterprise sellers whose queries surface during collection. ### **Fazeshift** Runs agents across invoicing and reconciliation in a single layer over the ERPs, CRMs and payment systems a company already has, for teams who want both directions in one place. ### **Stuut** Treats deductions and short pays as first-class objects and works across email, SMS and voice. Its buyer is the distribution or consumer goods seller where short pays are routine. ### **Monk** [Monk](https://monk.com) is the company I work for, an invoice-to-cash platform covering AP portal submission, collections and cash application on top of the ERP a company runs. Across the receivables we manage, matching runs at 80% automatic and rises to 95% once suggested matching rules are enabled. The remaining work concentrates in the payments whose remittance never arrived in a usable form, with specialty remittance software. ### What Should you Ask a Vendor in this Category? Ask about sources and exceptions before you ask about accuracy, because a high match rate on clean input tells you little about your own book. ### **Where does the remittance come from?** Which of these do you read without a person: email body, PDF attachment, spreadsheet, bank file, EDI 820, a page inside a customer portal? Ask which are live for customers today rather than scheduled. ### [**What happens when there is no remittance at all?**](https://monk.com/blog/how-to-match-a-wire-with-no-remittance-information) Ask what the system does with an unidentified receipt on day one, day five and day thirty, and who is expected to go and ask the payer. ### **Can you retrieve remittance from our customers' portals?** Ask how credentials are held, what happens when a customer enforces a password change, and whether a failed retrieval surfaces as an alert or as silence. ### **How do you identify the payer?** Ask what happens when the remitter name on the bank file has no counterpart in the customer master, and whether parent and subsidiary relationships can be modelled. ### **What does the system do with a short pay?** Ask whether it posts the invoice as partially paid and leaves a balance open, holds the receipt entirely, or codes a deduction reason and routes it to an owner. ### **How do you count an automatic match?** Definitions vary across the category, so ask for the arithmetic behind whatever rate you are quoted. ### **How quickly does the ledger reflect a receipt?** Ask whether posting to the ERP runs in real time or in a nightly batch, and what a collector sees in the hours between the money arriving and the payment being applied. ## What stays manual whatever you buy? Four things stay with your team whichever platform you pick. ### **Deciding whether a deduction is valid** Software can code a short pay as a freight claim and route it to the right desk. Approving it, disputing it or writing it off is a commercial decision that needs someone with authority over the customer relationship. ### **Persuading a customer to send remittance** When a payer sends nothing, parsing has nothing to work on. Someone has to contact their AP team and ask them to switch on remittance emails or add the invoice number to the payment reference. It is relationship work, and it lands often enough to be worth a collector's afternoon. ### **Keeping the customer master clean** Duplicate records, missing subsidiary hierarchies and invoice numbers reused after an ERP migration create ambiguity that no matching engine can resolve on its own. Hours spent here raise the automatic match rate as much as configuration does. ### **Setting unapplied cash policy** How long a receipt may sit on account, who approves clearing it, what the month-end threshold is for writing off a small residual. Those are decisions about your own books. ## Where to Start A useful diagnostic takes an afternoon. Pull last month's receipts and record, for each one, how the remittance arrived: attached PDF, email body, customer portal, bank file, EDI, or nothing. Then count how many required a person to open something before the payment could be applied. It tells you which of the questions above to press hardest, because a book that runs on portal remittance and a book that runs on EDI 820 need different things from the same category of software.