There is a family business in Belgium that makes caviar, called Imperial Heritage Caviar. Its client list includes Michelin three-star restaurants, luxury hotels, and a private yacht owner. The company is small, with about 500 active customers in the system.
Its order channels are very real: WhatsApp, email, SMS, phone. Chefs often only remember after the evening service ends that they need to restock for the next day, and messages often come in all night. In the past, entering these orders into Dynamics 365 Business Central took one to two hours every day. The bigger the business, the more these two hours feel like a thorn—what they squeeze out is not administrative time, but time talking with customers.
On November 11, 2026, Microsoft posted this case in its customer stories section. The results are not hard to guess: manual order entry was reduced to under 30 minutes, routine order preparation takes only a few seconds, and rework on complex orders "almost disappeared." But what is really worth looking at is not these numbers, but how they drew the boundaries.
I. Two agents, three skills, one confirmation button
At first, they wanted to use the sales order agent built into Business Central. That agent mainly handles orders that come in via email, following a single lead all the way through, and it couldn't meet the needs of multiple channels. What's more troublesome is that everyone in the company prefers different AI tools—some are used to Copilot in Teams, while others are used to Claude.
So technology partner Deltanexx built two: one based on Microsoft Copilot Studio, and one based on Anthropic's Claude. Both connect through Business Central's MCP server and can read, write, and execute in real time. At the upper layer, two “brains” were swapped in, while the lower layer shares the same set of interfaces.
There are only three skills, and they are all business actions, not technical actions: creating sales orders, creating customer profiles, and producing customer follow-up reports. They may seem few, but each one corresponds to something that must happen every day.
| Skills | How are boundaries drawn? | Why is it divided like this? |
|---|---|---|
| Create sales order | Translate natural language into customer and material records, referencing historical invoices to reproduce agreed prices and product codes; present the details first, and create only after human confirmation | Once an order is persisted to the database, it reserves inventory and factors into delivery lead time; one wrong order means three places have to be changed in sequence. |
| Create customer profile | Before creating a new one, first check whether this customer already exists in the system. | Creating duplicate records will not trigger an error, but it will cause reconciliation, rebates, and credit limits to all be misaligned. |
| Customer Follow-up Report | Generate weekly reports and sales overview, do not send externally | Reports are meant for people to make judgments, not for machines to execute |
The governance section is written in greater detail than the functionality—this is where the value of the case lies. On the Copilot Studio side, it uses Business Central MCP tools plus Microsoft's pre-registered application; on the Claude side, a separate application is registered in the customer's own Microsoft Entra ID tenant, with delegated access consented to by an administrator. The MCP configuration itself defines which APIs and operations the agent can call, and Azure Application Insights logs the calls for monitoring and support.
In plain terms: It's not about giving the agent a super account, but giving it a pass that clearly states which doors it can open, plus an entry and exit logbook.
The minimal structure of this case can be copied directly: one entry point (natural language, any channel) + three skills (create orders, create customers, generate reports) + one confirmation key (a human must review before saving to the database) + one audit log (who called what). Once these four things are in place, a company of a dozen or so people can maintain it themselves, without setting up an "AI platform project".
II. The truly difficult part is not reading the documents; it is recognizing them correctly
Four days ago, GrubMarket, a US food supply chain company, released a purchase order agent. What it does is very similar to the above: it converts supplier invoices, receiving receipts, and even a piece of natural language into structured purchase orders, which users can review and write into ERP with one click.
What is interesting in the product description is not the recognition capability—support for photos, PDFs, tables, and plain text is already a basic requirement in 2025. What is interesting is the section on matching: product matching does not just compare names; rather, it uses historical order behavior, a customer-configured "enterprise dictionary," and AI training specific to each supplier to map the product names written by suppliers to the distributor's own product catalog.
This sentence points out one thing. The bottleneck of document automation has long ceased to be 'reading it' and lies instead in 'recognizing it correctly'.
| segment | Apparent difficulties | The actual difficulty |
|---|---|---|
| Read Documents | How accurate is OCR, and how many formats does it support? | It is relatively mature; it is an engineering problem that can be solved if one is willing to spend money. |
| Recognize products | Does the name match? | Supplier part numbers are not equal to internal part numbers; one item has multiple names; new products have no history for reference |
| Calculate quantity | Did you copy the numbers correctly? | When purchasing units differ from inventory units, a single conversion error among boxes, pieces, and kilograms will throw off both inventory and costs. |
| Set price | There is an amount on the invoice. | Tax-inclusive vs. tax-exclusive, freight and surcharges, ad hoc negotiated pricing—when the basis differs, reconciliation clashes. |
What is even more troublesome is that errors at these four checkpoints do not cancel each other out; instead, each one amplifies the others. If the material on a purchase order is written wrong, inventory gains a batch of goods that does not exist, costs are allocated into finished products at the wrong unit price, gross profit analysis becomes distorted accordingly, and accounts payable ends up having to argue with the supplier once. Read one character wrong, and four departments each have to redo their work once.
This also explains why something as unsexy-sounding as a "corporate dictionary" is starting to be productized. It is not a knowledge base; rather, it codifies the company's internal naming conventions into a maintainable table: who maintains it, how often it is updated, and how old and new part numbers coexist. This is a management problem, not a model problem.
Third, putting this set of things back into Odoo comes down to four specific hurdles
If you are implementing Odoo, the points above can be applied step by step to specific tables and fields. The advantage of Odoo is that these things are all in the same database, so you do not need to stitch them together across systems; the disadvantage is also the same—make one mistake, and the entire database goes wrong together.
| Level | What does it correspond to in Odoo? | Common pitfalls |
|---|---|---|
| Customer | res.partner, duplicate warning based on name, email, phone, tax ID | A warning is not a block. Records with the same name under different entities, groups and stores created together, and overseas customers without tax IDs will all leave duplicate records. |
| Materials | Internal Reference and Barcode of product.product; Vendor Part Number and Vendor Product Name on product.supplierinfo | Supplier part numbers exist only in the counterparty's system; the same material has multiple aliases; new products have no historical orders for reference |
| Unit | Conversion factor between uom.uom and uom.category; the purchasing unit can differ from the inventory unit. | Purchasing is by the case, inventory by the piece, and sales by the kilogram; these three units belong to different categories, and a conversion error means systematic bias. |
| Price | Supplier prices of product.supplierinfo, customer pricelists, and historical invoice lines | Mixing tax-inclusive and tax-exclusive amounts; freight not included in cost; temporary negotiated price entered into unit price but no one changed it back to the price list |
Among the four gates, the second is the easiest to implement and yields the greatest benefit. Odoo's supplierinfo is inherently a mapping table from "the supplier's terms to our terms," except that many projects only fill in price and lead time at go-live, leaving supplier part numbers and product names blank. By the time document automation is needed, they discover this table is empty—so the agent can only guess via fuzzy matching, and the error rate is so high that the business dares not use it.
A concrete suggestion: Treat supplierinfo as a data asset to be governed, not as a price list to be filled in. For the top 50 commonly used materials from each major supplier, complete the four fields—supplier part number, supplier product name, minimum packaging, and lead time—and the accuracy of document automation will change visibly. This work doesn't require AI, just one person and two weeks.
Which layer should the confirmation key be placed in?
In that Microsoft case, confirmation occurs before the order is created. Mapped to Odoo, this corresponds to one clear line: the agent only writes drafts, and the confirmation action is triggered by a human.
- Sales side: the agent creates a draft quotation for sale.order, and a human reviews it and then clicks confirm; do not let the agent go directly to the confirmed state.
- Purchasing side: the agent creates a request for quotation for purchase.order, and after human review, it is converted to a purchase order.
- Accounting side: the agent only creates account.move drafts; posting is done by a human.
The reason is simple: a draft can be changed, deleted, or disregarded; once confirmed, inventory reservations, delivery commitments, and financial vouchers will occur in a chain reaction. Leaving irreversible actions to humans is the cheapest risk control for this type of project.
There is another thing that is often overlooked: the confirmation page must present a “difference that people can understand.” Merely showing “Agent suggestion: customer ABC, material XYZ, quantity 200” gives people no way to judge. What should be shown is what has changed compared with history—the customer changed, the material changed, the unit price is 8% higher than last time, and the delivery date is three days shorter than the standard commitment. The difference is the basis for judgment; a list of fields is not.
IV. Three Points for Implementers
First, treat alias tables as deliverables.Add three tables to the project acceptance checklist: supplier part number cross-reference, customer short name cross-reference, and unit conversion cross-reference. Each table must have a maintainer, update frequency, and deprecation flag. Without these three tables, no matter how smart the agent is, it can only guess; with these three tables, even the simplest rule matching can run.
Second, start by only doing 'read' and 'draft'; don't rush into 'modify'.Reading data, generating drafts, and showing people the differences—if these three things go wrong, the cost is small. Changing prices, changing delivery dates, deleting rows, and merging documents—if these four things go wrong, it takes a long time to trace back. The failure point for many projects is not a lack of capability, but turning write permissions to the maximum on the first day.
Third, use historical documents for replay testing, not demo data.Pull 100 real documents from the past month, deliberately covering four types of situations: new customers, new materials, temporary price changes, and returns. Measure two metrics: first-pass rate, and the average number of fields that need manual correction. These two numbers are more honest than any demo.
The step most easily skipped:Replay testing must include "running the same document through once more via a different entry point." Are the results consistent between what comes in by email and what's said in chat? Where they're inconsistent, is it a channel difference or is the system guessing? This question can't be asked during the demo stage—only replay can ask it.
Back to that Belgian company. Their solution took only a few weeks to develop; the procurement and supplier APIs were already integrated into MCP, and the next step is to build procurement skills. This pace says one thing: when interfaces, permissions, and skill boundaries are all kept in one place, the marginal cost of adding a new skill is very low. What really takes time is the preceding weeks of thinking through the boundaries clearly.
Many companies in China are stuck on the opposite issue: they have integrated three model providers, written over a dozen interfaces, and built twenty skills, but no one is maintaining supplier part numbers, and there are three thousand duplicate contacts lying in the customer records. Deploying agents at this point is like sending a newcomer to visit customers with the wrong phone book: the faster they run, the more mistakes they make.
One-sentence summary: AI's competitiveness in document handling ultimately doesn't rest on the model; it rests on how many unmaintained mapping tables your company has. Models change generation every three months; mapping tables don't grow on their own.
Sources: Microsoft Customer Stories《Imperial Heritage Caviar doubles time saved on administrative tasks by adding AI to its Dynamics 365 Business Central platform》(2026-11-11, including remarks by company owner Elisabeth Colman and Deltanexx managing partner Dhia Athmini, as well as governance details such as MCP configuration, Entra ID application registration, and Application Insights logging); PR Newswire《GrubMarket Launches AI Agent That Transforms Purchase Order Processing for Food Distributors》(2026-11-10, including enterprise dictionary, supplier-specific training, multi-channel submission, and ERP integration scope). The Odoo-side field and mechanism descriptions are based on standard Odoo 19/20 functionality; specific behavior varies by version and localization modules, and must be verified in a test database before implementation.
Data basis note: The Belgium case’s “1–2 hours per day reduced to under 30 minutes,” “routine preparation in a few seconds,” and “rework almost eliminated” are all customer-side estimates, and no statistical period or sample size was disclosed; GrubMarket did not disclose matching accuracy, customer count, or pricing. The Odoo recommendations in the text are judgments based on implementation experience and do not constitute a commitment to specific project results.
Zodioo Information (Zodioo) · Enterprise Digitalization Observation · 2026-11-12
