AP & Invoice Processing

Accounts payable and invoice processing is the set of steps a vendor bill goes through between arriving at a company and turning into a payment: capturing what the vendor sent, checking it against what was actually ordered and received, routing it for approval, and executing the payment on the terms agreed. Every one of those steps is a place where a real dollar amount can end up wrong, duplicated, or simply stuck — which is why AP is one of the few back-office functions where a genuine process failure shows up directly on a bank statement, not just in a report nobody reads.

What actually happens between a vendor invoice and a paid bill

A vendor invoice passes through five stages before it becomes a completed payment, and almost every question in this cluster is really a question about one specific stage failing.

1. Capture — the invoice arrives, by email, a supplier portal, EDI, or mail. This is the first point where the same invoice can enter twice, if it arrives through more than one channel and gets keyed in independently by two people.
2. Extract and enter — the invoice's vendor, amount, line items, and reference numbers get turned into structured data, whether by OCR, a vendor portal's own structured submission, or manual keying. Anything misread or mistyped here propagates into every step that follows.
3. Match — the invoice is checked against the purchase order it references and, for goods, against the receipt confirming delivery. This is where three-way matching happens, and it's the single biggest control point against overbilling, billing for undelivered goods, and outright fraud.
4. Code and approve — the invoice is assigned to the right GL account and cost center, and routed to whoever has authority to approve that amount and category of spend. This is also where non-PO invoices (a subscription renewal, a one-off service bill with no purchase order behind it) get their first and only human review.
5. Pay and record — the approved invoice is scheduled and paid on the agreed terms, and the payment is posted back against the open bill so the AP subledger reflects what's actually still owed.

Matching and approval carry most of the real risk in this list, because they're the two stages designed specifically to catch a problem before money leaves the company — everything before them is data entry, and everything after them is execution. Most of the diagnostic pages in this cluster are, at bottom, about what happens when matching or approval lets something through that it should have caught, or holds something it shouldn't have.

PO-based invoices vs. everything else

Everything above assumes a purchase order exists to match against — and for a large share of what AP actually processes, one doesn't. Software subscriptions, utility bills, professional services retainers, and one-off vendor invoices routinely arrive with no PO behind them at all, because the spend was never routed through procurement in the first place. Matching, in any of its forms, has nothing to compare a non-PO invoice against, which means the invoice's coding and approval step is the only control it will ever pass through before payment.

That single-checkpoint reality is why non-PO invoices deserve a different standard of scrutiny than PO-based ones, not a lighter one. A vendor invoice with a PO behind it has already been vetted once, at the point someone approved the purchase order; a non-PO invoice is being approved and verified for the first and only time in the same step. Companies that treat non-PO invoices with the same rubber-stamp speed they'd give a matched, PO-based invoice are, in effect, running their weakest control on their least-verified spend — which is backwards, and it's where a meaningful share of AP fraud and duplicate billing actually concentrates.

Why this keeps breaking, even at companies with real controls

A handful of root causes account for most of what goes wrong in AP, and they recur across companies of very different sizes and levels of automation:

• Duplicate vendor records — the same real-world vendor exists under two vendor IDs, most often after a name change, a merger, or simply two people independently onboarding the same supplier. Most duplicate-invoice checks only compare within a single vendor ID, so a duplicate vendor record quietly defeats the control that's supposed to catch duplicate payments.
• Decentralized entry — when more than one person or department can key invoices, the same invoice arriving through two channels gets entered twice by two people who each believe they have the only copy.
• Timing gaps between the PO, the receipt, and the invoice — a vendor often bills for a full order before every unit has been delivered and logged as received, which produces a match failure that looks like a billing error but is really just sequencing.
• Approval routing gaps — an invoice with no clear owner, or one routed to someone no longer with the company, sits unresolved not because it's hard to approve but because no one is clearly on the hook for it.
• Vendor master drift — a bank account update, a remittance address change, or a name change that reaches AP through an unverified channel (an email, rather than a callback to a known number) is one of the more common fraud vectors in AP specifically because it doesn't look like an error at all — the payment goes out clean, just to the wrong destination.

What each level of invoice matching actually catches

"Matching" isn't one thing — it's a spectrum of how much of the invoice gets checked against how many other documents, and each level catches a different category of problem. Microsoft's own Dynamics 365 documentation lays out four distinct matching types, and the differences between them explain a lot about why some errors get caught automatically and others don't:

The gap in that last column matters as much as what each level catches: no level of PO-based matching is designed to catch a duplicate payment, because matching compares one invoice against its own PO and receipt, not against every other invoice already paid. Duplicate detection is a separate control, run across the full paid-invoice history — which is exactly why duplicate payments survive at companies with otherwise strict three-way matching in place. It's also why moving from two-way to three-way matching, on its own, does nothing to reduce a company's duplicate-payment rate — the two controls are answering different questions, and improving one has no effect on the other.

The metrics that actually tell you whether this is working

A handful of numbers, tracked monthly, catch most AP regressions before they compound into a close-period problem:

• Touchless (straight-through) processing rate — the share of invoices that move from capture to approval with no manual intervention. A sudden drop usually means a vendor changed invoice format, a new vendor was onboarded outside the existing matching rules, or a connector broke.
• Days to approve — the gap between an invoice being captured and being approved for payment. This is what actually determines whether early-payment discounts are capturable and whether payments go out on the terms negotiated, independent of whether the vendor was paid "on time" by the due date alone.
• Exception queue age — not just how many invoices are held, but how long they sit. A large queue that clears within days is a healthy, matching-driven process; one that carries items past period close is what turns into the phantom-liability and mismatched-total problems this cluster's diagnostic pages walk through.
• Duplicate payment rate — Washington State's Auditor's Office, citing AFP and IOFM research, puts this at roughly 0.8 to 2 percent of total AP disbursements industry-wide. At any real payment volume, that's a real number worth tracking on its own, separate from the matching metrics above, because matching doesn't catch it.

Why days-to-approve is worth more than it looks

Many vendor contracts offer an early-payment discount — commonly written as terms like "2/10 net 30," meaning a 2 percent discount if the invoice is paid within 10 days, with the full amount due at 30. That discount is only capturable if the invoice clears capture, matching, and approval fast enough to leave time to actually schedule the early payment — which makes days-to-approve, not days-to-pay, the metric that actually determines whether a negotiated discount gets captured or quietly expires unused.

This is also why a slow but otherwise error-free AP process still has a real cost even when nothing is technically wrong: no duplicate payments, no phantom liabilities, every invoice eventually paid correctly — but every discount term the company negotiated and never captured, because the invoice was still sitting in an approval queue on day 11. That cost never shows up as an AP error on anyone's dashboard; it shows up as a slightly worse effective price on every vendor contract that offered terms nobody was fast enough to use.

Where this breaks between teams

AP sits at the intersection of three groups that rarely share a single system or a single manager: procurement cuts the purchase order, receiving or the requesting team logs what actually arrived, and AP processes the invoice and executes payment. When those three live in different tools — a procurement system, a warehouse or project-tracking tool, and the accounting system — the receipt that three-way matching depends on can lag behind the actual delivery simply because no one owns making sure it's logged promptly. The single highest-leverage fix available to most AP teams isn't a better matching algorithm; it's tightening how quickly a receipt gets logged after delivery, since that's the input most match failures actually trace back to.

The two costs that hide the longest

Two AP failures share a specific trait: nothing about them looks wrong from inside the tool where they happened, which is exactly why they survive until someone reconciles against a different source of truth. A phantom liability — a bill that's actually been paid but still shows open in AP because the payment record never synced back — looks entirely normal from the payment processor's side, which shows the payment as completed. A duplicate payment under a second vendor record looks entirely normal from AP's side, because the duplicate-invoice-number check that's supposed to catch it only ever compared within one vendor ID. Both only surface when someone reconciles across systems rather than trusting either one alone — which for many teams still only happens at month-end close, not continuously.

What's in this cluster

The pages below start with the diagnostic questions — a match failure between the PO, receipt, and invoice; a duplicate vendor payment; and what breaks in a specific integration when a workflow can create a bill but can't read it back — each written symptom-first, with the actual root causes ranked by how often they happen. If you're triaging a held invoice or an unexplained duplicate payment right now, start there. A broader diagnostic — a phantom AP liability from a broken sync — lives in the month-end close cluster, since it's specifically a period-close reconciliation problem rather than an invoice-processing one.