WareFlow
A multi tenant platform for warehouse and 3PL operators. Inventory, storage pricing, handling charges and invoicing, from receipt to invoice.
What it does
WareFlow handles the parts of a warehouse business that are easy to get almost right and expensive to get wrong.
- Inventory across multiple warehouses and multiple clients
- Inbound and outbound movements with a full audit trail
- Storage and handling charges calculated from actual positions
- Invoices generated from that calculation rather than typed by hand
- Separate access for the operator and for each of their clients
Built to be trusted with the billing
A billing engine is easy to write and hard to trust. Anyone can produce an invoice. The question is whether that invoice matches what physically happened in the warehouse.
So the check came first. Every billing run is reconciled line by line against production data. Not a sample, not a spot check, every line. When a number is wrong the system says so before the invoice reaches a customer.
That check has caught errors no code review would have surfaced. It is the difference between software that produces numbers and software you can bill a customer from.
When the invoice is rebuilt by hand every month
The situation
A warehouse operator stores goods for a dozen or so customers. Trucks arrive, stock is put away, trucks leave. Every movement is written on a gate pass at the door.
At the end of the month someone opens a spreadsheet and rebuilds the whole thing. They count the pallets that came in, the pallets that went out, work out how much stock sat in the building on each day, apply the rate card, and produce an invoice.
It works. It has worked for years. But it takes days, it depends on one person, and when a customer questions a line there is no record to point at, only the working that produced it.
We were asked to replace that spreadsheet. What we found on the way there turned out to be the more useful part.
Why this arithmetic is harder than it looks
The instinct is that warehouse billing is simple. Count pallets, multiply by a rate. It is not.
A pallet is not a fixed quantity. How many units fit on one depends on the product, and the same product can be counted differently by the operator and by the warehouse it rents space in. Two numbers for one item, both correct, used for different purposes.
Stock is billed daily, not monthly. Storage is charged on how much sat in the building each day, so the month is a running balance rebuilt from every arrival and every dispatch in sequence. One misplaced movement shifts every day after it.
Movements are fractional. A truck rarely carries whole pallets of one product. Half a pallet of one item and a third of another is normal, and those fractions carry through to the invoice.
And the rules have exceptions. Overtime is charged once per day rather than per truck, because the building opens once. Some rates round up, some do not. Minimums apply to some lines and not others.
None of that is unreasonable. All of it is hard to hold in a spreadsheet, every month, without drift.
What reconciliation surfaced
Before writing anything, we reconciled months of closed invoices against the source records behind them.
Differences turned up. They were not the result of carelessness. They came from the arithmetic being genuinely difficult: a rule that was printed on a template but applied differently in practice, a product measured one way in one record and another way elsewhere, a total that looked plausible because two separate differences happened to move in opposite directions.
Individually each one was small enough that nobody would investigate it. It is only when you total them across every account and every month that the number becomes worth a conversation.
Why none of it gets caught
The pattern underneath all of it is that there is no second opinion.
The spreadsheet is both the calculation and the record of the calculation. If it is wrong, the only thing to check it against is itself. A customer disputing a line is shown the working that produced the line, which is not evidence, it is the claim restated.
Errors of this kind are also quiet. A pallet count off by a fraction does not announce itself. It shows up as a total slightly different from last month, which is what every total is anyway.
What we changed
The portal records each movement once, at the gate, as it happens.
The charge is calculated at the moment the record is saved, from the rate card in force, and stored on the record itself. The invoice does not recalculate anything. It adds up charges that were already worked out, each one attached to a truck, a date and a person.
That inversion is the whole design. In a spreadsheet the invoice is where the arithmetic happens, so it is only as good as the month end reconstruction. In the portal the arithmetic happens at the door, when the facts are fresh and the person who saw the truck is the person entering it.
- Gate passwritten at the door
- Month endthe month is rebuilt
- Arithmetichappens here
- Invoiceas good as the rebuild
- Gate passrecorded once, at the door
- Arithmetichappens here, as it is saved
- Recordthe charge stored on it
- Invoiceadds up, recalculates nothing
Three things follow.
The month closes in an afternoon, because the working was done as the month went along. Nothing is re keyed, so nothing is mis keyed.
Every charge points at a record. A query about a line resolves to a specific gate pass with a specific date and vehicle. The conversation stops being an argument about whose spreadsheet is right.
Rates change in one place. Update the rate card and everything priced after it follows. There is no formula to find and edit in fourteen files.
How we proved it
A billing system that produces plausible numbers is worthless. It has to produce the right ones, and it has to be possible to demonstrate that.
So the acceptance test was never that the system worked. It was that the system reproduced the operator's own invoices, line by line, to the smallest unit of currency, from their own source records, for months already closed and paid.
Where our figure differed from theirs we found out why before changing anything. Sometimes the difference was ours and we fixed it. Sometimes it was not, and being able to show exactly which record caused it was worth more than the software.
That discipline also shaped what we did not do. Where a rule was ambiguous we did not pick the reading that made our numbers match. We asked, and where no answer was available we left the difference documented and visible rather than tuning it away.
What this is really about
The operator was not doing anything wrong. The person building that spreadsheet each month was doing careful work under real constraints, and most of the time getting it right.
The problem is that manual billing has no error term. It produces a number and offers no way to know how close that number is.
Recording the movement once, pricing it immediately, and deriving the invoice from the record does not make the arithmetic easier. It makes it checkable. That turns out to be the part that matters.
Who it's for
WareFlow suits operators running stock for more than one client, where storage and handling are charged rather than absorbed, and where the monthly invoice run is currently a spreadsheet somebody has to be careful with.
If that describes your operation, it can be running on WareFlow. If your business works differently, the same engine is the starting point for something built to fit it.
Want WareFlow running in your operation, or something like it built for the way you work? Tell us how your operation runs and we'll show you what it would take.
Book a Free Consultation