Invoice-to-PO Matching When Suppliers Use Different SKUs

The invoice line reads "BTL20-NV, 300 @ $6.00." The purchase order line reads "20 oz bottle, navy, 300." Anyone who has worked in promo accounts payable can see these are probably the same thing, and that "probably" is exactly the problem. A 20 oz navy bottle from one supplier can come in stainless or plastic, and the same short code can mean a different product in another supplier's catalog.

Reading the invoice is the easy part now. Software can pull the lines off a PDF quickly, but pulling text off a page isn't the same as verifying it for accounting. The harder work is deciding whether each billed line really corresponds to something you ordered, at the quantity and price you agreed, with charges you approved.

When a supplier's SKU differs from the PO, establish product identity first through an approved supplier-specific crosswalk or an explicit shared reference. Then compare quantities, units, prices, charges, and any required receipt evidence separately. A likely text match can suggest a candidate, but it shouldn't clear the invoice for posting or payment.

Keep the original before you clean it up

Retain the original file and capture the supplier, invoice number, invoice date, currency, PO references, line items, taxes, freight, fees, and total. Keep the supplier's exact item text beside any standardized version, because the original wording is what a reviewer will need when a match looks wrong.

Check the arithmetic separately from the interpretation. Recalculate quantity times unit price, line extensions, credits, and the invoice total according to how the document is laid out. An invoice can add up perfectly and still bill for the wrong item, and it can point to the right order while containing an arithmetic error.

Run a duplicate check early using the vendor, invoice number, amount, date, and whatever document history you have. Normalize formatting for comparison, but keep the original identifier. Similar invoice numbers can belong to separate documents, and the same PDF resent under a new filename is still the same invoice.

Build a supplier-specific item crosswalk

A crosswalk records that one supplier's item identifier corresponds to a particular internal product and variant. Each entry should be scoped to the supplier and cover product, color, size or capacity, unit of measure, and effective dates where they matter.

The safest matches come from an approved crosswalk or a reference both sides share. Past descriptions can suggest candidates, but a suggestion should show why it's plausible and what is still uncertain. "Navy bottle" isn't enough to tell two capacities or two materials apart.

Store who approved each mapping and what evidence they used. When an AP reviewer resolves a new alias, that decision can become a proposed crosswalk update for someone to approve. It shouldn't quietly turn into a permanent rule for every supplier, since the same short code can mean different things in different catalogs.

Match merchandise and charges separately

Here's how one line plays out. Every identifier and amount below is made up.

That example shows the arithmetic and a proposed review path. It isn't an approved payable for a real business, and it isn't accounting advice.

Proof fees, additional imprint locations, rush charges, personalization, and drop-ship fees each deserve their own approved charge types. A vague line such as "service" should prompt a question about what was charged, not an automatic decision to code it as a general expense.

Keep track of one-to-many relationships too. A single PO line may be invoiced across several shipments, and several invoice lines may be size splits of one ordered product. The comparison has to track quantities already invoiced and credited, so that a valid-looking line can't use up the same ordered quantity twice.

Write the matching policy down

Decide which matching level applies before the first invoice runs. Oracle's procurement documentation describes two-way matching of PO and invoice quantities, three-way matching that adds receipt quantities, and four-way matching that adds accepted quantities from inspection, each within tolerance. Those controls compare quantities. They don't tell you that two different product codes are the same item, which is the crosswalk's job. See Oracle's match approval level options.

Set tolerances by field and charge type. A small rounding difference may be fine under a documented rule, while a new rush fee or changed bank details shouldn't inherit that tolerance. Specify absolute and percentage limits where they make sense, who can approve an exception, and whether several small differences on one invoice should be looked at together.

The workflow should show the rule it applied. "Within tolerance" only helps a reviewer who can see the amount, what it was compared against, and the approved threshold. Accounting and tax policy belong to your finance owners, and nothing here replaces their decisions.

Route exceptions to a person before anything is written

Decide in advance which results can move ahead on their own and which go to a person. A voucher whose lines map through approved crosswalk entries, fall within your documented tolerances, and carry no unapproved charges can advance under that policy. Anything flagged goes to a reviewer before it's written to accounting: a new item alias, a charge the PO didn't approve, a line that could pair with two PO lines, a missing quantity, or a value read at low confidence. Flag those cases rather than guessing at them, and for each flagged voucher show the reviewer exactly what will be written: the matched PO lines, coding supplied by approved rules, tax treatment, attachments, partial quantities and credits, and the exception that stopped it.

Recheck the current PO and invoice history right before submitting, since another employee may have entered the same invoice while the workflow was running. Confirm what duplicate controls and retry behavior your accounting system actually supports, and don't assume a supplier's invoice number is unique everywhere.

If a write comes back with an uncertain result, look the transaction up before retrying. Once the record exists, verify its identifier and key totals. Creating a voucher is a separate step from authorizing payment, and the workflow should treat that boundary as fixed.

Use the exceptions to improve the process

Track false matches, duplicates caught or missed, unexplained charge differences, time spent on review, and corrections after posting. Sample invoices that looked clean as well as the ones that were escalated, because a high match rate can hide confident errors.

Over time, repeated exceptions point to the most useful fixes: a better crosswalk, clearer freight approvals, a charge dictionary for a particular supplier, or better receipt data. Each of those makes the process more consistent and gives any automation better evidence to work from. The standard to hold every prepared entry to is that someone can trace it back to the invoice, the order, and the policy that let it through.