Supply chain management software requirements: the complete checklist for buyers and builders

Every supply chain software project starts with a requirements document, and most of those documents are a list of feature names copied from vendor websites: lot tracking, demand forecasting, carrier integration, real-time visibility. A list like that cannot be tested, cannot be prioritized, and cannot tell a vendor or a development team what the business actually needs the software to do on a Tuesday afternoon when a truck arrives with the wrong pallets. It produces demos that look complete and systems that are not.

This article is the requirements document done properly. It walks through the six modules of supply chain management software (procurement and supplier management, demand and supply planning, inventory and warehouse management, order management, transportation, and visibility and analytics) and states the requirements for each as testable statements a buyer can prioritize and a builder can estimate. It then covers the requirements that sit across every module and decide whether any of it works: integration, data, security, and the non-functional requirements that make a system usable on a warehouse floor.

It is written for two readers. Buyers evaluating packaged software or a custom supply chain and logistics build can turn it into an RFP by adding their own priorities and volumes. Product and engineering teams building the system can turn it into a backlog. Both should read the section on phasing before either, because the most common failure is trying to specify and deliver all six modules at once. The companion guide on implementing a supply chain system covers what happens after the requirements are agreed.

How to write a requirement that can be tested, prioritized, and estimated

A requirement has four parts: the actor, the action, the condition, and the measure. "A warehouse operator can record a receipt against a purchase order by scanning the item and lot barcodes on a mobile device, with the receipt visible in inventory within two seconds" names who, what, how, and how well. Every requirement in this article follows that pattern or can be expanded to it. Requirements written this way can be demonstrated in a vendor evaluation (ask them to do exactly that), estimated by a development team (they know what a mobile receipt against a PO involves), and tested at acceptance (it either happens in two seconds or it does not).

Each requirement also needs a priority. The MoSCoW scheme (must, should, could, will not this time) is adequate and widely understood. Must means the system is unusable without it; should means a workaround exists but hurts; could means it would be nice; will not means it has been considered and deliberately deferred, which is worth recording so it does not resurface as scope creep. A useful discipline is to cap must requirements at roughly a third of the total; a document where everything is must has not been prioritized.

Finally, attach volumes and context. A requirement to pick orders means something different at 200 lines a day than at 20,000, and a requirement for lot tracking means something different for frozen food with expiry dates than for fasteners. The volumes section of a requirements document (SKUs, locations, orders per day at average and peak, lines per order, suppliers, carriers, users) is short and is the first thing an experienced vendor or architect will read. The guide to inventory management software features covers the inventory module in more depth; this document treats each module at the level of requirements a buyer must decide on.

Requirements habits that survive the RFP, and the ones that do not

Do this

• Actor, action, condition, measureA picker can complete a wave pick of up to 40 lines on a mobile device with each scan confirmed in under a second.
• A priority on every lineMust, should, could, or will not. Cap must at about a third.
• Volumes up frontSKUs, locations, orders per day at peak, lines per order, users. One short table.
• Exceptions written downWhat happens when the lot is not on the PO, the carrier rejects the tender, the count does not match.

Not this

• Feature names as requirementsSupports lot tracking. Supports what, for whom, how fast, and when the lot is unknown?
• Everything is mustA document with no priorities forces the vendor or team to guess which third actually matters.
• Best practice and industry standardUndefinable. Whose practice, which industry, as of when?
• Requirements copied from a vendor brochureYou will specify the vendor's product and discover your own needs in production.

Module 1: procurement and supplier management

Procurement is where the supply chain starts and where the most money is committed, and its requirements center on the purchase order lifecycle and the supplier record. The supplier master must hold contacts, addresses, payment terms, lead times by item, minimum order quantities, price lists with validity dates, certifications and compliance documents with expiry, and a performance history. Requisitions must be raised by users or generated by planning, routed for approval by rules (amount, category, cost center), and converted to purchase orders. Purchase orders must be sent to suppliers by email, portal, or EDI, acknowledged, amended with a change history, and tracked through expected receipt.

Receiving closes the loop and is where procurement meets the warehouse. The system must match receipts to purchase orders by line, handle over- and under-delivery against tolerances, record quality inspection outcomes with quarantine and rejection flows, and support three-way matching of PO, receipt, and invoice for accounts payable. Supplier performance must be measurable from this data: on-time delivery, fill rate, quality rejections, and lead time variance, by supplier and by item, without a spreadsheet.

Sourcing requirements depend on the business. Companies with strategic sourcing need RFQ and RFP management with supplier responses, comparison, and award; companies buying to catalog need contract pricing and punch-out to supplier catalogs. Both need a supplier portal or EDI so suppliers can see orders, confirm, and submit advance shipping notices without email. A requirement often missed is supplier onboarding: the workflow by which a new supplier submits documents, is vetted, and becomes orderable, with a record of who approved what.

Procurement requirements, with typical priorities

• Supplier master with lead times, MOQs, price lists, and compliance documents (must)Lead time and MOQ per item per supplier drive planning; expiring certifications must alert.
• Requisition to PO with rule-based approval (must)Approval by amount, category, and cost center; delegation when approvers are away.
• PO transmission, acknowledgment, and change history (must)Email, portal, or EDI 850 and 855; every amendment versioned.
• Receiving against PO with tolerances and inspection (must)Over and under delivery rules; quarantine and reject flows; ASN matching where available.
• Three-way match to accounts payable (should)PO, receipt, and invoice; exceptions routed, not blocked.
• Supplier performance scorecards (should)On-time, fill rate, quality, lead time variance, by supplier and item, from transaction data.
• RFQ and sourcing events (could)For businesses with strategic sourcing; catalog buyers rarely need it early.

Module 2: demand and supply planning

Planning answers how much to buy or make, and when, and its requirements are the ones most often oversold. Demand forecasting must produce a forecast by item and location at a chosen granularity (weekly is typical) using history, with seasonality and trend, adjustable by planners with the adjustment recorded, and measured for accuracy (forecast against actual, by item class) so the business can see whether the forecast is worth using. Statistical methods are a should; machine learning is a could, and only after the statistical baseline exists to compare against.

Replenishment turns the forecast into orders. The system must calculate safety stock and reorder points by item and location from demand variability, lead time, and a target service level; generate suggested purchase or transfer orders when projected stock breaches the reorder point; and respect supplier constraints (MOQ, pack sizes, lead time, order calendars). For manufacturers, material requirements planning explodes bills of material against the production schedule to generate component demand; for distributors, distribution requirements planning nets demand across a network of locations. Both need a planning horizon, a frozen period, and a way to see the projected inventory position day by day.

The requirement that matters most in planning is also the least glamorous: the planner's workbench. Planners spend their day on exceptions, items projected to stock out, items overstocked, orders late from suppliers, forecasts wildly off, and the system must surface those exceptions ranked by impact, let the planner act (expedite, cancel, adjust) from the same screen, and record what was done. A planning module with a brilliant forecasting engine and a poor exception workbench will be run from a spreadsheet within a quarter.

Planning requirements by business type

Requirement	Distributor	Manufacturer	Retailer	Typical priority
Statistical forecast by item and location, with accuracy tracking	Yes	Yes	Yes, by store	Must
Safety stock and reorder point from variability and lead time	Yes	Yes	Yes	Must
Suggested replenishment respecting MOQ, pack, lead time	Yes	Yes	Yes	Must
Distribution requirements planning across locations	Yes	Sometimes	Yes, DC to store	Should
Material requirements planning from bills of material	No	Yes	No	Must for makers
Promotion and event uplift in forecast	Sometimes	Rarely	Yes	Should for retail
Exception workbench with impact ranking	Yes	Yes	Yes	Must

The planning module differs most by whether the company makes, distributes, or retails. Most businesses need the first three rows before any of the last three.

Module 3: inventory and warehouse management

Inventory is the module everything else depends on, because planning, orders, and transportation all assume the stock figure is right. Inventory requirements begin with the model: multi-location (sites, zones, bins), multiple units of measure with conversions, stock status (available, allocated, quarantined, damaged), and, where the business needs it, lot, batch, expiry, and serial tracking with full genealogy. Every movement must be a transaction with a who, when, from, to, and why, and the system must be able to reconstruct any item's or lot's history. Cycle counting must be schedulable by ABC class or velocity, executed on a mobile device, and reconciled with variance approval, so that the annual physical count becomes unnecessary.

Warehouse management adds the operational flows. Receiving with ASN matching and directed putaway by rules (zone, velocity, hazard class, expiry). Picking in the methods the operation needs: discrete, batch, wave, zone, or cluster, with pick path optimization, and directed by mobile scan with substitution and short-pick handling. Packing with carton selection, packing list, and weight capture. Shipping with carrier label generation and manifesting, which is where the warehouse meets transportation. Replenishment of forward pick locations from bulk. Returns receiving with disposition (restock, refurbish, scrap). Task management that assigns work to operators, interleaves tasks to reduce travel, and shows supervisors the queue in real time.

The requirement that separates a system the warehouse will use from one it will resist is the device story. Operators work on handheld scanners or rugged mobile devices, often with gloves, in poor lighting and patchy connectivity. The system must present one task per screen with large targets, confirm every scan instantly, tolerate a lost connection for at least a few minutes without losing work, and print labels to the nearest printer without a menu. These are requirements, not implementation details, and they belong in the document. A warehouse management system that fails them is a system that gets bypassed with paper.

The warehouse flows the requirements must cover, in the order stock moves

1. 1

   ReceiveInbound

   Against PO or ASN; scan item and lot; tolerances; quality inspection and quarantine; label at receipt.

2. 2

   Put awayInbound

   Directed by rules on zone, velocity, hazard, and expiry; confirm location by scan; exceptions when the slot is full.

3. 3

   CountStock

   Cycle counts by class or velocity on mobile; blind counts; variance approval; annual physical becomes optional.

4. 4

   ReplenishStock

   Move from bulk to forward pick when below minimum; triggered by demand, not by walking past.

5. 5

   PickOutbound

   Discrete, batch, wave, zone, or cluster; path optimized; short picks and substitutions handled on the device.

6. 6

   Pack and shipOutbound

   Carton selection; packing list; weight; carrier label and manifest; hand-off to transportation.

7. 7

   ReturnReverse

   Receive against an RMA; inspect; disposition to restock, refurbish, or scrap; refund trigger to the order system.

Modules 4 and 5: order management and transportation

Order management sits between demand and the warehouse and its requirements are about capture, promising, and allocation. Orders must be captured from every channel the business sells through (sales team, e-commerce, marketplaces, EDI from retail customers, B2B portal) into one order record with the channel recorded. The system must check availability at capture and promise a date (available-to-promise, and for manufacturers capable-to-promise), allocate stock by rules (nearest location, oldest lot, priority customer), handle partial shipments and backorders, and manage holds for credit, fraud, or address problems. Order changes and cancellations must be possible up to a defined point (typically release to the warehouse) and audited. Returns must be authorized with an RMA, tracked back through receiving, and trigger the refund or credit.

Transportation management turns a shipment into a delivered parcel or pallet at the right cost, and its requirements scale with how much the business ships. Every business needs carrier integration for rating, label generation, and tracking across the carriers it uses, which the shipping API guide covers in depth. Businesses shipping freight need more: load planning that consolidates orders into shipments and shipments into loads; carrier selection by cost, service, and lane; tendering to carriers with acceptance and rejection; appointment scheduling at docks; proof of delivery capture; and freight audit that matches carrier invoices to agreed rates and disputes variances. Fleet operators add route optimization and driver mobile apps, which the fleet management articles on this site cover.

The two modules meet at the shipment. A requirement to state explicitly is who owns the shipment record and when: the order system creates it, the warehouse fills it, transportation rates and tenders it, and visibility tracks it, and each hand-off must be an event other systems can subscribe to. Companies that skip this end up with four systems each holding a different status for the same box.

Order and transportation requirements, with priorities by shipping profile

Requirement	Parcel e-commerce	B2B pallets and freight	Priority
Omnichannel order capture into one record	Yes	Yes, with EDI 850 from retailers	Must
Available-to-promise at capture	Yes	Yes	Must
Rule-based allocation, partials, backorders	Yes	Yes	Must
Holds for credit, fraud, and address	Fraud and address	Credit	Should
RMA and returns with disposition and refund trigger	Yes, high volume	Yes, lower volume	Must
Multi-carrier rating, labels, tracking	Yes, core	Yes, for parcel share	Must
Load planning, tendering, appointments	Rarely	Yes, core	Must for freight
Freight audit against contracted rates	Should	Must	Varies
Proof of delivery capture	From carrier	Signature, photo, exceptions	Should

A parcel shipper and a freight shipper need different transportation requirements; both need the same order requirements.

Module 6: visibility, exceptions, and analytics

Visibility is the module executives ask for first and should probably buy last, because it is only as good as the transactional data underneath it. Its core requirement is the end-to-end view of a unit of work: where is purchase order 4471, has the supplier shipped it, where is the container, when will it arrive, which customer orders are waiting on it. That requires the system to stitch events from procurement, carriers, the warehouse, and order management into one timeline per order, shipment, and item, with milestones and estimated dates that update as events arrive. Control tower is the term vendors use; the requirement is the timeline and the ability to search it.

Exceptions are what make visibility useful rather than decorative. The system must detect events that did not happen when they should (a PO not acknowledged in two days, a shipment not scanned for 48 hours, a receipt not put away by shift end, a forecast off by more than a threshold), rank them by business impact (value, customer priority, stockout risk), route them to the person who can act, and track resolution. A dashboard that shows everything is a dashboard nobody reads; a queue that shows the twelve things that need a decision today is a tool.

Analytics requirements are the KPIs the business already argues about, computed from the system's own transactions and available without an export: inventory turns and days of supply by item class, fill rate and on-time-in-full by customer, forecast accuracy by item class, supplier on-time and quality, warehouse productivity (lines per hour, accuracy, dock-to-stock time), transportation cost per unit and per lane, and returns rate by reason. The requirement to state is that these are computed from the same data the operation runs on, with definitions written down, so that finance and operations quote the same number. Advanced analytics, scenario simulation, and AI-driven recommendations are legitimate could requirements for a later phase.

OTIF On time, in full, by customer and order The number retail customers penalize on

Turns and DOS Inventory turns and days of supply by class The number finance asks about

Dock to stock Hours from receipt to available The number the warehouse can move fastest

Integration and data requirements: the half of the project nobody scopes

Supply chain software never runs alone. It sits between an ERP or finance system that owns the general ledger and often the item and customer masters, sales channels that generate orders, suppliers who receive purchase orders and send shipping notices, carriers who rate and track, third-party logistics providers who may run some warehouses, and, increasingly, customers who want a tracking link. Each of these is an integration requirement, and each needs a defined direction, trigger, data mapping, error handling, and owner. The requirements document should contain an integration table listing every system, what flows each way, how often, by what mechanism, and what happens when it fails.

The mechanisms are APIs and EDI. Modern systems expose REST APIs with webhooks for events, and the requirement is that the platform has them for every entity the business needs to integrate (items, stock, orders, shipments, receipts) with authentication, rate limits, and versioning documented. EDI remains how large retailers, many suppliers, and most freight carriers actually communicate: 850 purchase orders, 855 acknowledgments, 856 advance ship notices, 810 invoices, 204 load tenders, 214 shipment status, and 940 and 945 warehouse orders and confirmations for 3PLs. A business selling to major retailers or using 3PLs must state EDI as a must requirement, including the trading partner onboarding process and a way to see and fix failed transactions.

Data requirements are the ones that decide the integration story and the ones most often absent. Master data (items with units of measure, dimensions, weights, and hazard classes; locations with hierarchy and capacity; suppliers and customers with addresses and terms) must have a defined system of record, a governance process for changes, and validation rules at entry. The requirements document should state who owns each master, how a new item is created and propagated, and what quality checks run before data enters the supply chain system. Migration is its own requirement: how existing stock, open orders, and open POs move into the new system, how they are reconciled, and what the cutover looks like. The transportation management and warehouse layers in particular fail loudly when item dimensions and weights are wrong, because every carton, pallet, and rate calculation depends on them.

The integration table every requirements document should contain

System	Flows in	Flows out	Mechanism	Failure handling
ERP or finance	Items, customers, suppliers, GL accounts	Receipts, shipments, inventory value, invoices to match	API or file, near real time or nightly	Queue, alert, replay
E-commerce and marketplaces	Orders, returns requests	Stock availability, shipment tracking, order status	API and webhooks	Retry; never oversell
Retail customers (EDI)	850 orders, 860 changes	855 ack, 856 ASN, 810 invoice	EDI via VAN or AS2	Exception queue with SLA
Suppliers	855 ack, 856 ASN, invoices	850 POs, forecasts, schedules	Portal, EDI, or email	Chase list for unacknowledged POs
Carriers	Rates, labels, tracking events, invoices	Shipments, manifests, tenders	Carrier APIs or aggregator; EDI 204 and 214	Fallback carrier; manual label
3PL warehouses	945 ship confirms, 944 receipt confirms, stock	940 ship orders, 943 receipt advice	EDI or API	Reconcile stock daily

One row per system and direction. Fill in the mechanism, frequency, and failure handling for each; the blanks are where the project will hurt.

Security, compliance, and non-functional requirements

Security requirements are role-based access at the level the operation needs (a picker sees picks, a buyer sees POs for their categories, a 3PL user sees only their site), single sign-on with the corporate identity provider, an audit trail on every transaction and master data change that records who, when, and the before and after values, and segregation of duties where finance requires it (the person who creates a supplier cannot approve payment to it). Data protection requirements apply to customer addresses and contact details in orders; residency requirements apply if the business operates in jurisdictions that restrict where data can be stored. Compliance requirements depend on the industry: lot genealogy and recall reporting for food and pharmaceuticals, chain of custody for regulated goods, customs documentation for cross-border trade, and hazardous materials handling rules for the goods that carry them.

Performance requirements must be stated at peak, not average, and the peak in supply chain is real: a promotional day, the week before a holiday, the end of a quarter. The document should state orders per hour, picks per hour, and concurrent device users at peak, and require that scan confirmation, screen transitions, and availability checks stay within stated times at that load. Availability requirements should reflect the operation's hours; a warehouse running three shifts cannot take a nightly maintenance window. Recovery requirements (how long to restore, how much data can be lost) should be set by asking what an hour of warehouse downtime costs.

Usability and configurability round out the list. The warehouse device requirements described earlier belong here. So does the requirement that business rules (allocation, putaway, approval routing, replenishment parameters) be configurable by a trained administrator without a developer, with changes versioned and testable in a sandbox. So does localization if the business operates in multiple languages or countries, including units, currencies, date formats, and tax rules. And so does the requirement for a test environment that mirrors production with masked data, without which no change can be safely validated. A custom software build gives complete control over all of these; a packaged system trades some of that control for speed, and the requirements document is where a buyer finds out which trades they can live with.

Phasing the requirements: what to deliver first and why

Six modules, each with dozens of requirements, cannot be specified in detail and delivered at once by any organization that also has to run a supply chain. The requirements document should therefore state a phase for each requirement alongside its priority, and the phasing has a logic that rarely changes. Inventory and order management come first, because accurate stock and clean orders are what everything else consumes; a forecast built on wrong stock is wrong, and a transportation plan for orders the warehouse cannot fill is waste. Within that first phase, master data cleanup and the ERP integration are the real work.

Procurement and receiving come second, closing the inbound loop so that stock arrives into the system rather than around it, and giving planning the lead times and supplier performance it needs. Planning comes third, once the system has six months or more of clean transactional history to forecast from and once the organization trusts the stock figure enough to act on suggested orders. Transportation comes alongside or after, depending on shipping volume; a parcel shipper needs carrier integration in phase one because it cannot ship without labels, while a freight shipper can run tendering manually for a while. Visibility and analytics accrue with every phase and get their own phase only for the control tower and advanced analytics.

The document should also state what is deliberately not in scope for the first year, so that the will-not items are visible decisions. And it should state the exit criteria for each phase in the same testable language as the requirements: stock accuracy above a threshold by cycle count, order-to-ship time below a target, integration error rate below a level. The chart that follows shows a typical phasing; the logistics app build guide covers how a team turns a phase into sprints.

A typical phasing for a mid-size distributor

1. FoundationMonths 1 to 4

   Master data cleanup; ERP integration; inventory model; receiving, putaway, count, pick, pack, ship on mobile; order capture and allocation; parcel carrier integration.

   Done when Cycle count accuracy above 98 percent; all orders flow from channels to shipment without spreadsheets.

2. InboundMonths 4 to 7

   Supplier master; requisition to PO with approvals; PO transmission; receiving against PO and ASN; three-way match; supplier scorecards.

   Done when Every receipt matches a PO; supplier on-time and fill rate reported from system data.

3. PlanningMonths 7 to 11

   Statistical forecast with accuracy tracking; safety stock and reorder points; suggested replenishment; exception workbench.

   Done when Planners act from the workbench; forecast accuracy tracked by class; stockouts on A items down measurably.

4. Freight and 3PLMonths 9 to 13

   Load planning; tendering; appointments; proof of delivery; freight audit; 3PL EDI.

   Done when Freight invoices audited automatically; 3PL stock reconciled daily.

5. Control towerMonths 12 onward

   End-to-end timelines; exception ranking; KPI suite with written definitions; scenario analytics.

   Done when Operations and finance quote the same OTIF and turns from the same screen.

Spans are illustrative for a company with a few sites and a few thousand SKUs. Exit criteria are written so that someone outside the project can apply them.

Conclusion: a requirements document is a set of tests you have not run yet

The value of a requirements document for supply chain software is not that it lists features; vendors do that better. Its value is that it states, in testable terms, what the business needs the software to do, how well, at what volume, and in what order, so that a vendor can be held to a demonstration, a development team can be held to an estimate, and an acceptance test can be held to a result. The six modules give the document its structure; the integration, data, security, and non-functional sections give it its teeth; and the phasing gives it a chance of being delivered.

The single most useful thing a buyer can do before sending this document anywhere is to walk the warehouse and the buying desk for a day and write down the exceptions: the truck with the wrong pallets, the order that could not be promised, the lot nobody could find, the invoice that did not match. Those are the requirements the brochures leave out and the ones that decide whether the system will be used. Put them in.

• Testable statements, prioritized. Actor, action, condition, measure, and a must, should, could, or will not on every line.
• Six modules, three first. Inventory and orders, then procurement, then planning. Transportation when volume demands it; visibility as the data earns it.
• Integration is half the work. An integration table with mechanism and failure handling per system, and EDI where the partners require it.
• Peak, devices, and data. State the peak and test at it; specify the warehouse device experience; put master data ownership in the document.

Frequently asked questions

When a requirements checklist has to become a system the warehouse will actually use, AgileTech is an AI native software development company in Vietnam that builds warehouse, order, and transportation platforms with the integrations specified from day one.