Can Your ERP Match Purchase Orders, Receipts and Invoices? A Practical Evaluation Checklist

What three-way matching checks—and what it does not guarantee

Three-way matching generally refers to comparing a supplier invoice with a purchase order and a record of goods received. In one described purchase-to-pay workflow, accounts payable matches invoices to purchase orders and goods-receipt records; invoices that match proceed to payment processing [2]. Treat that as an example of a workflow, not a guarantee that every ERP uses the same rules.

Matching can help identify inconsistencies between order, receipt and invoice records. It cannot by itself establish that goods are usable, a service was satisfactory, a supplier is legitimate, or tax treatment is correct. Your receiving, approval, supplier and accounting controls still matter.

Do not assume every ERP compares the same fields or applies the same rules. The comparison might be at line level, document total, or both; it might use configured tolerances or require a person to resolve differences. Test the behavior you need instead of relying on a feature label.

• Purchase order: check which fields are used, such as item or service, ordered quantity, unit price and line or order total.
• Receipt: check how recorded quantities and values support the invoice, and whether more than one receipt can relate to an order.
• Invoice: check which quantities, prices, totals and other relevant charges are compared.
• Decision: establish whether a match merely flags a status, permits approval, or can move an invoice into a payment process.

Map your purchase-to-pay process, roles and approval thresholds before testing

Write down how a purchase moves through your organization before opening a demo. Include who requests it, who approves it, who places the order, who records receipt, who handles invoices and who authorizes payment. A test is meaningful only if the ERP is evaluated against the responsibilities and separation of duties your organization actually requires.

Define the limits and exceptions that matter to your business. Record approval thresholds, permitted price or quantity variances, required evidence for services, and rules for changing an order after approval. If you do not yet have a policy, mark the decision as unresolved rather than assuming the ERP’s default is appropriate.

Requirements differ by organization and jurisdiction. Have the people responsible for accounting, procurement and compliance identify local requirements, including any invoice, tax, recordkeeping or approval rules that apply. Do not treat a vendor’s general workflow description as legal or accounting advice.

• Sketch the normal path from request to order, receipt, invoice review, approval and payment.
• Name the role responsible for each action, including who may change a purchase order or receipt.
• Set representative approval thresholds and identify who can authorize an exception.
• List records you need to keep and the people who need access to them.
• Identify jurisdiction-specific questions for a qualified adviser or the relevant authority.

Build representative test cases: exact match, partial receipt, variance, credit and duplicate invoice

Prepare a small, repeatable test set using invented supplier and transaction data. Include both clean transactions and exceptions. For each case, write down the documents and values you enter, the result you expect, and the evidence you will capture. Use the same cases for every candidate ERP so the comparison is fair.

Include partial deliveries explicitly. For example, order a quantity, record a receipt for only part of it, and test an invoice for the received amount as well as one for the full order amount. Then record a later receipt and test how the remaining quantity is handled. The key evaluation question is how the ERP relates multiple receipts and invoices and what it allows at each stage.

Vary one condition at a time where possible. A small controlled price difference is easier to evaluate than a case that changes price, quantity and freight together. Then add more complex combinations that resemble your actual transactions.

• Exact match: invoice quantity and price align with the purchase order and recorded receipt.
• Partial receipt: invoice covers only the received portion; then test an invoice that exceeds the recorded receipt.
• Price variance: invoice unit price differs from the order while quantity matches.
• Quantity variance: invoice quantity differs from the received quantity or ordered quantity.
• Credit or adjustment: test how a credit note or supplier adjustment relates to the original invoice and order.
• Duplicate: submit the same invoice twice, then test a repeat with a changed reference or formatting if that reflects your risk.
• Additional charges: if relevant, test freight, tax, discounts or other charges separately and confirm how they affect comparison and approval.

Check how the ERP identifies discrepancies and affects approval or payment

For each test, observe what the system actually compares and reports. Record whether it identifies the affected document, line and field; whether it shows expected and entered values; and whether a user can tell what action is needed. A generic “exception” status may be insufficient if staff must search several records to understand the problem.

Test the consequence of each result, not just the warning. Does an exception stop approval, block payment, or merely appear in a list? Can an authorized person continue? Is the behavior different for a small variance and a material one? Do not assume a warning is a payment control, or that a blocked status cannot be overridden.

Ask the vendor to explain which matching rules are configurable and which are fixed. Confirm whether tolerances apply by amount, percentage, quantity, line or document, and whether taxes or other charges are handled separately. Record exactly what you verified; avoid generalizing from one successful sample.

• Capture the system’s result for each clean and exception case.
• Check whether the discrepancy is visible to the person expected to resolve it.
• Follow the invoice through the workflow far enough to confirm whether approval or payment is held.
• Repeat a variance case just below and above any proposed tolerance.
• Test whether changing an order, receipt or invoice after a match changes the status or creates a visible record.

Verify permissions, overrides and audit evidence

Evaluate the people and permissions involved, not only the matching calculation. Sign in as representative roles and try the actions that matter: editing an order, recording a receipt, resolving a mismatch, approving an invoice and authorizing payment. Confirm whether one person can perform actions that your process expects to keep separate.

Ask what happens when someone overrides a mismatch. Inspect the actual history produced by a test transaction and check whether it records who acted, when, which transaction was affected, what changed, the reason provided and any approval associated with the decision. These are evaluation questions, not guaranteed features. An ACM paper describes an audit trail in its proposed ERP workflow, but does not establish which details or retention rules every ERP provides [2].

Confirm retention, access, export and deletion behavior against your organization’s recordkeeping needs. A described workflow or vendor demonstration does not establish that the same configuration is enabled in your candidate installation.

• Test each role with a separate account where possible; do not rely only on an administrator demonstration.
• Attempt both permitted and prohibited actions and note the outcome.
• Check whether overrides require a reason or additional approval, if your policy requires that.
• Inspect the resulting history and confirm that relevant users can access it.
• Ask how audit records are retained, exported and protected, then validate the answers in the test environment.

Review exception handling, reporting and exports against your operational needs

The daily usefulness of matching depends on how exceptions are worked. Test whether staff can find unresolved invoices, identify the reason for each hold, see the related purchase order and receipt, assign or route the case, and record its resolution. If your workflow relies on email or another tool, check what information must be transferred manually.

Use realistic questions to assess reporting: Which invoices are awaiting receipt? Which have price or quantity differences? Which exceptions have remained unresolved? Can accounts payable distinguish a blocked invoice from one that is approved but unpaid? Report names and availability vary, so test whether the ERP can answer the questions your team actually asks.

Check exports using a representative period and a small set of transactions. Confirm that the output contains the fields, identifiers and statuses your finance team needs for reconciliation or further analysis. A field appearing in an export does not, by itself, prove that the underlying control worked correctly.

• Can the team locate open exceptions without searching each supplier record individually?
• Can staff see the relevant order, receipt and invoice from the exception?
• Can you identify the owner, age, reason and current status of an unresolved case?
• Can reports or exports be filtered and reconciled to the records used in your process?
• Are corrections and resolutions visible after the original exception is closed?

Use vendor documentation and a sandbox test; record limitations and jurisdiction-specific questions

Start with the vendor’s official documentation to understand the intended workflow, configuration options, prerequisites and terminology. For example, a Hyland installation guide lists purchase-order fields such as ordered quantity, unit price and line total, along with total goods-receipt and invoice quantities and values [1]. It also describes configuration options for obtaining purchase-order line data from a file or database [1]. These examples can inform test cases, but they do not establish that another ERP has the same fields or behavior.

Confirm behavior in a test environment using your own cases. Documentation describes a product or configuration; it is not proof that a particular setting is enabled in your candidate installation or suitable for your process. Keep a test log with the scenario, setup, user role, steps, observed result, expected result, evidence and any open question.

For self-hosted ERP applications, evaluate the application separately from the hosting arrangement. Consider who is responsible for application configuration, user access, data governance, backups and recovery procedures. Managed infrastructure can reduce infrastructure work, but it does not remove your organization’s responsibility for business rules, data and access decisions.

• Use official documentation as a guide, then reproduce the workflow in a sandbox or other safe test environment.
• Record the application version and configuration used for the test.
• Keep evidence for successful matches, exceptions, overrides, permissions and exports.
• Mark each requirement as verified, configurable, unsupported, unclear or still needing professional advice.
• Confirm accounting, tax, privacy and record-retention questions with appropriate advisers for your jurisdiction.

A decision checklist for comparing candidate ERPs

Score candidates against the same operational scenarios rather than counting feature names. A candidate that handles your common transactions clearly and makes exceptions accountable may fit better than one with a longer feature list but unclear behavior where your process is most exposed.

Separate non-negotiable controls from preferences. If an ERP cannot demonstrate a required approval boundary, traceable override or jurisdiction-specific accounting workflow, record that as a gap for resolution—not as a promise to revisit after adoption. Include implementation effort and ongoing administration in the decision.

• We mapped our purchase-to-pay steps, roles and approval thresholds.
• We tested exact matches, partial receipts, price and quantity variances, credits and duplicates.
• We verified what the system compares and what happens to an invoice with a mismatch.
• We tested role permissions, overrides and the evidence retained for each action.
• We can find, assign, resolve and report exceptions in a way that suits our team.
• Exports support our actual reconciliation and review needs.
• We documented configuration dependencies, limitations and unanswered vendor questions.
• We reviewed applicable accounting, tax, privacy and recordkeeping requirements with qualified people.