The exception is in the email, not your ERP

Every order management team has seen some version of this email. A supplier replies to a purchase order: "Confirmed, see attached. Line 3 will go in two drops, second one TBC, will advise." The attachment shows every line confirmed, full quantity, on the requested date.

Someone keys the acknowledgment into the ERP and moves on. By every measure the system can apply, the order is correct: fields populated, dates valid, status confirmed.

It's also wrong. Part of line 3 has no date at all, and that fact was never in a field. The record did its job perfectly and still missed the one thing your customer was going to feel.

Your ERP isn't broken. It was built to store fields, not read sentences. Exceptions usually arrive in sentences. So the part of execution that costs you the most is the part your systems can't see.

Why a system of record can't read the work it records

Look at what a system of record actually holds. Every order has a quantity, a date, a status, a ship-to. That structure is what makes it valuable: you can report on it, reconcile against it, and audit it.

It's also what makes it blind. A schema only holds what someone decided in advance was worth a field. Exceptions are the things nobody planned for: a split shipment, a partial short, a date "tentative pending raw material," a retailer notice that changes next month's routing guide. When reality departs from the plan, nobody updates a field. People write to each other, in prose, usually with an attachment. If someone catches it, the record catches up later, once they've read the message, decided what it means, and keyed in the change. If no one does, the first sign is the customer asking where their order is.

So the record captures the plan and, eventually, the outcome. Most of what happens in between plays out in emails, PDFs, portals, and threads, and that's where the outcome gets decided. That's unstructured data: information your systems can't act on because it never made it into a field.

The distance between what's written down and what the record knows is what we call the execution gap. It drives the roughly 2% of revenue that leaks out of a typical enterprise supply chain: about $20M a year for a $1B company.

Where unstructured data lives in supply chain execution

"Unstructured data" sounds like a storage problem. It isn't. It's a handful of specific documents, each carrying something the record misses.

1. Supplier confirmations. PDFs whose layout changes when the supplier upgrades their system, plus a cover email that sometimes disagrees with the attachment. The disagreement is usually the signal.
2. Shipping documents. Bills of lading, packing lists, and proofs of delivery, where a carton count or a signature note says more about what arrived than the status update does.
3. Retailer portals and compliance notices. Chargeback backup, routing guide updates, and deduction detail, built for a person reading one screen at a time.
4. Shared inboxes and long threads. Where an expedite gets negotiated, a substitution gets approved, or a commitment quietly moves, across six replies and three people.
5. Spreadsheets passed between teams. The allocation sheet, the open-PO tracker, the list of customers who get a call before a notice. Often the most current version of a business rule, and in nobody's system.

None of this is exotic. It's the daily working surface of order management, customer operations, procurement, and logistics.

Reading is not the same as extracting

Plenty of tools can pull text out of a PDF or classify an email. That's useful, and it's not the hard part.

Take the email above. Extraction gets you "line 3, two drops, second TBC." On its own, that isn't actionable. A workflow still has four steps to go:

1. Reconcile it against the record. The acknowledgment says line 3 is confirmed in full. The email says it isn't. The workflow has to detect the conflict and decide, under your business rules, which source governs the next action. Here, the supplier's explicit qualification changes what the confirmation means.
2. Interpret it in context. Does an undated second drop matter? That depends on what line 3 was promised against, whether stock exists elsewhere, and which customer is waiting. A TBC on a replenishment order is routine. A TBC against a retailer's must-arrive-by date is an escalation.
3. Choose a response. Chase the supplier, source the balance elsewhere, adjust the customer commitment, or flag the account owner. Your rules decide which.
4. Act and write back, with the evidence attached. Update the record to match reality, and keep the link to the sentence, document, and rule that justified the change.

That's the gap an AI Execution Layer closes. It works inside the systems you already run, reads what they can't act on, and orchestrates the response across your teams, suppliers, and customers.

It's the same distinction we drew in why brittle scripts break: the costliest failures aren't inputs that fail to parse. They're inputs that parse cleanly and are wrong to act on. It's also why "we added document AI" isn't the same claim as "we close the execution gap." One gets the text out. The other decides what the text means for the order, and acts on it.

How to trust an agent that reads your inbox

Once software can read the same documents your team reads, the question changes. It's no longer whether the technology understands the document. It's whether you can trust what happens next.

That comes down to four properties worth asking any vendor about:

• Provenance on every action. Every change should point back to the exact document, line, or sentence behind it. If a buyer asks why a commitment date moved, the answer should be one click away, in the supplier's own words.
• Uncertainty that routes instead of guesses. When a document is ambiguous (say, "second one TBC, will advise" and nothing more), the workflow should escalate to a named person with its reasoning attached, not pick the likeliest reading and carry on.
• Scoped access. A workflow that reads one region's supplier confirmations has no business in the finance inbox. Access should be as narrow as the job, and defined in advance.
• An audit trail a stranger can follow. What was read, what was concluded, which rule applied, and who approved it, in a form someone outside the team can reconstruct.

This matters most when two legitimate sources disagree. Trust doesn't come from pretending there's always one authoritative record. It comes from making the conflict visible, applying your rules, and keeping the evidence behind the decision.

Emerix operates under SOC 2 Type II, and we covered how these controls are scoped in grounding an agent in your business and how autonomy grows per workflow in the spectrum of autonomy. Put simply: a workflow that reads your documents should start by recommending, show its sources, and earn the right to act on its own.

Why this doesn't wait for standardized inputs

Standardizing supplier formats, or moving everyone onto EDI or a portal, is a reasonable goal. It just isn't a prerequisite.

Suppliers change systems. Retailers change requirements. Carriers send exceptions in prose. Even suppliers on EDI still send the email that explains the short. That's not a data problem to fix first. It's how companies talk to each other about exceptions.

So rather than waiting for the inputs to change, you read them as they are. That also keeps the first step small: one workflow where exceptions cost the most, reading only the documents it depends on, inside the systems you already run. A first workflow is typically live in about 12 weeks, because the scope is that narrow.

What your own data needs to be ready is a separate question, and the subject of an upcoming post.

Back to line 3. Everything in the system said confirmed. The only thing that said otherwise was a sentence.

Most teams already know where those sentences live: the shared inbox, last Thursday's thread, the portal notice someone meant to forward. Here's a simple way to size the gap. Take the last ten exceptions your team resolved, and count how many were settled by something your system of record never saw. That number is how much of your execution still runs on reading by hand.

Alison Crawford is Director of Product Marketing at Emerix, the AI Execution Layer for supply chain. She has spent her career in supply chain software, with prior roles at RELEX Solutions, Aera Technology, o9 Solutions, and Kinaxis, and was recognized in the 2023 Women in Supply Chain Awards. She writes about the distance between what supply chain software promises and what it actually executes. Connect with Alison on LinkedIn.

Frequently asked questions

What is unstructured data in supply chain execution?
It's the information that drives execution decisions but isn't represented in the system-of-record fields a workflow depends on: supplier emails and PDF acknowledgments, bills of lading, retailer portal notices, long email threads, and spreadsheets passed between teams. Some of it is technically semi-structured. What matters operationally is that it sits outside the record the workflow can act on.

Why can't an ERP or WMS handle unstructured data?
Systems of record are built around schemas, transactions, and predefined fields. They can store documents and, with additional technology, extract information from them. The harder problem is interpreting what that information means in context, reconciling it when it conflicts with the record, choosing the right response under your business rules, and carrying that response through execution.

Isn't this just OCR or intelligent document processing?
Extraction is one step. Acting on unstructured data also means reconciling the document against the record, judging whether the difference matters for this order and customer, choosing a response under your rules, and writing back with the source attached. Extraction produces text. Execution determines what the text changes and what should happen next.

How do you know an agent read a document correctly?
Every action should link to the document, line, or sentence it was based on. When sources conflict, the workflow should show the conflict and the rule used to resolve it. Ambiguous inputs should go to a named person with the reasoning attached, not be settled by a best guess. And the full trail should be auditable after the fact.

Do we need to standardize supplier formats before starting?
No. You rarely control the formats your suppliers, carriers, and retailers use, and exceptions arrive in prose regardless. Standardization can reduce variation, but it won't eliminate exceptions. Starting with one workflow and the documents it depends on is faster than normalizing every input first.