Get a personalized demo of Stuut and see how it can help with AR automation.
Unapplied cash sitting in suspense accounts delays your month-end close and obscures your true working capital position. A payment arrives in the bank, remittance shows up separately in an email, and an analyst has to reconcile both before the cash counts as collected. Multiply that by hundreds of transactions and your AR subledger is always running behind.
Most of the time manual cash application consumes goes to data entry and format handling, not to judgment. AI handles the volume and format variation while your team focuses on the decisions that require experience: Negotiating payment plans, resolving complex deductions, and managing relationships with strategic accounts. Your institutional knowledge of customer payment patterns is what makes automation work. AI covers the volume while you handle the exceptions that actually need a human.
This guide walks through every step of the cash application process, covers how to handle the hardest exceptions, and explains the real difference between legacy rule-based auto cash and modern AI-driven payment matching.
Cash application is the process of matching incoming customer payments to open invoices and recording them in your accounts receivable system. Every dollar collected sits in suspense until you complete this process, so unapplied payments inflate your bank balance without reducing your AR aging. Cash application covers three core operations: Receiving funds through ACH, wire, card, check, or lockbox, capturing remittance data that explains what those funds cover, and posting the applied payment as a debit to your cash account and a credit to your AR subledger. All three must happen before a close can proceed.
Accurate cash application determines your real DSO, your open invoice count, and your collection effectiveness index (CEI). Without it, your aging report misrepresents how much you've already collected, your team chases payments sitting unapplied, and your CFO makes working capital decisions based on incorrect data. Track how cash application speed affects overall DSO using our DSO improvement checklist.
The most common reason for unapplied cash is decoupled remittance advice: A customer sends an ACH transfer through one channel and emails the remittance detail separately, and the two never get linked. Other causes include partial payments that don't match any single invoice amount, bulk wires covering 40 to 50 invoices without a breakdown, and remittance data with incorrect or incomplete invoice numbers. Each of these lands in your suspense account until someone investigates.
Here is the full six-step workflow that takes a payment from bank receipt to cleared AR subledger entry. Each step builds on the previous one, and bottlenecks at any stage create downstream delays that affect month-end close timing and working capital visibility.
Your bank receives the funds and posts them to your account. For ACH and wire transfers this is automatic, though the transaction typically includes no remittance detail. For lockbox payments, the bank scans and batches checks before transmitting a data file overnight. At this point, the payment exists in your bank but not yet in your ERP.
Locate the data that explains what the payment covers: Invoice numbers, PO numbers, payment amounts, and any deduction reason codes. Remittance can arrive via email PDF, EDI 820 file, customer portal download, or lockbox image. This step is where most manual time is consumed because remittance often arrives separately from the payment and in an unstructured format.
With both the payment amount and the remittance detail in hand, match them against open invoices in your ERP. This can be a one-to-one match (one payment for one invoice), a one-to-many match (one wire covering 12 invoices), or a partial match (payment covers part of one invoice). Matching challenges include cases where a payment is slightly over or under due to rounding, or where a customer references a PO number rather than an invoice number.
When a customer pays less than the invoice amount, determine the reason before closing the invoice. Valid reasons include early-pay discounts, pricing errors, damaged goods, or promotional allowances. Invalid short-pays require a dispute to be opened and filed. This step adds significant time to manual cash application because it requires cross-referencing contracts, shipping records, and sales rep communications before a resolution can be reached.
Once you've matched the payment and resolved any exceptions, post it to the GL. The cash account receives a debit, the AR subledger receives a credit, and the open invoice closes. In a manual workflow, this means keying entries into SAP (T-code F-28), Oracle Receivables, NetSuite's Customer Payment record, or the Dynamics 365 Customer Payment Journal. Posting in real time rather than in daily batches removes the most common close bottleneck.
Reconcile your applied cash against your bank statement to confirm everything posted correctly. Any items remaining in suspense need to be investigated, escalated to the customer for missing remittance, or written off if below your threshold. Clearing the suspense account completely signals that your AR subledger matches reality.
Different payment channels create different cash application challenges. Understanding each one helps you prioritize where to apply automation first.
ACH and wire transfers dominate B2B payment volume. The challenge is that payment and remittance arrive through separate channels: The bank posts the deposit but includes no invoice detail, while remittance arrives in a different channel hours or days later. Until you link the two, the payment sits unapplied. This specific matching problem can consume substantial AR team time when ACH payments represent a large portion of your receivables.
Credit card and digital payment processing creates a batching problem: A processor like Stripe combines hundreds of individual card payments into a single daily deposit. Your team receives one bank statement line but needs to match it against potentially hundreds of individual invoices. Without automation, this batch reconciliation can consume a full analyst day. Our Stuut vs. Versapay comparison covers how different platforms handle bulk deposit reconciliation.
In a bank lockbox service, customers mail checks to a PO box controlled by your bank. The bank scans each check, keys remittance data, and transmits a BAI2 or EDI 823 file overnight. BAI2 lists each invoice and payment amount individually, which makes downstream matching more accurate than older formats. The limitation is that data entry quality depends on the bank's clerks, and errors in invoice numbers create exceptions on your end.
Large retail and enterprise buyers require suppliers to submit invoices and retrieve payment data through proprietary portals such as Ariba, Coupa, and Tungsten. This means logging into each portal separately to download remittance before matching work can begin. That repetitive portal task creates significant overhead for AR teams working at high portal volume, and it's exactly what our automated AR platform is built to eliminate.
Remittance extraction is the step where manual cash application loses the most time because the data arrives in formats ERPs can't read natively.
Most B2B remittance arrives as a PDF attachment or in the body of an email. AI uses NLP and OCR to read email bodies and PDF attachments, pull invoice numbers, payment amounts, and deduction codes, and convert unstructured text into structured records. This replaces the manual step of opening each email, reading the PDF, and typing the data into a matching screen.
EDI 820 (Payment Order/Remittance Advice) is a structured electronic remittance format used by large B2B buyers. EDI 835 (Healthcare Claim Payment/Advice) serves the same function but is specific to health plans and insurers rather than general commercial buyers. Their pre-structured data is more accurate than email PDFs, but they require a compatible EDI translator to parse and map fields to your chart of accounts. Most mid-market companies receive only a fraction of remittance in EDI format, so EDI-only solutions miss the majority of inbound data.
Automating portal data retrieval means using API connections or robotic process automation to log into portals programmatically, download remittance files, and pass them to your matching engine without an analyst touching a keyboard. This eliminates a significant source of daily manual overhead for teams with a large portal-customer base.
AI-powered OCR extracts data from scanned check images and lockbox files automatically, parsing printed remittance details that legacy bank file formats sometimes miss. This capability is useful for companies that still receive paper check volume from smaller regional customers.
Matching logic determines how efficiently payments clear your open invoice list.
One-to-one matching is the simplest case: One payment for one invoice where the amount matches exactly. Even this fails when customers reference a PO number instead of an invoice number, or when a payment is slightly over or under due to rounding. We handle these variations by learning each customer's referencing patterns over time rather than relying on exact-match rules.
One-to-many matching covers bulk wires where a single payment covers multiple invoices. A single payment can cover dozens of invoices in complex B2B relationships. Manually allocating a bulk wire requires downloading the aging report, sorting by customer, and allocating the payment line by line. We allocate the same payment against all matching invoices automatically.
When a customer's payment doesn't cover the full invoice amount, leave the residual balance open and flag it for follow-up. Partial payments require you to determine whether the short amount is an approved deduction or an unauthorized short-pay. Leaving the residual open without classification is the fastest path to a growing suspense balance.
Three-way match is primarily an accounts payable control that compares the purchase order, invoice, and receiving report to confirm a vendor payment is authorized. In accounts receivable, some industrial teams apply similar verification logic for high-value transactions, confirming that the purchase order reflects what the customer authorized, your invoice reflects what was shipped and priced, and the payment amount covers the agreed total. This is most relevant for complex, high-value transactions where dispute risk is elevated.
Exceptions are payments or invoices that don't clear automatically. They're the primary reason manual cash application consumes hours per day.
A short-paid invoice means the customer paid less than billed. Determine the reason first: Valid early-pay discount, pricing error, damaged goods, or unauthorized deduction. Valid short-pays require a credit memo. Invalid ones require a dispute. We route short-pays to the correct team based on reason code and amount threshold automatically, which reduces per-exception handling time significantly compared to manual review.
Deductions from large retailers (trade promotions, reclamation, late shipments) are the most complex exception type because they require you to pull backup documentation, validate the claim against your contract terms, and either accept or dispute the deduction within a filing window. Missing that window means writing off revenue that was actually recoverable.
Payments you can't link to any customer or invoice go into a suspense account until you identify them. The correct action is to contact the customer directly with the payment details and request remittance information. We handle this outreach automatically when we can't match a payment, rather than parking it in suspense waiting for an analyst.
Credits from returns, overpayments, or adjustments offset future invoices rather than sitting idle in the customer's account. Automating credit application means the system checks for available credits before flagging a payment as short-paid, which reduces exception volume and prevents unnecessary follow-up on balances already covered.
Manual cash application means an analyst opens the bank statement, exports the aging report to Excel, sorts payments by amount, searches for matching invoices, keys the allocation into the ERP, and repeats for every transaction. At mid-market scale, this creates a significant daily overhead that we reduce by 70%. Complex payments with multiple invoice references take significantly longer per transaction than simple one-to-one matches, and the gap compounds quickly at volume.
Legacy "Auto Cash" in the context of AR automation refers to rule-based matching engines built into ERPs like SAP (T-code F-28) and Oracle AutoCash. These systems match payments based on predefined criteria: Exact invoice number match, exact amount match, or customer account lookup. The limitation is that rule-based systems typically achieve 60 to 70% straight-through processing, meaning 30 to 40% of payments still require manual intervention. Rules also require constant maintenance as customer behavior changes.
Note that "Auto Cash" is also a brand name used by unrelated title loan businesses and a financial analytics platform, neither of which relates to AR payment matching.
AI-driven cash application uses machine learning and confidence scoring rather than rigid rules, which means it handles unstructured remittance, partial payments, and bulk deposits that defeat rule engines entirely. AI platforms consistently reach 95%+ straight-through processing for established customer relationships and improve automatically as they process more transactions. Unlike static rule systems, AI doesn't require IT intervention when a customer changes their payment format or starts referencing a different identifier. That said, match rates are lower for new customer relationships without established payment history, for highly customized remittance formats with no prior training data, and for multi-entity payments that span complex corporate family structures. Those scenarios still require human review, and we route them to your team with full context rather than parking them in suspense.
The cost difference is concrete. Manual cash application creates a significant daily cost for mid-market AR teams, before factoring in the cost of delayed posting or unapplied cash distorting working capital decisions. Shifting to our platform recovers those hours and redirects them to dispute resolution, credit analysis, and relationship management.
We integrate with NetSuite via API using credentials your NetSuite administrator provisions. No modifications to your chart of accounts or custom workflows are needed. We read open invoices, execute matching, and write the applied payment record back to NetSuite's Customer Payment object in real time, with average onboarding completing in 3 to 4 days.
Oracle AutoCash is the native module within Oracle Receivables, configured through AutoCash Rule Sets. The limitation of Oracle's native AutoCash is the same as all rule-based systems: Matching logic is only as good as the rules you configure, and exceptions still require manual review. Our AI layers on top of Oracle's standard AR APIs without replacing your existing configuration, pushing applied payment records back in real time.
Microsoft Dynamics 365 Finance uses the Customer Payment Journal for cash application, with standard APIs enabling external integration. D365's native matching handles basic automatic settlement, but complex scenarios (bulk deposits, multi-entity payments, partial-pay deductions) typically fall to manual. We connect via the standard D365 API and post settled payments directly to the Customer Payment Journal in real time. See our HighRadius implementation timeline breakdown for a direct comparison of deployment speed across platforms.
We parse incoming remittance from bank accounts, lockboxes, and digital payment rails using AI models trained on B2B payment patterns. Our system identifies the relevant fields, maps them to open invoices in your ERP, and queues the payment for matching without any analyst involvement. This eliminates the manual remittance processing steps that consume hours in manual workflows.
Our matching algorithm learns each customer's payment patterns, remittance formats, and reference number conventions, reaching a 95%+ automated match rate for established customer relationships. For new customers without prior payment history in the system, match rates are lower initially and improve as the algorithm processes more transactions from that relationship. We handle exact matches, partial payments, overpayments, and bulk deposits where a single Stripe deposit covers 100 individual card payments. Each matched payment posts to your ERP in real time, and our system captures metadata that most ERPs never store, such as originating company identifiers in bank transactions, so future payments from the same source match instantly without any configuration change.
When we can't match a payment at high confidence, we automatically contact the customer to request remittance details rather than parking the payment in suspense. For deductions, we categorize the reason code, pull supporting documentation, and route valid deductions to credit memo creation while flagging invalid deductions for recovery. Disputes we resolve can take significantly less time than manual dispute processing. Complex legal disputes and highly nuanced relationship-based deductions still require human judgment, and we escalate those with full context attached so your team can focus on negotiation rather than data gathering.
We post all applied cash directly to your ERP subledger in real time via API, eliminating manual rekeying and batch delays. Average onboarding takes 3 to 4 days for standard SAP, Oracle, NetSuite, and Dynamics environments. Full go-live, including configuration and first autonomous cash application, completes within 6 to 10 days. Your existing chart of accounts, customer portals, and payment processing stay unchanged.
Use this checklist before your next month-end close to identify where your cash application process is losing time.
Cash application matching checklist:
Manual cash application at mid-market companies creates a predictable month-end bottleneck because posting backlogs accumulate throughout the month. We reduce manual tasks by 70%, freeing your analysts to focus on deduction recovery, credit recommendations, and managing at-risk accounts. PerkinElmer reduced overdue invoices from 50% to 15% in one year (PerkinElmer case study) by using Stuut to automate routine matching and contact workflows. The role becomes more strategic, and more satisfying, when we handle the high-volume data entry.
For high-value transactions with payment discrepancies, some AR teams apply three-way match logic borrowed from AP: Checking that the customer's purchase order reflects what they authorized, your invoice reflects what was shipped and priced, and the payment amount covers the agreed total. This verification step is most relevant for complex, high-value transactions where an underpayment might otherwise close without investigation.
If you use a bank lockbox, verify that the BAI2 file your bank transmits lists individual invoice amounts rather than lump-sum totals. BAI2 format supports invoice-level detail that enables automated matching. If your bank transmits only lump-sum data, request the upgrade to invoice-level BAI2 before investing in any matching automation, because the matching logic is only as good as the remittance data it receives.
We handle the high-volume exceptions (bulk deposits, partial pays, missing remittance) that consume most manual cash application time. Your team stays focused on the exceptions that genuinely require judgment: Negotiating payment plans on overdue balances, managing deduction disputes with major retail buyers, and handling multi-entity payments that span corporate family relationships. Companies using AI for routine cash application free their teams to focus on complex cases that drive real business value.
See how our AI handles your actual payment volume and ERP configuration in a live demo. We'll show you real remittance extraction, complex payment matching, and exception handling using your data. Book a demo with our team.
The cash application process is the cycle of receiving a customer payment, capturing remittance data, matching the payment to open invoices, handling exceptions, posting to the AR subledger, and reconciling against the bank statement. It converts collected cash into closed invoices in your ERP.
Manual payment matching creates significant daily overhead for mid-market AR teams, before factoring in the additional time lost to delayed posting and unapplied cash distorting working capital decisions. We reduce those manual tasks by 70%.
Three-way match is an AP control that compares the purchase order, invoice, and receiving report to verify a payment is authorized. In AR, some teams apply similar logic to high-value transactions, confirming the PO, invoice, and payment amount all align before closing the transaction.
Legacy auto cash uses predefined rules to match payments and typically achieves 60 to 70% straight-through processing, leaving 30 to 40% for manual review. AI-driven cash application uses machine learning to reach 80 to 95% automated match rates for established customer relationships and improves without rule reconfiguration.
The most common cause is decoupled remittance advice: A payment arrives via ACH while remittance arrives separately in an email or customer portal, and the two never get linked before the payment posts to suspense.
In a bank lockbox service, customers mail checks to a bank-controlled PO box. The bank scans each check, keys remittance data, and transmits a BAI2 or EDI 823 file overnight listing invoice numbers and payment amounts for your matching engine.
We connect to SAP, Oracle, NetSuite, and Dynamics 365 via standard APIs without modifying your existing configuration. Average onboarding completes in 3 to 4 days, with full go-live in 6 to 10 days.
Cash application: The process of matching incoming customer payments to open invoices and posting them to the AR subledger.
Remittance advice: Documentation sent by a customer explaining which invoices a payment covers, including invoice numbers, amounts, and any deduction reason codes.
Suspense account: A temporary holding account for payments that cannot yet be matched to an invoice or customer record.
Short-pay: A customer payment for less than the full invoice amount, which may reflect a valid deduction or an unauthorized underpayment.
Three-way match: An AP verification process comparing the purchase order, invoice, and receiving report before authorizing payment, also applied in AR for disputed invoice resolution.
Straight-through processing (STP): The percentage of payments matched and posted automatically without any manual intervention.
BAI2: A standardized bank file format that lists individual invoice amounts within a lockbox deposit, enabling invoice-level automated matching.
EDI 820: A structured electronic remittance format used by large B2B buyers to communicate payment details alongside their transactions.
DSO (Days Sales Outstanding): The average number of days between issuing an invoice and receiving payment, used as the primary measure of AR efficiency.
GL posting: Recording a transaction to the general ledger, which updates both the cash account and the AR subledger to reflect the applied payment.
