# Where do contract terms live if you use Sage Intacct?

> Sage Intacct stores GL and AP transactions, not rate cards or rebate clauses. Here is where contract terms actually sit, and why that gap matters.

Source: https://valuexpa.com/insights/where-do-contract-terms-live-if-you-use-sage-intacct
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. Sage Intacct is built to record what an invoice says once it arrives, not to hold the contract that should have priced it.

That distinction matters more than it sounds. A controller running Sage Intacct can produce a clean GL entry for a freight bill or a staffing invoice in seconds. Finding the rate card that invoice was supposed to match usually means opening a different system, or a shared drive, entirely.

## Executive Summary

Sage Intacct's dimension structure is strong for allocating cost by department, location, and project. It has no native object for a rate card, a rebate tier, or a not-to-exceed cap. Those terms live in whatever system procurement or legal used to negotiate the contract: a PDF, a vendor portal, a spreadsheet, sometimes a signed email thread.

The mechanism that causes drift is simple. AP in Sage Intacct approves an invoice against a purchase order or a budget line. Neither check reads the underlying contract clause. An invoice can match its PO in quantity and unit price and still violate a volume tier or a surcharge cap that only exists in the contract PDF.

What changes this is not a new module inside Sage Intacct. It is treating contract terms as a separate system of record that gets checked against the invoice before payment, using the terms as written rather than the terms as re-typed into a PO.

## 1. What does Sage Intacct actually store about a vendor contract?

**Sage Intacct stores a vendor record, payment terms, a default GL account, and whatever purchase orders or bills get entered against that vendor. It does not store a rate schedule, a rebate tier structure, a surcharge table, or a not-to-exceed clause as a searchable field. Those terms exist only if someone manually re-enters a price into a PO line, and a PO line cannot hold a conditional clause like a volume trigger or an expiration date.**

The vendor record in Sage Intacct is built for payment routing: remit-to address, terms code, 1099 status, default expense account. It answers who to pay and how, not what the agreed price should be under which conditions.

A purchase order can carry a unit price, and some AP teams treat that as the contract. It is a snapshot, not the contract. If the vendor negotiated a rate card with several volume tiers, the PO reflects one tier, entered once, and is not automatically revisited when volume crosses a threshold.

Bills and adjustment journals record what happened after the fact. They are the wrong place to look for what should have happened, which is the question a contract answers.

## 2. Where do rate cards and rebate clauses actually get filed?

**Rate cards, rebate schedules, and surcharge tables sit outside the ERP entirely: in a contract management tool if one exists, in a shared drive folder maintained by procurement, in a vendor's own portal, or as a PDF attachment to the original email negotiating the deal. Sage Intacct's attachment feature can hold a copy of the file, but attaching a PDF does not make its terms queryable or checkable against an invoice line at the point AP approves payment.**

Procurement and legal negotiate contracts using tools built for redlining and signature, not for structured pricing data. The output is a document, and a document's terms are not the same thing as a data field a system can check an invoice against.

Sage Intacct allows a file to be attached to a vendor record or a transaction. That solves storage. It does not solve enforcement, because nothing in Sage Intacct parses the PDF to compare a fuel surcharge table against the surcharge line on this week's freight invoice.

The result is a split: transactions live in the ERP, terms live somewhere else, and the two are joined only when a human opens both and compares them line by line.

## 3. Why doesn't three-way matching catch a contract violation?

**Three-way matching in Sage Intacct checks that the invoice quantity and price agree with the purchase order and the receipt. It does not test whether the price on the PO itself is correct against the contract, and it does not evaluate conditional terms like a volume tier trigger or a surcharge expiration date. A vendor can bill exactly what the PO says and still be charging a rate the contract no longer permits.**

The match compares three documents Sage Intacct already has: the PO, the receipt, the bill. If all three agree, the invoice passes. The contract is a fourth document the match never opens.

This is why a stale PO price is a straightforward way for drift to persist undetected. A unit price gets entered on a PO in year one. The contract's volume rebate kicks in at a threshold reached later. The PO still carries the original price, the invoice matches it, and three-way matching has nothing to flag because both documents agree with each other while disagreeing with the contract.

A surcharge with an end date behaves the same way. The PO line for the surcharge was created once. The contract clause that says the surcharge should have expired lives in the PDF, not in the PO.

## 4. Can a custom Sage Intacct dimension or GL account hold contract logic?

**A custom dimension can tag a transaction as belonging to a particular contract, vendor category, or project, which helps with reporting and allocation. It cannot evaluate a conditional rule such as a rebate that only applies above a volume threshold, because dimensions classify a transaction after entry rather than test it against a clause before approval. The logic still has to be applied by a person reading the contract.**

Dimensions in Sage Intacct answer a classification question: which department, which location, which project does this cost belong to. That is valuable for reporting spend by category, which is a separate and legitimate use.

A rebate clause or an NTE cap is not a classification. It is a rule with a condition: if cumulative spend exceeds a threshold, the unit price changes, or if a project runs past a cap, additional hours require a change order. Sage Intacct has no field type built to store and evaluate a conditional rule against an incoming bill.

Teams sometimes build a custom field to note a contract number for cross-reference. That helps a human find the contract faster. It does not check the invoice against it.

## 5. What are the practical options for closing this gap?

**Three approaches exist, and each has a real tradeoff. Manual review by AP or a controller works for low volume but does not scale as invoice count grows. A dedicated contract management tool centralizes terms but still requires someone to manually compare them against each invoice. A retrospective audit reviews a period of history against the actual contract terms and identifies where the invoice and the contract diverged, without requiring a new system.**

- **Manual review:** Someone with contract knowledge opens both documents and checks the math by hand. It works when vendor and invoice counts are small enough that this is a realistic weekly task, and it degrades as volume grows because the review time scales with invoice count, not with risk.

- **Contract management software:** A separate system stores terms in structured form, searchable and centralized. It reduces the time to find a clause. It does not by itself compare an incoming Sage Intacct invoice against that clause; someone still has to run the comparison.

- **Retrospective audit:** Rather than building a new system, a fixed-scope review of a period of AP history checks invoices against the contracts that governed them and quantifies where they diverged. This works without any change to how Sage Intacct is used day to day.

## 6. Should a mid-market manufacturer fix this inside Sage Intacct or build a separate control?

**Sage Intacct was not designed to store or evaluate contract terms, and building that capability inside it means custom fields and manual workflows that still depend on someone remembering to check them. A separate control, whether a person, a process, or a system built for the purpose, that reads the contract as written and checks it against each invoice before or after payment, closes the gap without asking the ERP to do a job it was not built for.**

Extending Sage Intacct with custom objects to hold rate tiers is possible in principle. In practice it means maintaining a second copy of every contract term inside the ERP, keeping it synchronized every time a contract renews or amends, and still writing the logic that checks an invoice against it, none of which the ERP vendor built or supports.

The same gap exists on other ERPs built for transactions rather than contracts. A manufacturer running [Infor CloudSuite SyteLine](/insights/for-infor-syteline) or [Plex](/insights/for-plex) faces the identical split between where the invoice lands and where the contract terms sit, and whether to build the check in a spreadsheet or buy software for it is a separate question from which ERP is in use.

Whichever way a company decides to close the gap, the first question is not which tool to buy. It is which contracts and vendor categories carry the most exposure, which is a question a review of existing spend answers before any tool decision does. See diagnostic or software: what to buy first for how to sequence that decision.

## 7. Where does the wider pattern behind this fit?

**This gap is not specific to Sage Intacct. Any ERP built to record transactions rather than negotiate contracts leaves the same split: terms in one place, invoices in another, joined only when someone checks. The fix is the same regardless of which ERP a manufacturer runs: treat contract terms as a system of record checked against every invoice, rather than assuming the ERP's approval workflow already does that job.**

For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide, which covers how this gap shows up across freight, staffing, MRO, and IT services contracts, not just inside a single ERP.

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).

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

### Can Sage Intacct's contract management add-on hold rate cards?

Sage Intacct's revenue recognition and contract billing features are built around subscription and usage billing for what a company sells, not for tracking the terms of what it buys from service vendors. They do not give AP a field for a supplier's rate card, rebate tier, or surcharge cap.

### Does a Sage Intacct implementation partner usually set up contract tracking?

Implementation work in Sage Intacct centers on the chart of accounts, dimensions, and approval workflows. Vendor contract terms are a procurement and legal artifact and fall outside a standard ERP implementation scope unless a company specifically asks for custom fields to reference them.

### Is a custom object the right way to store contract terms in Sage Intacct?

A custom object can hold structured data, but someone still has to build the logic that evaluates a conditional clause like a volume-tier rebate against each invoice, and keep it synchronized every time a contract changes. Sage Intacct does not provide that evaluation logic out of the box.

### What should an AP team check first if they suspect contract drift in Sage Intacct?

Start with vendors on multi-tier rate cards or contracts with an expiration or threshold clause, since those are the terms a PO snapshot and three-way match cannot represent. Pull the original contract PDF and compare it line by line against a sample of recent invoices.

### Does adding more Sage Intacct dimensions help catch a rebate that was never applied?

Dimensions classify a transaction by department, location, or project after it is entered. They do not evaluate whether a rebate threshold was crossed or whether the vendor applied it, because that requires comparing cumulative spend against a contract clause, not tagging a transaction.

### Can Sage Intacct workflow approvals be configured to flag a contract mismatch?

Approval workflows in Sage Intacct route a transaction based on amount, department, or vendor, not on whether the invoiced price matches a contract clause, since the contract itself is not data the workflow engine can read.

### Is there a legal risk to keeping rate cards only as email attachments?

Storing contract terms only as email attachments makes them hard to find and easy to lose track of during a vendor or staff transition, which is an operational risk more than a legal one. This is general information, not legal advice; consult counsel on document retention obligations specific to a company's contracts.

### How long does a retrospective contract audit against Sage Intacct data typically take?

ValueXPA's Margin Drift Diagnostic delivers a prioritized recovery and prevention roadmap in 2 to 4 weeks, across the full engagement rather than a single ERP's data alone.

### 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

Sage Intacct's dimension structure is strong for allocating cost by department, location, and project. It has no native object for a rate card, a rebate tier, or a not-to-exceed cap. Those terms live in whatever system procurement or legal used to negotiate the contract: a PDF, a vendor portal, a spreadsheet, sometimes a signed email thread. The mechanism that causes drift is simple. AP in Sage Intacct approves an invoice against a purchase order or a budget line. Neither check reads the underlying contract clause. An invoice can match its PO in quantity and unit price and still violate a volume tier or a surcharge cap that only exists in the contract PDF. What changes this is not a new module inside Sage Intacct. It is treating contract terms as a separate system of record that gets checked against the invoice before payment, using the terms as written rather than the terms as re-typed into a PO.

## 1. What does Sage Intacct actually store about a vendor contract?

Sage Intacct stores a vendor record, payment terms, a default GL account, and whatever purchase orders or bills get entered against that vendor. It does not store a rate schedule, a rebate tier structure, a surcharge table, or a not-to-exceed clause as a searchable field. Those terms exist only if someone manually re-enters a price into a PO line, and a PO line cannot hold a conditional clause like a volume trigger or an expiration date. The vendor record in Sage Intacct is built for payment routing: remit-to address, terms code, 1099 status, default expense account. It answers who to pay and how, not what the agreed price should be under which conditions. A purchase order can carry a unit price, and some AP teams treat that as the contract. It is a snapshot, not the contract. If the vendor negotiated a rate card with several volume tiers, the PO reflects one tier, entered once, and is not automatically revisited when volume crosses a threshold. Bills and adjustment journals record what happened after the fact. They are the wrong place to look for what should have happened, which is the question a contract answers.

## 2. Where do rate cards and rebate clauses actually get filed?

Rate cards, rebate schedules, and surcharge tables sit outside the ERP entirely: in a contract management tool if one exists, in a shared drive folder maintained by procurement, in a vendor's own portal, or as a PDF attachment to the original email negotiating the deal. Sage Intacct's attachment feature can hold a copy of the file, but attaching a PDF does not make its terms queryable or checkable against an invoice line at the point AP approves payment. Procurement and legal negotiate contracts using tools built for redlining and signature, not for structured pricing data. The output is a document, and a document's terms are not the same thing as a data field a system can check an invoice against. Sage Intacct allows a file to be attached to a vendor record or a transaction. That solves storage. It does not solve enforcement, because nothing in Sage Intacct parses the PDF to compare a fuel surcharge table against the surcharge line on this week's freight invoice. The result is a split: transactions live in the ERP, terms live somewhere else, and the two are joined only when a human opens both and compares them line by line.

## 3. Why doesn't three-way matching catch a contract violation?

Three-way matching in Sage Intacct checks that the invoice quantity and price agree with the purchase order and the receipt. It does not test whether the price on the PO itself is correct against the contract, and it does not evaluate conditional terms like a volume tier trigger or a surcharge expiration date. A vendor can bill exactly what the PO says and still be charging a rate the contract no longer permits. The match compares three documents Sage Intacct already has: the PO, the receipt, the bill. If all three agree, the invoice passes. The contract is a fourth document the match never opens. This is why a stale PO price is a straightforward way for drift to persist undetected. A unit price gets entered on a PO in year one. The contract's volume rebate kicks in at a threshold reached later. The PO still carries the original price, the invoice matches it, and three-way matching has nothing to flag because both documents agree with each other while disagreeing with the contract. A surcharge with an end date behaves the same way. The PO line for the surcharge was created once. The contract clause that says the surcharge should have expired lives in the PDF, not in the PO.

## 4. Can a custom Sage Intacct dimension or GL account hold contract logic?

A custom dimension can tag a transaction as belonging to a particular contract, vendor category, or project, which helps with reporting and allocation. It cannot evaluate a conditional rule such as a rebate that only applies above a volume threshold, because dimensions classify a transaction after entry rather than test it against a clause before approval. The logic still has to be applied by a person reading the contract. Dimensions in Sage Intacct answer a classification question: which department, which location, which project does this cost belong to. That is valuable for reporting spend by category, which is a separate and legitimate use. A rebate clause or an NTE cap is not a classification. It is a rule with a condition: if cumulative spend exceeds a threshold, the unit price changes, or if a project runs past a cap, additional hours require a change order. Sage Intacct has no field type built to store and evaluate a conditional rule against an incoming bill. Teams sometimes build a custom field to note a contract number for cross-reference. That helps a human find the contract faster. It does not check the invoice against it.

## 5. What are the practical options for closing this gap?

Three approaches exist, and each has a real tradeoff. Manual review by AP or a controller works for low volume but does not scale as invoice count grows. A dedicated contract management tool centralizes terms but still requires someone to manually compare them against each invoice. A retrospective audit reviews a period of history against the actual contract terms and identifies where the invoice and the contract diverged, without requiring a new system. 1. Manual review: Someone with contract knowledge opens both documents and checks the math by hand. It works when vendor and invoice counts are small enough that this is a realistic weekly task, and it degrades as volume grows because the review time scales with invoice count, not with risk. 2. Contract management software: A separate system stores terms in structured form, searchable and centralized. It reduces the time to find a clause. It does not by itself compare an incoming Sage Intacct invoice against that clause; someone still has to run the comparison. 3. Retrospective audit: Rather than building a new system, a fixed-scope review of a period of AP history checks invoices against the contracts that governed them and quantifies where they diverged. This works without any change to how Sage Intacct is used day to day.

## 6. Should a mid-market manufacturer fix this inside Sage Intacct or build a separate control?

Sage Intacct was not designed to store or evaluate contract terms, and building that capability inside it means custom fields and manual workflows that still depend on someone remembering to check them. A separate control, whether a person, a process, or a system built for the purpose, that reads the contract as written and checks it against each invoice before or after payment, closes the gap without asking the ERP to do a job it was not built for. Extending Sage Intacct with custom objects to hold rate tiers is possible in principle. In practice it means maintaining a second copy of every contract term inside the ERP, keeping it synchronized every time a contract renews or amends, and still writing the logic that checks an invoice against it, none of which the ERP vendor built or supports. The same gap exists on other ERPs built for transactions rather than contracts. A manufacturer running [Infor CloudSuite SyteLine](/insights/for-infor-syteline) or [Plex](/insights/for-plex) faces the identical split between where the invoice lands and where the contract terms sit, and whether to build the check in a spreadsheet or buy software for it is a separate question from which ERP is in use. Whichever way a company decides to close the gap, the first question is not which tool to buy. It is which contracts and vendor categories carry the most exposure, which is a question a review of existing spend answers before any tool decision does. See diagnostic or software: what to buy first for how to sequence that decision.

## 7. Where does the wider pattern behind this fit?

This gap is not specific to Sage Intacct. Any ERP built to record transactions rather than negotiate contracts leaves the same split: terms in one place, invoices in another, joined only when someone checks. The fix is the same regardless of which ERP a manufacturer runs: treat contract terms as a system of record checked against every invoice, rather than assuming the ERP's approval workflow already does that job. For the wider pattern this sits inside, start with the [margin drift](/insights/best-invoice-validation-software-smb) guide, which covers how this gap shows up across freight, staffing, MRO, and IT services contracts, not just inside a single ERP. 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

### Can Sage Intacct's contract management add-on hold rate cards?

Sage Intacct's revenue recognition and contract billing features are built around subscription and usage billing for what a company sells, not for tracking the terms of what it buys from service vendors. They do not give AP a field for a supplier's rate card, rebate tier, or surcharge cap.

### Does a Sage Intacct implementation partner usually set up contract tracking?

Implementation work in Sage Intacct centers on the chart of accounts, dimensions, and approval workflows. Vendor contract terms are a procurement and legal artifact and fall outside a standard ERP implementation scope unless a company specifically asks for custom fields to reference them.

### Is a custom object the right way to store contract terms in Sage Intacct?

A custom object can hold structured data, but someone still has to build the logic that evaluates a conditional clause like a volume-tier rebate against each invoice, and keep it synchronized every time a contract changes. Sage Intacct does not provide that evaluation logic out of the box.

### What should an AP team check first if they suspect contract drift in Sage Intacct?

Start with vendors on multi-tier rate cards or contracts with an expiration or threshold clause, since those are the terms a PO snapshot and three-way match cannot represent. Pull the original contract PDF and compare it line by line against a sample of recent invoices.

### Does adding more Sage Intacct dimensions help catch a rebate that was never applied?

Dimensions classify a transaction by department, location, or project after it is entered. They do not evaluate whether a rebate threshold was crossed or whether the vendor applied it, because that requires comparing cumulative spend against a contract clause, not tagging a transaction.

---

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