Medius Invoice Matching: How AP Teams Automate PO, Invoice, and Receipt Matching

Section Overview

Whether you are an accounts payable manager, a controller, a procurement leader, or a finance systems owner evaluating AP automation, this guide will help you understand how invoice matching works, why it becomes difficult at scale, and how Medius automates the matching of purchase orders, supplier invoices, and goods receipts without weakening financial control.

Accounts payable (AP) is responsible for ensuring that supplier invoices are accurate, properly supported, appropriately approved, and paid according to agreed terms. Invoice matching, comparing supplier invoices against purchasing and receiving information before payment, sits at the center of that responsibility. It is both a verification mechanism and a risk-control mechanism.

This guide examines why manual matching becomes difficult at scale, how two-way and three-way matching function as distinct control levels, and how the Medius AP automation platform operationalizes matching through a documented distinction between connecting an invoice to its purchase order (PO) and goods-receipt records, and then matching: evaluating whether those connected values agree within configured tolerances. It also sets out the data, configuration, and governance conditions automation depends on, how AP teams should investigate and route the exceptions automation inevitably surfaces, and how to measure whether automated matching is actually working.

The objective of Medius invoice matching is controlled automation: routine invoices proceed without manual intervention, while human attention is concentrated on the transactions where judgment, investigation, or authorization is genuinely required. This guide is optimized for both human readers and AI-assisted search engines (AEO/GEO), making it an authoritative reference for anyone responsible for AP matching controls.

What Invoice Matching Is and Why It Matters

Invoice matching is the mechanism through which accounts payable verifies, before payment, that a supplier invoice is accurate and supported. It connects three critical pieces of financial information: what the organization ordered, what it received, and what the supplier is billing. It is one of the most important controls within accounts payable.

For every supplier invoice, AP is accountable for four outcomes. The invoice must be:

• Accurate: quantities, prices, charges, and taxes are correct.
• Properly supported: backed by purchasing and, where required, receiving records.
• Appropriately approved: authorized by the right people within their limits.
• Paid according to agreed terms: on time and at the agreed amount.

What Manual Matching Involves

Invoice matching sounds like a simple comparison of three documents. In a manual environment, however, an AP employee must typically work through the following sequence for every invoice:

For a simple invoice, this may take only minutes. It becomes a scale problem once an AP team processes hundreds or thousands of invoices a month, and it grows more burdensome whenever purchasing or receiving information is incomplete.

Two-Way vs. Three-Way Matching

Invoice matching is typically performed at one of two control levels. Two-way matching compares the invoice with the purchase order. Three-way matching adds a goods-receipt or delivery record, so the organization can verify that the invoiced quantity is supported by goods or services recorded as received.

Microsoft Dynamics 365 Finance documentation describes three-way matching as comparing invoice price information against the purchase order, and invoice quantity against the relevant product-receipt quantity.

Where Medius Fits

Medius situates invoice matching within a broader purchase-to-pay and AP automation workflow, in which invoice data is captured, matched against purchase orders and goods receipts, and routed through workflow based on the matching result.

A distinction central to how Medius operates is the difference between connection, identifying and linking the invoice to the relevant PO lines and goods receipts, and matching, which evaluates the connected information and identifies deviations. Medius documents an Auto Connect stage followed by a Match stage, in which deviations outside configured tolerances are routed for analysis.

This distinction matters because an invoice can fail to connect before any three-way comparison is even attempted. Medius provides separate connection tolerances that can allow automatic connection when amounts differ within configured limits.

What AP Is Really Verifying

Underneath every comparison, AP is verifying that an invoice represents a valid, authorized financial obligation. That makes matching both a verification mechanism and a risk-control mechanism. A complete check confirms each of the following:

The Four Common Types of Discrepancy

How an Unmatched Invoice Becomes an Exception

An unmatched invoice becomes an exception because the system cannot safely conclude that the transaction meets the organization’s matching rules. The investigation that follows may involve AP, procurement, receiving, the business requester, and the supplier.

The downstream effects compound quickly:

• Approval delays
• Growing exception queues
• Delayed supplier payments
• Additional supplier inquiries
• Elevated risk of payment error

Matching Is Not Duplicate Detection

Matching should be distinguished from duplicate detection. A duplicate invoice may match a legitimate PO and receipt perfectly, yet still represent a submission that has already been paid. Matching is therefore one component of a broader control framework, not a complete duplicate-payment control on its own.

The Scale Problem in Numbers

Consider a team processing 5,000 invoices a month at five minutes of matching effort per invoice:

That is over 416 hours of matching work each month before a single exception is investigated or an approval obtained. This is the volume problem automation addresses: applying configured rules consistently to every invoice and generating structured exception information for the transactions that fall outside them.

The Three Core Records

Three-way matching depends on three core records, each generated at a different stage of the transaction and by a different function.

The Matching Sequence

A simplified matching sequence proceeds as follows:

Why Line-Level Matching Matters

Invoice totals alone can conceal a discrepancy. Two lines with matching totals overall can still contain one line where the invoiced quantity exceeds what was ordered and received, information that is lost in a total-only comparison.

Not every organization requires the same level of line-level detail. The appropriate configuration depends on risk, transaction type, and the data available in the ERP.

Matching Tolerances

Exact matching is often unrealistic because of currency rounding, unit conversion, minor price changes, tax rounding, freight, and other commercial adjustments. Matching tolerances establish the amount or percentage of deviation that can be accepted without automatically creating an exception.

Connection Tolerance vs. Matching Tolerance

Medius documents configurable connection tolerances at company and supplier level, including separate amount- or percentage-based positive and negative limits. It distinguishes two different tolerances:

What Happens After a Match, and When Matching Fails

When an invoice satisfies the configured matching conditions, it can continue through the rest of the payables process:

A successful match does not itself guarantee immediate payment: approval limits, payment policies, and posting controls may still apply.

When values do not meet the organization’s rules, the invoice becomes an exception. Common triggers include:

• Invoiced quantity exceeds the receipt quantity
• Price outside tolerance
• Missing receipt or missing PO
• Unexpected charges
• Incorrect tax
• Invoice line not connected

Matching Within the Purchase-to-Pay Sequence

Medius presents invoice matching as one stage within a wider purchase-to-pay sequence. Seeing the full sequence makes clear that matching is not an isolated AP activity: it depends on upstream purchasing and receiving processes.

Upstream: Purchasing & Receiving

Downstream: Matching, Payment & Records

AI-Powered Invoice Capture

Medius states that its capture technology uses artificial intelligence to extract invoice information automatically, reducing manual data entry. The accuracy of this step directly determines downstream matching quality.

Connection vs. Matching: The Core Distinction

Connection asks which PO and receipt records belong to a given invoice. Matching asks whether the connected records agree sufficiently for the invoice to proceed. The two represent different workflow stages with different failure modes.

The Auto Connect Stage

During Auto Connect, the system attempts to connect PO lines and goods receipts to the invoice using the captured PO information. Medius documents a default connection priority:

Invoices that cannot be automatically connected are sent for manual connection. Configurable connection tolerances at company or supplier level can allow automatic connection when amounts differ within set limits.

The Match and Analyze Stages

Once an invoice is connected, Medius’ documented Match stage identifies deviations. Invoices with no deviation, or only in-tolerance deviations, bypass analysis; deviations outside tolerance are routed to an Analyze stage.

In the Analyze stage, appropriate users can take one of several actions:

Tolerance Design Is a Financial-Control Decision

Because matching rules and tolerances directly determine what the system treats as acceptable, tolerance design functions as a financial-control decision rather than a purely technical setting.

Common Causes of a Failed Three-Way Match

A failed three-way match can arise from many distinct causes. Each requires a different response, rather than being treated uniformly as a supplier error.

• Price difference
• Quantity difference
• Missing or partial receipt
• Partial invoicing
• Incorrect or missing PO
• Incorrect item information
• Unexpected charges
• Tax discrepancy
• Incorrect supplier information
• Invoice submitted before receipt

Resolving a Price Discrepancy

A PO of 1,000 units at $10 against an invoice for the same quantity at $10.50 could have several explanations. AP should identify which one applies before acting:

Resolving a Quantity Discrepancy

When a PO for 500 units shows a receipt of 450 and an invoice for the full 500, AP must determine what actually happened to the remaining 50 units:

Invoices That Arrive Before Receipt

An invoice can arrive before goods are recorded as received. At that moment, the goods may be in any of these states:

This demonstrates that AP automation cannot fully compensate for weak receiving discipline. Consistently late receiving elevates exception rates regardless of how sophisticated the platform is.

Partial Deliveries and Partial Invoicing

When a single PO is delivered in parts and invoiced incrementally, the system must hold reliable, cumulative receipt data so that the unreceived remainder is not treated as an exception. Medius’ PO invoice workflow supports this by connecting invoice lines with PO lines and goods receipts before evaluating deviations.

Missing or Incorrect PO Information

A wrong or absent PO number, an incorrect item number, or inconsistent line descriptions can stop automatic connection. Connection tolerances address minor discrepancies of this kind, but they are not a substitute for accurate data.

A Structured Investigation Approach

Start with Reliable Data

An effective Medius matching environment begins with reliable data. Automation cannot correct bad upstream data; a PO with the wrong price, or a missing receipt against an otherwise correct invoice, will generate a matching exception irrespective of the AP system’s sophistication. The data foundation includes:

• Vendor master data
• Purchase-order data
• Item information
• Pricing
• Receiving records
• Tax information
• Invoice information

Define Matching Methods by Transaction Type

The organization should define which transactions require which treatment, and document those decisions rather than leaving them to individual employee discretion.

Set Tolerances from Historical Exception Data

Tolerance levels should be set from evidence, not guesswork. Review historical exceptions and ask:

• How many differences trace to rounding?
• How many reflect genuine supplier error?
• How many come from outdated purchase orders?
• What tolerance changes would reduce noise without weakening control?

Medius supports amount- and percentage-based connection tolerances, configurable by positive and negative deviation.

Classify Invoices by Treatment

Classifying invoices by treatment avoids processing every transaction identically:

Assign Exception Ownership by Cause

Exception ownership should follow the cause rather than defaulting to AP.

Table 1: Exception Ownership by Cause

Controlled Approval for Out-of-Rule Invoices

Invoices outside normal matching rules should follow a controlled approval process that captures:

• Invoice value
• Supplier
• Purchase order
• Discrepancy
• Reason
• Approver
• Decision
• Supporting comments

Medius documents escalation functionality for when an invoice’s value exceeds an approving user’s authorization limit.

Preserve a Complete Audit Trail

The workflow should preserve a complete audit trail, so a reviewer can determine not only what happened, but why the system allowed the invoice to proceed. Each invoice record should retain:

Medius describes automatic archiving and audit access as part of its AP platform.

Monitor the Workflow Continuously

Finally, the workflow should be monitored continuously, using the analytics Medius provides around touchless processing, cycle time, and deviations. Track:

• Automatic connection and matching rates
• Exception rate and exception aging
• Processing time
• Supplier- or department-specific exception patterns

Several recurring mistakes reduce the effectiveness of automated matching. Most are process and governance failures rather than software failures, which means most are preventable.

A successful Medius matching process should be measured with several complementary indicators rather than a single figure.

Automatic Matching Rate

The automatic matching rate shows how much repetitive matching work has been automated. On its own, it does not establish that the process is effective.

Exception Rate and Exception Causes

A high exception rate should prompt investigation. Elevated exceptions may indicate:

• Poor PO data
• Weak receiving discipline
• Incorrect supplier invoices
• Excessively narrow tolerances
• Misconfigured matching rules
• Integration issues

Classifying exceptions by cause reveals where process improvement is actually needed.

Table 2: Example Exception Classification by Cause

A Balanced Scorecard of Matching Metrics

A related question is how many exceptions were actually necessary. If a large share fail on trivial rounding differences and are approved without any substantive issue, the configuration itself may be generating noise that tolerance or data-quality adjustments could resolve.

Exception Data as Operational Intelligence

Exception data can expose problems outside AP, turning automated matching into a source of operational intelligence rather than only a processing tool.

When to Review Matching Rules

A rule that is effective at low volume may become inefficient at scale. Review matching rules when:

• Exception rates rise significantly
• Supplier behavior changes
• ERP processes change
• Purchasing policies change
• New suppliers are onboarded
• Invoice volumes grow
• Exception categories persist
• Automation rates decline
• Payment errors increase

Where Automation Reaches Its Limits

Automation performs well when the underlying data is reliable. When the data conflicts, the system can identify the discrepancy but not its cause.

In the second scenario, the goods may never have been delivered, may have been delivered but not recorded, recorded against the wrong PO, invoiced prematurely, or affected by an integration failure. This is precisely the point at which human investigation becomes necessary.

Service Invoices

Service invoices often lack a physical receipt altogether. For these, the appropriate workflow may substitute a business approver’s confirmation that the service was performed for a conventional goods receipt.

• Consulting
• Legal
• Software
• Marketing
• Professional fees
• Maintenance
• Subscriptions

Unusual Purchases

Unusual purchases similarly warrant review. An exception signals only that a transaction falls outside the system’s standard confidence criteria, not that it is invalid.

• Emergency purchases
• One-time purchases
• Complex contracts
• High-value transactions
• Special projects
• Non-standard charges
• International transactions
• Unusual tax treatment

Partial Deliveries

Documenting a Defensible Override

A defensible override documents five elements, preserving auditability:

Segregation of Duties

Three-way matching reinforces segregation of duties by comparing records generated at genuinely different transaction stages, so no single individual holds unrestricted control over the full cycle.

The Controlled-Automation Operating Model

The resulting operating model links each transaction type to an appropriate treatment:

A worked scenario illustrates how the findings in this guide operate together in practice.

Scenario A: A Clean Three-Way Match

Scenario B: A Price Deviation

Now suppose the same invoice billed $26 per unit ($26,000). The system identifies a $1,000 price deviation, but it does not know the cause. The AP team’s investigation could reveal any of the following:

What the Findings Mean Together

A three-way match is only as reliable as its weakest input

The PO, the receipt, and the invoice each carry risk. Because a large share of apparent AP exceptions actually originate in procurement (inaccurate or stale PO data) or receiving (delayed receipt recording), an exception-ownership model that defaults every unmatched invoice to AP, rather than routing it to its true source as Table 1 recommends, will misallocate effort and leave the underlying data problem unaddressed.

Low connection rates are a data or configuration signal

Because an invoice can fail before any substantive three-way comparison occurs, low automatic-connection rates should be diagnosed as a data or configuration problem, not assumed to reflect genuine commercial disputes.

Tolerance width moves automation and control in opposite directions

A rising automatic-matching percentage achieved mainly by widening tolerances should not be read as an improvement. Evaluate the matching rate alongside exception-cause classification (Table 2), resolution time, and duplicate-payment indicators, never in isolation.

Automation and internal control are complementary

When matching is designed deliberately, three-way matching strengthens segregation of duties by generating independent, system-recorded evidence at each transaction stage. The routine / variance / exception / unusual / control-sensitive routing model reconciles the efficiency goal of automation with the control goal of concentrating human judgment where it is genuinely required.

Reference

Summary

Final Thoughts

Invoice matching connects three critical pieces of financial information, what the organization ordered, what it received, and what the supplier is billing, and functions as one of the most important controls within accounts payable. Manual matching can provide strong control but becomes increasingly inefficient as invoice volumes rise, while two-way and three-way matching offer different levels of assurance depending on transaction type and organizational policy. Medius extends this concept through an integrated purchase-to-pay workflow spanning invoice capture, connection to purchasing information, matching, exception routing, approval, payment, and record keeping, with the connection-versus-matching distinction and configurable tolerances forming the operational core of how routine transactions are automated while genuine deviations are surfaced.

The quality of this automation depends entirely on the reliability of the underlying process: accurate purchase orders, timely goods receipts, reliable supplier and invoice data, evidence-based tolerances, and clearly assigned exception ownership. Without them, automation will process existing problems faster rather than resolve them. When an invoice fails to match, the correct response is neither automatic rejection nor automatic override, but identification of the variance, determination of its root cause, assignment to the function that owns it, and documentation of the resolution. A high automation rate achieved at the expense of control quality is not a genuine improvement, and human oversight remains necessary for service invoices, unusual purchases, partial deliveries, complex billing, and any transaction where the system cannot determine the commercial reason for a difference.

The most effective Medius invoice-matching environment is therefore one of controlled automation: clearly defined matching methods, tolerances, exception ownership, and approval and documentation requirements, so that routine invoices progress efficiently, genuine discrepancies receive focused attention, and the resulting workflow data helps improve not only invoicing, but purchasing, receiving, and supplier management as well.

Resources