Does Epicor Kinetic check invoices against contract terms?

Executive Summary

Kinetic's AP module runs two-way or three-way matching: invoice against PO, and where configured, against the receipt. That control catches a quantity mismatch or a unit price typed differently from the PO line. It is a real control, and it stops a specific class of error before payment.

It is not a contract compliance control. A vendor rate card with volume tiers, a surcharge schedule with an expiration date, a not-to-exceed cap, or a rebate clause are terms that live outside the PO line item Kinetic matches against. If the PO itself was cut at the wrong rate, or the contract term changed after the PO was issued, three-way matching approves the invoice cleanly because it never tests the contract, only the PO.

That is the mechanism behind margin drift on an ERP that is otherwise working exactly as designed. Closing the gap means testing invoices against the contract terms themselves, not just against the PO Kinetic already holds.

1. What does Epicor Kinetic actually check on an invoice?

Epicor Kinetic's AP module checks an invoice against the purchase order and, where three-way matching is configured, against the goods or service receipt. It confirms the quantity billed matches the quantity ordered and received, and that the unit price on the invoice matches the unit price on the PO line. Tolerance thresholds can flag or block a mismatch.

That is the full scope: PO, receipt, invoice line. Nothing outside those three records is tested.

Three-way matching is a document-matching control, not a contract-reading one. It compares fields that already live inside Kinetic: the PO number, the line item, the quantity, the unit price. When those three documents agree, the invoice clears for payment automatically or with minimal review.

The control works well for what it was built to catch: a keyed-in quantity error, a unit price that drifted from the PO at data entry, or an invoice submitted against the wrong PO. Those are structured discrepancies between records Kinetic already owns.

What it cannot do is check whether the PO itself reflects the correct contract rate. If procurement cut the PO at an old price, or a volume discount tier was never applied, matching passes cleanly. The invoice agrees with the PO. The PO is simply wrong.

2. Why does a clean three-way match still allow contract drift?

A clean three-way match only proves internal consistency: the invoice agrees with the PO and the receipt. It says nothing about whether the PO reflects current contract terms. A rate card update, a rebate tier crossed mid-year, or a surcharge that should have expired are all invisible to matching because none of those terms are fields the PO carries.

The invoice can match perfectly and still overbill against the contract.

A purchase order is a snapshot, written once, of what someone believed the price should be. A contract is a living document with tiers, dates, and conditions attached. The two drift apart the moment either one changes and the other does not get updated.

Take a volume tier. A contract might state that spend above a threshold earns a lower unit rate for the rest of the term. Kinetic has no field for cumulative spend against a rebate tier. The PO carries whatever rate was entered when it was cut, and matching checks the invoice against that number, not against the tier the vendor should now be applying.

A surcharge with an expiration condition behaves the same way. The PO line for a surcharge stays open until someone manually removes it, and matching has no mechanism to test whether the condition that justified the surcharge still holds.

3. What contract terms sit outside Kinetic's matching logic?

Rate cards with volume tiers, rebate clauses, not-to-exceed caps, and surcharge schedules tied to a condition or date all sit outside what a PO line item captures, and therefore outside what Kinetic's matching logic tests. These terms live in the contract document, often a PDF, not in a structured ERP field. Testing an invoice against them requires reading the contract directly and comparing it to the invoice line by line, a step matching does not perform.

These four categories share one trait: they are conditional. A volume tier depends on cumulative spend. A surcharge depends on a date or an index. An NTE cap depends on total billed-to-date against a ceiling. Matching logic compares fixed fields on fixed documents; it was not built to evaluate a running condition against an external contract clause.

That is not a flaw specific to Kinetic. It is true of ERP matching generally, because the contract was never entered as structured data the ERP can query. The rate card sits in a PDF a vendor emailed two years ago.

A. Rate cards and volume tiers

A rate card defines pricing by category, and a volume tier drops the rate once cumulative spend crosses a threshold. Kinetic has no native field that tracks spend-to-date against a tier boundary, so the PO price stays static even after the contract's own terms say it should change.

B. Rebate clauses

Rebates are typically calculated and issued outside the transactional flow entirely, often on a schedule set by the vendor. Nothing in the invoice-to-PO match tests whether an earned rebate was applied as a credit or simply left unclaimed.

C. Not-to-exceed caps and surcharge schedules

An NTE cap limits total billing on a labor or service line regardless of hours logged. A surcharge schedule ties an added charge to a condition, a fuel index level, a date range, that Kinetic does not evaluate. Both require reading the contract document itself, not the PO.

4. Can Kinetic be configured to close this gap?

Kinetic can be configured to tighten PO accuracy, add approval tolerances, and enforce stricter three-way matching rules, all of which reduce data-entry error. What configuration cannot do is turn a PO field into a contract clause. Closing the gap between contract and invoice requires either manually re-keying every rate card, tier, and expiration condition into the ERP and maintaining it as contracts change, or testing invoices against the contract separately from the ERP's matching flow.

Kinetic administrators can add price tolerance thresholds, require secondary approval above a dollar amount, or block payment until a receipt exists. These settings improve control over what the ERP already tracks. They do not add contract awareness the system was not built to hold.

Some teams attempt to encode rate cards into PO templates or item master pricing, updating them each time a contract changes. That approach works only as long as someone catches every amendment, every tier crossing, and every surcharge expiration, and updates the corresponding PO data before the next invoice arrives. In practice, contract terms change on a different cadence than someone remembers to update the ERP, and unstructured PDF terms, rebate schedules and NTE language among them, resist being reduced to a PO field at all.

5. How would a company confirm whether drift exists in its Kinetic data?

Confirming drift means pulling paid invoices from Kinetic and matching each line against the actual contract document, not the PO, for a sample of service vendors over a recent period. Compare invoiced rate to the rate card, check whether volume tiers were applied, and check surcharge lines against the condition that justifies them. A clean three-way match in Kinetic tells you the PO and invoice agree with each other; it does not tell you either one agrees with the contract.

Start with vendor categories where contract terms carry the most conditional logic: freight and 3PL surcharges, contract labor NTE caps, and maintenance agreements with tiered rates. These are the categories where a PO field is least likely to reflect a rate card update.

Pull twelve to eighteen months of paid invoices for a sample of vendors in those categories, then lay each invoice line next to the governing contract clause. A rate schedule violation, a surcharge that outlived its trigger condition, or a rebate that was never credited all show up the same way: the invoice matched Kinetic's records and still charged the wrong amount.

This kind of review is what a margin drift diagnostic does as a fixed-scope engagement, working from the contract and the invoice history together rather than from ERP matching alone.

6. Should a company add a separate control on top of Kinetic?

Yes, where service vendor contracts carry tiers, caps, or surcharge conditions Kinetic cannot evaluate. Kinetic's matching and a contract compliance layer are complementary, not redundant: matching stops PO and receipt errors before payment, while a contract-aware review catches drift that a clean match cannot see. Whether that layer is a one-time retrospective audit or an ongoing check depends on how much of the vendor base carries conditional pricing terms.

A company with mostly fixed-price, simple-catalog vendors gets less benefit from a contract layer, because there is little conditional logic for matching to miss. A company running significant freight, contract labor, or maintenance spend under tiered or capped contracts carries more exposure, because those are exactly the terms matching cannot see.

The two controls test different things and neither substitutes for the other. Matching verifies internal document consistency inside the ERP. A contract compliance review verifies the ERP's own records against the outside document that should govern them, the contract itself.

For the wider pattern this sits inside, start with the margin drift guide. See also the Margin Drift Diagnostic and our insights.

7. Frequently Asked Questions (People Also Ask)

Does Epicor Kinetic support three-way matching?

Yes. Kinetic can match an invoice against its purchase order and, where configured, against the goods or service receipt, checking quantity and unit price agreement across the three documents before releasing payment.

Will Kinetic catch a duplicate invoice payment?

Kinetic's AP controls can flag a duplicate invoice number or reference against the same vendor and PO. That check operates on document identifiers already inside the ERP, separate from whether the underlying rate is correct.

Can Kinetic read a vendor's rate card automatically?

No. A rate card is typically an external document, often a PDF, and Kinetic has no native capability to ingest and evaluate it against invoice lines. Any rate card terms have to be manually entered into PO or item pricing and kept current.

Does a clean PO match mean the invoice is contract-compliant?

No. A clean match confirms the invoice agrees with the PO and receipt already in Kinetic. It does not confirm the PO itself reflects the correct contract rate, tier, or condition, which is a separate check against the contract document.

What vendor categories are most exposed to this gap in Kinetic?

Categories with conditional pricing, freight and 3PL surcharges, contract labor with not-to-exceed caps, and maintenance agreements with tiered rates, carry terms that a PO field does not capture, so they are where a PO-to-contract mismatch is most likely to persist unnoticed.

Can Kinetic be customized to track rebate tiers?

Some teams build custom fields or reports to approximate tier tracking, but this requires manual setup and ongoing maintenance as contracts change. Kinetic has no native rebate-tier engine, so any tracking is a workaround rather than a built-in capability.

Is this a Kinetic-specific limitation?

No. Matching logic in ERP systems generally compares structured fields already inside the system, PO, receipt, invoice, rather than reading contract documents. The gap between PO data and contract terms exists wherever pricing conditions are not re-entered as structured ERP data.

How do we find out if this has already cost us money?

Pull paid invoices for service vendor categories with conditional contract terms over the last 12 to 18 months and compare each line to the governing contract clause rather than to the PO. A margin drift diagnostic does this work as a fixed-scope engagement.

Does adding tolerance thresholds in Kinetic fix this?

Tolerance thresholds catch a PO-to-invoice mismatch above a set amount, which reduces data-entry error. They do not test whether the PO price itself reflects the current contract, so they narrow one problem without addressing the other.

Do we need to replace Kinetic to close this gap?

No. The diagnostic and matching serve different purposes and can run alongside each other. Kinetic continues handling document matching; a separate contract compliance review or ongoing control addresses the terms matching was never built to evaluate.