The complete guide to 3PL warehouse management & billing software.

What a 3PL WMS actually is

The distinction sounds academic until you try to run a third-party floor on single-owner software. A standard WMS is a cost-measurement machine: it was built for a brand or manufacturer whose warehouse is an expense line, so it optimises picks, tracks locations and reports efficiency — and never once asks who should be charged for any of it, because the answer is always “ourselves”. A 3PL warehouse is the opposite animal. The operator owns the shelves and none of the goods. Every unit belongs to a client, every touch has a price on that client’s rate card, and the warehouse is not a cost center at all — it is the revenue engine, provided the billing keeps up with the floor.

Which is also why the buyer matters more than the feature list. This guide — and Binsy, the product behind it — is written for third-party warehousing and fulfilment companies: operators running storage and fulfilment on behalf of client brands, and forwarders who’ve added a warehousing arm. If you’re a brand managing your own inventory, a standard WMS is genuinely the right tool, and the multi-client machinery described below would be dead weight. The full line-by-line comparison lives at standard WMS vs 3PL WMS.

The market these operators sit in is not small. India’s 3PL warehousing market was valued at $11.23 billion in 2025, heading for $16.76 billion by 2031 at a 6.84% CAGR, per Mordor Intelligence. The software that runs it is growing faster still — one widely cited series puts global WMS software at $4.57 billion, reaching $10.04 billion by 2030 at 17.1% CAGR — though WMS market figures diverge noticeably by research firm, so treat any single number as one firm’s estimate rather than gospel.

The software landscape: who serves whom

The 3PL software market looks crowded until you sort it by who each product was actually built for. Then a pattern appears — and so does a hole.

Read the table twice and the gap declares itself. The US products understand the third-party business model but price and write for American 3PLs. CartonCloud understands the SME operator but lives in Australia, New Zealand and the US. The India players are excellent software aimed at the wrong buyer — brands running their own stock, not operators running everyone else’s. The enterprise tier wants a Fortune-500 budget, and the forwarding-suite modules want six to twelve months of your life before the first GRN.

The quadrant that remains — multi-client native, activity billing built in, item-level and pallet operations on one floor, priced for India and the GCC — is, as of this writing, empty. That quadrant is where Binsy lives, and the rest of this guide is effectively a tour of why each of those four properties matters on a real floor.

Billing: where the money leaks

This is the section that pays for the other nine. Industry figures — originating from Extensiv, a vendor with an interest but also the largest dataset of third-party warehouses — suggest more than 80% of 3PL warehouses lose revenue to uncaptured charges. The primary survey behind that number is hard to pin down, so treat it as directional rather than precise; but the mechanism it describes is one every operator recognises. The kitting job squeezed in on a Thursday. The extra labelling run. The re-palletising nobody wrote down. The storage days between a client’s “we shipped that” and the pallet actually leaving. Work that happened, cost labour, and never met an invoice.

The same Extensiv benchmark — this one from a named study of 200+ warehouses — found that operators who complete their monthly billing in under 16 hours are 2.8× more likely to report high profitability growth. The causation runs through the mechanism: fast billing is only possible when the events were captured as they happened, and captured events don’t leak. Month-end reconstruction from packing slips, WhatsApp threads and a walk of the floor is slow because it is lossy, and lossy because it is slow.

What does the work actually bill at? For the US market, published anchors exist:

The structural fix for leakage is the same regardless of currency: billable-event capture. Every GRN, every storage snapshot, every pick, every kit and every returns touch writes an event against the client’s rate card as the work happens — Binsy stamps the event at the scan, not at month-end. Invoicing then becomes a review of what was captured instead of an archaeology of what might have happened. To see what your own leak is plausibly costing, run your volumes through the calculator.

GRN discipline: it starts at the door

The goods receipt note is the least glamorous document in the building and the anchor of everything downstream. A GRN records what actually arrived — counted at the dock — against what the client’s ASN or packing list said would arrive. Everything a 3PL later claims rests on it:

• Counts vs ASN. The variance between advised and received is captured at the door, while the truck is still there and the driver can still sign — not discovered three weeks later as a phantom stock-out with no one left to blame.
• Batch and expiry at the threshold. If batch numbers and expiry dates aren’t captured at the GRN, FEFO rotation is impossible forever after — no amount of downstream diligence recovers data that was never recorded. The door is the only chance.
• The storage clock starts here. The GRN timestamp is when storage billing begins. A sloppy receipt date is a billing dispute with a head start.
• Dispute evidence. When a client argues a month-end line — and one will — the GRN, the bin history and the dispatch record are the receipts that end the argument with evidence instead of a goodwill credit.

The floor-level truth: if it isn’t captured at receipt, it’s rarely captured at all. Receiving is the one moment when the goods, the paperwork and a human with a scanner are guaranteed to be in the same place. In Binsy the GRN is where a pallet or carton acquires its client identity, its bin destination, its batch data if it has any — and its first billing event, priced off the rate card the moment it crosses the dock.

One floor, many owners

Multi-client segregation is the discipline that makes third-party warehousing a business rather than a favour. One physical floor, many legal owners — and the software has to hold walls the building doesn’t have:

• Inventory walls. Client A’s stock can never fill client B’s order, however convenient the bin, however identical the SKU. Ownership is structural in the allocation logic, not a report filter bolted on afterwards.
• Per-client rules. FEFO for the batch-and-expiry client, FIFO for the next, different putaway zones and SLAs for a third — one floor, many rulebooks, enforced by the system rather than remembered by the supervisor.
• Per-client rate cards. The same pick costs different amounts for different clients because their contracts say so. Every captured event prices off the right card automatically.
• Client portals. Each client sees their own stock, their own orders, their own reports — and nobody else’s. Self-serve visibility is also the quiet end of the “can you send me a stock report” email genre.

A useful test of any 3PL WMS candidate: describe your messiest real floor — say, an FMCG client on pallets, a Shopify apparel seller at item level and an industrial client with batch-tracked stock, all in one facility — and ask the vendor to model it without consultants. That exact floor, and three more like it, are walked through in the use cases.

Accuracy: counts, rotation, mispacks

Accuracy in a 3PL carries a weight it doesn’t have in a single-owner warehouse: the stock you miscount belongs to a client who is paying you specifically not to miscount it. Three disciplines matter.

Cycle counts vs stock takes. They answer different questions and a good operation runs both:

FIFO vs FEFO. First-in-first-out rotates stock by arrival date; first-expired-first-out rotates by expiry date, which is what food, pharma and cosmetics clients actually need. The operational catch, worth repeating from the receiving section: FEFO is only possible if batch and expiry were captured at the GRN. A 3PL that promises FEFO without door-level batch capture is promising arithmetic without the numbers.

Pick accuracy, in money. The difference between 97% and 99.5% pick accuracy sounds like rounding. On 500,000 orders a year it is 15,000 mispacks versus 2,500 — twelve and a half thousand apologies, reships and returns-processing touches, most of them absorbed by the operator because the client didn’t cause them. Scan-verification at pack is the cheapest insurance in the building. Meanwhile the biggest hidden cost in picking isn’t error at all — travel time can consume up to 50% of picking activity, which is what wave picking and sequenced pick paths exist to attack.

E-commerce fulfilment on a mixed floor

E-commerce fulfilment is where item-level discipline earns its keep. The flow, end to end: a client connects their Shopify store and orders drop into the queue as they’re placed; orders are batched into waves with sequenced pick paths; packs are scan-verified against the order before they seal; dispatch manifests close the loop and tracking flows back to the store so the client’s customer sees fulfilment without the client sending you a single email. Each order writes its own pick-and-pack billing events as it moves — a flash-sale Friday of 900 orders ends with the work done and the billing already done with it.

Two things distinguish a 3PL running e-commerce from an e-commerce-only platform. First, returns are not a nuisance — they’re a billable value-added service: inspection, restock or quarantine, and a per-unit charge on the rate card ($3–7/unit in the US anchors above). The operator who processes returns without billing them is donating labour to their most demanding workflow. Second, the e-commerce client doesn’t get the building to themselves. Item-level and pallet clients coexist on one floor — the apparel seller’s 900 scan-verified orders move down the same aisles as the FMCG client’s forty inbound pallets, each on their own rate card, each writing their own events. The step-by-step mechanics are on how it works.

GST & e-invoicing on client invoices

A 3PL’s billing engine produces invoices, and invoices live under tax law. This section is strictly about the invoices you raise on your warehousing clients — nothing here concerns customs or the movement of goods across borders. Three jurisdictions matter for India/GCC operators:

The through-line: every one of these regimes rewards billing that is structured, itemised and produced on time — and punishes the spreadsheet reconstructed in the first week of the month. An invoice built from captured events, with every line traceable to a GRN, a snapshot or a scan, is also an invoice that survives a tax audit without a bad afternoon.

Choosing: the questions that matter

First, clear the acronym fog. Three layers of warehouse software get conflated in vendor decks:

Then interrogate the WMS candidates with the questions that separate a 3PL product from a single-owner product wearing a client field:

• Is multi-client native? Not “can you add a client column” — are inventory walls, per-client rules and per-client rotation in the allocation logic itself?
• Is billing event-driven? Does every receive, snapshot, pick and VAS task write a priced event as it happens, or does invoicing start from an export and a spreadsheet?
• Item and pallet on one floor? Can a scan-verified Shopify client and a pallet-in/pallet-out client share the facility, each on their own rate card?
• Implementation in weeks, not months? If onboarding the software takes 6–12 months, what will onboarding each new client take? A 3PL wins clients for a living; the software shouldn’t tax that motion.
• Priced for your geography? A US price list in an India/GCC cost structure is a decision about your margins made in someone else’s market — see how Binsy frames it on pricing.

Getting started: the 14-day path

The lowest-risk start is scoped, parallel and honest about what moves when. Fourteen days, three phases:

• Days 1–3: scope the floor. Client list, rate cards as actually agreed (including the ones agreed by email), item-level vs pallet-level per client, batch/expiry clients flagged, storage rules and surcharge terms written down — often for the first time in one place.
• Days 4–10: configure and shadow. Clients, rate cards, bins and rules go in; Shopify stores connect; real GRNs and orders run through Binsy in parallel with your current process. Billing events accrue in shadow — so you can compare what the system captured against what your month-end would have found.
• Days 11–14: go live, client by client. Cut over the first clients, run the first live waves, and preview the first month-end invoices from captured events. The shadow-period comparison is usually where the leakage stops being a statistic and becomes a number with your name on it.

Success is measured in your own operation, not our brochure: hours to close monthly billing (the benchmark cohort says under 16), events captured vs events invoiced (the target is a match), disputes settled with evidence instead of credits, and a floor where a new client is a configuration task rather than a project.