Accounts payable (AP) and accounts receivable (AR) look like opposites. AP tracks what your company owes to vendors; AR tracks what customers owe to you. One is a liability, the other an asset. One pays out, the other collects in. But there is a deeper structural similarity between them that most automation strategies overlook: both break down in exactly the same place, at the exceptions, and both stall for the same underlying reason. Understanding this matters before you choose your automation tools, because the choice has real consequences for cost and complexity. For a comparison of how the two processes differ mechanically, see AP Automation vs AR Automation: 6 Differences Finance Teams Confuse.
TL;DR
AP is the obligation side of the ledger: you owe vendors for goods and services received. AR is the entitlement side: customers owe you for goods and services you provided. Both are core finance operations, staffed and tooled separately at most companies.
Both automate well on the easy volume. AP automation handles PO-matched invoices efficiently. AR automation handles clean, complete customer payments efficiently. In both cases, the touchless rate plateaus when exceptions arrive.
AP exceptions include non-PO invoices (nothing to match against, coding must be determined from scratch), price and quantity discrepancies, duplicate invoices, and GL coding ambiguity. AR exceptions include short pays, unresolved deductions, unapplied cash, and disputed amounts.
Both require the same resolution capability: reading context and applying judgment that rule-based automation cannot supply. This is why both AP and AR automation plateau at the same phase, and why getting past that plateau requires the same class of AI capability on both sides.
For automation strategy, this means: if you buy two separate point tools (one for AP exceptions, one for AR exceptions), you are buying two implementations of the same underlying capability. A platform that can reason through exceptions in plain language can handle both sides on a single implementation.
AP and AR are mirror images
AP tracks what the company owes to vendors: invoices arrive, are processed, and are paid. AR tracks what customers owe the company: invoices go out, payments arrive, and are matched to open receivables.
They mirror each other at the accounting level. When Vendor A sends your company an invoice, that is a transaction in your AP and a transaction in Vendor A's AR. When your company sends Customer B an invoice, that is a transaction in your AR and a transaction in Customer B's AP. The same underlying business transaction is an AP entry on one side and an AR entry on the other. The ledger is the same; the direction is opposite.
This is not just accounting theory. It matters for how each process works and where it breaks.
AP: you owe the vendor
Accounts payable manages the outbound obligation cycle. The company receives goods or services from a vendor, receives an invoice, validates it (matches it to the purchase order or validates it in another way for non-PO invoices), codes it to the right GL account and cost center, routes it for any required approval, and pays it within the agreed terms. The goal is accuracy and control: pay the right vendor the right amount at the right time, coded correctly, with an audit trail.
The standard AP automation mechanism is matching: the system compares the invoice to the purchase order and goods receipt (two-way or three-way match) to confirm the invoice is correct. Invoices that match clean flow through automatically. For more on how matching works, see Two-Way vs Three-Way vs Four-Way Match: When to Use Each. Invoices that do not match, and invoices that arrive without a purchase order, require a different approach. See Non-PO Invoice Automation: Handling Invoices Without a Purchase Order for why those are the hardest cases and PO vs Non-PO Invoices: Why the Difference Decides Your AP Automation for the strategic implications.
AR: the customer owes you
Accounts receivable manages the inbound entitlement cycle. The company delivers goods or services, sends an invoice to the customer, receives payment, and matches that payment to the open receivable. The goal is speed and accuracy: collect what is owed, apply it correctly to the right invoice, and resolve any discrepancies so the cash is recognized and the receivable is cleared.
The standard AR automation mechanism is cash application: matching incoming payments to open invoices automatically, so cash is applied without manual effort. Clean payments that reference a single invoice and match the expected amount flow through efficiently. For more on how cash application stalls, see Touchless Cash Application: Getting Past the Plateau and Order-to-Cash Automation: The 2026 Guide. Payments that do not match cleanly, including short payments, payments with unexplained deductions, or payments where the remittance does not match the outstanding invoices, fall into exception queues.
Same ledger, opposite sides
Both processes are part of the same financial system. AP controls working capital outflows; AR controls working capital inflows. Days payable outstanding (DPO) lives on the AP side; days sales outstanding (DSO) lives on the AR side. Together they determine how much cash is tied up in the operating cycle.
Despite this symmetry, most companies staff them separately, run them on different systems, and automate them independently. That is understandable from an organizational standpoint, but it may mean solving the same underlying problem twice, since the automation challenge in both cases is structurally identical.
Both break at the exceptions
Here is where the structural similarity becomes practically important. AP automation and AR automation both follow the same pattern: they automate the easy volume efficiently, and they stall at the exceptions.
In AP, once the PO-matched invoices are automated, the remaining manual work concentrates in the exceptions: non-PO invoices (nothing to match against, coding must be determined from scratch), price discrepancies, quantity mismatches, duplicate invoices, and coding ambiguity. These are the cases that rule-based automation routes to human queues, because they require reading the invoice, assessing context, and making a judgment. The result is the well-known AP touchless-rate plateau: PO-matched volume automates, non-PO volume stalls. For the full picture, see Accounts Payable Automation: The 2026 Guide.
In AR, once the clean, full-pay customer payments are automated, the remaining manual work concentrates in the exceptions: short pays, deductions that may or may not be valid, unapplied cash where remittance does not match any open invoice, and disputed amounts where the customer is contesting the charge. These are the cases that rule-based cash application routes to human queues, because they also require reading the remittance, assessing its validity, and making a judgment.
What is an AP exception?
An AP exception is an invoice or payment event that the automated AP process cannot handle without human review. The most common types:
- Non-PO invoices: invoices that arrive without a purchase order (nothing to match against, coding must be determined from scratch, approval routing must be decided without a PO-defined path)
- Price discrepancies: the invoiced amount does not match the purchase order
- Quantity discrepancies: the invoiced quantity does not match the goods receipt
- Duplicate invoices: the same invoice or amount from the same vendor appears more than once
- Coding ambiguity: the system cannot determine the correct GL account, cost center, or other required coding
- Missing or mismatched data: the invoice lacks required fields or the data does not match the vendor master
The common thread is that each exception requires reading the specific invoice, understanding its context, and making a judgment that a rule cannot reliably make.
What is an AR exception?
An AR exception is a payment or cash event that the automated AR process cannot handle without human review. The most common types:
- Short pays: the customer paid less than the invoice amount, without explanation
- Deductions: the customer withheld an amount for a claimed credit, discount, promotion, or defect, and the deduction must be validated before it can be accepted or disputed
- Unapplied cash: payment arrived but the remittance advice does not match any open invoice clearly enough to apply automatically
- Disputed invoices: the customer has contested the invoice or part of it, and the dispute must be resolved before the payment is applied
- Remittance mismatches: the payment references multiple invoices and the amounts do not reconcile cleanly to the open items
The common thread is identical: each exception requires reading the specific payment, understanding its context (customer history, open invoices, dispute records), and making a judgment.
The structural similarity
The structural similarity between AP and AR exceptions is not just conceptual: it is architectural. Both require:
- Reading unstructured or semi-structured inputs (invoices, remittance files, customer communications)
- Matching against reference data that may be incomplete or imprecise
- Applying judgment that is not easily expressed as hard-coded logic
- Learning from resolution patterns so future similar cases handle more automatically
- Maintaining an audit trail of why a decision was made
Rule-based automation handles the volume that is clean and structured. AI that can read, reason, and apply judgment handles the exceptions. That capability is the same whether it is operating on the AP side or the AR side.
Why this matters for automation strategy
If AP exceptions and AR exceptions require the same underlying capability (reading, reasoning, and judgment applied in plain language), then building or buying that capability twice, once for AP and once for AR, is an avoidable cost and complexity. For a broader framing of how agentic AI differs from rule-based automation in finance, see RPA vs Agentic AI in Finance: 6 Key Differences for CFOs.
Where automation works
Both AP and AR automation work well on the volume that is structured and clean. In AP: PO-matched invoices with accurate pricing, complete data, and clear coding. In AR: full-pay customer payments with accurate remittance that references specific open invoices. These are the cases where rules and matching work well, and where automation achieves high touchless rates on the first pass.
Investing in automation for this volume is valuable and the return is fast, because the volume is high and the processing is repetitive. This is not where the argument for a platform matters most; standard AP and AR tools handle it adequately.
Where it stalls
Both AP and AR stall when they hit the exceptions. The typical AP touchless rate plateaus at 60 to 80 percent once PO-matched invoices are automated, because the remaining volume (non-PO invoices and mismatched PO invoices) requires judgment that rules cannot provide. The typical AR cash application rate plateaus at a similar level, because short pays, deductions, and unapplied cash require the same kind of judgment.
The plateau is not a sign that the automation is poorly configured. It is a sign that rule-based automation has done what it can, and the remaining exceptions require a different kind of capability. Most organizations reach this plateau and then assign staff to work the exception queues manually, which is costly and does not improve over time on its own. The exception queues become a permanent feature of the operation rather than a temporary backlog that technology is actively reducing.
Solving the same problem twice
If AP exceptions and AR exceptions require the same capability (reading, context, and judgment applied in plain language), then buying separate point solutions for AP exceptions and AR exceptions means paying for and implementing that same capability twice. You get two separate systems, two integration projects, two sets of training, and two sets of ongoing maintenance, for what is fundamentally the same underlying problem.
This is where a platform approach, rather than separate point tools, offers a structural advantage. See What is Neurosymbolic AI? and What is English as Code? for how a plain-language AI reasoning approach differs structurally from rule-based automation. For a platform that handles both AP and AR under the same reasoning engine, see Kognitos Finance & Accounting Automation Solutions.
The practical test is simple: if the AI capability that resolves an AP non-PO invoice (read it, determine the coding, route it for approval based on the policy) is fundamentally the same capability that resolves an AR short pay (read the remittance, determine whether the deduction is valid based on the customer agreement, route it for resolution), then buying two separate implementations of that capability is a choice, not a requirement.
Putting it together
AP and AR are opposites on the ledger but mirrors in their automation challenges. Both run efficiently on the structured, clean volume. Both plateau at exceptions. Both require reading, reasoning, and judgment to resolve those exceptions, and both improve as the AI learns from resolution patterns.
The practical implication for finance leaders is to evaluate automation investments with this symmetry in mind. A tool that handles only the easy AP volume, or only the easy AR volume, will reach a plateau that is costly to work around. A platform that can reason through exceptions in plain language, whether the context is an AP invoice with no PO or an AR short pay with an unmatched deduction, handles the full range without requiring two separate implementations of the same underlying capability.
For more on how Kognitos works across the AP and AR exception surface, see Finance & Accounting Automation Solutions. For how the two processes differ mechanically even though they share the exception problem, see AP Automation vs AR Automation: 6 Differences Finance Teams Confuse. For the foundational AP context, see Accounts Payable Automation: The 2026 Guide.
Whether you are starting with AP or AR, or both, the underlying question is the same: how do you get past the exception plateau? The answer is the same on both sides. AI that can read, reason, and resolve in plain language, learning from every resolution so the exceptions that needed human review today require less review next time.
The company that solves the exception problem on one side of the ledger has already done most of the work to solve it on the other.
Book a working session with a Kognitos solutions engineer → Try Kognitos free →