Search for 3PL software and you get a list of warehouse management systems. That is not wrong. A third-party logistics operator lives or dies on the floor, and the WMS is the system that runs the floor. But a WMS is one of five things a 3PL needs, and the one that decides whether the operator makes money is the one that appears on none of the lists.
This post is a buying map. It says what a 3PL of thirty to three hundred people actually needs, which of those things to buy, which to connect, and why the fifth one, contract billing, is the engine no WMS has and every growing 3PL ends up needing.
A 3PL does not sell warehousing. It sells a contract. Each client has a schedule of rates: storage per pallet per week, or per bin per month, or per cubic foot; receiving per pallet or per carton; picking per order plus per line plus per unit; packing by carton size; value-added services like kitting, labelling and returns processing, each at its own rate; and a list of surcharges for rush orders, hazmat, oversized items, weekend work and whatever else was negotiated on the day the contract was signed.
Every one of those rates was agreed by a salesperson and lives in a document. Every one of the activities they price is recorded by the WMS as a movement: a receipt, a putaway, a pick, a pack, a shipment. The movement is recorded. The rate is in a document. Nothing connects the two. That gap is the whole subject of this post, and we will get to it after the map.
This is the system everyone means by 3PL software. It holds locations, inventory by client, receiving, putaway, wave and pick, pack, ship and cycle counts. Buy it. Do not build it. The mid-market has good options and the differences between them matter less than whether your floor supervisors will use it. The one thing to check hard before signing is the API: whether every movement the WMS records can be read out by another system, in near real time, without an export.
Orders arrive from the client's shop, marketplace or ERP, and shipments leave with a carrier label. Most WMS products have this built in or bolt it on through a shipping platform. Buy it, and check the same thing: every order in and every shipment out should be readable by the system that will bill for them.
A 3PL client wants to see inventory, orders, shipments and, sooner or later, their invoice, without emailing you. Most WMS products ship a white-label portal that shows the first three. We have written about what happens when the built-in portal stops being enough, and the short version is that it stops being enough on the day a client asks why an invoice line does not match what they can see. The portal can only answer that when it can see billing.
Invoices, receivables, payables, payroll, the general ledger. Buy it. Keep it. It is not the billing engine, and the mistake most 3PLs make is to think that because the invoice comes out of accounting, the billing logic lives there. Accounting can hold an invoice. It cannot read a thousand pick events and a contract and produce one.
This is the fifth system, and here is why the WMS vendor does not have it. A WMS is built around the floor, where every client's pallet is a pallet. Contract billing is built around the contract, where every client's pallet is a different price under different conditions with different minimums and different surcharges. The two models do not share a centre. WMS vendors have tried to add billing modules and they tend to handle the easy cases, per-pallet storage and per-order picking, and hand the rest back to a spreadsheet.
So the billing engine is the thing you connect or build, and it is the subject of the rest of this post.
We wrote a longer piece on 3PL billing software and the three to fifteen percent of revenue that leaks when billing is done by hand from WMS exports. The mechanism is short enough to repeat here.
Activities that are done and never billed. A rush pick, a relabel, a returns inspection. The floor did it; the WMS may or may not have a code for it; the person building the invoice from the export did not see it. It is gone.
Rates that are applied from memory. The contract says one rate for the first two hundred orders a month and another after that. The spreadsheet says one rate. Whoever built the spreadsheet rounded.
Storage billed from a snapshot. Storage is the biggest line and the one most often billed from one count a month rather than the daily balance the contract specifies. Whether that under-bills or over-bills depends on the client's pattern, and either way it produces a dispute the day the client checks.
Invoices that arrive late. Building an invoice from exports takes days. Every day it takes is a day added to days sales outstanding, on a business that has already paid its warehouse staff for the month.
None of these are software bugs. They are the predictable result of recording activity in one place, keeping rates in another and connecting them with a person.
The engine sits between the WMS and the accounting system, and it does four things.
It reads every billable event from the WMS as it happens: every receipt, pick, pack, shipment, special handling code and daily storage balance, by client. This is why the WMS API check above is the one that matters most.
It holds every client's contract as rules, not as a document: rate schedules, tiers, minimums, surcharges, effective dates, and the definition of a billable unit for that client. When the contract changes, the rules change from the effective date, and the old rules keep applying to the old period.
It applies the rules to the events and produces invoice lines, continuously, so that on any day of the month you can see what each client owes so far. This is the number that tells you whether a client is profitable before the month ends rather than after.
It hands the finished invoice to accounting as an invoice, with lines the client can reconcile against what they see in the portal, and it hands the same lines back to the portal so the client sees them before the invoice arrives.
Here is the position. Buy the WMS, the shipping layer and the accounting system; they are commodities and the market is good. Connect them, because the value of a 3PL's stack is the joins and not the boxes. For the billing engine, look first at the standalone 3PL billing products, and take one if your contracts are simple enough to fit. Many are not. When the contracts are the reason clients chose you, the billing engine is the part of the stack that is genuinely yours, and it is worth building on a platform where the rules can be yours too.
For the 3PLs we work with, that platform is usually Zoho, with the billing rules in a custom application, the invoices in Zoho Books, the client-facing view in a portal built on the same records, and the WMS connected through its API. The WMS stays. The accounting stays. The engine in the middle is built to your contracts, and the joins are built so that the floor, the invoice and the portal agree.
If you are earlier than this, still deciding whether the problem is a missing system or a missing connection, this piece on whether you need an ERP or need your systems to talk is the honest place to start, because for most 3PLs the answer is the second one.
We start with a no-risk discovery: a few days to read your contracts, map what the WMS actually records against what the contracts actually price, and put a number on what is being done and not billed. You get a written plan and a guaranteed estimate for the billing engine and the joins around it. If a standalone product would cover your contracts, the plan says so. If it would not, the plan says what to build first, and the first thing is always the piece that recovers the most revenue for the least work, which is almost always storage billing from daily balances.
3PL software is five things, not one. Buy the WMS, the shipping layer and the accounting; connect them; and treat contract billing as the engine that none of them includes. The margin of a 3PL is the difference between what the floor did and what the contract says, and until a system reads both, a person is guessing at it every month.
In a no-risk discovery we follow an order from sale to shipment to invoice across your systems and show where it breaks and what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
3PL Inventory Management Software: A Zoho Stack for Ecommerce Operators (article)
3PL Billing Software: How to Stop Leaking 3-15% of Revenue (article)
When a White-Label Logistics Customer Portal Stops Being Enough (article)
The WMS is the largest licence line and is usually priced per user or per warehouse on a monthly subscription. The shipping layer and the accounting system are smaller subscriptions. The billing engine is the variable: a standalone 3PL billing product is a modest subscription if your contracts fit it, while a custom engine built to your contracts is a one-time project. The connections between the five systems are the line most buyers forget to price, and they recur as long as the systems do.
Most 3PLs need both. The WMS is built around the floor, where a pallet is a pallet, and it is good at receiving, putaway, picking, packing and counts. Contract billing is built around the client's rate schedule, where the same pallet carries a different price, minimum and surcharge for each client. WMS billing modules handle the simple per-pallet and per-order cases and tend to hand the rest back to a spreadsheet. A single product covers both only when every contract is simple.
The one check that matters most is the API. Every movement the WMS records, including receipts, picks, packs, shipments, special handling codes and daily storage balances by client, should be readable by another system in near real time without an export. That is what lets a billing engine, a portal and an accounting system work from the same events. Also check that floor supervisors will actually use it, that it holds inventory by client, and that the shipping and order layer is readable the same way.
Each client has a schedule of rates: storage per pallet or bin per period, receiving per pallet or carton, picking per order plus per line plus per unit, packing by carton size, value-added services at their own rates, and surcharges for rush, hazmat, oversize and weekend work. A billing engine holds that schedule as rules with effective dates, reads every billable event from the WMS as it happens, applies the rules, and produces invoice lines continuously, so what each client owes is visible on any day of the month.
Build when the contracts are the reason clients chose you. If your rate schedules are standard, a packaged 3PL billing product will model them and is the faster choice. If they include tiers that change mid-month, client-specific minimums, bundled value-added services and surcharges negotiated deal by deal, a packaged tool flattens them and the leak returns. A built engine on a platform where the rules are yours keeps the WMS and accounting as they are and puts the contract logic in the middle.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
