How do you audit vendor invoices in Epicor Kinetic?

Executive Summary

Kinetic's three-way match compares an invoice, a purchase order, and a receipt line, and it does this well. The system flags a quantity mismatch or a price that differs from the PO price. What it cannot do is evaluate a contract term that never entered Kinetic as structured data: a volume tier, a rebate clause, an NTE cap, or a surcharge schedule that lives in a signed PDF in a vendor file, not in a Kinetic price list.

The mechanism that causes drift is simple. A vendor's rate changes, a surcharge that was supposed to expire persists, or a volume threshold is crossed and the tier discount never gets applied to the PO price Kinetic is matching against. The invoice can match the PO exactly and still be wrong, because the PO price itself was never updated when the contract term changed upstream of Kinetic.

What changes this is treating contract terms as a separate, standing input to the audit, checked against invoices directly rather than through the PO. That can be done as a one-time retrospective diagnostic across service vendor spend, or built as a continuing control once the categories and rules that matter to a given plant are known.

1. What does Kinetic's AP module actually check on an invoice?

Kinetic's accounts payable module runs a three-way match: it compares the invoice line to the purchase order line and to the receipt line for quantity and unit price. If those three agree, the invoice is approved for payment. The match is a data comparison inside Kinetic's own tables.

It has no mechanism for reaching outside those tables to test the PO price itself against a signed contract, a rate card, or a rebate schedule that was never keyed into Kinetic.

This is a deliberate design choice, not a gap in the software. Three-way matching exists to stop a vendor from billing more than what was ordered and received. It answers that question reliably across every module version.

The question it does not answer is whether the PO price was correct in the first place. If a freight carrier's fuel surcharge should have stepped down after a rate renewal and nobody updated the PO template, Kinetic will match the invoice against the stale PO price every time and approve it.

The contract itself, the document defining what the rate should be, sits outside Kinetic entirely. It lives in a vendor management file, an email thread, or a shared drive. Nothing in the AP workflow reads it.

2. Where does a contract term live if it is not in Kinetic?

Contract terms that drive margin drift, rate cards, volume tiers, rebate clauses, surcharge schedules, and not-to-exceed caps, typically live as unstructured text in a signed PDF or an email negotiation outside the ERP. Kinetic's price lists capture a snapshot of the negotiated rate at setup time. They do not capture the conditions attached to that rate: when it steps down, when a rebate becomes due, or when a surcharge should expire.

Those conditions require someone to re-read the contract and.

A rate card sets a base price. The conditions around it, a volume tier that drops the price after a threshold, a rebate that is owed quarterly, a cap on total spend before a rate renegotiates, are usually written as prose clauses, not as fields a system can evaluate.

Epicor Kinetic has no field for a rebate clause and no workflow step that asks whether a volume threshold has been crossed this quarter. Someone has to read the contract, notice the trigger, and manually adjust a price list or flag an invoice for a rebate claim.

When that manual step does not happen, and there is no control that ensures it does, the rate card drifts away from what is actually being billed, and Kinetic keeps approving invoices against the stale number.

A. Rate cards and volume tiers

A rate card names a price for a unit of service. A volume tier changes that price once a threshold is crossed. Kinetic can hold a static price on a price list, but nothing evaluates cumulative volume against a tier boundary defined in the contract unless someone builds that check manually outside the system.

B. Surcharges and NTE caps

A surcharge schedule ties an extra charge to an index or a condition, and is meant to expire when that condition changes. A not-to-exceed cap sets a ceiling on total billing for a scope of work. Both require comparing the invoice against a condition Kinetic never stored, which is why they persist past their expiration undetected.

3. Why does an invoice pass three-way match and still overbill?

An invoice passes three-way match whenever it agrees with the purchase order and the receipt, regardless of whether the PO price itself is correct. If a vendor's contracted rate changed, a rebate went unclaimed, or a surcharge should have expired, the PO price was never updated to reflect it. The invoice then matches a wrong number exactly, clears without exception, and pays.

The match confirms internal consistency between three Kinetic records, not correctness against the contract that governs the rate.

Consider a maintenance vendor billed on a PO built from last year's rate. The vendor's invoice matches that PO precisely. Three-way match passes. Nothing in the workflow asks whether last year's rate is still the contracted rate.

The same pattern applies to a freight surcharge tied to a fuel index. The surcharge was set when fuel prices were high and was contractually due to step down. Kinetic's PO carries the original surcharge line, unaware that a condition in the carrier agreement changed the rate.

Three-way matching checks the invoice against the PO and the receipt. It does not test a surcharge's expiration condition, a rebate's accrual threshold, or a rate card's renewal date, because none of those conditions were ever loaded into Kinetic as a rule to test against.

4. Can Kinetic's own price list catch these gaps?

Kinetic's price list module stores a current negotiated price per vendor and item, and it will flag an invoice that deviates from that stored price. It cannot independently verify that the stored price is still the correct one under the contract, because updating the price list is a manual step that depends on someone reading the contract and re-entering the new number. If that update never happens, the price list becomes the wrong reference the audit checks against.

The price list is only as current as its last manual update. It has no connection back to the contract document that defines when a price should change.

This creates a specific failure mode: the control looks like it is working, because the invoice matches the price list, while the price list itself has quietly gone stale relative to the contract.

Closing this requires a separate check that compares the price list, and the invoices matched against it, back to the actual contract terms on a recurring basis. That check sits outside Kinetic's native workflow.

5. What does a contract-to-invoice audit add on top of Kinetic?

A contract-to-invoice audit reads the actual contract, rate card, or service agreement and compares its terms directly against invoice lines, independent of whatever price sits in Kinetic's PO or price list. It tests for rate schedule violations, surcharge persistence past an expiration condition, missed rebates, and not-to-exceed overruns. It complements Kinetic rather than replacing it: Kinetic still catches quantity and receipt discrepancies; the contract audit catches whether the underlying rate was ever right.

This is retrospective work by design. It looks at invoices already paid, typically across a recent stretch of history, and tests each one against the contract clause that should have governed it, not the PO price Kinetic happened to store.

The categories where this matters most in a Kinetic environment are the indirect service spend lines that rarely get renegotiated attention: freight and 3PL, contract labor, maintenance and repair, IT and professional services, MRO and Class C consumables, and calibration and safety compliance.

A diagnostic of this kind produces a finding list by vendor and category, plus a roadmap for which contracts need a standing control going forward, distinct from a one-time recovery exercise.

6. Should a Kinetic manufacturer build this check or buy it?

Building the check inside Kinetic means writing custom rules, in BAQs or an add-on module, for every rate card, rebate clause, and surcharge condition across every vendor category, and maintaining those rules as contracts renew. Buying a fixed-scope diagnostic means an outside team reads the contracts and matches them to invoice history directly, without requiring anyone to first model every clause as a Kinetic rule. Which is right depends on whether the manufacturer can already name which contracts are leaking.

If a controller can already list the specific vendors and clauses suspected of drift, a targeted BAQ or reporting rule inside Kinetic can test that narrow set going forward.

If the honest answer is that nobody knows which contracts have drifted, building rules first means guessing which rules to write. A rule built against the wrong assumption enforces the wrong assumption, indefinitely, without anyone noticing.

A diagnostic run first establishes which categories and vendors actually carry drift, using the contracts and invoice history that already exist, before anyone commits engineering time to Kinetic customization that may target the wrong vendors.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and what is margin erosion? causes and prevention for manufacturers.

7. Frequently Asked Questions (People Also Ask)

Does Epicor Kinetic do three-way matching automatically?

Yes. Kinetic compares the invoice, purchase order, and receipt line for quantity and price, and flags exceptions where they disagree. This runs as a standard part of the AP workflow and does not require add-on configuration for the basic match.

Can Kinetic check an invoice against a rebate clause?

No. A rebate clause is contract language, not a field in Kinetic. Kinetic has no native mechanism for tracking when a rebate accrual threshold is crossed or for flagging an invoice that should trigger a rebate claim.

Why did an invoice that matched the PO still overbill us?

Three-way match confirms the invoice agrees with the PO and receipt. It does not confirm the PO price is still the correct contracted rate. If the underlying contract changed and the PO price was never updated, a matching invoice can still be wrong.

What vendor categories are hardest to control inside Kinetic?

Indirect service spend categories carry the least structured pricing data inside Kinetic: freight and 3PL, contract labor and staffing, maintenance and repair, IT and professional services, MRO and Class C consumables, and calibration and safety compliance.

Do we need to replace Kinetic to fix this?

No. Kinetic's three-way match remains useful for what it does. A contract-to-invoice audit adds a separate check against the contract terms Kinetic never stored; it works alongside the existing AP workflow rather than replacing it.

How far back should a contract-to-invoice review look?

A diagnostic of this kind typically reviews leakage already embedded in 12 to 18 months of historical spend, across ValueXPA diagnostics, since that window usually captures at least one full rate renewal or surcharge cycle per vendor.

Is this the same as a duplicate payment audit?

No. A duplicate payment audit checks whether the same invoice was paid twice inside AP records. A contract-to-invoice audit checks whether the rate billed on a single, non-duplicate invoice actually matches the contract terms behind it.

Can a BAQ in Kinetic replace a contract audit?

A BAQ can test a specific rule once that rule is known, such as flagging invoices above a known rate ceiling. It cannot discover which rules should exist in the first place, which is what a contract-by-contract review establishes before any BAQ is built.

Who should own this check, AP or procurement?

The contract terms usually originate with procurement, while the invoice matching happens in AP. Because the drift sits at the boundary between the two, a review typically needs someone with visibility into both the signed contract and the Kinetic transaction history.