Human-AI Collaboration in Supply Chain Exception Reviews

Quick Answer

In an exception review, agents can check source material and organize it. One agent compares the supplier's notice with the purchase order, and another lists the order lines that may be affected, based on data the team provides. Their results are preliminary. Team members resolve conflicts between sources, and each decision goes to the person authorized to make it.

The review produces a package. The package records sources and their times, conflicts, missing items, assumptions, candidate options, and the decisions taken. It does not stand in for the company's formal business records. Actions such as contacting the supplier or changing an order happen in the systems where they belong, carried out by members with the right permissions, and their results are checked there.

The example in this article is fictional. It describes a suggested way of working; it is neither a customer case nor a test run on real data. No system was connected, and no figures in it are measured results.

The Example: One Delayed Shipment Notice

The fictional distributor has three people involved in this review. The purchasing lead handles supplier follow-up within their authority. The planner maintains planning data and the formal records that come from it. The customer service lead is authorized to confirm customer delivery commitments in this fictional team.

The team assigns two agents, one for each independent check. A notice-check agent compares the supplier's email with the purchase order line. An impact-list agent reads a planning export that the planner provides and lists order lines that may depend on the delayed supply. Neither agent connects to the company's enterprise resource planning (ERP) or planning system, and neither contacts the supplier or customers.

The team limits the material to people and agents authorized to see this customer and order data. The email and the export go to a private space shared by the three members and the two dedicated agents. Keeping files in that space is one boundary. The computers the agents run on, and any credentials stored there, form a separate boundary that the team checks on its own terms.

Ship, Arrival, and Customer Dates Are Different Facts

The supplier's email states a new ship date. A later ship date does not by itself mean the boards arrive one week late, and it does not mean every customer order that uses them is delayed. Transit time, receiving time, and stock already on hand all sit between the ship date and a customer delivery.

The review keeps three dates apart. The ship date is when goods leave the supplier, the arrival date is when they reach the distributor's warehouse, and the customer date is when an order line is scheduled for delivery. The email in the example gives a new ship date and no arrival estimate. Until someone obtains one, the arrival date is recorded as unknown.

Planning software has its own definitions for late supply. Oracle Fusion Cloud Supply Planning documentation (release 25D) describes a Late Replenishment for Sales Order exception, raised when supplies for a sales order line are due later than the line's scheduled date. The same page explains that, for constrained supply plans, this kind of order-based exception is configured as a user-defined exception. A supplier email does not by itself establish that a sales order line meets that definition. Whether any line fits it depends on linked supply and demand data and the relevant dates.

What Is Confirmed, What Conflicts, What Is Missing

Before any analysis, the team lays the material side by side. The table below uses fictional values to show the three states a fact can be in.

The export was taken before the email arrived. It therefore cannot reflect the new date, and its quantities describe Monday evening. The review records that time next to every figure drawn from the export.

Two Agents, Two Preliminary Checks

The two checks use different material and can run in parallel. One agent working through both steps in sequence would also suit a review this size. The team chose two because each check has its own input and output.

The notice-check agent reads the email and the purchase order line. It lists each field the email states, marks which fields match the order, and flags the ones that differ or are absent. In the example, it reports the new ship date, the difference between shipment quantity and order quantity, and the missing arrival estimate. An order for 500 boards and a shipment of 400 can both be correct if the shipment is partial. The agent asks what the notice covers and what is planned for the remaining 100 boards.

The impact-list agent reads the planning export. For each candidate line, it reports the part, the supply line, the linked demand or sales order line, the quantity with its unit, the relevant dates, and the export time. A line that uses the same part, or ships in the same week, without a recorded link, goes on a separate list of lines to check. The agent does not present its output as a complete list of affected orders.

The two results are preliminary. Both depend on the same documents, so agreement between them does not count as independent confirmation. Until the scope of the delay is confirmed, the impact list stays conditional. If the team requests scenarios for a delay affecting 400 boards or all 500, each version labels that scope as an assumption and identifies the allocation data still needed.

Resolving Conflicts Between Sources

The purchasing lead asks whether 400 boards is a partial shipment, a revised total, or an error, and whether the new date applies to that shipment or the whole order. The answer also needs to explain the status of any remaining quantity. The answer, its time, and the person who received it go into the review record. Until then, the review leaves the affected quantity unresolved.

The newer email and the older export also disagree on the ship date. Neither source wins automatically. The email is more recent, and the export reflects the formal record as of Monday. The review notes the source, time, status, and owner of each version, and the planner confirms the current state with the purchasing lead.

Once the new date and quantity are confirmed, the planner updates the formal record in the planning system. The review then continues from that confirmed state. A conflict closed this way leaves a trace in both places. The review package shows how it was resolved, and the formal record holds the current figures.

Options and Who Decides Each

The review ends with candidate options. Each comes with its prerequisites and the person who decides it, and none of them is carried out by the agents.

A decision by the purchasing lead does not stand in for approvals that belong to others. The alternate source, for example, may need sign-off on quality or cost before anyone places an order. Customer commitments stay with the customer service lead.

Each action then happens in its own system. The purchasing lead contacts the supplier through the company's usual channel, and the customer service lead updates customers where they are reached. The result of each action is checked in the system where it took place.

What the Review Package Contains

The package collects the review in one place. It contains the following records:

• Each source, with the time it was received or extracted.
• Facts sorted into confirmed, conflicting, and missing.
• Assumptions, labeled as assumptions.
• Candidate order lines, each with the link and dates that support it, and the lines still to check.
• Options with their prerequisites.
• The person who made each decision, their scope of authority, and the decision itself.
• Actions still to be carried out, the owner of each, and the evidence still needed to confirm them.

A decision recorded in the package is a decision, and it does not mean the action has been completed. A task should not show an order as changed when the team has approved a plan and nobody has yet carried it out. A task that tracks the order change stays open with an owner and a next action until execution evidence is checked. A review-only task can close when its package is accepted, with any later actions tracked in separate tasks that name their owners.

The package supports the review and does not stand in for the company's formal records. Order status, quantities, and dates live in the systems the business relies on for them.

A Checklist Before Closing the Review

The questions below summarize the example. A team can use them before marking an exception review as complete.

• Are ship, arrival, and customer dates recorded separately, with unknown dates marked as unknown?
• Does every candidate order line show the link and dates that support it?
• Are lines without a recorded link listed as lines to check?
• Is every conflict between sources recorded with its source, time, status, and owner?
• Has each confirmed change been entered in the formal record?
• Does each decision name the person who made it and their scope of authority?
• Are actions still open tracked with an owner and the evidence needed to confirm them?

Where Syfo Fits

Syfo publishes this article. The features mentioned here come from its documentation, and the example did not run in the product.

A Syfo task records an owner, a status, a next action, and deliverables, which suits an exception review that moves from preliminary checks to decisions and follow-up. Syfo's documentation describes deliverables as items that need explicit marking, so the team marks the final review package on the task. Its files documentation advises placing sensitive files in a private channel or a controlled task. Its security guidance separates channel attachments from an agent's working files, which stay on the computer where the agent runs.

The documentation used for this article does not describe connections between Syfo and ERP, warehouse, or transportation systems. The example does not rely on any. Syfo's security guidance lists payments, contract-related actions, and external commitments among actions an agent should not carry out automatically, and the example leaves those actions with authorized team members.

FAQ

Can the agents in this example change orders or inventory directly?

The agents in this example read files the team provided. They do not connect to or write to any business system. This article does not describe what agents could do with other access, and that question depends on the permissions a company grants in its own systems.

Does an exception review need more than one agent?

One agent working step by step can handle a review like this one. The example uses two because the notice check and the impact list have separate inputs and outputs. Adding agents does not make their results independent of each other.

What should a team do when the email and the system records disagree?

Record the source, time, status, and owner of each version, and confirm the current state with the responsible business owner. Once it is confirmed, update the formal record and continue from there. A newer email and an older export can each be partly right.

What if the material is not enough to identify affected orders?

List the candidate lines with their supporting links, list the items still to check, and state what is missing. A conditional list with open questions gives decision makers more to work with than a list filled in by guesswork.

Sources

The definition of the Late Replenishment for Sales Order exception, and its configuration as a user-defined exception for constrained supply plans, come from Oracle's Configure Order-Based Exceptions for Constrained Supply Plans (Oracle Fusion Cloud Supply Planning, release 25D).

Task fields come from Syfo's Tasks documentation, and deliverable marking and the placement of sensitive files from Files & Deliverables. Guidance on attachments compared with working files, and actions that need confirmation, comes from Security & Permissions. All pages were read on October 20, 2026.