# Where do contract terms live if you use Acumatica?

> Acumatica stores PO price and vendor defaults, not rebate tiers or NTE caps. Here is where contract terms actually sit, and what checks that gap.

Source: https://valuexpa.com/insights/where-do-contract-terms-live-if-you-use-acumatica
Publisher: ValueXPA (https://valuexpa.com)
Updated: 2026-10-22

---

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Acumatica users hit this gap in a specific spot: the fields that hold a price are well defined, and the fields that hold a contract's conditions mostly are not.

A vendor contract carries clauses Acumatica was never built to store: a volume tier that drops a rate after a threshold, a rebate that accrues quarterly, a surcharge that should have expired, a not-to-exceed cap on a labor line. Those live in PDFs, side spreadsheets, and someone's inbox, not in the ERP.

## Executive Summary

Acumatica's AP and Purchasing modules hold a purchase order price, a vendor record, and whatever a three-way match can confirm against a receipt. That is a real control, and it works for the thing it checks: does the invoice match the PO and the receipt. It was not built to test whether the PO price itself still reflects a rate card that changed months ago, or whether a rebate clause triggered and nobody claimed it.

The mechanism that causes drift is structural, not a defect in the software. Contract terms are conditional logic written in prose: "if volume exceeds X, rate drops to Y," "surcharge applies only while the fuel index exceeds Z." Acumatica's price and cost fields store a single current value, not a condition. Someone has to read the contract, decide whether the condition fired, and update the field by hand. Every step in that chain is a place the update can fail to happen.

What changes it is separating the two jobs cleanly. Let Acumatica do line matching against whatever price and PO data it holds, and run a second, deliberate check against the contract document itself, on a cadence that matches how often those documents actually change. Waiting for the ERP to surface a stale rate card on its own leaves the condition unenforced indefinitely.

## 1. What fields does Acumatica actually use to hold a vendor price?

**Acumatica stores price through Vendor records, Purchase Order lines, and optional Vendor Price/Cost Sheets that hold a single current unit price per item or non-stock service line. AP three-way matching then compares the invoice line to the PO line and the receipt. All three of these hold one number at a time. None of them stores why that number is what it is, what condition would change it, or when it was last checked against the source contract, so.**

The Vendor Price/Cost Sheet is the closest thing Acumatica has to a rate card, and for stocked items with stable pricing it works well. It holds an effective price per vendor per item, and it can carry a start date.

What it cannot hold is a condition. A rate card with a volume-tier discount, "$42/unit under 10,000 units, $38/unit above," needs someone to recognize the threshold was crossed and manually change the sheet. Acumatica will not notice on its own; it only knows the value it was given.

Non-stock service lines, which is where freight, contract labor, and professional services usually post, often skip the price sheet entirely and take whatever price is typed onto the PO line at the time it is cut. That is one more step removed from the contract.

## 2. Why doesn't three-way matching catch a stale rate or an expired surcharge?

**Three-way matching checks the invoice against the purchase order and the goods receipt. It confirms the vendor billed what was ordered and what arrived. It does not open the contract to check whether the ordered price is still the correct price, and it does not test time-bound conditions such as a surcharge that should have expired last quarter or a rebate threshold the year's cumulative volume already crossed. The match passes cleanly even when the underlying rate is wrong.**

This is not a configuration gap someone forgot to close. Three-way matching is a consistency check across three internal records: order, receipt, invoice. A contract is a fourth document, external to all three, and the match was never designed to reach it.

A surcharge is the clearest example. A fuel surcharge tied to a diesel index should turn off when the index drops below the contract's trigger. Nothing in Acumatica watches an external index or the surcharge clause's expiration condition. If the PO line still carries the surcharge, the invoice matches it every time, correctly, against a rate that is no longer contractually owed.

A rebate works the same way in reverse: it is owed to the buyer, not billed by the vendor, so no invoice line ever surfaces it for the match to catch at all.

## 3. Where does a not-to-exceed cap or a rebate clause actually get tracked?

**In practice, not-to-exceed caps and rebate clauses get tracked outside Acumatica entirely: in the signed contract PDF, in a procurement team's side spreadsheet, or nowhere formal at all, remembered by whoever negotiated the deal. Acumatica has no native field for an NTE ceiling on a labor engagement or a rebate accrual schedule, so there is no system location for either to live in unless someone builds one manually.**

A not-to-exceed cap on a staffing or professional services contract sets a ceiling on cumulative billing for a project or period. Testing it requires summing every invoice against that vendor and that engagement since the cap's start date, then comparing the running total to the ceiling. Acumatica can produce the invoice history; it will not compute the comparison against a cap it was never told existed.

### A. Where NTE caps typically end up

Most commonly in the signed statement of work itself, referenced only when someone remembers to pull it back out. A minority of teams keep a manual tracker, usually a spreadsheet, that someone updates after each invoice posts. Neither location talks to Acumatica.

### B. Where rebate terms typically end up

Rebate clauses sit in the master service agreement or a rebate addendum, often with a quarterly or annual accrual schedule. Claiming a rebate requires proactively invoicing or crediting the vendor; Acumatica has no mechanism that prompts that step when a threshold is crossed.

## 4. Can a custom field or generic inquiry close this gap inside Acumatica?

**Acumatica's customization tools, custom fields on the vendor or item screens, generic inquiries, and workflow rules, can store a condition once someone writes it in and can flag a simple threshold breach. What they cannot do is read a contract PDF, interpret a rebate clause's language, or update itself when the contract is renegotiated. The gap moves from missing storage to a maintenance task, and maintenance tasks compete with other AP priorities for attention.**

A custom field for "NTE cap" and a generic inquiry that sums invoiced amounts against it is a genuinely useful build. It gives the system somewhere to hold the number and a report that flags when cumulative billing approaches it.

The work that does not go away is getting the number into that field correctly the first time, and updating it every time the contract changes. That is a manual, one-time-per-contract task, done by a person reading the document. If the field is never created for a given vendor, or the update is missed when the contract renews at a new cap, the customization protects nothing.

This is the same underlying limit as the price sheet: Acumatica can hold a value faithfully once given one. It cannot extract that value from a contract on its own.

## 5. Should a company on Acumatica build this tracking in-house or run a separate audit?

**Building custom fields and inquiries inside Acumatica works for a small, stable set of terms an internal team can maintain over time. It works less well for a full contract portfolio, because every new vendor, renewal, and clause type adds another manual entry point that has to be built and kept current. A periodic audit against the actual contract documents, run independently of the ERP, tests the whole portfolio without depending on prior customization work.**

The decision hinges on how many contracts carry conditional terms and how often those terms change. A handful of stable vendor agreements can reasonably be tracked with custom fields inside Acumatica, maintained by whoever owns AP.

A broader indirect spend book, freight, contract labor, maintenance, IT services, with dozens of vendors and rate cards that renew on staggered schedules, outgrows manual field maintenance quickly. Each renewal is a fresh chance for the field to go stale.

An audit run against the contract documents directly does not require the customization to already exist. It reads the actual PDFs and compares them to what was billed, which is the same comparison Acumatica's fields would need updating to perform, done once, on demand, without carrying the ongoing maintenance burden.

## 6. What does a company on Acumatica actually need to check first?

**Start with the vendor categories where conditional terms are common and the volume is high enough to matter: freight and 3PL contracts with tiered or fuel-indexed pricing, and contract labor or professional services engagements with NTE caps. Pull the current signed contract for each, list its conditions in plain terms, and compare those conditions against the last several invoices and the current PO price. That comparison shows directly whether Acumatica's stored price still matches the contract.**

This is a scoping exercise, not a full audit. The goal is to find out how much of the gap is real before deciding how to close it.

List, for each contract, every clause that changes the price under a condition: volume tiers, surcharge triggers, rebate thresholds, NTE ceilings. Then check the PO or price sheet value against what the contract says the price should be right now, given the condition's current state.

Where the two disagree, that disagreement has usually been compounding since the contract last changed and nobody updated the field. Where they agree, that vendor is a lower priority for a deeper check.

For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for).

## 7. Frequently Asked Questions (People Also Ask)

### Does Acumatica have a contract management module?

Acumatica does not ship a dedicated contract management module that stores conditional terms like rebate tiers or NTE caps. It has Vendor records, Purchase Orders, and optional Price/Cost Sheets, which hold a current price. Conditional contract logic has to be built with custom fields or tracked outside the system.

### Where should I look first if I suspect a stale rate in Acumatica?

Check the Vendor Price/Cost Sheet and the most recent Purchase Order lines against the signed contract's current rate card. If the contract has a volume tier or renewal date, confirm the PO price reflects the tier the vendor's actual volume has reached, not the tier from when the PO was first cut.

### Can Acumatica flag a not-to-exceed overrun automatically?

Not out of the box. Acumatica can be customized with a field and a generic inquiry that sums invoiced amounts against a manually entered cap, but someone has to create that field, enter the correct cap, and keep it current through every contract renewal for the flag to work.

### Does three-way matching in Acumatica check contract compliance?

No. Three-way matching confirms the invoice agrees with the purchase order and the goods receipt. It does not check whether the PO price itself still matches the contract, and it cannot test time-bound conditions like a surcharge expiration or a rebate threshold.

### Why would a rebate go unclaimed even though Acumatica has the invoice history?

A rebate is owed to the buyer, not billed by the vendor, so no invoice line ever prompts Acumatica to act on it. The system has the purchase history needed to calculate whether a threshold was crossed, but nothing initiates that calculation or the claim unless someone builds and runs the check manually.

### Is it worth customizing Acumatica to track every contract clause?

For a small, stable set of vendor contracts, custom fields can work if someone maintains them through every renewal. For a full indirect spend portfolio with frequent renewals across many vendors, the ongoing maintenance burden usually outweighs the benefit compared to a periodic check run directly against the contract documents.

### What's the difference between Acumatica's price sheet and an actual rate card?

The Vendor Price/Cost Sheet stores one current price per item or vendor. A rate card in a contract typically defines several prices under different conditions, such as volume tiers or time-based surcharges. The price sheet can hold whichever single value someone enters, but it does not evaluate the condition that determines which value is correct.

### Does this gap apply to non-stock service lines like freight or IT services?

Yes, and often more so. Non-stock service lines frequently take whatever price is typed directly onto the PO line rather than pulling from a maintained price sheet, which removes one more layer of structure between the contract and the invoiced amount.

### Should we fix this inside Acumatica or run a separate diagnostic?

That depends on how many contracts carry conditional terms and how stale the data already is. A diagnostic run against the contract documents directly does not require existing customization and shows the current gap in weeks; building tracking inside Acumatica is a longer-term maintenance commitment once the gap is known.

### Is contract complexity quietly draining your operating margin?

A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit.

**[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)**

## Executive Summary

Acumatica's AP and Purchasing modules hold a purchase order price, a vendor record, and whatever a three-way match can confirm against a receipt. That is a real control, and it works for the thing it checks: does the invoice match the PO and the receipt. It was not built to test whether the PO price itself still reflects a rate card that changed months ago, or whether a rebate clause triggered and nobody claimed it. The mechanism that causes drift is structural, not a defect in the software. Contract terms are conditional logic written in prose: "if volume exceeds X, rate drops to Y," "surcharge applies only while the fuel index exceeds Z." Acumatica's price and cost fields store a single current value, not a condition. Someone has to read the contract, decide whether the condition fired, and update the field by hand. Every step in that chain is a place the update can fail to happen. What changes it is separating the two jobs cleanly. Let Acumatica do line matching against whatever price and PO data it holds, and run a second, deliberate check against the contract document itself, on a cadence that matches how often those documents actually change. Waiting for the ERP to surface a stale rate card on its own leaves the condition unenforced indefinitely.

## 1. What fields does Acumatica actually use to hold a vendor price?

Acumatica stores price through Vendor records, Purchase Order lines, and optional Vendor Price/Cost Sheets that hold a single current unit price per item or non-stock service line. AP three-way matching then compares the invoice line to the PO line and the receipt. All three of these hold one number at a time. None of them stores why that number is what it is, what condition would change it, or when it was last checked against the source contract, so. The Vendor Price/Cost Sheet is the closest thing Acumatica has to a rate card, and for stocked items with stable pricing it works well. It holds an effective price per vendor per item, and it can carry a start date. What it cannot hold is a condition. A rate card with a volume-tier discount, "$42/unit under 10,000 units, $38/unit above," needs someone to recognize the threshold was crossed and manually change the sheet. Acumatica will not notice on its own; it only knows the value it was given. Non-stock service lines, which is where freight, contract labor, and professional services usually post, often skip the price sheet entirely and take whatever price is typed onto the PO line at the time it is cut. That is one more step removed from the contract.

## 2. Why doesn't three-way matching catch a stale rate or an expired surcharge?

Three-way matching checks the invoice against the purchase order and the goods receipt. It confirms the vendor billed what was ordered and what arrived. It does not open the contract to check whether the ordered price is still the correct price, and it does not test time-bound conditions such as a surcharge that should have expired last quarter or a rebate threshold the year's cumulative volume already crossed. The match passes cleanly even when the underlying rate is wrong. This is not a configuration gap someone forgot to close. Three-way matching is a consistency check across three internal records: order, receipt, invoice. A contract is a fourth document, external to all three, and the match was never designed to reach it. A surcharge is the clearest example. A fuel surcharge tied to a diesel index should turn off when the index drops below the contract's trigger. Nothing in Acumatica watches an external index or the surcharge clause's expiration condition. If the PO line still carries the surcharge, the invoice matches it every time, correctly, against a rate that is no longer contractually owed. A rebate works the same way in reverse: it is owed to the buyer, not billed by the vendor, so no invoice line ever surfaces it for the match to catch at all.

## 3. Where does a not-to-exceed cap or a rebate clause actually get tracked?

In practice, not-to-exceed caps and rebate clauses get tracked outside Acumatica entirely: in the signed contract PDF, in a procurement team's side spreadsheet, or nowhere formal at all, remembered by whoever negotiated the deal. Acumatica has no native field for an NTE ceiling on a labor engagement or a rebate accrual schedule, so there is no system location for either to live in unless someone builds one manually. A not-to-exceed cap on a staffing or professional services contract sets a ceiling on cumulative billing for a project or period. Testing it requires summing every invoice against that vendor and that engagement since the cap's start date, then comparing the running total to the ceiling. Acumatica can produce the invoice history; it will not compute the comparison against a cap it was never told existed. ### A. Where NTE caps typically end up Most commonly in the signed statement of work itself, referenced only when someone remembers to pull it back out. A minority of teams keep a manual tracker, usually a spreadsheet, that someone updates after each invoice posts. Neither location talks to Acumatica. ### B. Where rebate terms typically end up Rebate clauses sit in the master service agreement or a rebate addendum, often with a quarterly or annual accrual schedule. Claiming a rebate requires proactively invoicing or crediting the vendor; Acumatica has no mechanism that prompts that step when a threshold is crossed.

## 4. Can a custom field or generic inquiry close this gap inside Acumatica?

Acumatica's customization tools, custom fields on the vendor or item screens, generic inquiries, and workflow rules, can store a condition once someone writes it in and can flag a simple threshold breach. What they cannot do is read a contract PDF, interpret a rebate clause's language, or update itself when the contract is renegotiated. The gap moves from missing storage to a maintenance task, and maintenance tasks compete with other AP priorities for attention. A custom field for "NTE cap" and a generic inquiry that sums invoiced amounts against it is a genuinely useful build. It gives the system somewhere to hold the number and a report that flags when cumulative billing approaches it. The work that does not go away is getting the number into that field correctly the first time, and updating it every time the contract changes. That is a manual, one-time-per-contract task, done by a person reading the document. If the field is never created for a given vendor, or the update is missed when the contract renews at a new cap, the customization protects nothing. This is the same underlying limit as the price sheet: Acumatica can hold a value faithfully once given one. It cannot extract that value from a contract on its own.

## 5. Should a company on Acumatica build this tracking in-house or run a separate audit?

Building custom fields and inquiries inside Acumatica works for a small, stable set of terms an internal team can maintain over time. It works less well for a full contract portfolio, because every new vendor, renewal, and clause type adds another manual entry point that has to be built and kept current. A periodic audit against the actual contract documents, run independently of the ERP, tests the whole portfolio without depending on prior customization work. The decision hinges on how many contracts carry conditional terms and how often those terms change. A handful of stable vendor agreements can reasonably be tracked with custom fields inside Acumatica, maintained by whoever owns AP. A broader indirect spend book, freight, contract labor, maintenance, IT services, with dozens of vendors and rate cards that renew on staggered schedules, outgrows manual field maintenance quickly. Each renewal is a fresh chance for the field to go stale. An audit run against the contract documents directly does not require the customization to already exist. It reads the actual PDFs and compares them to what was billed, which is the same comparison Acumatica's fields would need updating to perform, done once, on demand, without carrying the ongoing maintenance burden.

## 6. What does a company on Acumatica actually need to check first?

Start with the vendor categories where conditional terms are common and the volume is high enough to matter: freight and 3PL contracts with tiered or fuel-indexed pricing, and contract labor or professional services engagements with NTE caps. Pull the current signed contract for each, list its conditions in plain terms, and compare those conditions against the last several invoices and the current PO price. That comparison shows directly whether Acumatica's stored price still matches the contract. This is a scoping exercise, not a full audit. The goal is to find out how much of the gap is real before deciding how to close it. List, for each contract, every clause that changes the price under a condition: volume tiers, surcharge triggers, rebate thresholds, NTE ceilings. Then check the PO or price sheet value against what the contract says the price should be right now, given the condition's current state. Where the two disagree, that disagreement has usually been compounding since the contract last changed and nobody updated the field. Where they agree, that vendor is a lower priority for a deeper check. For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide. See also [the six categories drift hides in](/insights/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/insights/what-is-margin-erosion-causes-and-prevention-for).

## Common questions

### Does Acumatica have a contract management module?

Acumatica does not ship a dedicated contract management module that stores conditional terms like rebate tiers or NTE caps. It has Vendor records, Purchase Orders, and optional Price/Cost Sheets, which hold a current price. Conditional contract logic has to be built with custom fields or tracked outside the system.

### Where should I look first if I suspect a stale rate in Acumatica?

Check the Vendor Price/Cost Sheet and the most recent Purchase Order lines against the signed contract's current rate card. If the contract has a volume tier or renewal date, confirm the PO price reflects the tier the vendor's actual volume has reached, not the tier from when the PO was first cut.

### Can Acumatica flag a not-to-exceed overrun automatically?

Not out of the box. Acumatica can be customized with a field and a generic inquiry that sums invoiced amounts against a manually entered cap, but someone has to create that field, enter the correct cap, and keep it current through every contract renewal for the flag to work.

### Does three-way matching in Acumatica check contract compliance?

No. Three-way matching confirms the invoice agrees with the purchase order and the goods receipt. It does not check whether the PO price itself still matches the contract, and it cannot test time-bound conditions like a surcharge expiration or a rebate threshold.

### Why would a rebate go unclaimed even though Acumatica has the invoice history?

A rebate is owed to the buyer, not billed by the vendor, so no invoice line ever prompts Acumatica to act on it. The system has the purchase history needed to calculate whether a threshold was crossed, but nothing initiates that calculation or the claim unless someone builds and runs the check manually.

---

ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us