3PL billing software: from warehouse activity to an invoice nobody disputes

The short answer

What a 3PL actually bills for

The rate card usually starts with storage and handling and then grows, because clients keep asking for things that are not on it. A realistic list:

• Storage. Per pallet, per bin, per cubic metre, per week or per day, sometimes with a free period and a long-stay surcharge. Simple to state, awkward to compute, because occupancy changes daily and the billing basis is usually a snapshot someone has to define.
• Inbound handling. Per carton, per pallet, per unit; with a distinction between a standard receipt and one requiring counting, labelling or repacking.
• Outbound handling. Pick and pack, per order and per item, with multipliers for multi-item orders, gift wrapping, inserts, or a specific packaging type.
• Value-added services. Kitting, assembly, re-labelling, FBA prep, quality checks, photography. Almost always ad hoc, almost always under-billed.
• Returns handling. Receipt, inspection, disposition, restock, refurbish, disposal — each a separate event with its own effort and its own line.
• Exception work. Address corrections, re-deliveries, failed collections, stock investigations, cycle counts triggered by a discrepancy. Work nobody quoted because nobody foresaw it, and work that is only billable if it was recorded when it happened.
• Transport. Pass-through carrier cost plus a margin or a fixed fee, which introduces its own reconciliation problem when the carrier invoices weeks after the shipment.

Why the rate card is not the problem

Rate cards are fiddly, but they are also deterministic. Given the events and the schedule, the arithmetic is arithmetic. The genuinely hard properties are these:

• Effective dating. A rate change applies from a date, not from now. Recomputing last month’s invoice under this month’s rates is a defect that is easy to introduce when rates live in a spreadsheet and are applied by hand.
• Per-client variation. The same activity has a different price per client, and the same client may have several schedules by site, by volume band or by contract year.
• Volume tiers and minimums. A rate that drops above a threshold, or a minimum monthly charge, means the invoice is not a simple sum of lines.
• Pass-through versus margin. A carrier charge is passed through at cost, at cost plus a percentage, or at a flat rate with the difference as margin. Which one applies is per contract, and getting it wrong is the error clients notice first.
• Whether an item is billable at all. Re-work caused by the 3PL is not; re-work caused by a client’s late or wrong instruction usually is. That is a judgement, which means it needs a rule and a record.

None of this is beyond a spreadsheet for one client. It stops working at the point where the number of schedules, the number of exceptions and the number of people applying them by hand exceed what anyone can hold in their head — which is usually somewhere around the third or fourth client, and it is a cliff rather than a slope.

Every line needs a record

This is the whole argument. A billable line is only defensible if it points at something that happened, and the record has to carry enough context to answer the question a client will actually ask.

A useful test: pick a line on last month’s invoice and try to answer, without leaving your desk, what happened, when, to which goods, why, and who recorded it. If any of those takes more than a few minutes, the operation is one dispute away from writing off the line.

What a record needs to carry, at minimum:

• The event: what was done, in terms the rate card recognises.
• The timestamp and the client and the site it belongs to.
• The subject: which SKU, order, shipment or return.
• The quantity, in the unit the rate card prices.
• The actor, because “who did this” is the second question after “when”.
• The rate applied and which schedule version produced it.

Two design consequences follow. First, the event has to be captured where the work happens — on the scanner or the warehouse screen — not reconstructed afterwards from memory or from a pick list. Second, the rate schedule has to be versioned, so that reproducing last month’s invoice produces last month’s numbers.

The reconciliation step is where the margin goes

In most 3PLs the invoice is assembled in finance and the events live in the warehouse system, joined by a manual process at month end. That process has three costs, and only the first is obvious:

1. The labour. Days of senior time every month, at the worst possible moment, with a deadline attached.
2. The leakage. Events that were performed but never recorded, or recorded in a form nobody could match later. Unbilled returns handling and unquoted exception work are the usual culprits, and they are invisible because nothing flags a line that was never created.
3. The blind spot. You cannot price new business accurately if you do not know what the current business actually costs to serve. An operation that under-bills exception work believes it is more profitable per client than it is, and quotes the next client on that belief.

The third is the expensive one. Leakage on an existing contract is a recoverable amount. A quote built on a wrong cost base compounds for the length of the contract.

Disputes are usually visibility disputes

When a client queries an invoice, the disagreement is rarely about the rate. It is about whether the work happened, happened that many times, or was authorised. That is a question of evidence, and it has a predictable shape:

• If the client can see the events — the return, its condition photo, its disposition, the exception and who raised it — the conversation moves to the rate, and the rate is contractual. It is short.
• If the client cannot see them, they are being asked to accept a number on trust, and the dispute becomes about the whole invoice rather than one line.

This is why a client-facing view is not a customer-service nicety but a billing control. Exposing the event stream before the invoice goes out removes most of the queries, and the ones that remain are the ones actually worth arguing about.

It also changes when the argument happens. A warehouse exception that is visible to the client on the day it occurs can be approved in a message. The same exception, first mentioned on an invoice three weeks later, is a negotiation.

What to automate first

In order of relief per unit of disruption:

1. Capture billable events at the point of work. Until the disposition on a return, or the re-label in a kitting job, creates a billing line as a side effect, everything downstream is reconstruction.
2. Version the rate schedules. Then any invoice can be reproduced, which is the precondition for answering a query in a day rather than a week.
3. Let the client see the events. Before optimising anything else, remove the information asymmetry that turns a line item into a dispute.
4. Report unbilled activity. A weekly list of events with no invoice line is the single most direct measure of leakage, and it usually pays for the exercise in the first month.
5. Then cost per client per activity. Not to compare clients, but to replace the guess you currently use when quoting the next one.

The common thread is that none of these are pricing features. They are records, and the pricing features only work once the records exist.