3PL billing: the accessorials that never make it onto the invoice

Storage, receiving and picking are counted by the warehouse system as a side effect of doing them. A receipt creates a record, a pick creates a record, and the billing run reads the records. Accessorial work mostly does not. Relabelling fifty cartons for a customer's retailer that changed its spec produces no transaction in a system that only knows about receipts and picks, so the work exists on a whiteboard, in a supervisor's memory, or in an email asking whether anybody did it.

Month-end capture then asks people to reconstruct a month of exceptions from memory. The careful ones under-report and the rest guess, so the invoice is wrong either way, and the customer who checks it finds the guesses rather than the omissions.

• Rework and relabelling: new labels, new cartons, kitting and de-kitting, usually triggered by a retailer changing a rule
• Rush and same-day orders: the pick happened, the premium was never coded
• Returns processing: inspect, grade, restock or dispose, each a separate line on most rate cards and each recorded nowhere
• Special packaging and materials: dunnage, shrink wrap, pallets supplied, branded inserts
• Extended storage: the pallet that crossed into a second period, missed because storage was billed off a snapshot taken on the last day
• Detention and dock time: a carrier held past free time on your dock, chargeable to the customer whose freight it was
• Customer-requested work with no item code: counts on demand, photographs, document retrieval, a visit from the customer's auditor

Each one has a rate. None of them has a transaction, which is the whole problem.

More than it seems. The labour system and the scanners log who did what and for how long; the warehouse system logs every inventory move, including the ones that only happen during rework; the dock log holds trailer arrival and departure; the returns area usually keeps its own sheet; and email holds the customer's request for nearly every one of these. The evidence of the work exists. It is just not in the shape of a billable line.

So the fix starts from those records rather than from a new form for the floor to fill in. A form is month-end capture with extra steps; a record that already exists is captured by definition.

• A billable-event code on the handheld, chosen from the customer's own rate card, at the point where the work is done: rework starts, a rush pick is released, a return is graded
• Automatic events from the records that already exist: an inventory move of the rework type, a trailer past free time on the dock log, a pallet crossing its storage anniversary
• A queue for the ones that need a human decision, reviewed weekly rather than monthly
• Every event tied to a customer, an order or a receipt, and a date, so the invoice line can be defended when the customer asks

Then the billing run reads the events the way it reads receipts and picks, and the accessorial lines appear on the invoice without anyone having to remember anything.

The second half is comparing activity against invoices as a report rather than as a month-end argument: for each customer, the events recorded, the events billed, and the difference. Run every week, the difference is a handful of lines somebody can explain. Run once a quarter, it is a dispute.

The same comparison answers the question most 3PLs cannot: which customers are actually profitable. Cost to serve per customer is the activity priced at cost set against the activity priced at the rate card, and it only works once the activity has been captured.

That report is the billing reconciliation the 3PL reporting layer exists to produce, from the records above, in a database the warehouse owns. The rate engine and the invoicing that read the captured events are the 3PL billing and settlement work on our logistics page. For the vocabulary, the glossary's billing section covers rate cards, anniversary billing and accessorial capture, and says why it carries no leakage figure.