3PL Software: What a Third-Party Logistics Operator Actually Needs to Buy, and the Billing Engine No WMS Has.
Updated: 3 days ago
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.
What a 3PL actually sells.
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.
The five things a 3PL needs.
The WMS, which runs the floor.
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.
The order and carrier layer, which faces the client's customers.
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.
The client portal, which faces the client.
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.
The accounting system, which faces the bank.
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.
The billing engine, which nobody sells you.
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.
Where the margin goes.
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.
What the billing engine has to do.
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.
Buy, connect or build.
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.
How we start.
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.
The short version.
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.
Find out where your orders, inventory and invoices stop agreeing.
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:
Comments