The module spans the full procure-to-pay cycle and the physical handling that surrounds it. On the buying side it manages purchase requisitions, converts approved requisitions into purchase orders, and routes those orders through configurable approval workflows before they are released to a vendor. It maintains vendor records and supports vendor evaluation and scorecards, so that award decisions rest on delivery performance, quality and price rather than habit.

On the receiving and fulfilment side it records goods receipt against open orders, reconciles what was ordered with what arrived and what was invoiced, and manages the warehouse: physical locations and bins, and the pick, pack and ship cycle for outbound movement. Around all of this sits logistics tracking and carrier management, giving visibility of shipments in transit and a structured relationship with the carriers that move them. The four dashboard areas, procurement, purchase orders, logistics and warehousing, map directly onto these responsibilities and form the module's working surface.

The domain is built around a small set of durable entities. A vendor is the counterparty an order is placed with, carrying terms, contact and performance history, and it is the anchor for the scorecard that accumulates delivery and quality metrics over time. A purchase requisition captures an internal request to buy: what is needed, in what quantity, for which cost centre or work order. An approved requisition becomes a purchase order, the commercial commitment, composed of header terms and line items each referencing a catalogue or material record, a quantity, a price and an expected delivery.

Against a purchase order line the module records a goods receipt, the event that confirms physical arrival and quantity. Warehouse structure is modelled as a hierarchy of locations and bins, the addressable places stock rests, while outbound demand is served through pick, pack and ship records that draw against those bins. Shipments and carriers model goods in motion. These entities are deliberately shared: the purchase order line is the same object that Accounting & Control matches an invoice against, and the material on a line is the same item Manufacturing & Operations plans and inventory counts, which keeps a single version of each fact across the suite.

The central process is requisition to order to receipt to settlement. A requester raises a requisition; it passes through an approval workflow whose steps and thresholds are configurable by value, category or cost centre. On approval the requisition is converted into a purchase order, which itself may require a further release approval before it reaches the vendor. When goods arrive, a receipt is booked against the order, updating expected-versus-actual quantities and making the stock available in its receiving bin.

The outbound workflow runs the other way: demand triggers a pick from the correct bins, a pack step consolidates the picked items, and a ship step hands the consignment to a carrier and opens a tracked shipment. In parallel, vendor evaluation runs as a continuous background process rather than a single event, with each receipt and each on-time or late delivery feeding the vendor scorecard so that the next sourcing decision is informed by evidence. Each of these workflows produces an auditable trail of who requested, who approved, what was received and when it moved.

The financial discipline of the module lives in matching. Goods receipt supports both two-way and three-way matching against Accounts Payable. In a two-way match the vendor invoice is reconciled against the purchase order; in a three-way match the purchase order, the goods receipt and the invoice must all agree on quantity and price within defined tolerances before the invoice is cleared for posting. This is the control that prevents payment for goods never ordered or never received, and it is enforced at the line level rather than the document level so that partial deliveries and partial invoices are handled correctly.

The accounting treatment follows from the same events. A goods receipt against an order gives rise to a goods-received-not-invoiced position, the recognised liability for stock that has arrived but not yet been billed, which is later cleared when the matched invoice posts in Accounting & Control. Approval thresholds, segregation between requester and approver, and match tolerances together form the module's control framework, giving finance a defensible answer to why every purchase liability exists. Warehouse controls, accurate bin-level quantities and receipt confirmation, keep the physical record aligned with the financial one.

Supply Chain Management is an operational hub that only delivers value connected to its neighbours. It integrates with Manufacturing & Operations through the bill of materials: production demand explodes a BOM into component requirements, and those requirements flow into the module as requisitions and purchase orders, so procurement is driven by real production plans rather than manual reorder. It integrates with Accounting & Control for AP posting: matched receipts and invoices become posted liabilities and, ultimately, payments, with the purchase order line as the shared reference on both sides.

It integrates with inventory so that goods receipt, bin movements and pick, pack and ship keep on-hand quantities and valuations current across the enterprise. Because the module reuses shared vendor, material and order entities rather than private copies, these integrations are matters of reference rather than synchronisation, which removes a common class of reconciliation error. The result is a procurement and warehousing spine that manufacturing plans into, finance settles from, and inventory reflects, all against one set of records.

The suite treats AI Workers as first-class users, and Supply Chain Management is a natural place for them to act. A worker can be queried conversationally over module data: which orders are overdue, which vendors slipped on delivery this quarter, how much value sits in goods-received-not-invoiced. It can execute actions within its granted permissions, raising a requisition from a shortfall, drafting a purchase order, or booking a receipt from a delivery note.

Workers run anomaly and exception alerting across the flow: a price that deviates from the order, a three-way match that will not reconcile within tolerance, a shipment that has stopped moving, a vendor whose scorecard is trending down. They perform document and data extraction, reading a supplier invoice or delivery note and mapping its lines onto the open purchase order to propose a match. They offer decision support for sourcing, weighing scorecard history against price and lead time. Critically, a worker can be placed as an approval or review node in a requisition or purchase-order workflow, applying policy at a defined threshold and escalating anything outside it to a human, so automation and control advance together rather than at each other's expense.