TL;DR
An MSA sets terms, a SOW spends against them, an MOU commits nothing. Business Central has one flat vendor record for all three, and cannot show the hierarchy.
Separately, and that is the problem. An MSA sets the terms, a statement of work spends against them, and a memorandum of understanding commits nothing — but Business Central holds one flat vendor record for all three. The hierarchy your agreements have is the part the ERP has no field for.
What are these three documents actually doing?
They sit at different levels, and only one of them prices anything.
| Document | What it does | What it usually contains |
|---|---|---|
| MSA — master services agreement | Sets the rules once for a relationship that will have many transactions | Liability, indemnity, IP, payment terms, notice periods, governing law, rate card |
| SOW — statement of work | Spends against the MSA. Each one is a specific piece of work | Scope, deliverables, dates, milestones, price for that work |
| MOU — memorandum of understanding | Records an intention, often before anything is binding | Shared objectives, roles, a term, rarely any payment obligation |
Almost all of it is [third-party paper](/blogs/what-is-third-party-paper) — drafted on the counterparty's template, which changes how it has to be reviewed.
The relationship between them is the whole point. A SOW inherits the MSA's liability cap and payment terms without restating them. Read a SOW alone and you will not find the terms that govern it — which is exactly how a company ends up performing against clauses nobody has looked at since signature.
Add leases and funder agreements — both common in the same portfolios — and you have four document types with different renewal behaviour, different notice rules and different consequences for missing a date.
Where does each one land in Business Central?
Only the parts that move money get a home. The rest has nowhere to go.
| What it is | Where it lands |
|---|---|
| MSA payment terms, delivery terms | The vendor card. Microsoft: a purchase invoice records "your agreement with a vendor to purchase products on certain delivery and payment terms" |
| MSA rate card | Prices and discounts, applied per line |
| A committed volume over time | A blanket order — "a framework for a long-term agreement between you and your customer or vendor" |
| A recurring fee | A vendor subscription contract, whose lines carry "detailed information about the billing" |
| Notice period and renewal term | Cancellation Possible Until, Term Until, Subsequent Term — real fields, and usually blank |
| The SOW's scope and deliverables | No field. These are not commercial mechanics |
| Liability cap, indemnity, governing law | No field |
| The MOU | No field |
| Which MSA a purchase order falls under | No field for it on Business Central purchase documents |
"No field" is the precise claim, and it is not the same as "nowhere." Business Central can hold the document itself as an attachment on a record. What it has no place for is the term as data — a liability cap you can filter, report on or compare against a purchase order. An attached PDF is storage; a field is something the system can act on.
That last row is the structural gap. On Finance & Supply Chain Management there is an object for it — a purchase agreement, which Microsoft describes as "a contract that commits an organization to buy a specified quantity or amount by using multiple purchase orders over time", and applying it copies the terms onto the order header. Business Central has no equivalent hierarchy, which is one of the real differences between the two tiers.
What actually breaks when the hierarchy is flat?
Four things, and none of them raises an error.
- A SOW gets its own terms by accident. Somebody raises the order, the vendor card supplies thirty-day payment terms, and the MSA said sixty. The SOW never mentioned payment terms because it did not need to — it inherits them from a document the ERP has never seen.
- The liability position becomes unanswerable. "What is our maximum exposure on this supplier?" requires the MSA's cap and every live SOW's value. The second half is in the ERP; the first half is in a PDF.
- Renewal cascades are invisible. An MSA lapsing takes its SOWs with it. Nothing in the vendor record knows the SOWs depend on it.
- The same vendor under two MSAs looks like one relationship. Different entities, different regions, different terms — one vendor card.
None of this is a defect in Business Central. It is a system of record for transactions, and it records them accurately. It was never built to model a document hierarchy, and expecting it to is the mistake.
And what about MOUs, which commit nothing?
They commit nothing financially, which is exactly why they get lost.
An MOU has no invoice, no purchase order and no billing schedule, so nothing in the transactional record represents it. It usually has a term, sometimes an exclusivity or confidentiality clause, and often an expectation that converts into a real agreement later.
Funder agreements behave similarly and matter more. They carry conditions — how money may be spent, what must be reported, by when — and those obligations are real even though no purchase order references them. A grant-funded organisation with a portfolio of funder agreements carries reporting obligations that its transactional record has no field for.
The practical consequence: the documents with no financial footprint are the ones no system reminds you about, and they are not the least important ones.
So how do you actually handle this?
Split the job by document level, and stop trying to make one record carry four.
- Put the MSA's commercial terms on the vendor card and get them right — payment terms, delivery terms, prices. These are the ones that execute on every order.
- Put the notice period and renewal term in the fields that exist. Blank is not neutral; Microsoft's own wording is that unset periods mean a line is "valid indefinitely or can be terminated at any time."
- Record which MSA governs a purchase order in the field you do have — the external document number or a dimension. It is a convention rather than a feature, but a consistent convention is searchable.
- Keep the documents wherever they already are. Moving them into the ERP solves nothing; storage is a different problem from verification.
- Check the record against the paper on a schedule, because the flat structure means drift is invisible rather than detectable.
Step five is the one that needs building. Reading an MSA, extracting the terms that should be on the vendor card, and comparing them is document intelligence — the same capability that reads an inbound invoice, pointed at an agreement instead. A sidecar app running in your own Azure tenancy can do that without the document ever moving, and it leaves Dynamics as the system of record while something beside it works out whether the record is faithful.
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 one MSA and one SOW raised under it, and check whether the purchase order carries the master agreement's payment terms or the vendor default. Bring the answer to a 15-minute call.
Sources
- Overview of tasks to manage purchasing — Business Central ·
ms.date2026-06-17 - Work with blanket sales orders or purchase orders — Business Central ·
ms.date2026-04-07 - Cancel planned subscription lines — Business Central ·
ms.date2025-07-11 - Purchase agreements — Supply Chain Management ·
ms.date2026-09-08 - Contract Management functionality — Dynamics community forum · read 2026-09-10
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | What an MSA, SOW and MOU each do and contain | T2 — ours, general commercial definitions, no vendor or legal authority claimed | — | PASS — definitional, not sourced to anyone |
| 2 | 1 | Leases and funder agreements appear in the same portfolios | T1 — the buyer's own list, attributed | community.dynamics.com thread, read 2026-09-10 | PASS |
| 3 | 2 | A purchase invoice records "your agreement with a vendor to purchase products on certain delivery and payment terms" | T1 — verbatim | purchasing-manage-purchasing, fetched 2026-09-10 | PASS |
| 4 | 2 | Blanket order is "a framework for a long-term agreement" | T1 — verbatim | sales-how-to-create-blanket-sales-orders | PASS |
| 5 | 2 | Subscription contract lines carry "detailed information about the billing" | T1 — verbatim | Vendor-contracts page, fetched 2026-09-10 | PASS |
| 6 | 2 | The renewal field names | T1 — names character-exact | service-commitment-cancellation, fetched 2026-09-10 | PASS |
| 7 | 2 | F&SCM purchase agreement "commits an organization to buy a specified quantity or amount…" and copies terms to the PO header | T1 — verbatim | purchase-agreements (ms.date 2026-09-08) | PASS |
| 8 | 2 | Business Central purchase documents have no field for the governing master agreement | T2 — bounded absence. Scoped in the body to Business Central purchase documents, and stated beside the tier that does have the object | The four Microsoft pages in sources: | PASS — bounded, and the contrast is the evidence |
| 9 | 3 | The four failure modes | T2 — ours, mechanism described, no frequency or cost claimed | — | PASS |
| 10 | 3 | "None of this is a defect in Business Central" | T2 — ours, positioning | — | PASS — complement, never compete |
| 11 | 4 | MOUs and funder agreements carry obligations with no financial footprint | T2 — ours, reasoned | — | PASS |
| 12 | 5 | Unset periods mean "valid indefinitely or can be terminated at any time" | T1 — verbatim | service-commitment-cancellation | PASS |
| 13 | 5 | External document number as a convention | T1 — the field exists and "refers to the vendor's numbering system" | purchasing-manage-purchasing | PASS — described as a convention, not as a feature for this purpose |
| 14 | 5 | Sidecar document intelligence in the customer's Azure tenancy | T2 — ours, capability language: no customer, no count, no measured result | — | PASS |
Tier summary: 8 × T1 (all verbatim), 6 × T2 — 0 × T4.
§1 is deliberately unsourced and says so. MSA, SOW and MOU definitions are general commercial knowledge; inventing a citation for them would be worse than claiming none. No legal authority, no jurisdiction and no standard is invoked, and nothing in §1 is presented as legal advice.
Claim 8 is the one absence claim and it is carried by a contrast rather than a search. We do not say "Microsoft documents no way to link an order to a master agreement." We say Business Central purchase documents have no such field while naming the Finance & Supply Chain Management object that does — which is evidence a reader can check in one click.
All five sources were fetched on 2026-09-10 or, for the two carried from earlier in the day, fetched that same day before first use. No source is cited because a sibling article used it.
No figures of ours. No count of contracts, no error rate, no time saved. The only quoted portfolio figures belong to the forum poster and are attributed.
