WMS vs WCS: who controls what in an automated warehouse?
Understand how warehouse software, controls and automated equipment work together; and which system should own each decision.
A clear division of responsibility between the WMS, WCS and equipment controls reduces integration risk, simplifies testing and helps the operation recover when something does not go to plan.
The simple difference between a WMS and a WCS
The WMS plans warehouse activity. The WCS coordinates the automated equipment needed to carry it out in real time.
Manages the operation at a business level
The Warehouse Management System understands inventory, orders, priorities and warehouse tasks. It normally decides what needs to happen and where an item ultimately belongs.
- Inventory availability and allocation
- Order and wave priorities
- Picking and replenishment tasks
- Customer, store, carrier or route destination
- Labels, shipment data and order completion
Coordinates movement through the automated system
The Warehouse Control System works closer to the equipment. It tracks each item, selects a live route and coordinates scanners, conveyors, sorters and other automation.
- Item identification and real-time tracking
- Conveyor routing and sorter destinations
- Merge, accumulation and lane-full logic
- Measurement, scanner and device results
- Exceptions, fallback routes and status events
The exact boundary varies between projects. What matters is that every important decision has one agreed owner before development begins.
Where ERP, WMS, WCS and equipment controls fit
Each layer has a different job. The strongest projects keep those roles clear while allowing information to move reliably between them.
Business and enterprise systems
Customers, products, purchasing, billing and enterprise-level data.
Warehouse planning
Inventory, orders, picking tasks, waves, priorities and shipment requirements.
Real-time orchestration
Item routing, equipment coordination, tracking, exceptions and operational status.
Machine and device control
Motors, sensors, scanners, diverters, conveyor zones, robots and machine sequences.
What happens from induction to destination
A well-designed integration should make the physical journey easy to follow, from the first routing instruction to the final confirmation event.
Scanning, measurement and tracking connect the physical parcel to its digital instruction.
Route assigned
The WMS sends the item identity and destination to the WCS. Optional data may include expected weight, dimensions, service level or priority.
Item identified
The WCS coordinates barcode reading, image capture and tracking so the physical item is associated with the correct digital identity.
Data checked
Measured weight, dimensions, barcode validity and item profile can be checked against expected values and agreed tolerances.
Item routed
The WCS coordinates conveyors, merges and sorter destinations while reacting to lane availability, blockages, faults or item exceptions.
Result confirmed
The WCS reports events such as arrived, read successfully, diverted, no read or out of tolerance so the WMS can update the order.
Who should own each decision?
The table below is a practical starting point—not a rigid rule. Your project specification should document the agreed owner for every important decision and exception.
| Decision or function | Typical owner | Practical explanation |
|---|---|---|
| Order priority | WMS | Based on customer, service level, wave and operational requirements. |
| Inventory allocation | WMS | Determines which available stock should fulfil the order. |
| Final business destination | WMS | Defines the store, carrier, route, customer or process destination. |
| Real-time path through equipment | WCS | Selects the live route based on equipment availability and agreed fallback rules. |
| Scanner and measurement coordination | WCS | Coordinates device triggers, results and item association. |
| Motor, sensor and machine sequence | PLC | Executes the local machine-level sequence and device control. |
| Lane-full response | WCS | Applies the agreed temporary route, buffer or stop-induction rule. |
| Business exception resolution | Shared | Usually combines WMS status, operator workflow and WCS physical handling. |
| Equipment fault status | WCS / PLC | Generated locally and reported upwards to the operator and business systems. |
| Safety functions | Safety controls | Handled by the engineered safety system, not ordinary routing logic. |
| Operational event history | Shared | The WCS records equipment events; the WMS records business and order outcomes. |
Most integration problems begin before the equipment is installed
Hardware problems are visible. Ownership and data problems are harder to see—and often create more delay.
Two systems both own routing
Product data does not match
Label logic is decided too late
Exceptions have no owner
Business rules are buried in PLC code
Offline behaviour is not defined
The integration can be simple, but it must be precise
The systems do not need to exchange every piece of warehouse data. They need a reliable set of messages that lets each item be identified, routed, tracked and confirmed.
Routing request
Item ID, destination and optional values such as expected weight, dimensions, service level and priority.
Operational event
Item ID, event type, timestamp, station, measured data, image reference or structured error code.
Lookup request
Used when the WCS identifies an item but does not yet know the required destination or business instruction.
Heartbeat and status
Confirms that the connection and systems are available and exposes a loss of communication quickly.
Design the interface for predictable recovery
REST APIs can work well for request-and-response flows. File transfer may still suit defined batch processes. Other architectures can also be appropriate. The important part is a stable, documented contract.
- Unique item identities
- Defined timestamps and time zones
- Idempotent processing
- Retries and time-outs
- Duplicate detection
- Offline and recovery behaviour
- Structured error codes
- Logging and traceability
{
"item_id": "ABC123",
"event_type": "DIVERTED",
"destination": "D23",
"station": "SORTER-02",
"timestamp": "2026-06-20T10:15:27Z",
"measured_weight_g": 740,
"error_code": null
}
What should normally happen locally in the WCS?
Fast operational decisions should not depend on unnecessary round trips to higher-level business systems.
Item tracking
Maintain the identity and position of each item as it moves through the automated flow.
Scanning and measurement
Coordinate scanner, camera, scale and dimensioning triggers and associate the result with the correct item.
Movement and spacing
Coordinate conveyor gaps, merge sequencing, accumulation and local routing through available paths.
Lane-full handling
Apply agreed fallback rules when a destination, route or downstream process is unavailable.
Jam and restart coordination
Support controlled stop, recovery and restart sequences without losing item traceability.
Device and system status
Monitor scanners, drives, sensors, conveyor zones and automation availability.
Exception routing
Send no-reads, oversize items and out-of-tolerance items to their agreed physical destinations.
Event generation
Create a traceable event history and return the important business outcomes to the WMS.
A successful system is defined by how it handles the unusual items
Every exception needs a physical destination, a system response and a clear operator action. “Send it to reject” is not a complete process.
| Exception | Physical response | System response | Operator action |
|---|---|---|---|
| No barcode read | Send to a manual-read lane or exception spur. | Create a NO_READ event and retain the tracking reference. | Identify, relabel or investigate the item. |
| Weight outside tolerance | Send to check-weigh or inspection. | Create a WEIGHT_EXCEPTION event with measured value. | Inspect the order or product data. |
| Destination unavailable | Use the agreed buffer, fallback lane or controlled stop. | Report route change or unavailable destination. | Clear or reopen the destination. |
| Oversize item | Use a dedicated exception route or manual handling point. | Create an OVERSIZE event. | Handle through the agreed non-standard process. |
| Duplicate identity | Stop, hold or reject the affected item. | Create a DUPLICATE event and prevent duplicate completion. | Investigate the source and correct the data. |
| Scanner offline | Use an agreed fallback process or stop induction. | Raise a device alarm and system-availability event. | Restore the scanner and reconcile affected items. |
Do not test only the machines. Test the operation.
The final test should prove that equipment, routing, data, exceptions and operator workflows function together under realistic conditions.
Operational tests
- Sustained throughput at a defined item mix
- Correct destination under a representative wave
- Standard and difficult item profiles
- Peak-volume operating conditions
- Operator workflow and exception handling
- Controlled recovery after a stoppage
System and data tests
- Barcode read rate at design speed
- Weight and dimension tolerances
- Event response time and completeness
- Duplicate prevention and retries
- Connection loss and offline behaviour
- Restart, reconciliation and event accuracy
Statements such as “the system runs well” are not acceptance criteria.
Configure wherever possible. Customise where it creates clear value.
Standard configuration is easier to test, support and change. Bespoke development should solve a real operational need rather than compensate for decisions made too late.
Standard settings and operating parameters
- Destination names and routing tables
- Conveyor speeds and operating modes
- Scanner windows and device settings
- Weight and dimension tolerances
- User roles and permissions
- API endpoints and alarm thresholds
Unique workflows with measurable value
- Special customer routing logic
- Non-standard item handling
- Bespoke exception processes
- Specialist reporting requirements
- Integration with unusual legacy systems
- Unique operational interfaces
Questions to answer before choosing the equipment
Answering these questions early makes technology selection, supplier responsibility and project acceptance much clearer.
01 Business ownership
- Which system owns the destination?
- Which system owns item master data?
- Where and when are labels created?
- Who owns exception resolution?
02 Interface design
- Which messages are exchanged?
- Which identifiers are used?
- How quickly must events be returned?
- What happens when a system is unavailable?
03 Performance
- Required sustained and peak throughput
- Required barcode read rate
- Routing accuracy and response time
- Weight and dimension tolerances
04 Site and equipment
- Equipment and automation scope
- Power, network and floor readiness
- Safety interfaces and operator stations
- Manual fallback and recovery process
05 Testing and sign-off
- FAT and SAT responsibilities
- Representative test items and data
- Measurable acceptance criteria
- Named owners and final signatories
06 Support and change
- Who maintains each system?
- How are routing changes approved?
- What logs and diagnostics are available?
- How will future equipment be added?
One coordinated project across equipment, controls and software
The equipment cannot be separated from the information that tells it what to do. We develop the operational process, control responsibilities and interfaces as one connected project.
Understand the operation
Review processes, systems, item profiles, throughput, exceptions and business requirements.
Define ownership
Agree WMS, WCS, PLC, operator and third-party responsibilities before development.
Agree the interfaces
Document messages, identifiers, errors, timing, offline behaviour and recovery rules.
Test the complete process
Test hardware, routing, data, exceptions and operator actions as one operating system.
Commission and support
Prepare go-live, monitor performance and create a practical foundation for future expansion.
WMS and WCS FAQs
Does every automated warehouse need a WCS?
Not always. A small standalone machine may be controlled locally. A WCS becomes more valuable when several pieces of equipment, routes or processes must work together and share item tracking, routing and exception rules.
Can a WMS control conveyors directly?
A WMS may send high-level instructions, but real-time coordination of conveyors, scanners, sorters and live routes is normally handled closer to the automation layer by a WCS and local equipment controls.
What is the difference between a WCS and a PLC?
A WCS coordinates item identities, routes and equipment across the wider process. PLCs control machine-level sequences, sensors, motors, drives and devices. The exact interface depends on the system architecture.
Where should routing logic sit?
The business destination normally comes from the WMS. The WCS manages the real-time physical path and agreed fallback behaviour when a route, lane or machine is temporarily unavailable.
What happens if the WMS connection is lost?
The behaviour should be designed before go-live. Depending on the operation, the WCS may finish known items, buffer them, use temporary rules or stop controlled induction. Recovery and reconciliation must also be defined.
Can CoreConvey integrate with our existing WMS?
Yes, where a suitable interface can be agreed with the WMS provider or your internal IT team. The project should define messages, ownership, timing, testing and support responsibilities clearly.
What should be tested before go-live?
Testing should cover throughput, barcode reading, routing, tolerances, exceptions, event delivery, connection loss, restart behaviour, reconciliation and operator workflows—not only individual machine inputs and outputs.
Should we configure or customise the WCS?
Configure standard functions wherever practical. Use custom development where it provides meaningful operational value, and ensure every bespoke rule is documented, tested and maintainable.
Define the system responsibilities before the equipment arrives
Send CoreConvey your automation scope, existing WMS, routing requirements and expected throughput. We can help identify the interfaces, responsibilities and acceptance criteria needed for a coordinated project.
