Every result on this search is published by a company that sells a WMS. So none of them can tell you the most useful thing about one, which is where it stops.
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.
Send us the build. We will tell you honestly what needs fixing.
A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait. Free, within 48 hours, and no obligation follows it.
If your app has few users, takes no payments and stores no personal data, you probably do not need us yet. We will say so.
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 now has a dated timetable of its own. The Ministry of Finance's e-invoicing programme runs on the OpenPeppol standard, began its pilot on 1 July 2026, and requires every business with annual revenue of AED 50 million or more to appoint an accredited service provider by 31 July 2026 and be live by 1 January 2027, with everyone else live by 1 July 2027. A system built today for one Gulf market should not hard-code the assumption that invoicing is a local operation, because within a year it will not be in either.
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.
What should 3PL billing software actually do?
Turn every movement into a charge you can defend, under the contract that governed it at the time, and hand the result to whichever tax platform your market requires. That is the whole job. Most products sold as 3PL billing software do the first third of it well and leave the rest to you.
Hold one rate card per client, versioned, with effective dates. Storage per pallet-day, per pallet position on an anniversary cycle, per square or cubic metre with a minimum. Handling per pallet, per carton, per order, per line or per unit. The shapes matter less than the versioning. A charge that cannot say which version of which contract produced it is a spreadsheet cell with better formatting, and it will lose the first dispute it meets.
Capture accessorials where the work happens, not at month-end. A re-wrap, a relabel, a kitting job, a return, a rush pick after hours. The scanner or the portal records the work as it is done, tied to the client and the stock it touched. Anything left to memory leaks, and it only ever leaks in one direction.
Give each client a statement, not just an invoice. Charges to date, the movements behind every line, stock on hand, documents. A portal that shows the client the same ledger you see removes most of the email your operations team answers, and it ends most disputes before they are raised, because there is nothing left to argue about.
Reconstruct any invoice, months later, to the identical number. This is the test that separates a billing engine from a report. Movements land in a ledger that is never edited. Charges are derived from the ledger and the contract version, never typed in. Rerun a disputed month a year on and the figure has to match to the cent.
Treat the tax authority as an integration with failure states. In Saudi Arabia, the Fatoora platform under ZATCA's integration phase clears a standard tax invoice before it is valid, returning it with a cryptographic stamp and QR code, while simplified invoices are reported to the platform within 24 hours of issue, both as XML. The integration phase has arrived in waves since January 2023 and the turnover threshold that pulls a business in has dropped with every wave, so a 3PL that sat outside it two years ago may not now. In the UAE the mechanism is different: invoices travel between accredited service providers on the Peppol network under the Ministry of Finance's programme, on the timetable above. Either way the billing engine needs a queue, retries, a record of what the authority accepted and rejected, and a plan for the hour at month-end when the platform does not answer.
Ask a vendor to show you each of those five on a live screen before you buy, and ask a build partner to show you where each one sits in the plan before you sign. The products that sell themselves as 3PL billing software are usually strong on the first two. It is the last three where the spreadsheet comes back.
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.
CEO and co-founder of Geminate Solutions, a software and product development partner. He has led teams shipping custom web apps, mobile apps, SaaS platforms, and AI products that serve over 250,000 daily active users.
Find out what your invoice run is missing
Send us one month of movements and the matching invoices. A senior engineer re-derives the charges from your own rate cards and sends back every line that does not reconcile, with the reason. No pitch, no commitment, and you keep the analysis whether or not we ever work together.
- Accessorial work that happened but never reached an invoice
- Clients whose contract terms have drifted from what you actually bill
- Whether your WMS can export movement data clean enough to bill from
- An honest answer on whether you need a build at all, or just a better export
Get your free billing leakage check
Tell us which WMS you run and your work email. We reply within 48 hours.
Frequently asked questions
Get a free 24-hour review of your website
Send us your website link on WhatsApp. Within 24 hours we tell you exactly what is costing you customers and what we would fix first. No obligation and no sales script.
4.9 rated · 50+ products shipped · 250K+ daily users served
Already built something, and it is starting to break?
Most teams that reach us have a working product and a growing list of things that scare them. We read the code first and tell you what actually needs fixing, including the parts that do not. Rebuilding from scratch is rarely the honest answer.
Lovable Authentication: What Breaks the Week Real Users Log In, and What to Fix First
Google login bounces to the preview URL, sign-ups stop confirming, a customer wants an admin, an investor asks about two-factor. Why each one happens in a Lovable app, the Supabase limits behind them, who can ignore all of it, and the order to fix it in without logging anyone out.
Your Fleet Data Lives in Samsara or Geotab. Here Is What You Can Actually Build on It
What the Samsara and Geotab APIs let you build without touching the hardware. Their documented rate limits and pagination side by side, why one pushes events and the other only polls, who should use Fleetio or Zapier instead, and what to build first.
Lovable Backend Solutions: What You Have, Where It Ends
Lovable gives you a real backend, until it does not. The documented ceilings of the edge function model, the five signals your app has outgrown it, the three ways to add a custom backend without a rebuild, and the honest case for doing nothing yet.
AI App Builder: Which One to Pick, and What Breaks After
Every comparison ranks these tools on the demo. None say what you are left holding. What Lovable, Bolt.new, v0, Replit Agent, Base44 and Firebase Studio each generate, where no-code AI app builders differ from code-generating ones, and the four failures that show up the week real users arrive.
How Do You Stop Prompt Injection in a Production AI Agent?
Your system prompt telling the model to ignore injected instructions does not hold, and a classifier will not save you either. Where the trust boundary actually belongs, why closing the exit beats guarding the entrance, and the six published patterns that trade capability for a guarantee.
AWS IoT Core vs Azure IoT Hub: Does the Choice Matter?
Every comparison is a table of checkmarks. None say whether the decision deserves the three weeks you are about to give it. What each platform actually is, where lock-in really accumulates, what breaks first once the fleet is real, and when the right answer is to skip both.
React Web App to Mobile: Wrap, Rewrite, or Neither?
The tutorials say the wrap takes five minutes. They are right, and that is not the hard part. What ports out of a React codebase, what quietly does not, the App Store rule nobody mentions until after the work is done, and how to tell which of the three answers your product actually needs.
Can You Put PHI in an LLM? What a BAA Actually Covers
Every page tells you ChatGPT is not HIPAA compliant. None tell you what compliant looks like in your stack. Which vendors sign a BAA, what that signature reaches, why zero data retention decides whether it means anything, and the leak sitting in your own observability tooling.
Firebase Studio Is Shutting Down: Getting Your App Out Before March 2027
Google deletes Firebase Studio workspaces on 22 March 2027. Your data survives and your app keeps running. The record of why it was built the way it was does not. What the export contains, what it leaves behind, and what breaks first under real users.
Base44 to Production: What You Own and What You Cannot Take
You pressed export and got a repository. Then you read the environment file and found it still points at Base44. What the export actually contains, what stays behind, what the Wiz security disclosure means, and the four-stage sequence for moving off the platform.
Your AI Pilot Works. Why Is It Still Not Live?
The demo landed and the budget followed. Nine months later it is still a pilot. Why a pilot is a complete answer to a different question, what has to exist around the model before real users arrive, how to tell a retrieval problem from a generation one, and the order the work has to happen in.
FlutterFlow to Production: What Export Actually Gives You
You pressed Export Code and found out it only goes one way. Somebody has already said the word rebuild. It is real Flutter and it compiles, so this is almost never a rewrite. What actually lands in your repository, why the helper library is now yours to maintain, where custom code stops, and the order a takeover has to happen in.
Single Tenant to Multi Tenant: What Actually Has to Change
Fifteen customers on fifteen deployments, or one bespoke build you now want to sell as a product. Somebody has told you this needs a rewrite. It usually does not. Why the tenant column is the easy afternoon, why enabling row-level security does not apply it to the role that owns the table, and what breaks that is not the database at all.
Expo Go to Production: What Actually Breaks
It ran fine in Expo Go and now it will not ship. The JavaScript is not the problem and almost none of it needs rewriting. Why you no longer eject, why your environment variables were baked in at build time, what the New Architecture migration really costs, and who should not do any of this.
On-Premise LLM Deployment: Do You Actually Need It?
The data cannot leave our infrastructure is four requirements in one sentence, and only one of them needs your own hardware. What the cloud already guarantees by default, why strict retention quietly switches off specific frontier models, and the three cases where on-premise is genuinely the only answer.
Supabase Scaling: Which Wall You Actually Hit (2026)
Three walls, in a fixed order. Connection exhaustion first, query shape second, real architectural limits a distant third. Why upgrading compute is usually the wrong first move, why Prisma times out when nothing else does, and the three cases where leaving Supabase is genuinely the answer.
What Does Lovable Actually Generate? The Answer Changed in May 2026
Nearly every guide still says React on Vite. Lovable s own FAQ says apps created from 13 May 2026 use TanStack Start with server-side rendering. How to check which one your project is, why it decides whether AI crawlers can read you, and why you almost certainly do not need a Next.js rebuild.
Next.js 16 Migration: What the Codemod Cannot Do For You
The codemod renames middleware to proxy and moves your Turbopack config. It cannot decide where your auth boundary lives, and it will not stop next build failing on a webpack config you never wrote. What breaks, in what order, and who should wait.
Originally published on Geminate Solutions.
Top comments (0)