The short version
Most 3PL operators looking for new warehouse software don't need a new WMS. They need the billing layer their WMS was never built to hold. The picking and putaway you already run is fine. What broke is the bit where a movement in the warehouse turns into a line on a client invoice, and that's a smaller, cheaper and far less disruptive thing to fix.
One question tells you which situation you're in. Is your month-end invoice run happening inside your WMS, or does it start with an export?
If it starts with an export, keep reading. Saying this first costs us the larger project. It's still the right answer.
Why does 3PL billing always end up in a spreadsheet?
Because a warehouse management system models one rate card, and a third-party logistics business sells a different one to every client. That's the whole mechanism. Everything else follows from it.
Take storage on its own. One contract charges by pallet position on a receipt anniversary cycle, so a pallet received on the 9th bills in cycles from the 9th rather than from the start of the month. The next client pays per square metre, monthly, with a minimum that applies whether they use the space or not. A third is on cubic metres, because their goods are light and bulky and they negotiated hard. Same building. Same racking. Three different meanings for the word storage.
Handling splits the same way. Receiving might bill per pallet for one client and per carton for another. Pick and pack might be per order, per line, or per unit, and the client who agreed per order two years ago has since started sending single-line orders in volume. That's quietly the worst deal in the building. Then come the accessorials: wrapping, labelling, kitting, returns, rush handling, after-hours work. Plenty of those were agreed on a phone call and live in an email rather than in any system.
A standard WMS handles a rate card perfectly well. What it can't handle is fifty of them, each with exceptions, each on its own cycle, changing whenever a contract gets renegotiated. So the operations team does the only sane thing left. They export the movements, open a spreadsheet, and finish the job by hand.
None of this is the WMS failing. It was built to know where the stock is, and it does that. Billing a commercial agreement is a different problem that happens to use the same data.
What does an off-the-shelf WMS actually stop doing?
It is worth being precise about where the line falls, because the useful answer is not that off-the-shelf software is bad. It is that the line sits in a consistent and predictable place.
On the near side of the line, do not rebuild any of this. Receiving and putaway. Location and bin management. Wave and batch picking. Cycle counting and inventory adjustment. Lot, batch and serial tracking, including first-expired-first-out rotation if you hold food or pharmaceuticals. Barcode and scanner workflows. This is mature software that took the vendors years to get right, and there is no prize for doing it again.
On the far side, this is where teams start improvising. Multi-client rate cards with per-contract rules. Billing cycles that follow contract anniversaries rather than the calendar. Accessorials that need to be captured at the moment the work happens rather than remembered at month-end. A client-facing portal where your customers can see their own stock and their own charges without emailing you. Customs and tax obligations that treat an invoice as an integration rather than a document. Margin visibility per client, which is the one most operators want and almost nobody has.
That last one deserves a sentence of its own. Most 3PL operators can tell you revenue per client exactly. Very few can tell you which clients are actually profitable once labour, space and accessorial work are attributed properly, because the data needed to answer it is split across a WMS, a payroll system and a spreadsheet. The clients people assume are their best are not always the ones that survive that calculation.
What is the spreadsheet actually costing you?
Three things, and only one of them is time.
The first is leakage you can't measure. Accessorial work is the usual culprit. Someone re-wraps a damaged pallet, or handles a rush order after hours, and whether it gets charged depends on a person remembering to write it down. Charges that depend on memory get missed. They also get missed in one direction only, because nobody ever over-remembers work they didn't do.
The second is that you can't defend an invoice you can't reconstruct. A client disputes a storage charge four months later. To answer properly you need a chain running from the invoice line back to the movements that produced it, with the contract version that was in force at the time. If the calculation happened in a spreadsheet that's been edited fourteen times since, that chain doesn't exist. So the dispute gets settled with a credit note, because arguing costs more than conceding.
The third is a person. There's always one person who understands the billing spreadsheet. They can't easily take leave at month-end, and if they resign the knowledge walks out with them. That's a real operational risk sitting in a file nobody has ever tested.
None of it appears on a profit and loss statement as a line item. It shows up as margin that's slightly worse than it should be. Every month, for years.
Who should not build warehouse software?
Plenty of people, and it's worth saying so plainly.
Don't build if you run one client, or a few on near-identical terms. The thing that justifies custom work is contractual variety. Without it you're buying an expensive way to do something simple.
Don't build if your rate card fits in one table with no exceptions. That's exactly what off-the-shelf 3PL billing modules are for, and they'll handle it.
Don't build if your invoice run takes an afternoon. Annoying isn't the same as broken. The threshold worth acting on is when it takes days, or when it needs one specific person.
Don't build if your WMS can't export clean movement data. This one is a sequencing problem rather than a permanent no. If you can't get reliable, timestamped movements out of the system you already run, a billing layer on top of it inherits that mess. Fix the data first, or change the WMS first, then come back to this.
In any of those cases, look at Extensiv, Logiwa, ShipHero or Da Vinci Unified before you talk to anyone about a build. They solve the common case properly. We'd rather tell you that now than three months into a project that was never going to pay for itself.
Should you replace the WMS or build alongside it?
Alongside it, in almost every case we look at. The urge to replace usually comes from frustration rather than analysis. Replacing a working WMS means stopping the part of your operation that's currently fine in order to fix the part that isn't.
The shape that works is a seam. Your WMS stays the system of record for stock truth: what's where, in what condition, owned by whom. A separate service subscribes to movement events coming out of it, receipts, putaways, picks, shipments, adjustments, and stores them as an immutable ledger of things that happened. Nothing in that ledger is ever edited. Charges get derived from the ledger by applying the contract that governed each movement at the time it happened.
That last detail is the difference between a system you can defend and another spreadsheet with better styling. Rate cards need versioning with effective dates, and every charge has to reference the version that produced it. Re-run a month a year later and you should get the same answer. If you can rerun a disputed invoice and land on the identical number, the dispute ends in one email.
The seam has a second benefit that matters more than it sounds. It keeps the risky, changing part of the project away from the part of the operation that must not stop working. If the billing service fails on a Tuesday, pickers keep picking.
The same reasoning applies if you also run vehicles. Telematics and route data belong in their own system for the same reason, and we cover that separately in our guide to fleet management software.
What changes for a 3PL in Saudi Arabia or the UAE?
Two things that most warehouse software quietly assumes away, and both of them touch billing rather than operations.
An invoice stops being a document and becomes an integration. Under the Saudi e-invoicing regime administered by ZATCA, invoices have to be generated in a prescribed electronic format and passed through the authority's platform rather than simply issued to the customer. That changes the engineering problem. Your billing system now has to produce a structured document, handle acknowledgement and rejection responses, deal with the case where the platform is unavailable at month-end, and keep the resulting records. A billing module designed around producing a PDF has nowhere to put any of that. The UAE is moving in the same direction, so a system built today for one market should not hard-code the assumption that invoicing is a local operation.
Stock carries a customs status, not just a location. If you operate in a free zone or a bonded facility, the same physical pallet can be in different duty states, and moving it across a boundary can constitute an import with paperwork attached. Off-the-shelf systems typically model location and owner. Fewer model duty state as a first-class property of the stock, and almost none let you bill differently based on it. Operators end up tracking this in a parallel system, which is the same failure mode as the billing spreadsheet, with worse consequences if it is wrong.
Neither of these is a reason on its own to build. They are reasons to check, early, whether the product you are evaluating can express them at all. That question is much cheaper to ask before a migration than after one.
How do you connect it to carriers, ERPs and client systems?
Through EDI and modern APIs at the same time, which surprises people who expected to pick one.
Larger retail and manufacturing clients still transact over ANSI X12 document sets, and a 3PL sees a predictable handful of them. The 940 warehouse shipping order tells you to ship. The 945 shipping advice tells them you did. The 943 and 944 cover stock transfers in and out, the 947 covers inventory adjustments, the 846 reports inventory levels, and the 997 acknowledges that a message was received at all. Meanwhile your ecommerce clients want REST endpoints and webhooks, and they want them documented.
So the integration layer has to translate between both worlds and stay honest about delivery guarantees. The practical rule is that no inbound message can be trusted to arrive exactly once. Shipment confirmations in particular get retried, and a retry that creates a second shipment record is how a client gets billed twice for one order. Idempotency keys on every inbound write, and a replayable log of what arrived, are not sophistication. They are the minimum for a system that will be argued about.
We have built this shape of integration surface before in fleet and tracking work, including the platform behind Pixytan, which tracks more than 30,000 vehicles. The domain differs. The problem of ingesting high-volume events from systems you do not control, without losing or duplicating any of them, does not.
What does the build look like, in what order?
Billing first, and against history rather than against the future.
Step one is the movement ledger and the rate engine. Pull movements from the WMS, model the contracts properly with versioning and effective dates, and generate charges. No user interface worth mentioning yet.
Step two is reconciliation, and it is the real acceptance test. Run the last three months through the new engine and compare every line against the invoices you actually sent. You are not looking for a perfect match. You are looking to explain every difference. In our experience of building calculation engines, the differences are the most valuable output of the whole project, because each one is either a bug in the model or revenue you were not charging. Teams routinely find the second kind.
Step three is the client portal. Stock levels, order status, charges to date, documents. This is usually where the commercial return shows up, because it removes a large volume of email that currently lands on your operations team, and it is the part clients notice.
Step four is automation and the rest of the integration surface. Automated invoice generation and dispatch, carrier connections, EDI onboarding for new clients, and the tax platform integration if you operate somewhere that requires it.
Doing it in that order means the thing that pays for the project is live first. If the work stops after step two, you still have a defensible invoice run, which was the actual problem.
How we would approach the build
We would start by asking to see your rate cards and one month of invoices, not by asking about your technology. The contracts are where the difficulty is. The technology follows from them, and any partner who quotes you a plan before reading a rate card is guessing.
We should be straight about one thing. Geminate Solutions has not shipped a 3PL warehouse platform. What we have shipped, across 50+ products, is the harder half of this problem: event ingestion at volume, calculation engines whose numbers get disputed, multi-tenant systems where one customer must never see another's data, and integrations with systems we do not control. The Pixytan fleet platform tracks over 30,000 vehicles. An exam platform we built absorbs more than 10 million requests a minute. An EdTech platform serves 250,000+ daily users. If you want a partner who has built this exact product before, that is a fair requirement and we are not it. Say so and we will tell you honestly.
You own the code and the infrastructure from day one. Geminate Solutions is a software and product development partner, which means we own delivery and you own the result. We are not a staffing agency and we do not place engineers into your team for you to manage.
If you want the drivers of effort rather than the architecture, our guide to what drives logistics software effort covers scope, integration surface and data volume in more detail. For the wider picture of what we build in this sector, see logistics software development.
