Where contract terms live in Dynamics 365 BC

Executive Summary

Business Central holds structured pricing data: purchase prices, vendor discounts, and price lists tied to items or item categories. It does not hold the contract itself. The rebate tiers, minimum volume commitments, fuel surcharge formulas, and not-to-exceed caps that actually govern a vendor relationship live in a PDF, a signed agreement, or a side spreadsheet, disconnected from the transaction the system is posting.

That split is not a Business Central weakness specific to this ERP. It is what happens whenever contract terms are unstructured text and the ERP's pricing engine expects structured fields. The system enforces what it can encode: a unit price, a discount percentage. It has no field for a surcharge that resets after a stated period, or a rebate that triggers at a stated spend threshold.

The practical consequence: someone has to read the contract, translate its clauses into a rule, and check every invoice against that rule outside the ERP. Whether that check happens as a one-time retrospective audit or as a standing control is a separate decision. This page is about where the terms sit today and why that location does not enforce itself.

1. Where does Business Central actually store vendor pricing?

Business Central stores vendor pricing through Purchase Prices, Purchase Line Discounts, and vendor-item price lists. Each record ties a vendor, an item or item category, a unit of measure, and a price or discount percentage together, with optional start and end dates. This is a lookup table, not a contract.

It captures the number the system should charge on a purchase order line. It captures nothing about why that number was agreed, what conditions change it, or what the vendor.

These fields work well for what they were designed to do: give purchasing a default price and flag a line that deviates from it. A purchase order pulling the wrong unit price against an active price list is a visible, catchable error.

The gap opens on everything the price list cannot represent. A price list has no field for a volume tier that drops the unit price after a cumulative threshold, no field for a surcharge that should expire, no field for a rebate owed back at period end. Those clauses exist in the contract, not in the system that pays against it.

So the price list answers what a line should cost today, narrowly defined. It does not answer whether a vendor is honoring the deal that was signed. That second question needs the contract document itself, read against the invoice.

2. What contract terms fall outside any ERP field entirely?

Four clause types routinely fall outside what any ERP pricing table can encode: volume-tiered rebates that trigger at a spend threshold, fuel or accessorial surcharges with an expiration condition, not-to-exceed caps on labor or service categories, and minimum volume commitments that shift the effective rate. Each requires reading a condition against a running total or a date, something a purchase price field does not track. They stay in the signed agreement, and nobody re-enters them into the ERP once the.

Take a freight contract with a fuel surcharge tied to a diesel index and a stated reset period. Business Central has no field for reducing that surcharge when the index falls below a threshold. The surcharge gets keyed in once, often correctly, and then persists on invoices after the condition that justified it has passed.

A staffing agreement with a not-to-exceed cap on billed hours per role behaves the same way. The ERP posts whatever hours the vendor bills. It has no concept of a ceiling defined in a separate document.

These are not edge cases. They are the normal shape of a service contract: a base rate plus conditions. The base rate fits a database field. The conditions do not.

3. How does three-way matching handle a contract clause?

Three-way matching in Business Central checks that the invoice quantity and price agree with the purchase order and the receipt. It does not check the purchase order price against the underlying contract, because the contract is not a system object it can reference. If a stale unit price was keyed into the purchase order, three-way matching confirms the invoice against that stale price cleanly, and the mismatch never surfaces as an exception.

This is a control doing exactly what it was built to do, not failing at its job. Three-way matching exists to catch billing errors relative to what was ordered and received: wrong quantity, wrong price versus the PO, a duplicate invoice number.

A contract violation is a different kind of error. The PO price itself can be wrong, set months ago and never updated when the rate card changed, and three-way matching has no way to know that, because the rate card lives outside the transaction system it operates on.

Closing that gap means checking the PO and invoice price against the contract document directly, on a cadence the ERP does not run on its own.

4. Which document types actually hold the governing terms?

The governing terms for a vendor relationship typically sit across three document types: the master service agreement or supply contract itself, a rate schedule or tariff attached as an exhibit, and amendment letters issued when rates change mid-term. None of these are system records in Business Central. They are files, usually PDFs, held in a contract folder, a vendor management platform, or an inbox, separate from the vendor card that references them only by name.

A master agreement sets the structural terms: payment terms, audit rights, termination conditions, and often the rebate or volume-tier framework in outline.

The rate schedule or tariff, frequently a separate exhibit or a carrier's published rate table, carries the actual numbers: per-mile rates, accessorial charges, hourly bill rates by labor category.

Amendment letters are where drift most often starts. A rate changes, a letter is signed, and the purchase price in Business Central is updated for some line items and missed for others. The letter itself is rarely filed anywhere the AP team checking an invoice would think to look.

A. Contract repository

Where the master agreement and its exhibits live: a shared drive, a vendor management tool, or a contract lifecycle system if one is in use. Business Central does not link to this repository natively. The connection, if it exists, is a naming convention or a manual cross-reference someone maintains.

B. Rate schedule or tariff

The numeric core of the deal: per-unit rates, tiers, surcharge formulas. For freight specifically, a carrier's published accessorial tariff often sits outside even the signed contract, referenced by version rather than reproduced in full.

C. Amendment and renewal letters

The most likely source of a stale purchase price. A rate change lands in an email or a letter, and updating every affected price list line in Business Central is a manual step that competes with everything else on the AP team's list.

5. Can a Business Central customization enforce contract terms directly?

A customization can extend Business Central's price and discount tables, add date logic, or flag a purchase line that falls outside a configured range. What it cannot do is read a PDF contract and derive the rule itself: someone still has to translate the clause into a structured field before any extension can check against it. The customization moves where the rule is enforced.

It does not remove the translation step between contract language and a checkable rule.

This matters because the translation step is where the real work sits, not the enforcement step. A developer can build a field for a not-to-exceed cap in a week. Reading vendor contracts to find every NTE clause, every rebate tier, and every surcharge condition, and keeping that list current as contracts renew, is the ongoing effort.

A custom extension is a reasonable answer once the rules are known and stable. It is a poor first move when the rules have not yet been extracted from the contracts, because the extension will faithfully enforce whatever was guessed.

6. Should you fix this by adding fields or by auditing history first?

Adding fields to Business Central is a forward-looking fix: it helps the next invoice, not the ones already paid. A retrospective audit against the underlying contracts answers a different question, whether drift has already accumulated in months of invoices paid against a stale or misread price. The two are not competing options.

The audit tells you which fields are worth building; building fields first risks encoding the wrong rule.

An AP team that jumps straight to configuration is choosing a structure before confirming what needs structuring. If a freight contract's fuel surcharge clause was misread when it was first keyed in, a new custom field just enforces the same misreading more consistently.

Reading the contracts against the invoice history first identifies which vendors, which categories, and which clause types actually carry a stale or mismatched term. That list is what should drive which fields get built and in what order.

This sequencing question, whether to buy a forward-looking control first or diagnose the backlog first, is covered in full elsewhere. For a Business Central specific consideration: the ERP's price list structure only helps once the correct numbers are known.

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 Business Central have a contract management module?

Not natively. Business Central manages purchase prices, discounts, and vendor records. Contract documents themselves, along with their clauses, rebate tiers, and surcharge conditions, are typically stored outside the ERP in a shared drive, inbox, or separate contract management tool, referenced only by name on the vendor card.

Where do freight rate contracts sit if we use Business Central?

The carrier's rate schedule or tariff is usually a separate PDF or exhibit, not reproduced inside Business Central. Only the resulting per-unit price gets keyed into a purchase price record, and only if someone updates it each time the tariff changes.

Can I build a report in Business Central to catch contract drift?

You can build a report comparing purchase order prices to a reference table, but the reference table has to be populated with the correct current rates first. The report checks what you tell it to check. It cannot derive the rule from a contract document on its own.

Why did three-way matching not catch a stale rate?

Three-way matching confirms the invoice against the purchase order and receipt, not against the contract. If the purchase order price was already stale, the invoice matches it cleanly and no exception is raised, because the contract is not a system object the match can reference.

Does adding custom fields to Business Central fix this?

It can, for terms already correctly identified. A custom field enforces whatever rule is configured into it. If the underlying clause was misread when the field was set up, the customization enforces the misreading consistently rather than correcting it.

What is the difference between a price list and a contract?

A price list is a structured record: vendor, item, price, effective dates. A contract is the source document containing the conditions that justify that price, including tiers, caps, and surcharge logic the price list has no fields to hold.

Should we track contracts in Business Central item attributes instead?

Attributes can hold reference notes, but they are not designed for conditional logic like a rebate threshold or a surcharge expiration. They work as a pointer back to the source document, not as a substitute for reading that document.

How do amendment letters get lost in this setup?

A rate change usually arrives as a signed letter or email rather than a structured update. Someone has to manually revise every affected purchase price line in Business Central. Lines that are missed keep posting at the old rate indefinitely.