3PL WMS Software: What to Ask Before You Sign

Why 3pl wms software matters more than the warehouse floor

When you sign with a third-party logistics provider, you’re evaluating dock doors, pick-and-pack rates, and shipping zones. What you’re not usually evaluating — because it’s rarely offered as a choice — is the 3pl wms software running underneath all of it. That’s the mistake. The warehouse management system is what decides whether your stock count is accurate, whether a lot recall is traceable, and whether the number your store shows a shopper matches what’s actually on a shelf in New Jersey or Nevada.

Two other Pointerflow articles cover 3PL fulfilment models and how to evaluate a 3PL’s warehouse network. This one stays on the layer underneath both: the software a 3PL runs, what you can and can’t see inside it, and what to check before you sign a contract you’ll be stuck with for a year or more.

This article is written for operators running $3M-$30M in revenue on Shopify Plus or a comparable paid subscription platform, evaluating a 3PL for the first time or replacing one that’s underperforming. If you’re pre-revenue or shipping under a few hundred orders a month, a 3PL’s WMS sophistication isn’t your bottleneck yet — your own order volume is too low to expose the gaps this article covers, and you’d be paying for infrastructure you don’t need.

What “real-time inventory” actually means

Every 3PL sales page says “real-time inventory visibility.” Almost none of them mean a live, continuously open connection. What they usually mean is a batch sync: a scheduled job that pushes inventory changes from the WMS to your store, your 3PL portal, or both, on an interval — every few minutes, every fifteen minutes, sometimes hourly overnight.

The gap between a scan on the warehouse floor and the number your customer sees is the sync interval, not an error. If a picker scans the last unit of a SKU at 2:03pm and your store’s sync runs on a 15-minute cycle, that SKU can still sell on your site until 2:15pm. At low volume that’s a rounding error. At $3M-$30M, with concentrated demand around a launch or a promotion, it’s an oversell.

Ask the 3PL two specific questions, not “is it real-time”: what’s the sync interval in minutes, and does that interval hold during a promotion or peak volume, or does it widen when the WMS queue backs up. A WMS vendor’s own documentation will usually state the interval as a range rather than a fixed number — that’s a structural fact about how the system works, not a red flag on its own, but it’s the number you need before you plan a flash sale around it.

How cycle counting and inventory accuracy actually work

A cycle count is a scheduled, partial physical count of inventory — a subset of SKUs or bins counted on a rolling basis, rather than a full stock-take. It’s how a WMS catches drift between what the system says is on a shelf and what’s physically there, without shutting the warehouse down for a full audit.

Ask three things about your 3PL’s cycle-count practice specifically:

What triggers a count. Some WMS configurations count on a fixed schedule (every SKU touched within a rolling window). Others count only when a discrepancy is flagged — a pick that comes up short, a receiving mismatch. A schedule-based approach catches drift before it compounds; a flag-based approach catches it after a customer already didn’t get their order.

Who sees the discrepancy log. Most 3PLs will tell you the corrected total after a count. Fewer will show you the count log itself — what was expected, what was found, and how large the variance was. The log tells you whether accuracy is improving or slipping over several months; the corrected total alone doesn’t.

What counts as inventory “accuracy.” Ask whether the 3PL measures it as a percentage of SKUs within tolerance, a percentage of units, or something else, and over what period. A 3PL that can’t answer this in specific terms probably isn’t tracking it in a way you can hold them to.

Lot, batch and expiry: what changes if you sell perishables

If you sell anything with a shelf life — supplements, cosmetics, food, anything under FDA or comparable regulatory oversight — lot and batch tracking isn’t optional, and it isn’t automatically switched on just because the WMS supports it as a feature.

Confirm three things before you sign:

The module is active on your account, not just available in the platform. Lot tracking is usually a configurable module inside a WMS, not a default. A 3PL can run a platform capable of lot tracking while your specific account is set up without it, because most of their other clients don’t need it.

How FEFO picking is configured. FEFO (first-expired, first-out) picking means the system directs a picker to the unit closest to its expiry date, not the oldest unit by arrival date (FIFO) or a random bin. For expiry-sensitive goods, ask specifically whether picking logic is FEFO or FIFO — they’re not the same, and a WMS defaulting to FIFO can ship you a batch with a shorter shelf life still sitting behind a batch that expires sooner.

What a recall actually looks like in their system. Ask the 3PL to walk through, step by step, how they’d trace every unit of a specific lot number across every order it shipped in, if you ever needed to issue a recall. If they can’t describe that process in concrete terms — which report, which fields, how fast — you won’t get it fast enough when you actually need it.

The API or EDI you’ll integrate against

Every 3PL relationship runs on a data connection between your store or ERP and their WMS. For brands at this revenue range, that connection is usually one of two shapes.

An API, usually the 3PL’s own layer over the underlying WMS, or occasionally a direct pass-through to the WMS vendor’s API. Ask which it is. A 3PL-built layer tends to be more stable for you, because the 3PL absorbs changes when they upgrade the underlying WMS. A direct pass-through can change field names or behaviour when the WMS vendor ships an update, with no involvement from the 3PL at all.

EDI (Electronic Data Interchange), the older, still-common standard for structured messages between a brand’s or retailer’s systems and a warehouse — advance ship notices (the 856 transaction set), purchase orders (850), inventory advices, and similar. EDI shows up most often when a 3PL also fulfils wholesale or retailer-direct orders alongside your DTC channel, since most retailers require it.

Whichever it is, ask three concrete questions: which specific data moves (inventory levels, order status, tracking numbers, ASNs — not “everything”), whether setup is a flat fee or billed per transaction type, and whether test access exists before go-live so your team can verify the feed against a real order before your first live shipment depends on it.

Six 3PL WMS platforms, and who each doesn’t fit

You’re evaluating a 3PL, not shopping for a WMS directly — but knowing what platform sits underneath a shortlisted 3PL tells you a lot about what you can expect. Confirm the specific platform with the 3PL directly; some run more than one across different warehouses, and configuration varies by account even on the same platform.

Manhattan Active WM (Manhattan Associates)

An enterprise-grade WMS, cloud-native, built for large multi-node operations with heavy automation and complex slotting logic. 3PLs running it tend to serve larger, higher-SKU-count clients and can usually support sophisticated lot tracking and yard management. Who this is not for: a brand doing a few hundred orders a day with a simple SKU catalogue — you’ll be paying, through the 3PL’s rates, for infrastructure sized well above your order profile.

Blue Yonder Warehouse Management

Another enterprise platform, strong in retail and grocery supply chains, with deep support for wave planning and labour management. 3PLs running Blue Yonder often serve mixed retail and DTC clients. Who this is not for: a brand whose main requirement is a clean, simple API for a single Shopify store — the platform’s depth is built for multi-channel retail complexity you may not have.

Deposco Bright Suite

A cloud WMS pitched squarely at mid-market omnichannel brands and the 3PLs that serve them, with order management and inventory visibility built into the same suite rather than bolted on. Who this is not for: a brand needing heavy, custom EDI mapping for a large wholesale book — check Deposco-running 3PLs’ EDI transaction-set support specifically before assuming it covers your retailer requirements.

Extensiv (formerly 3PL Central)

Built specifically for 3PLs, not adapted from a general enterprise WMS, with a billing and client-management layer alongside the warehouse functions. It’s common among small-to-mid-size 3PLs serving multiple ecommerce clients from shared space. Who this is not for: a brand needing complex lot/expiry-driven FEFO picking at scale — verify that module’s depth directly rather than assuming a 3PL-built platform covers it as thoroughly as an enterprise WMS would.

Made4net SCExpert

A configurable WMS used by both 3PLs and brands running their own warehouses, positioned between pure mid-market and enterprise tiers, with modular add-ons for labour management and yard management. Who this is not for: a brand wanting a fully out-of-the-box setup with no configuration project — Made4net’s flexibility usually comes with an implementation phase, even on the 3PL’s side.

A custom or in-house WMS

Some larger 3PLs, and a few smaller ones with in-house engineering, run software built or heavily modified internally rather than licensing a named platform. This can mean either an unusually well-fitted system for that 3PL’s specific operation, or an under-resourced tool with no external roadmap and no support outside their own team. Who this is not for: any brand unwilling to ask hard questions about what happens if the engineer who maintains it leaves — get a specific answer, not a reassurance, before you commit volume to it.

What breaks when the WMS and your store fall out of sync

Picture a returns clerk at the 3PL scanning a damaged unit back into a bin at 4:50pm on a Friday. If the WMS-to-store sync runs on a 30-minute batch and the warehouse’s outbound feed queues behind the day’s shipping confirmations, that unit might not show as available — or might show as available when it’s actually damaged and pending disposition — until Monday morning. Multiply that by every return, every damage write-off, and every manual adjustment a picker makes during a shift, and you get a store inventory count that’s structurally always a little behind the physical warehouse.

That’s not a bug in any one platform. It’s the nature of connecting two separate systems — your store’s inventory ledger and the 3PL’s WMS — with a sync job instead of a single shared database. The two ledgers will drift apart between syncs by design; the only question is how far and how often they’re reconciled. Ask the 3PL what the reconciliation process looks like when the two numbers disagree beyond the normal sync gap — a manual review, an automated flag, or nothing until you notice a customer complaint.

Returns, RMAs, and where inventory accuracy actually breaks

Most of the accuracy conversation focuses on outbound picking, but the sharper failure point is the return. An outbound pick is a single decision: take this unit from this bin. A return is three decisions stacked together: receive the unit back into the building, inspect it, and decide what happens to it next. A WMS only handles the first two automatically. The third, restocking, is where the ledger drifts.

When a returned unit arrives at the 3PL, the WMS logs it against an RMA (return merchandise authorization) number, usually generated by your store or a returns platform and passed to the 3PL as a reference. From there, someone has to make a physical call: sellable as-is, sellable after repackaging, damaged and written off, or held pending your instruction. That call is made by a warehouse associate, often under time pressure during a return surge after a holiday or a promotion, and it’s the single most common point where a unit’s system status stops matching its physical condition.

Ask the 3PL two specific things about returns processing. First, what’s the default disposition when no rule is set: does an unclassified return sit in a quarantine bin until someone reviews it, or does it go back into sellable stock automatically unless flagged. The second answer is the one that costs money if you don’t ask it: automatic-sellable defaults mean a genuinely damaged unit can get picked and shipped to your next customer before anyone looks at it. Second, how long a return sits in “received, not yet dispositioned” status before it either returns to sellable inventory or gets written off. A queue that backs up during peak is a queue of units your system may already be counting as available stock they aren’t.

Kitting and bundles: one SKU code, multiple physical realities

A kit or bundle (three products sold and shipped as one SKU) is represented in a WMS as either a pre-built kit, assembled into a single bin ahead of demand, or a pick-and-pack kit, assembled at order time from the components’ individual bins. The difference matters more than it sounds like it should, because it changes what “in stock” means for that SKU.

A pre-built kit consumes warehouse labour ahead of the order and ties up a bin slot for the assembled unit. Its stock count is straightforward, because the kit is a physical thing sitting on a shelf. A pick-and-pack kit has no physical existence until an order triggers assembly, so its “available” quantity is really a calculation: the lowest available quantity among its component SKUs, divided by however many of each the kit requires. If your WMS doesn’t run that calculation correctly, or runs it on a sync delay against the component inventory, the kit can show as available after one of its components has actually sold out elsewhere.

Peak season exposes a WMS’s kitting logic hardest. A component SKU that also sells standalone can be depleted by direct sales faster than the kit’s availability recalculates, so the storefront keeps selling a bundle it can no longer assemble, and the order comes back from the warehouse as a partial or a delay, after the customer already checked out believing it was in stock. Ask specifically whether kits are pre-built or pick-and-pack in your account, and, if pick-and-pack, how frequently the component-availability calculation refreshes relative to the general inventory sync.

Multi-warehouse allocation: which node actually ships the order

Once you’re running inventory across more than one warehouse, a common step once volume in this range justifies a second coast for shipping speed, the WMS (or an order-management layer sitting above it) has to decide, for every order, which node fulfils it. That decision usually weighs some combination of proximity to the shipping address, which node currently holds stock of every SKU in the order, and cost or SLA rules the 3PL has configured on your account.

The failure mode to ask about specifically is the split shipment: an order containing two SKUs where no single warehouse holds both, so the system either splits the order across two nodes (doubling your shipping cost on that order) or allocates the whole order to whichever node has the most items, backordering the rest. Ask which behaviour is the default, whether you can set a preference (accept the split cost, or hold the order until one node has both items), and whether that preference is configurable per SKU or only account-wide.

Before you commit to a second node, ask how the allocation engine treats safety stock at each location. A naive allocation logic will happily draw a coastal warehouse down to zero on a fast-moving SKU to save two days of transit time on one order, leaving the node that actually needs stock for its regional demand empty until the next replenishment cycle.

Onboarding: SKU setup, labelling, and the first count

Onboarding is where a lot of the accuracy problems described in this article get set up, one way or another, in the weeks before you’ve shipped a single order through the new 3PL. Three parts of onboarding are worth treating as more than paperwork.

SKU setup. Every SKU needs to be created in the 3PL’s WMS with dimensions, weight, and any kitting or lot-tracking configuration matched to how you actually sell it, not a generic default. A SKU set up without its correct case pack or unit-of-measure can throw off cycle counts from day one, because the system and the shelf are counting in different units without anyone noticing until a discrepancy shows up.

Barcode and labelling requirements. Most 3PLs require inbound inventory to arrive with scannable barcodes at the unit or case level, in a format their WMS reads (GS1-128, UPC, or a 3PL-specific label) that they’ll ask you to apply before shipment. Ask for the labelling spec in writing before your first inbound shipment, not after it’s rejected or relabelled at your expense on arrival.

The first count. When inventory first arrives at a new 3PL, it’s received against your purchase order or ASN, then typically verified by an initial count before it’s marked sellable. That first count is your only chance to catch a receiving discrepancy before it becomes an unexplained variance three cycle counts later, with no record of when it actually happened. Ask whether the 3PL shares the receiving discrepancy report from that first count as a matter of course, or only if you ask for it.

What to put in the contract, not just ask about verbally

Everything above is worth confirming before signing, but confirmation that doesn’t make it into the contract or its technical exhibit isn’t enforceable when it matters. Three terms are worth pushing to get in writing specifically.

An accuracy SLA with a number attached. Not “we maintain high accuracy” but a stated percentage (of SKUs or units within tolerance) measured over a stated period, with a defined remedy if the 3PL falls short of it. A 3PL that resists putting a number in the contract, after describing one verbally, is telling you something about how confident they are in hitting it consistently.

The cycle-count cadence, in writing, not as a description of general practice. If counts are schedule-driven, get the schedule; if discrepancy-driven, get the trigger criteria. A cadence that exists only in a sales conversation can change without notice once you’re a signed client rather than a prospect.

Who pays for a miscount. When a cycle count or an order-fulfilment error reveals a shortage between what the WMS says you have and what’s physically there, the contract should say, specifically, whose inventory value that loss comes out of, yours or the 3PL’s, and under what conditions liability shifts (a 3PL-caused miscount versus a discrepancy traced to your own inbound shipment being short). Without this term, the default in most 3PL contracts favours the 3PL, and you find out which way it defaults only after the first real discrepancy.

Questions to ask before you sign

Before signing, get specific written answers, not sales-page language, on: the exact sync interval between their WMS and your store or 3PL portal; whether lot and batch tracking is active on your account specifically; whether picking logic is FEFO or FIFO for expiry-sensitive SKUs; which data fields the API or EDI feed actually exposes; whether cycle counts run on a schedule or only on a discrepancy flag; and what happens to your integration if they migrate to a different WMS platform during your contract term.

This detail rarely shows up in a warehouse tour. It shows up in the contract’s technical exhibit, if there is one, or in a call with whoever actually administers the WMS day to day — not the sales rep who sold you the account.

Getting straight answers to those questions, and building the sync checks and discrepancy alerts that catch drift before a customer does, is an ops automation problem: connecting your store’s inventory ledger to whatever your 3PL’s WMS actually exposes, on a schedule you’ve verified rather than one you assumed. Pointerflow’s ops automation service works on exactly that layer for brands past the scale where a manual spreadsheet reconciliation still holds up — a group covered in more detail in what changes for scaling brands.