What Is Invoice Validation?

Invoice validation is the step in accounts payable where a supplier invoice is checked against the records and rules that apply to it, before anyone can account for it or pay it. Many teams and tools call the same step invoice verification. SAP names it Logistics Invoice Verification and describes it as checking incoming invoices for content, prices and arithmetic, with or without a purchase order behind them.

In most ERPs, validation is a gate. Oracle's documentation is explicit: an invoice must be validated before it can be paid or have accounting entries created. The gate also covers far more than people expect. Oracle's validation calculates tax and withholding, checks variances between what was ordered, received, consumed and invoiced, places or releases holds, validates project details, and checks conversion rates, whether the accounting period is open, and whether budget is available. Microsoft describes four kinds of invoice matching and then notes that other forms of validation run through separate vendor invoice policies. Matching is one part of the job.

It helps to keep four questions apart, because each has its own owner and each answer stands alone:

1. Extraction: did we read the invoice correctly?
2. Validation: does it satisfy the checks that apply?
3. Approval: has someone with authority agreed to it?
4. Payment: are the conditions for releasing funds met?

SAP draws the same line in its own training, where invoice verification does not include payment, which belongs to financial accounting. A yes to one question never stands in for a yes to the next. Our guide to the invoice approval workflow covers the third and fourth questions.

One more meaning of the phrase is worth setting aside. "Invoice validation" also describes checking that a structured e-invoice follows a technical format. In the EU, Directive (EU) 2025/516 makes electronic invoicing the default and phases in mandatory e-invoicing and digital reporting through 2035, with a major stage on 1 July 2030, according to the EU's own summary. Format validation matters, and it is a separate job from the business checks this guide covers.

Invoice Validation Checklist: What to Check Against What

A useful checklist names two things for every check: what the invoice is compared with, and what happens if the comparison does not pass. A list of check names on its own leaves a team guessing which record to open and who should act.

A few rows deserve more than a line in a table.

Supplier and billed entity. For US companies paying suppliers who receive 1099s, the IRS runs a free TIN Matching program that checks a supplier's name and taxpayer identification number against IRS records. It handles up to 25 pairs interactively with immediate results, or up to 100,000 in a bulk file returned within 24 hours. Running it when a supplier is set up turns "is this a real supplier?" into a check with an answer.

Purchase or contract terms. Oracle lets companies set tolerances for each supplier site, so two suppliers can face different checks on the same kind of invoice. That flexibility is useful, and it also means "the system checks price" may be true for one supplier and loose for another.

Charges. Microsoft compares invoice charges with the order only for charge codes where that comparison has been switched on. Freight, handling or licence fees on any other code reach the ledger without being compared to anything.

The rest of the table follows the same idea: every row has a record to check against and an action to take, so a failed check arrives with its own instructions. Our guides to invoice coding and the non-PO invoice cover the accounting-fields row and invoices with no order to compare against.

How the Invoice Validation Process Works

Validation runs in six steps, and the last one is the step most processes leave to chance.

1. Select the rules that apply to this invoice type, supplier and entity
2. Gather the evidence: the order, the contract, the receipt and the supplier record
3. Run the checks
4. Record each result, with the evidence and the version of the rule that produced it
5. Resolve what did not pass, through the owner each check names
6. Revalidate after any change that could affect a result

Steps one to five are what most people picture. A failed check puts a hold on the invoice. In Oracle, some holds can be released by hand, while others need the invoice or the purchase order corrected and validation run again, and an invoice on a matching hold cannot be paid until the hold is released. The hold does its job well. It stops money leaving while a question is open.

Step six is different, because whether it happens at all depends on a setting somebody chose. Microsoft recalculates matching each time an invoice is edited, unless the company has switched it to on demand. One of Oracle's batch options processes only the lines added since the last run and skips invoices already on hold. Both are reasonable choices for performance. Both also mean a team can believe everything gets rechecked when part of it does not.

The fix is to treat every result as belonging to a particular moment. Record which version of the invoice was checked, against which evidence, under which rule. A change then shows you which results it reopens, so you rerun those instead of everything or nothing.

Invoice Validation Example: One Invoice, Several Results

One invoice can pass some checks, fail another, and have a third reopened by a later change, so "is it valid?" has more than one answer.

Take a supplier invoice for 100 units at $100 each, $10,000 before tax. The figures are illustrative. The purchase order agrees on both quantity and price. The receiving record shows 80 units, and company policy requires a receipt for this kind of purchase.

The receiving team confirms that the other 20 units arrived and were never booked in. They record them, and only the receipt check runs again. It passes, and the hold comes off. Oracle's documentation walks through the same pattern: an invoice billing 6 units against 5 received goes on hold, the warehouse records the remaining receipt, and validation is resubmitted to release it.

Now add one more event. A week later, the supplier sends a replacement invoice with new bank details. The price check and the receipt check say nothing about whether those details are genuine. They answered different questions, about a different version of the document. The change goes to the supplier-change process, with its independent callback, and inherits nothing from the earlier passes. Our approval workflow guide sets out why bank-detail changes sit on its list of invoices never to auto-approve.

The lesson of the example is small and practical. Each check supports one conclusion, and a change reopens only the conclusions it touches. A single "validated" flag on the invoice would have hidden all of that. Receipt mismatches and tolerances are covered in depth in our guide to three-way matching.

Why Invoices Fail Validation, or Cannot Be Verified

A check can end in a real discrepancy, in no result at all, or in a pass that proves less than it appears to. Each needs a different response, and the third is the one that costs money.

A genuine discrepancy is the familiar case: a price variance, a receipt mismatch, a duplicate, a supplier nobody recognizes. These show up as holds, and our approval workflow guide sets out the seven exception types, who owns each one and how to fix them upstream.

A check that could not run is quieter. The receiving system was offline, the contract sits in a shared drive the workflow cannot reach, or the supplier record is missing a field. A missing record proves nothing about the supplier, and it also proves nothing in the supplier's favor. Four results keep that distinction visible:

These four are a recommended design, and each ERP has its own status names. The rule that matters is that "not verified" never becomes "passed" by default.

A pass that should not be trusted is the hardest to see, because nothing turns red. ERP documentation describes three ways it happens.

• A blank tolerance accepts everything. Oracle's documentation notes that a zero percentage tolerance allows no variance at all, while an active tolerance left without a value means "infinite variance is allowed." One empty field turns a price check into a formality.
• A comparison that is switched off never runs. Microsoft compares charges only for the charge codes where the comparison is enabled, so a charge on any other code passes without being checked.
• Each invoice passes, and the series fails. Microsoft's own example uses a purchase order line for 1,000 USB drives at $10.00, with a price-total tolerance of 15% or $500. Three invoices arrive at $10.80 a unit, and each one passes the unit-price check on its own. The third fails the price-total check only because that check counts the earlier invoices too: together they bill $11,880 against a $10,000 order line. A check that looks at one invoice at a time would have passed all three.

This matters because fraudulent invoices are built to pass, and the ACFE's 2026 Report to the Nations shows how often billing schemes succeed and how long they run before anyone notices. An inflated invoice from a familiar supplier, matched to a real order and with perfect arithmetic, clears every matching check on the list. The weight falls on the checks that ask different questions: is this supplier who it says it is, have we seen this invoice before, and did anyone change where the money goes?

What to Automate in Invoice Validation

Start with the checks your ERP already runs and how they are configured, then automate what sits outside them.

The earlier sections show how much the big systems already do. Oracle, Microsoft and SAP already validate tax, matching, periods, budgets and charges. Rebuilding those checks in a separate tool adds cost and a second source of truth without adding control. The useful first step is an audit with three columns: which checks run, how each tolerance and comparison is set, and which evidence never reaches the ERP at all.

That third column is where most of the hours go. A contract lives in a document system. A client's policy lives in a PDF. A service confirmation lives in someone's email. The ERP cannot check what it cannot see, so people bridge the gap by hand, invoice by invoice.

Codebridge starts every AP automation project with that three-column map. Most of the value sits in the last column: connecting a contract, a receiving record or a client's policy to the check that needs it, so the ERP's existing rules get the evidence they were designed for.

From there, the work divides three ways.

• Rules handle what is explicit: arithmetic, required fields, valid account combinations, configured tolerances, workflow conditions. Rules are predictable, testable and cheap to run
• AI-assisted steps handle interpretation and preparation: extracting details from a messy PDF, linking an invoice to the right contract, finding the clause that sets a rate, summarizing why an item needs review. Each output should carry its source and say how certain it is
• Authorized people handle judgment: disputed amounts, unclear tax or accounting treatment, policy exceptions and supplier changes

One control belongs in any automation that fills gaps in an invoice. Keep four facts side by side: what the invoice said, what another source supplied, which source it was, and who accepted the change. Without that record, a well-meaning system can correct an invoice field by field until it passes, and nobody can later tell which values came from the supplier. Our AP automation guide covers how these decisions fit across the wider AP process.

How to Test Whether Invoice Validation Is Working

Test validation the way you would test any control: feed it invoices that should fail, and cases where the evidence is missing, then see what it does.

This is a different test from choosing software. Our AP software comparison uses a seven-invoice test to choose a product. This one checks whether the rules you have configured behave the way you believe they do.

The last two come straight from the failure modes above, and they tend to surprise people. A tolerance left blank by an implementation consultant years ago can sit unnoticed until someone runs this test.

Measure the results with numbers that reveal weaknesses: known errors missed, unnecessary holds, checks that could not run, handling time per exception, and whether relevant changes triggered revalidation. A touchless-processing rate is worth tracking too, and on its own it hides the first and third of those numbers, since an invoice that skipped a check also skipped a human.

Invoice Validation for Accounting Firms Running Client AP

A firm running AP for clients validates against each client's rules and records, and for clients it also audits or reviews, the approval that follows belongs to the client.

The same check needs different settings for different clients. One client allows recurring utilities without a purchase order. Another requires a receipt for every purchase. Tolerances, approvers and acceptable evidence all vary, so a firm's validation runs on one rule set per client, applied to that client's data and nothing else.

The line between the firm and the client is set by the AICPA's independence rules. Approving vendor invoices for payment is among the activities that impair a firm's independence for a client it audits or reviews. Validation is work the firm can do. It runs the checks, investigates what fails, and proposes the fix. The client's designated person approves.

The location of those results matters as well. Under the AICPA's hosting interpretation, a firm that takes responsibility for hosting an attest client's data or records impairs its independence. Validation results, and the evidence behind them, belong in each client's own system of record. Our guide to vendor statement reconciliation sets out these rules in full.

Codebridge builds validation workflows for accounting firms that run AP for many clients: one rule set per client, results recorded in each client's own system, and every exception routed to the client's designated approver.

How Codebridge Builds Invoice Validation Workflows

Codebridge's AP invoice resolution workflow, described on our professional services page, reads invoices, matches them to the ledger, runs bookkeeping checks and routes exceptions for approval.

Built around an ERP's existing validation, it adds the evidence and rules the ERP cannot reach on its own, and it records what each check passed, failed or could not verify. The ERP stays the system of record, and approval stays with the people who hold the authority. The company owns the repository, the prompts and the configuration from day one.

The closest reference we can offer, labelled for what it is: Knowledge Cloud, built for a Big Four tax and legal practice, runs an expert review queue with an immutable audit log, so a senior practitioner approves each output before the firm acts on it. A knowledge platform rather than an AP system. It demonstrates the review and approval-record pattern.

Our founding team spent more than a decade at KPMG.

Which invoice checks are still happening outside your accounting system? Book a 30-minute call, and we will help you find out whether the gap is configuration, missing data, or a workflow that needs building.