Cash Application
Matching every payment to the invoice it pays
Cash application is the step between money landing in the bank and the invoice showing as paid. In LedgerUp, Ari reads every incoming payment and its remittance, matches it to the open invoices it settles, posts the application to your accounting system, and brings only the true exceptions to a person: a short pay with no reason, a lump sum that does not add up, a payment from a customer with nothing open.
What cash application is
Cash application is the accounts receivable process of matching customer payments (ACH, wire, check, card, portal payouts) to the specific open invoices they pay, recording the application in the ledger, and resolving whatever does not match. It is different from payment reconciliation, which confirms that the payments recorded in the ledger agree with the bank statement or processor payout. Cash application answers the question which invoice did this payment pay; reconciliation answers the question does the ledger agree with the bank. A team can be fully reconciled and still carry a large unapplied cash balance, because the money is in the ledger but not on the invoices.
How cash application runs
What happens to a payment from the moment it arrives. Every matching rule, tolerance, and routing threshold is configurable.
Payment arrives
Ari sees the payment where it lands: a bank feed or lockbox file for ACH, wire, and check; a Stripe or card processor payout; a payment made inside an AP portal such as Coupa, Ariba, Bill.com, or Tipalti. Each payment carries whatever identifiers the rail provides: payer name, amount, date, memo, and any reference numbers.
Remittance is captured and parsed
Remittance advice arrives separately from the money more often than not: an email, a PDF attachment, a portal payment record, a bank addenda line, or nothing at all. Ari collects remittance from every source, reads it, and extracts invoice numbers, amounts, deduction codes, and notes, so the match is made on what the customer said they were paying, not only on the amount.
Payments are matched to invoices
Matching runs in order of confidence: exact invoice number and amount; customer plus exact amount; customer plus a combination of open invoices that sums to the payment; partial payment against the oldest or the referenced invoice; and finally a suggested match with a confidence score for a person to confirm. Lump sums are split across the invoices they cover.
Exceptions are classified, not parked
A short pay, a deduction, an overpayment, a duplicate payment, a payment with no invoice reference, or a payment from a customer with nothing open is tagged with its reason and routed to the right owner in Slack with the invoice, contract, and customer history attached. Nothing sits in an unapplied bucket without an owner and a next step.
The application is posted to the ERP
Applied payments post to QuickBooks, NetSuite, Xero, or Sage Intacct against the specific invoices, with credit memos or write-offs created only where your rules allow and approvals have been given. The invoice status, the customer balance, and the aging report update at the same time.
Deposits and payouts are reconciled
Bank deposits are tied to the payments that make them up. Stripe payouts are broken into the underlying charges, fees, refunds, and disputes so the net deposit reconciles to gross invoice payments with fees recorded separately. What is in the bank and what is in the ledger agree, and the difference is explained line by line.
Unapplied cash goes to zero at close
Anything still unapplied is on an aged list with a reason and an owner. Ari follows up with the customer for missing remittance, proposes matches for a person to confirm, and reports what remains so the close does not start with a mystery balance.
What you configure
The controls that decide how much of cash application runs without a person touching it.
Matching rules and order
Which match types are allowed to auto-apply (exact reference, amount, combination, partial) and which require confirmation. Most teams auto-apply exact and combination matches and confirm partials.
Tolerances
The amount or percentage under which a short pay is auto-written off as a bank fee or rounding difference rather than routed as a deduction. Typical B2B tolerances are a few dollars or a fraction of a percent.
Remittance sources
The inboxes, portals, lockbox files, and bank feeds Ari reads remittance from, and how a remittance is linked to a payment when they arrive on different days.
Deduction and short-pay reason codes
The reasons a customer pays less than invoiced (pricing dispute, damaged goods, early-payment discount taken, tax withheld, portal fee) and where each one routes: finance, the account owner, or a credit memo workflow.
Stripe and processor payout handling
How payouts are split into charges, fees, refunds, and disputes, which GL accounts fees post to, and how a refund or chargeback reverses an earlier application.
Unidentified payment handling
What happens to a payment with no matching customer: hold in a suspense account, attempt payer-name matching, or ask the customer, with an aging clock so it does not sit indefinitely.
Multi-entity and multi-currency
Which entity and bank account each payment belongs to, and how foreign-currency payments are matched to invoices with the exchange difference recorded rather than left as an unexplained short pay.
Approval controls
Who can approve a write-off, a credit memo, or a manual reapplication, and the audit trail that records who approved what, when, and why.
docs.ledgerup.ai
Open the cash application setup guide
Bank feed and processor connections, matching rule configuration, tolerance settings, and ERP posting mappings are documented step by step on the docs site.
Go to docs.ledgerup.aiRelated reading
What Ari matches automatically and how exceptions reach your team.
Tying ledger payments to bank deposits and processor payouts.
Payouts, fees, refunds, and disputes reconciled to invoices and the bank.
Reason codes, credit memos, and follow-up on the remaining balance.
Subsidiary-aware customer payments and remittance parsing into NetSuite.
Stripe payout reconciliation and payment posting through the QuickBooks API.
Cash Application FAQ
What is cash application in accounts receivable?
Cash application is the process of matching customer payments to the open invoices they pay and recording that match in the accounting system so the invoice shows as paid and the customer balance is correct. It covers reading remittance advice, matching by invoice number or amount, splitting lump sums across invoices, handling short pays and deductions, and posting the result to the ledger. In LedgerUp, Ari does this for every payment across bank, Stripe, and portal rails and routes the exceptions to a person in Slack.
What is the difference between cash application and payment reconciliation?
Cash application matches a payment to the invoice it pays. Payment reconciliation confirms that the payments recorded in the ledger agree with the bank statement or the processor payout. They fail differently: a team can be fully reconciled to the bank while carrying a large unapplied cash balance, because the money is recorded but not applied to invoices. LedgerUp does both, and links them, so a reconciled deposit is made up of applied payments rather than a single lump.
What is remittance advice and why does it matter?
Remittance advice is the note a customer sends with a payment listing which invoices it covers, the amounts, and any deductions taken. It matters because the payment itself usually carries only an amount and a payer name. Without the remittance, a $47,300 ACH from a customer with nine open invoices is a puzzle; with it, the application is mechanical. Remittance arrives by email, PDF, portal record, or bank addenda, and often on a different day from the money, which is why capturing and linking it is the first step in automated cash application.
How do I parse remittance advice automatically?
Collect remittance from every channel it arrives on (a shared AR inbox, portal payment records, lockbox images, bank addenda), extract the structured fields (invoice numbers, amounts, deduction codes, dates), and link each remittance to the payment it describes by payer, amount, and date. Ari reads emailed and attached remittance the way a person would, including free-form notes such as 'paying 1041 and 1042 less the disputed line', and turns them into a proposed application with a confidence score.
What causes unapplied cash and how do I fix it?
Unapplied cash is money received and recorded but not matched to an invoice. The usual causes are missing or late remittance, payments that do not equal any open invoice or combination of invoices, payments referencing invoice numbers that do not exist, customers paying from a different legal entity name, and processor payouts recorded as one lump. The fix is process, not effort: capture remittance from every source, allow combination and partial matching, split payouts into their underlying charges, and put every unapplied payment on an aged list with an owner and a customer follow-up so it does not wait for month-end.
How do I get unapplied cash to zero at month-end?
Work it daily instead of at close. Every payment that fails an automatic match should be classified the day it lands (missing remittance, short pay, unidentified payer, overpayment), assigned an owner, and, where the answer sits with the customer, followed up the same day. By the last week of the month the open list should be small and every item should carry a reason. Ari runs that routine: it proposes matches, asks customers for missing remittance, and reports what remains with the reason for each.
How do I reconcile bank deposits to open invoices?
In two steps. First, break each deposit into the individual payments that make it up, using the bank detail, lockbox file, or processor payout report. Second, apply each payment to its invoices. A deposit rarely maps to a single invoice: a lockbox deposit may contain twenty checks, and a Stripe payout contains many charges net of fees and refunds. Reconciling the deposit to the ledger and applying the payments to invoices are separate outcomes, and both have to be true before the aging report is right.
How do I match a lump-sum payment across multiple invoices?
Use the remittance if there is one. If there is not, search the customer's open invoices for a combination that sums to the payment, allowing for small tolerances and for early-payment discounts the customer may have taken. Take a customer with invoices open for $5,000, $3,000, and $2,000 that sends a single $8,000 ACH: the only combination that sums to $8,000 is the first two, so those are applied and the $2,000 invoice stays open. When more than one combination fits, or the amount fits none, the match is proposed with a confidence score and confirmed by a person rather than guessed.
How do I apply a payment when the customer did not include an invoice number?
Match on what you do have: the payer name to a customer, then the amount to that customer's open invoices or a combination of them. If the amount matches exactly one invoice or one combination, apply it. If it matches several, or none, ask the customer for remittance the same day and hold the payment as unapplied with an owner rather than applying it to the oldest invoice on a guess. Ari sends that request automatically with the customer's open invoice list attached, which usually gets the answer in one reply.
How do I handle short payments and deductions?
Classify the reason first. Amounts under your tolerance (a bank fee, rounding, a few dollars) are written off automatically. Everything else gets a reason code: an early-payment discount taken, a pricing or quantity dispute, tax withheld, a portal or processing fee deducted, a returned item. Valid deductions become a credit memo through an approval step; invalid ones become a collections follow-up for the remaining balance with the original invoice and the customer's remittance note attached. What you should not do is apply the short payment and let the residual sit on the aging report with no explanation.
What is a deduction management process for B2B payments?
A deduction management process is the workflow for identifying why a customer paid less than invoiced, deciding whether the deduction is valid, and resolving it: writing it off, issuing a credit memo, or collecting the difference. The steps are capture (from remittance and short-pay detection), coding (a reason for every deduction), routing (pricing disputes to sales, returns to operations, fee deductions to finance), resolution with an approval trail, and reporting on deduction volume by reason and customer so the root causes get fixed upstream, usually in the contract or the invoice.
How do I reconcile Stripe payouts to invoices in QuickBooks?
A Stripe payout is a net deposit: the sum of many charges minus Stripe fees, refunds, and disputes. Recording the payout as a single deposit against a single invoice is the most common mistake. Break the payout into its balance transactions, apply each charge to the invoice it paid, record fees to a fee expense account, and record refunds and disputes as reversals of the original applications. The net then agrees to the bank deposit. LedgerUp does this for every payout and posts the applications to QuickBooks Online through the official QuickBooks API, so the QuickBooks bank feed match is a one-to-one deposit match rather than a monthly clean-up.
What is the best way to automate payment matching in NetSuite?
Feed NetSuite applied payments rather than raw deposits. Match outside NetSuite or in a layer that reads the bank feed, lockbox file, and processor payouts alongside the remittance, then create the customer payment records in NetSuite against the specific invoices, with the correct subsidiary, currency, and GL accounts for fees and adjustments. Ari does the matching and the remittance reading, posts the customer payments to NetSuite with subsidiary-aware routing, and leaves only the exceptions for a person.
What is the best cash application automation software?
It depends on which layer you are buying. Banks and lockbox providers automate capture but not matching. ERPs (NetSuite, Sage Intacct) match on exact references and stop. AR automation suites such as HighRadius, Billtrust, and Versapay add remittance capture and matching rules, typically for larger companies with dedicated AR teams. LedgerUp is an AI billing operations layer: Ari reads remittance from any source, matches across bank, Stripe, and portal rails, resolves short pays and deductions with your approval, and posts to QuickBooks, NetSuite, Xero, or Sage Intacct, as part of the same workflow that creates the invoices and runs collections. For B2B companies on a mainstream accounting system that want cash application handled rather than tooled, that is the fit.
What AI tools exist for cash application?
AI is useful in cash application for three jobs: reading unstructured remittance (emails, PDFs, portal notes) into structured invoice and amount data, proposing matches when the amount does not equal any single invoice, and classifying the reason behind a short pay. LedgerUp's Ari does all three inside your existing systems and brings the decisions to Slack. Enterprise AR suites offer machine-learning matching as a module. Generic document-AI tools can extract remittance fields but do not know your open invoices, so they stop before the match.