How do you run a contract compliance audit in Business Central?

Start from the ERP, not the filing cabinet. Business Central already holds the terms being performed every day — payment terms, prices, renewal dates. Auditing those against the signed documents finds the money faster than reading every contract, because it starts with what is already being charged.

Why does nobody know what was agreed?

Four causes, and none of them is carelessness.

• The people who negotiated it left. The reason behind an unusual term is rarely written down, so the term survives and the reasoning does not.
• The agreement was amended and the record was not. A renegotiated price arrives as a signed amendment in an inbox and never reaches the vendor card.
• The terms were typed once, from a document read once. After that the record operates on its own, and no error is raised when it drifts.
• The documents are spread across drives, inboxes and one person's laptop. This is the cause everyone names first and it is the least important of the four — finding the contract faster does not tell you whether the record matches it.

That last point is the one that changes what you do next. Most advice on this problem is centralise your contracts in a searchable repository, which is genuinely useful and solves cause four. It leaves the first three untouched, and those are where the money is.

Where should you actually start?

With the terms that are executing right now, which live in your ERP.

Business Central registers each supplier with a vendor card, and a purchase invoice exists to "record your agreement with a vendor to purchase products on certain delivery and payment terms." That is a description of the answer you are looking for, already in structured form.

Three field groups carry almost all of the commercial risk:

On the enterprise tier there is more to work with. A purchase agreement is "a contract that commits an organization to buy a specified quantity or amount by using multiple purchase orders over time", and applying one copies "the payment terms, delivery terms, and delivery address" onto the order header — so the link between agreement and transaction is explicit rather than implied.

Either way the method is the same: the ERP tells you what you are behaving as though you agreed. The document tells you what you did agree. The gap between them is the answer to the question.

Which terms do you check first?

The ones that act without anyone deciding.

A liability cap matters enormously and does nothing on a Tuesday. A payment term applies to every invoice that posts. So order the work by what executes, not by what a lawyer would rank as serious:

1. Payment terms — cheapest to check, applies to everything, and the most common mismatch.
2. Prices and discounts — the negotiated rate against what the line actually charges.
3. Renewal and notice dates — because the cost of being wrong is a full extra term. Note that a blank notice period is not neutral: Microsoft's own wording is that unset periods leave a line "valid indefinitely or can be terminated at any time."
4. Delivery terms and addresses — cheap to verify, and wrong more often than expected.
5. Everything else — caps, indemnities, governing law. Read these when a decision needs them.

This ordering is deliberately not the legal one. It is the operational one, and it exists because a team that starts with liability caps runs out of energy before reaching payment terms — which is where the recoverable money was.

Why doesn't "read all the contracts" work?

Because it produces a snapshot, and the problem is continuous.

Reading everything is a project. It has a start, an end and a document at the end of it. Six months later the answer is stale, because agreements get amended, prices get renegotiated and someone edits a vendor card. The organisation is back where it started, minus the budget.

It also answers the wrong question. A full read tells you what the contracts say. It does not tell you whether your systems are behaving accordingly — and only the second question has money attached to it.

The check that works is small, repeatable and starts from the record: take the agreements behind your largest spend, put the signed document beside the vendor card, and compare the three field groups above. If it takes an afternoon it can be repeated. If it takes a quarter it will happen once.

And repeatability is exactly what changed recently. The reason a compliance audit used to be a project is that reading a hundred and fifty agreements required a hundred and fifty person-hours. Extracting a payment term, a notice period and a rate card from a signed PDF is now a solved engineering problem — Microsoft's own Payables Agent already reads an inbound document, pulls the terms out and matches them to a record, aimed at invoices. The same operation aimed at agreements turns the audit from a project into a job that runs.

What does a good answer look like?

Not a document. A standing property of the system.

You know what you agreed when:

• Every live agreement has its commercial terms on the record, and somebody can say when they were last checked against the paper.
• Renewal and notice dates are populated rather than blank, and a scheduled job keeps them current.
• A change to a negotiated term is [routed for approval](/blogs/approval-workflow-protect-negotiated-term-business-central) rather than typed over.
• New counterparties are blocked until reviewed — which is exactly the pattern Microsoft's own Payables Agent uses when it creates a vendor.
• The comparison runs again on a schedule, because drift is continuous and a one-off answer decays.

The last point is where this stops being a filing problem and becomes an engineering one.

An agentic version of this audit is three steps, and none of them is speculative. Read the agreement and extract the terms that should be on the record. Compare them against the vendor card, the price lines and the notice dates. Propose the corrections, with the clause attached, for a person to approve.

Every one of those steps exists in production somewhere today — extraction in the Payables Agent, comparison as a straightforward query, approval as a Business Central workflow.

What makes it agentic rather than a report is the third step and the schedule. A report tells you about a mismatch. An agent proposes the corrected value, cites the clause it came from, and waits for a human decision — then runs again next month, because drift is continuous.

That is decision intelligence applied to legal operations: not a list of exceptions for somebody to work through, but a specific proposed change with its evidence attached.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.

Take the agreements behind your ten largest suppliers and compare payment terms on the vendor card against the signed document. Bring the mismatches to a 15-minute call.

Sources

• Overview of tasks to manage purchasing — Business Central · ms.date 2026-06-17
• Cancel planned subscription lines — Business Central · ms.date 2025-07-11
• Purchase agreements — Supply Chain Management · ms.date 2026-09-08