How to build a mro rate card AP can check against

Executive Summary

MRO invoices pass three-way match on quantity and purchase order number, then post at whatever unit price the vendor entered, because no reference price exists to check the price field itself. On MRO spend the resulting gap accumulates quietly: fastener, safety and Class C items rarely carry a line-item rate card an AP clerk can open next to the invoice.

The mechanism is structural, not a training gap. Purchasing negotiates a catalog discount off list, procurement signs it, and the discount sits in a PDF or an email thread. AP systems match invoices against the purchase order, and the purchase order price is whatever the vendor's punchout or EDI feed sent that day.

Nothing forces the negotiated rate back into the reference AP actually checks against.

What changes it is building a rate card in the format AP can use at the moment of match, not the format procurement negotiated in. That means one file, one row per SKU or SKU family, an effective date range, and a tolerance band, sitting somewhere AP touches before the invoice posts. The rest of this page is the concrete steps to build that file and keep it current.

1. What does a usable MRO rate card actually contain?

A usable MRO rate card is a flat file with one row per SKU or SKU family: vendor item number, your item number if different, unit of measure, contracted unit price, discount percentage off list where that is how the contract is written, and an effective date range. Without unit of measure and an effective date, AP cannot tell a real overcharge from a case-versus-each mismatch or a rate that already expired.

Contracts for MRO categories are rarely priced as flat unit rates across the board. Many run as a percentage discount off a published list price that the vendor updates on its own schedule. Others carry tiered pricing by order quantity, or a blended rate for a kit versus its individual components.

A rate card that only captures the final negotiated number, with no note of which pricing method produced it, cannot be rebuilt when the vendor's list price changes.

Unit of measure deserves its own column, not an assumption. A vendor that ships gloves by the case and bills by the pair is not committing fraud; it is using its own catalog convention, and an AP clerk without the conversion documented will either reject a correct invoice or approve a wrong one.

The effective date range matters as much as the price itself. A rate card with no end date looks current forever, even after a renegotiation. Every row needs a start date and, once superseded, an end date, so AP can tell which price applied to an invoice dated six months ago.

2. Where do MRO rate cards break down before AP ever sees them?

MRO rate cards break down at the handoff between procurement, which negotiates in a contract document, and AP, which matches against a purchase order price populated by the vendor's own catalog feed. The contracted discount never gets loaded as a reference AP can query, so the PO price and the contract price can diverge for months without anyone comparing them side by side.

Procurement signs an MRO contract that specifies a discount schedule, a rebate threshold, or a fixed price list attached as an exhibit. That document is built for negotiation, not for lookup. It sits in a contract repository or an email thread, readable by a person but not queryable by an accounts payable system.

Separately, the vendor sets up a punchout catalog or an EDI price feed that populates the purchase order at the point of order. That feed reflects whatever the vendor's own systems say the price is, updated on the vendor's schedule, not the buyer's. Nothing in most AP workflows compares the punchout price against the signed contract price before the PO is cut.

Three-way matching then checks the invoice against the PO and the receipt. It confirms the invoice matches what was ordered and received. It does not test whether the ordered price matches the contracted price, because the contracted price was never loaded as a comparison point. The control exists; it is checking the wrong reference.

3. How do you build the first version of the rate card, step by step?

Pull every active MRO contract, extract SKU-level pricing into one spreadsheet, match each row to the vendor's actual item numbers, add unit of measure and effective dates, then reconcile the file against a sample of recent invoices before AP starts using it. Six concrete steps, in order, turn a folder of contracts into a checkable reference.

180 to 320 words of supporting detail is above, structured as the list.

1. Collect every contract: Gather every active MRO contract and price list, including verbal or email-confirmed pricing that has not been formalized. Anything not written down cannot be checked.
2. Extract SKU-level rows: Extract each priced item into rows: vendor item number, your internal item number, description, unit of measure, contracted price or discount method, effective start date.
3. Cross-reference item numbers: Match vendor item numbers against your own item master to catch cases where the same physical part has two different codes.
4. Add a tolerance column: Exact-match pricing rarely survives rounding or minor packaging variance; add a tolerance column now and set it using the method below.
5. Reconcile against recent invoices: Pull a sample of recent MRO invoices and run them against the draft rate card manually, line by line, before rolling it out. This catches unit-of-measure errors and missing SKUs before AP relies on the file.
6. Assign a file owner: Name an owner for the file itself, not just the process around it. A rate card with no named owner degrades within one price change cycle.

4. How should AP actually check an invoice against the rate card?

AP checks an invoice against the rate card by matching vendor item number and unit of measure, then comparing invoiced unit price to the contracted price within the tolerance band, flagging anything outside it before the invoice posts, not after. The check has to happen pre-payment, because a correction after posting requires a credit memo and a vendor who agrees to issue one.

The mechanical check is simple once the file exists: for each invoice line, look up the vendor item number, confirm the unit of measure matches, and compare the invoiced price to the contracted price for that effective date. Anything within tolerance passes. Anything outside it holds for review before payment.

Timing is the part that actually determines whether this control works. A check run after the invoice has posted only produces a list of things to dispute later, which depends on the vendor agreeing to issue a credit. A check run before posting, even a manual one against a spreadsheet, stops the overcharge from being paid at all.

Line volume also shapes which method fits. A vendor with a high count of small MRO SKUs is hard to check line by line every cycle without some automation, even a simple spreadsheet lookup formula. A vendor with a low line count can be checked manually indefinitely. Size the checking method to the vendor's line volume, not to a single company-wide policy.

5. How do you set a tolerance band instead of demanding exact-match pricing?

Set a tolerance band as a small percentage of unit price, wide enough to absorb rounding and minor packaging conversions but narrow enough to catch a real rate change, and apply it per category rather than as one number across all MRO spend. Fasteners tolerate a different band than calibrated instruments, because their unit prices and packaging conventions differ.

Exact-match pricing sounds like the safest control and produces the least useful list in practice. Rounding to two decimal places, small currency conversion differences, and vendor-side unit conversions all generate false flags that train AP to ignore the report entirely.

A percentage-based tolerance, applied per line, absorbs that noise while still catching a genuine rate change. The right percentage is a judgment your AP lead should make from the reconciliation sample pulled earlier: measure the actual variance on lines you already know priced correctly, and set the band just above that.

Different MRO subcategories warrant different bands. High-volume, low-unit-cost items like fasteners can tolerate a wider percentage band because the dollar exposure per line is small. Lower-volume, higher-unit-cost items like calibrated instruments or specialized tooling warrant a tighter band, because a percentage miss there carries real dollars.

Illustrative starting points for tolerance bands by MRO subcategory, to be recalibrated against your own reconciliation sample.

6. How do you keep the rate card current once it exists?

Keep the rate card current by tying updates to the contract renewal calendar, requiring procurement to submit a change file whenever a rate is renegotiated, and running a periodic reconciliation against a fresh invoice sample rather than trusting the file to stay accurate on its own. A file built once and never revisited returns to the same gap it was built to close.

Price file governance fails most often through silence rather than error: a contract renews with new pricing, and nobody updates the reference file AP checks against. Building the rate card is the smaller task. Keeping it synchronized with every renegotiation, index-linked adjustment, and vendor catalog update is the ongoing one.

The practical fix is to make an update to the rate card a required output of every MRO contract renewal, not a follow-up task someone remembers later. Procurement submitting a change file at signature time closes the gap at its source.

Commodity-linked pricing is a separate case. Some MRO categories, particularly machinery and general equipment components, move with published cost indexes rather than a fixed vendor list. The US Bureau of Labor Statistics Producer Price Index for machinery and equipment, general purpose (series WPU114), read 2026-09-05, showed an index value of 379.724 in July 2026, up 5.6% year over year.

A rate card for index-linked MRO categories should record which index a contract references and check that a vendor's stated increase actually tracks the published movement, rather than accepting an increase on the vendor's word alone.

For the wider pattern this sits inside, start with the margin drift guide. See also the three-way match gap: what your erp structurally cannot see and n-way invoice matching explained.

7. Frequently Asked Questions (People Also Ask)

Does a rate card need to cover every MRO SKU or just high-value ones?

Coverage should follow the same reconciliation sample used to set tolerance: start with SKUs that appear in your recent invoice sample, then expand. A card covering only the highest-dollar items still leaves the SKU-level pattern this guide describes uncovered on everything else.

Who should own the MRO rate card, procurement or AP?

AP needs to be the day-to-day user, since it runs the check before posting, but procurement holds the contract relationship and must submit updates at renewal. The file needs one named owner accountable for both sides staying synchronized.

What format should the rate card live in?

A flat file such as a spreadsheet or a simple database table works, as long as it has one row per SKU or SKU family with unit of measure and effective dates. The format matters less than whether AP can query it at the moment of invoice match.

How do you handle a vendor that changes its item numbers?

Cross-reference the new item numbers against your item master as soon as the vendor communicates the change, and update the rate card row rather than adding a duplicate. An unmapped new item number will otherwise pass through invoice matching with no reference price at all.

Can this approach work without any software beyond a spreadsheet?

Yes for vendors with a manageable line count; the check is a lookup and a comparison, which a spreadsheet formula handles. Vendors with a high SKU count benefit from automation, but the underlying method, one row per SKU with unit of measure and effective dates, is the same either way.

What happens to invoices that fall outside the tolerance band?

They should hold for review before payment rather than post automatically. A held invoice gets checked against the contract document and either approved at the contracted price or returned to the vendor for correction.

Should kits and bundles get their own rate card rows?

Yes. A kit priced as a blended rate needs its own row separate from its individual components, because checking the kit price against the sum of component prices will produce false mismatches if the contract prices the kit differently.

How often should the rate card be reconciled against invoices?

Tie reconciliation to the contract renewal calendar at minimum, and run an additional periodic check against a fresh invoice sample so drift introduced between renewals gets caught rather than accumulating silently.