Executive summary
For organizations looking at or using Microsoft Dynamics 365 Finance and Supply Chain Management, there is a choice that needs to be made around architecture of your ERP environment. The clearest way to explain the architecture decision we are discussing is through the example of using Framework Interchange. This is an EDI package for Microsoft Dynamics 365 Finance & Operations that generates, validates and transports X12 / EDIFACT and API transactions inside the customer’s own Dynamics environment. There is no external infrastructure.
That design was originally about security, simplicity and continuity. It has turned out to matter for a far more critical reason, and that reason is the subject of this paper.
Organizations everywhere are discovering that AI gives them plausible, confident, and wrong answers about their own operations. The usual explanations are that the model is not good enough, or that the data is dirty. Both explanations are now mostly out of date. Frontier models like Microsoft Co-Pilot, Anthropic Claude, and ChatGPT Astra are extremely capable. They are now capable of processing many standard ERP processes. Data quality is a solved discipline as well — you can profile, cleanse and validate your data, and many companies have completed this against their ERP data only to find the results with AI still lacking.
The explanation that survives is architectural. A canonical model is an agreed upon structure that gives meaning to what the data represents, not just what it holds. AI is only as good as the canonical model of the data it is given. the structure that says what each value is, what it is called, what it relates to, what states it can be in, and what rules govern it. Microsoft Dynamics 365 contains one of the most thoroughly worked-out canonical models in enterprise software, refined across decades of Dynamics AX and Finance & Operations releases. When trading partner data is processed inside that model, AI inherits all of it for free. When the data is extracted, flattened and merged into someone else’s platform, that meaning is left behind — and nothing in the output warns you that it happened.
The practical consequence is that where you process EDI and API traffic, it is now an AI decision, not just an integration decision. Processing it inside Dynamics keeps one data model, one owner and one security boundary. Those three things are what make both integration and AI efficient and more accurate.
1. Framework Interchange: the EDI engine comes to the data
Framework Interchange is a Dynamics 365 Finance & Operations product, written in X++ on the Data Management Framework. It is installed as a deployable package into the customer’s own environment, which means it lives where the customer’s other Dynamics extensions already live.
What it does, concretely:
Full X12 and EDIFACT. Any transaction set, defined by using any LLM model to create the map form the trading partner to Dynamics 365.
Generated inside Finance & Operations. ISA, GS and ST envelopes, partner-specific maps and any business logic you apply all execute in your instance.
Validated before it leaves. X12 and EDIFACT compliance checking, automatic 997 and 999 handling, and a test workbench where a raw EDI string can be pasted and parsed without touching production data.
Transported through your Azure. Azure Files and Storage Queues for file handling; SFTP, FTPS and AS2 endpoints for partner connections; pull from a partner mailbox or let them push to yours. Your tenant, your keys, your certificates. Where a trading partner uses a VAN, Interchange sends to that VAN from your tenant.
Auto-Map. Give it a partner’s existing EDI files and it proposes the map. Over 100 configurable mapping actions cover date formats, qualifiers and conversions, so most partners need no custom code.
Interfaces, processes and records API transactions inside Dynamics 365.
Yours to extend. X++ extension points at map, load, parse, stage and process, and a single error processor that brings file, validation, Data Management and mapping errors into one screen.
| RECEIVE | PARSE | MAP IN D365 | POST | REASON |
|---|---|---|---|---|
| Partner drops a file on your endpoint | Interchange reads it in your instance | Mapped against live ERP master data | Staged through DMF into a real record | Advisor works on that same record |
Trace an inbound order through that row. A partner delivers an EDI X12 850 to your endpoint. Interchange retrieves it, parses it, maps it, stages it through the Data Management Framework and posts it. An 850 goes in; a live Dynamics sales order comes out. Outbound is the mirror image: you post an invoice, Interchange maps it to that customer’s implementation guide, generates the 810, validates it and writes the file to your storage for transmission.
The important part is what is absent from that description. There is no Framework-operated server in the middle, no queue we monitor, no copy of your orders or prices in our database. Also, it is fast, very fast. 80% of the EDI/API processing time is DMF doing it magic. Plus, your organization owns it all: the maps, the keys, the history and the software in your tenant, forever.
2. Why AI produces slop
Before we go further, let’s discuss why AI fails so often. "AI slop" is the polite name for output that reads well and is wrong: a confident summary of an exception that misstates the quantity at risk, a recommendation that ignores a commitment already made to a customer, a plausible answer built on a field the AI model misunderstood. Everyone running AI against operational data has seen it. There are three common explanations, and only the third holds up.
Explanation one: the model is not smart enough
This was a reasonable diagnosis two or three years ago. It is not a reasonable diagnosis now. Current frontier models reason carefully over long context, follow complex instructions, and will tell you when they are uncertain if the material lets them. If a model is handed a purchase order line and asked what it means, the limiting factor is almost never the model’s capability. Swapping one good model for another good model does not fix slop, which is itself the evidence.
Explanation two: the data is dirty
This one is true but incomplete, and it is where most effort goes. Dirty data is a solvable problem with mature tooling: profile it, deduplicate it, enforce referential integrity, validate on entry. Many organizations have done exactly that and found their AI output barely improved.
The reason is that cleansing operates on values. It makes the customer number correct, the date well-formed, the quantity numeric. It does not tell anyone what the quantity is a quantity of, which commitment it is attached to, or what happens downstream if it changes. Correct and meaningless are perfectly compatible.
Explanation three: the architecture of the data
This is the one that explains the behavior. AI reasons over whatever structure it is given. If the structure encodes the business — entities, relationships, states, rules, units, effective dates, ownership — the model reasons about the business. If the structure is a flat payload of correct values, the model reasons about a flat payload of correct values and fills the gaps with inference. Inference that looks like knowledge is exactly what slop is.
| Explanation | What it gets right | The output |
|---|---|---|
| The model is weak | Early models did hallucinate structure they could not see | Today’s models are strong; changing models rarely changes the outcome |
| The data is dirty | Bad values genuinely produce bad answers, and cleansing is worth doing | Cleansing fixes values, not meaning — clean data can still be uninterpretable |
| The data architecture is wrong | AI can only reason about what the structure expresses | This is the answer: the canonical model is the ceiling on the output |
3. What a canonical model actually gives an AI model
A canonical model is the agreed structure and meaning of a business’s data: what each thing is, what it is called, how it relates to everything else, which states it may be in, and which rules apply to it. It is the difference between a number and a fact.
Dynamics 365 Finance & Operations is, among other things, a very large canonical model. It has been refined over decades, through Dynamics AX and into Finance & Operations, by people solving real accounting, supply chain and manufacturing problems. Several parts of it do specific work for an AI:
Tables and relations. A purchase order line is not an isolated row. It is joined to the order, the vendor, the item, inventory transactions, the sales demand it covers and the ledger it will eventually post to. The joins are declared, not guessed.
Extended data types. A field is not a string; it is a typed business concept reused consistently across the application, so the same idea has the same name and shape everywhere it appears.
Enumerations. A status is a fixed set of allowed values with known transitions, not free text. The model does not have to interpret "CO" or wonder whether "Confirmed" and "confirmed" are the same state.
Units and conversions. The relationship between each, case and pallet is a stored, auditable record. A quantity is never ambiguous about what it counts.
Effective dating. Trade agreements, prices and costs are valid over date ranges, so "the price" is always the price on a particular day rather than the latest row.
Legal entities, dimensions and posting rules. The model already knows which company, which cost centre and which accounts a transaction belongs to.
Security and audit. Who may see a record and who may change it is part of the model, not a layer bolted on beside it.
Consider a single fact: a supplier confirms 750 units against an order for 1,000. Here is that same fact in two architectures.
| The fact | In a flattened extract | In the Dynamics 365 model |
|---|---|---|
| 750 | A number in a quantity field | A confirmed quantity on a purchase line, in a known unit, with a conversion to the selling unit |
| The item | A partner item code, possibly cross-referenced | Your item, with its product master, dimensions, site, warehouse and on-hand position |
| The shortfall | A difference between two numbers | An inventory transaction that no longer covers the demand it was reserved against |
| Who is affected | Not present — it is in another system | The sales orders, production orders, transfers and safety stock the line was supporting |
| How urgent | Must be supplied as a rule written by hand | Derivable from customer priority, promised dates, buffers and alternative supply already in the model |
| What may be done | Whatever the external platform is permitted to do | Bounded by approval policy, user authority and the audit trail, as for any Dynamics user |
The values are identical. The meaning is not. An AI given the left column can only produce a sentence about a number. An AI given the right column can produce a sentence about the business, and can be held to it, because every claim it makes traces to a record someone can open.
4. What is lost when the data leaves the ERP
Most integration architectures move trading-partner data out of the ERP to process it. The document is generated, translated or validated on a platform outside Dynamics, and ERP context is copied out to that platform when it is needed. That is a legitimate and widely used design. It also has a specific cost, and the cost lands on AI quality.
Three kinds of loss
Semantic loss. Typed business concepts become generic columns. Enumerations become strings. Unit conversions become assumptions. The information is not deleted — it simply stops being expressed in the structure, which for a model amounts to the same thing.
Relational loss. Inside Dynamics, related records are a join away. Outside, they have to be copied across and re-keyed, usually only the subset someone anticipated needing. The questions nobody anticipated cannot be answered, and an AI will answer them anyway.
Governance loss. Permissions, approval thresholds and audit trails have to be re-expressed in the second system and kept in step with the first. Two security models describing the same business will diverge; the only question is when.
There is a fourth, quieter cost: drift. Two copies of the same operating reality are never quite synchronized. A reconciliation step appears, then a team to run it, then a set of exceptions that exist only because there are two copies.
None of this makes external platforms wrong. They offer real advantages: large pre-connected partner networks, managed onboarding, outsourced operations and intelligence drawn from network-scale traffic. For an organization adding many small partners a year, that network reach is worth paying for, and any honest vendor should say so. The point of this section is narrower: whatever else the architecture buys you, the canonical model does not travel with the data, and AI quality follows the canonical model.
5. Mapping inside Dynamics: the ERP is in reach
The mapping step is usually treated as plumbing — move field A to field B, reformat a date, look up a code. When mapping runs inside Dynamics, it stops being plumbing, because the whole ERP is available at the moment the decision is made rather than afterwards.
| At the moment of mapping | Processing outside Dynamics | Processing inside Dynamics |
|---|---|---|
| Resolving a partner item code | A cross-reference table maintained separately | The live product master, with its variants, units and warehouse setup |
| Pricing a line | A price list synchronized on some schedule | The trade agreement in force on that date, for that customer |
| Checking availability | A periodic inventory snapshot | On-hand, reservations and planned supply as they stand now |
| Applying a business rule | Rules rewritten on the external platform | The rules already configured in Finance & Operations |
| Handling an error | A vendor portal, then a Dynamics screen | One error interface with the file, the validation and the record |
| What the result is | A payload to be imported | The record itself — a sales order, not a copy of one |
That last row is the one that matters most for AI. Outside, the output of integration is a message that later becomes a record. Inside, the output is the record. There is no second version to reconcile, no window in which the two disagree, and no mapping layer for an AI to reason through before it reaches the business.
Have you ever seen an EDI file imported that had a data error, and the ERP fixed the data on the fly? With Framework Advisor and Frameworks Interchange, the imported data can reason over the error with an AI agent to decide if the data matches a pattern. If a pattern is detected, like a new product name, or a new payment term, the fix can be emailed to a user for approval. Apon approval, the agent can automatically add the data to Dynamics and complete the EDI file import; with only one user approval, not 5 people sitting around a table on a call with their EDI vendor trying to figure out why the file will not process.
Nothing about these changes the trading partner relationship. Partners keep their specifications, their acknowledgement expectations and their preferred transport. If a partner works through a VAN, Interchange sends to that VAN. What changes is which system does the interpreting, and therefore which data model the interpretation happens in.
6. One model, one owner, one security boundary
| ONE DATA MODEL | ONE OWNER | ONE SECURITY BOUNDARY |
|---|---|---|
| EDI and AI reason over the same structure | Maps, history and intelligence stay in your tenant | One set of roles, permissions and audit applies to both |
Efficiency
A single model removes a category of work rather than automating it. There is no export, no transform, no re-import and no reconciliation between two versions of the same order. For the AI specifically, there is no retrieval layer to design, populate and maintain, and far less context has to be spent explaining what the data means — because the Dynamics metadata already says so. Both the integration and the reasoning get cheaper for the same reason: there is one thing to understand instead of two.
Ownership
Maps are the real asset in any EDI estate: they are the accumulated knowledge of how each trading partner actually behaves, which is never quite what the specification says. Under this architecture those maps, the transaction history, the connections and the configured intelligence sit in the customer’s own Dynamics environment, alongside the orders they belong to. Changing a transport, a VAN or a partner is a configuration decision rather than a migration project. Nothing is copied to Framework Systems, so there is nothing of yours for anyone else to train on.
A single security model
This is the part most often discovered late. When integration runs outside the ERP, there are two security models: the one in Dynamics and the one on the external platform, each with its own identities, roles, key material and audit log, and each needing to be reviewed. Add AI and there may be a third.
Inside Dynamics there is one. The same Microsoft Entra identities, role-based access, table permissions, data residency and audit trail that govern a user govern the EDI data and the AI alike. When Advisor proposes or executes something, it does so under the authority someone granted, recorded the way every other Dynamics action is recorded. Security review has one system to examine, not a chain.
7. What a good canonical model lets AI do
Framework Advisor is the AI companion to Interchange, running in the same Dynamics environment, on the customer’s data, using the customer’s chosen AI model through their own subscription. It is the practical demonstration of the argument in this paper: the same reasoning is worth far more when it happens where the canonical model is.
An example of Advisor working in four steps:
It recognizes business events. An 850 arrives. A planned order’s date has passed. A confirmed quantity does not match what was ordered. Each is treated as an event with meaning rather than a row in a table.
It correlates across the supply chain. The event is tied to orders, inventory, planning and production in Dynamics — the same data Interchange already writes into, so nothing is copied out.
It recommends. Advisor builds a decision package: several options, each scored against the policy the customer configured, one marked as recommended, and every individual action carrying the reason it was proposed. Then it asks.
It acts, once approved. Approved actions execute in Finance & Operations — firm a planned order, confirm, source, raise the purchase order — with a complete record of who permitted what.
Four guardrails sit underneath: a human stays in the loop, Advisor acts only within granted authority, every decision is auditable, and the AI model is the customer’s choice.
A worked example
In a live Dynamics environment, Advisor scans the results of master planning and asks which planned orders, exceptions and action messages are actually worth a decision. It produces a decision package with three scored options — apply the recommended actions, apply every offerable action, or cancel the orders planning no longer needs — and promotes the recommended one into a plan. Each line of that plan names the action, the item, the order it refers to and a column headed "why this was proposed": for example, that the order date passed 137 days ago. A person submits, approves and executes, and the planned order is firmed in Dynamics. Nothing changed before a human said so, and every step is legible afterwards.
Note what makes the reasons possible. "The order date passed 137 days ago" requires knowing what an order date is, which calendar applies, what state the order is in and what firming would mean. All that comes from the canonical model, not from the AI.
With Advisor, you can start with the it is assisting Users. It can simply recommend next steps and most likely decisions. Once advisor has gained enough historical knowledge and is advising with strong, consistently correct recommendations, you can have Advisor operate approved actions and pause exceptions. Once exceptions become below a threshold, you can have advisor automatically process transactions with a manager overseeing the process through reporting. You always have a human in the loop. When a wrong decision is made, just when a human makes a mistake, you reverse the transaction and keep going. The more automation you deploy, the more time your team has to work on other tasks and the fewer the people you need as the company grows.
How much it does is your decision
| ASSIST | OPERATE | AUTONOMOUS |
|---|---|---|
| It analyses, recommends and explains; you execute | It executes approved actions and routine exceptions; you supervise | It acts independently within policy and escalates the rest; you set the policy |
It is the same software at every level. What changes is how much of your judgment has been encoded into it, and a process can be promoted from one level to the next once results have earned the promotion.
Advisor’s direction is to extend this across procurement and sourcing, as well as manufacturing, so that every trading-partner event becomes something Advisor can reason about. That is direction rather than a dated commitment, and it should be read as such. What is production capability today is the sales and planning work described above, AI-assisted mapping through Auto-Map, and the validation and exception handling in Interchange.
8. Questions to ask any EDI / AI vendor
These questions expose the operating model rather than the marketing. A product can answer well on some and poorly on others; that is not a contradiction, it reflects a different business model. The purpose is to know what you are buying before integration plumbing quietly becomes your AI strategy.
| Area | Question to ask |
|---|---|
| Runtime | Where do mapping, transformation, validation, exception logic and AI processing execute? |
| Foundation | Is it built from the ground up to work seamlessly with Microsoft’s DMF interface without modifications? |
| Mapping | Does it generate EDI maps automatically using AI? |
| Transport | Whose tenant, keys and certificates carry the file to the trading partner? |
| Canonical model | Which data model does the AI reason over — the ERPs, or a copy flattened into the vendor’s schema? |
| Context | Can the intelligence reach live orders, inventory, production, planning, pricing and policy with real time updates without duplicating the data model elsewhere? |
| Ownership | Who controls the maps, rules, configuration, history and process intelligence built up over years? |
| Portability | If the commercial relationship ends, what can you keep and continue to use without conversion? |
| Extensibility | Can your own Dynamics team or partner extend it without routing every change through the vendor? |
| Security | How many security models, identity stores and audit trails does this add? Who reviews each one? |
| Model choice | Can you use the AI model already approved in your tenant, or are you bound to the vendor’s? |
| Continuity | If the vendor stopped operating, what keeps running? |
| Economics | What is charged per transaction, agent, run, user or module? What is the TCO over 5 years? |
9. The decision
EDI is not going away, and neither are the trading partner relationships built on it. APIs have not removed the need for business semantics. AI has not removed the need for deterministic validation, governance or process design. What has changed is that these three now share a single dependency: the structure of the data underneath them.
An organization that processes trading-partner traffic inside Dynamics 365 is choosing to keep that structure intact. Its EDI runs against the same model its planners, buyers and controllers use. Its AI reasons over decades of accumulated business semantics rather than a flattened copy without context. Its security team reviews one system. Its maps, history and configured intelligence stay on its own balance sheet.
An organization that processes it outside is choosing network reach and outsourced operations and accepting that the canonical model has to be approximated somewhere else. Both can be defensible. The mistake is to treat them as equivalent, or to make the choice on transaction fees alone and discover its consequences later, when the AI answers are confident and wrong.
Framework Systems built Interchange and Advisor for organizations that want the answer to be "inside". Interchange brings external business transactions into the customer’s Dynamics environment. Advisor reasons and acts within it. Neither requires Framework Systems to sit in the operating path, which is why the argument in this paper is an architectural one and not a promise.
About Framework Systems
Framework Systems develops Microsoft Dynamics 365-native software for business integration and operational intelligence. Framework Interchange generates, validates and transports X12 / EDIFACT and API transactions inside Dynamics 365 Finance & Operations. Framework Advisor applies contextual intelligence, exception analysis and governed automation across supply-chain business processes in that same environment. Both are written in X++ on the Data Management Framework. Learn more at frameworksystems.net, or visit Framework Systems at Community Summit North America 2026, Booth 311, Ryman Exhibit Hall.
Research notes
Market claims in this paper were checked against current vendor and Microsoft materials available in September 2026. Vendor descriptions are included to characterize architecture, not to imply that one model is universally superior. Framework roadmap items are identified separately from current production capability throughout. The numbered references are included in the downloadable document.
Qualification. This paper does not claim that competing vendors fail to give customers rights in their own maps, nor that managed platforms are inherently inferior. Its distinction is the operating model described here: Framework Systems is not required as an external runtime intermediary for Interchange or Advisor, and the business assets configured around both products remain in the customer-controlled Dynamics environment. Exact legal ownership and licence rights are governed by Framework Systems customer agreements.