Reporting invoice exceptions in Epicor Kinetic

Executive Summary

Epicor Kinetic reports invoice exceptions through AP workbench variance queues, the three-way match hold report, and Business Activity Queries built against the APInvHed and APInvDtl tables. These tools flag quantity, price, and tolerance mismatches against the purchase order. They do this reliably for goods invoices where a PO line carries the agreed unit price.

Service vendor invoices break that model. A freight invoice can match its PO for the base linehaul charge and still carry an accessorial fee, a fuel surcharge past its expiration date, or a minimum-charge violation that no PO line ever encoded. Kinetic's exception logic has nothing to compare those charges against, because the contract terms live in a PDF outside the ERP, not in a field the match engine reads.

The practical answer is to use Kinetic's native exception reporting for what it does well: catching PO and receipt mismatches, quantity variances, and duplicate invoice numbers. For contract-term violations, the reporting has to happen against the contract itself, either through a manual review process or a system that ingests the rate card and tests each invoice line against it.

1. How does Epicor Kinetic flag an invoice exception by default?

Kinetic flags an invoice exception when the invoice fails three-way match: the invoice quantity or price differs from the purchase order or the goods receipt beyond a configured tolerance. The AP workbench holds the invoice, and the variance appears in the match exception report with the PO line, the receipt line, and the dollar difference. This process runs on structured PO data, so it only catches what the PO itself recorded.

The match runs at the line level. A price variance beyond the tolerance percentage set in company configuration puts the invoice on hold automatically, and the AP clerk sees it in the workbench queue with a reason code.

Quantity variances work the same way: invoiced quantity against received quantity, with a tolerance band before the system stops the invoice. Both checks assume the PO line is the source of truth for what should have been charged.

For a service invoice, that assumption often does not hold. Many service POs are issued as a blanket amount or a not-to-exceed ceiling rather than a unit price per line, so the match engine has little to compare against beyond the total.

2. Where does three-way match stop working for service vendor invoices?

Three-way matching checks the invoice against the purchase order and the receipt. It does not test a surcharge's expiration date, a rate card tier that changed with volume, or a rebate clause that should have reduced the invoice total. A service invoice can pass match cleanly on quantity and unit price while still charging a fee the contract does not permit, because that fee was never represented as a PO line.

A freight invoice is the clearest case. The linehaul charge might match the PO exactly, while an accessorial charge, a residential delivery fee, or a fuel surcharge calculated off a stale index rides along on the same invoice untouched by the match logic.

Contract labor invoices show the same pattern with markup rates and overtime multipliers. Maintenance and calibration invoices show it with rates that should have stepped down after a contract renewal but did not.

None of this is a failure of Kinetic's match engine. It is doing what it was built to do: compare the invoice to the PO and the receipt. The rate card, the surcharge schedule, and the NTE cap sit in a contract document the match engine never reads.

3. What tools inside Kinetic can build a broader exception report?

Three native paths exist inside Kinetic for building invoice exception views beyond the standard workbench: Business Activity Queries against the AP invoice tables, SSRS reports run against the same data, and Kinetic's dashboard tiles built on a BAQ. All three read what is already in the ERP: invoice header and detail, PO reference, vendor ID, and GL distribution. None of them can test a condition that is not stored as structured data somewhere in Kinetic.

A BAQ built against APInvHed and APInvDtl can group invoices by vendor and flag totals that exceed a threshold, surface invoices with no PO reference, or list invoices paid against the same PO number twice, which catches a real share of duplicate payment exposure.

SSRS reports layered on the same query give a scheduled version of the same view, useful for a monthly AP recovery audit pass rather than a real-time hold.

What none of these three paths can do is evaluate a rate against a contract, because Kinetic has no field for the contract's rate card, surcharge schedule, or rebate terms. Building that comparison means loading the contract terms into Kinetic as reference data first, which is a project most AP teams do not take on for every vendor.

4. What does a contract-aware exception report actually require?

A contract-aware exception report needs three inputs a standard Kinetic BAQ does not have: the contract's rate card and its effective dates, the surcharge and accessorial schedule with expiration conditions, and the NTE or minimum-commitment terms by vendor. Once those are captured as structured reference data, each invoice line can be tested against the matching clause rather than only against the PO.

The work is mostly data entry rather than software configuration. Someone has to read each service contract, pull out the rate table, the surcharge conditions, and any volume tier or rebate trigger, and put it somewhere Kinetic or a connected tool can reference it line by line.

1. Rate card capture: The approved unit rate for each service line, with its effective date range, so a rate change mid-contract does not slip through unnoticed.
2. Surcharge and accessorial terms: Which fees apply, under what conditions, and when a fuel surcharge or index-based charge should have reset.
3. NTE and minimum commitment caps: The ceiling an invoice should never cross and the floor a vendor is guaranteeing, both of which sit outside a standard PO line.

5. Should AP build this exception logic in Kinetic or run it separately?

Kinetic can hold the contract reference data and the exception query if AP is willing to maintain it as vendor contracts renew, which is real ongoing work. Running the comparison outside Kinetic, against exported invoice data, avoids customizing the ERP but adds a reconciliation step. Neither answer is free: the question is which team already owns contract updates and whether they will keep the reference data current.

Building inside Kinetic keeps the exception report next to the invoice data it references, and a BAQ-based dashboard can flag a hold before the invoice posts. The cost is that every contract renewal, rate change, or new vendor requires someone to update the reference tables, and that maintenance tends to lapse once the person who built it moves on.

Running the check separately, against an export of invoice and PO data, keeps the ERP untouched and lets a dedicated review focus purely on contract terms. The tradeoff is timing: a separate process usually runs after the invoice has already been paid, which turns prevention into recovery.

For a first pass, a retrospective review of 12 to 18 months of invoices against contract terms shows where the actual exposure sits before deciding how much ongoing exception logic is worth building.

6. How does this connect to a broader margin drift review?

Invoice exception reporting inside Kinetic and a full margin drift review answer different questions. Kinetic's exception queue asks whether an invoice matches its PO. A margin drift review asks whether the PO, the invoice, and the underlying contract agree with each other, across freight, contract labor, maintenance, and professional services invoices going back over a defined period, line by line.

The two are complementary rather than competing. Kinetic's native reporting, once tuned with BAQs and dashboard tiles, is the right place to catch duplicate payments, missing PO references, and straightforward quantity variances on an ongoing basis.

A contract compliance pass answers the harder question: whether the rates, surcharges, and caps Kinetic never checked were honored across the invoices that already cleared. That review reads the contract, builds the reference data Kinetic does not hold, and tests every line against it rather than only the lines a PO happened to cover.

For manufacturers running Epicor Kinetic, the freight and 3PL category is usually where this gap shows up first, because accessorial and surcharge logic is the least likely to be captured as a PO line in the first place.

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 a built-in contract compliance module?

Kinetic's native functionality centers on purchase order and receipt matching, not contract term enforcement. There is no standard module that reads a rate card, surcharge schedule, or rebate clause and tests invoices against it. That comparison has to be built as custom reference data and queries, or run outside the ERP.

Can a Business Activity Query catch a duplicate payment in Kinetic?

Yes. A BAQ grouping AP invoices by vendor, PO number, and invoice amount can surface invoices that look like repeats, which is one of the more reliable exception checks Kinetic's own tables support without any contract data added.

Why does a freight invoice pass three-way match but still overcharge?

Three-way match compares the invoice to the PO and the receipt. A fuel surcharge, accessorial fee, or minimum charge is often not represented as its own PO line, so the match engine has nothing to compare it against and the invoice clears even when the fee violates the contract.

What data does AP need before it can report on rate card violations?

The vendor's approved rate table with effective dates, the surcharge and accessorial conditions, and any NTE or minimum commitment terms, captured as structured data Kinetic or a connected tool can reference against each invoice line.

Is a manual spot check enough to catch contract compliance exceptions?

A spot check finds some violations but not the pattern behind them, and it does not scale across freight, labor, and professional services invoices at once. A line-by-line review against the full contract set finds recurring violations a sample would miss.

Should we build contract exception logic inside Kinetic or use a separate review?

It depends on who owns contract updates. Building inside Kinetic catches issues before payment but requires someone to maintain the reference data as contracts renew. A separate periodic review avoids ERP customization but runs after invoices are already paid.

Does fixing the exception report stop drift from recurring?

A report only flags what has already happened. Preventing recurrence requires the underlying rate and surcharge data to stay current as contracts renew, which is a process commitment separate from the reporting tool itself.

How far back should an invoice review go to find contract violations?

Reviewing 12 to 18 months of historical invoices against contract terms, across ValueXPA diagnostics, gives enough volume to see whether a violation is a one-time error or a standing gap in how invoices are checked.