You're Not Undercharging. Your WMS Can't See the Work.

The Invoice Looks Clean

Pull last month's invoice for your largest account. A few line items, sensible volumes, rates that match the agreement. Nothing on it looks wrong.

Now put it next to what the operation actually did for that client, and the two documents stop describing the same month.

The special packaging somebody improvised in week two isn't there. Neither is the emergency relabel, or the manual cycle count someone ran because the numbers had drifted, or the third redelivery attempt.

Nobody decided not to bill for that work. The invoice simply had no way of knowing it happened.

Not Undercharging. Under-Capturing.

This is usually diagnosed as a pricing problem, and it responds badly to pricing solutions.

You can raise rates and still lose the same margin, because the leak isn't in the number attached to each activity. It's in which activities produce a number at all.

A rate card is negotiated with custom terms. The billing system never sees those terms, so it bills the standard ones. Operations absorbs an exception because the client needed it that day and the alternative was a difficult phone call. Finance assembles the invoice from what it can see and charges what it can defend.

Every one of those is a reasonable decision made by someone doing their job well, and the sum of them is an invoice that describes a cheaper month than the one you had.

Billing Can Only Invoice What the Floor System Recorded

Here is the part that gets missed when this is treated as a back-office problem.

Your billing system is downstream. It cannot invoice an event that was never recorded as an event. If the special packaging was never captured as a billable activity in the system running the floor, no amount of finance discipline recovers it, because there is nothing to recover.

Which means the ceiling on what you can bill is not set in accounting. It is set by what your warehouse system is capable of representing.

Some systems can model a client-specific rate card, accessorial charges, exception handling, and storage billed on a schedule the client negotiated. Some can model receiving and picking and consider the rest an integration problem for somebody else.

The gap between those two is invisible in a demo and shows up in the first month of invoices.

Nobody Tests This in a Demo

I have sat on the vendor side of these evaluations, and I can tell you where the questions concentrate.

Buyers test receiving. They test picking paths and putaway logic and how the handheld behaves. They watch a wave get released. These are the parts of the operation they can see from the floor, so these are the parts they think to interrogate.

Almost nobody asks the vendor to price a month. Nobody hands over a real rate card with its exceptions and asks the system to produce the invoice that follows from it.

The vendor is not hiding anything. They answer the questions in front of them, thoroughly, and billing complexity is not one of the questions.

The capability that determines whether you get paid for your work is the one part of the system that never appears in the room where it is chosen.

The Version of This Nobody Calls Billing

There is a variant of this that doesn't look like a billing problem at all, because the operation running it doesn't think of itself as billing for anything.

A distributor holds inventory belonging to a supplier. It gets framed as consignment, or as a favor inside an important relationship. The distributor stores it, handles it, counts it, ships it, and absorbs every one of those costs, because the ERP cannot represent inventory the company does not own and therefore cannot attach a charge to touching it.

That is third-party logistics being performed for free, tracked on a spreadsheet, by a business that would never describe itself as a 3PL.

The system doesn't fail to bill for that work because the arrangement is informal. The arrangement stayed informal because the system was never able to represent it.

The operators who close this gap tend to find it the same way: they try to answer a straightforward question about which clients are actually profitable, and discover the data to answer it was never captured. I've written separately about what that exercise turns up.

What it turns up is a list of the work your operation performs and your systems cannot see. That list is a billing problem today. It is also, almost word for word, the requirements document for whatever you buy next.