Where contract terms live if you use Epicor Kinetic

Executive Summary

Epicor Kinetic enforces the PO. It checks that a vendor billed the price it quoted and that a receipt exists for the quantity invoiced. It has no field for a rebate threshold, a fuel surcharge formula, or a minimum volume commitment, because those terms do not belong to a single transaction. They belong to the contract as a whole, and Kinetic was not designed to hold contract-level logic.

The result is that contract terms end up in PDFs, email threads, and spreadsheets outside the ERP, disconnected from the invoices Kinetic approves every week. A surcharge can persist past its stated expiration date and clear the three-way match cleanly, because nothing in Kinetic tests the surcharge against the date in the contract.

Finding this gap does not require replacing Kinetic. It requires reading every active service contract against 12 to 18 months of invoice history and matching each line to the clause that governs it, a task that sits outside what any ERP module does. That comparison is what recovers the drift that Kinetic's own controls were never built to catch.

1. What does Epicor Kinetic actually control on a vendor invoice?

Kinetic's AP module controls three things well: that a purchase order exists, that a receipt confirms the goods or service arrived, and that the invoiced price matches the PO price within tolerance. This three-way match catches a vendor billing above its own quote or billing for something never received. It does not test whether the quoted price is still the correct price under the contract, because the contract's rate logic is not a field Kinetic stores or checks.

The three-way match is a transaction-level control. It compares three documents that all exist inside Kinetic: the PO, the receipt, and the invoice. Each one is generated or logged inside the system, so the match is fast and reliable for what it covers.

What it covers stops at the transaction. It does not ask whether the PO price itself was set correctly six months ago and never updated, or whether a volume tier should have dropped the rate last quarter. Those questions require a document the match never opens: the contract.

This is not a flaw in Kinetic. A three-way match was never designed to interpret a rebate clause or a surcharge expiration date. It was designed to confirm that a transaction is internally consistent, and it does that reliably.

2. Where do rate cards and volume tiers actually get stored?

Rate cards, volume tiers, and rebate schedules live in the contract document itself: a PDF or Word file negotiated with procurement or a category manager, stored in a contract repository, a shared drive, or an email attachment. Kinetic has no native structure for a tiered price schedule that changes based on cumulative volume, so the tiers are never entered as data the system can check an invoice against.

A vendor contract for freight or contract labor sets a base rate, then a schedule of discounts that apply once volume crosses a threshold. That schedule is written as prose or a table inside the contract PDF, not as a rule in any transactional system.

Kinetic's PO carries a single negotiated price at the time of order. It has no mechanism to track cumulative volume across a quarter and apply a tier retroactively, so if a vendor's own billing system does not apply the tier correctly, nothing downstream catches it.

The practical result is that the document holding the actual pricing rule and the system approving the invoice never talk to each other. Someone has to read both and compare them by hand.

3. Why doesn't the three-way match catch a stale surcharge or an expired NTE cap?

Three-way matching checks the invoice against the PO and the receipt. It does not test whether a surcharge's stated expiration date has passed or whether cumulative billing has crossed a not-to-exceed cap written into the contract. Both conditions require a date or a running total that lives in the contract text, not in any field the match compares, so an invoice can pass cleanly while still violating the agreement.

A fuel surcharge is often written into a freight contract with a start condition and an end condition, tied to a published diesel index crossing a threshold. Kinetic has no field for that index or that threshold, so it cannot test whether the surcharge should still be active on a given invoice date.

A not-to-exceed cap works the same way. It is a ceiling on cumulative spend over a defined period, not a per-invoice check. The three-way match evaluates one invoice at a time against its own PO, so a cap breached across several invoices produces no exception on any single one of them.

A. Surcharge persistence

A surcharge added under a temporary condition, a fuel spike, a capacity shortage, keeps appearing on invoices after the condition that justified it has ended. The PO price was set once; the surcharge rides on top of it as a separate line, and nothing in Kinetic checks that line against the date the contract says it should stop.

B. NTE cap breach

A not-to-exceed clause caps total billing for a project or a period. Kinetic approves each invoice against its own PO and receipt, one at a time, so a cumulative total that crosses the cap across several invoices never triggers an exception on any of them.

4. Should you build a workaround in Kinetic to track contract terms, or read the contracts separately?

A workaround inside Kinetic, custom fields, a side spreadsheet linked by PO number, can track a handful of contract terms for a handful of vendors. It does not scale to freight, contract labor, MRO, IT services, and calibration contracts at once, because each category has different clause structures. A periodic read of the contracts against invoice history, done as a defined project, catches what the workaround misses without permanently modifying the ERP.

Custom fields and side spreadsheets are a reasonable stopgap for a single high-value contract. A controller can track one freight rate card in a spreadsheet and reconcile it against invoices manually, and it works, until the contract renews with new terms or a second vendor is added with a different structure.

The workaround breaks down at scale because contract clauses are not uniform. A rebate clause in an IT services contract reads nothing like a volume tier in a freight contract, and a single spreadsheet template does not hold both without becoming its own maintenance burden.

A defined review of contracts against 12 to 18 months of invoice history, across categories, finds what accumulated while no one was watching. It is a project with a start and an end, not a new system to maintain.

5. How do you find drift that already happened before Kinetic ever flagged it?

Finding drift that already occurred means matching invoice history against the actual contract clause that governs each line, not against the PO price Kinetic already approved. This is a document-to-transaction comparison across categories: freight, contract labor, maintenance, IT services, MRO, and calibration. It surfaces duplicate payments, missed credit memos, unapplied rebates, and rate violations the three-way match had no way to test.

The invoice history sits in Kinetic already, approved and paid. The question is not whether those invoices matched their POs, they did, but whether the POs themselves reflected the current contract terms at the time.

That comparison requires pulling the contract document for each active vendor relationship and reading the specific clause, rate card, tier, or cap, against every invoice line in the relevant period. It is a line-by-line exercise, not a system query, because the contract terms were never entered as structured data anywhere.

Across these categories, the findings vary by contract and by how long a term has gone unchecked. A duplicate payment surfaces immediately once two invoices are placed side by side; a rebate that was never claimed can take longer to trace back to the clause that earned it. Either way, the review is what recovers a leak the three-way match had no way to see.

6. What changes once contract terms are matched against invoices going forward?

Once a contract's rate card, tiers, surcharge conditions, and NTE cap are read and documented as explicit rules, every future invoice can be checked against those rules, not just against the PO. This shifts the control from transaction-level, what Kinetic already does, to contract-level, which requires a forward enforcement layer built from the rules the diagnostic documents.

The diagnostic's output is not just a recovery figure. It is a documented rule set: this vendor's contract expires this surcharge on this condition, this vendor's rebate applies above this volume, this contract caps spend at this ceiling.

That rule set is what a forward control needs to check every new invoice against, rather than relying on someone remembering to re-read the contract at renewal. Kinetic keeps doing what it does well, matching POs and receipts. The contract-level check runs alongside it.

Whether that forward check is a manual quarterly review or a continuous system depends on invoice volume and how many active contracts a category carries. The diagnostic gives you the rules either way needs.

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 have any module for contract compliance?

No. Kinetic's procurement and AP modules cover POs, receipts, and the three-way match. There is no native module for storing rate cards, rebate tiers, surcharge conditions, or not-to-exceed caps as structured, checkable data.

Can a custom field in Kinetic hold a contract's NTE cap?

A custom field can store a static number, but Kinetic has no built-in logic to track cumulative spend against that number across multiple invoices over time. Someone still has to pull the running total and compare it manually.

Why does a duplicate payment get past Kinetic's three-way match?

The three-way match checks a single invoice against its own PO and receipt. Two separate invoices, each correctly matched to its own PO, can both pay for the same underlying charge without either one triggering an exception.

Does upgrading or reconfiguring Kinetic fix this gap?

No. The gap exists because contract-level terms and transaction-level records are different categories of data. Reconfiguring Kinetic changes how it handles transactions; it does not give the system a place to store and test contract clauses.

How far back should an invoice review go to find missed drift?

12 to 18 months of invoice history, across ValueXPA diagnostics, gives enough history to catch a surcharge that outlived its trigger or a rebate tier that was never applied, without the review becoming unmanageable.

Is a rebate clause typically written the same way across vendors?

No. Rebate clauses vary by category and by vendor: a freight rebate may trigger on volume, an IT services rebate on spend threshold, a labor contract on hours billed. Each has to be read on its own terms.

What happens to invoices Kinetic already approved once drift is found?

Confirmed overbilling, duplicate payments, or unapplied rebates identified in the review become a recovery claim against the vendor. Kinetic's own approval does not prevent a retroactive correction once the contract violation is documented.

Do we need to replace Kinetic to close this gap permanently?

No. Kinetic keeps performing the three-way match it was built for. Closing the gap means adding a contract-level check alongside it, not replacing the ERP or its existing controls.