Cold Storage Warehouse Software: Why Tariff Billing and Catch Weight Break General WMS Products

Why a public refrigerated warehouse is not a warehouse with a thermostat

A truck arrives at a dock at 5am with 22 pallets of boneless beef. The bill of lading says 22 pallets. It does not say the weight, because the weight is not a fixed number: every case is different and the customer is billed and inventoried on actual pounds. The receiving clerk weighs each pallet, records the lot code and production date, and decides where the pallets go, which is a temperature and segregation question rather than a slotting one. Half the load is destined for blast, and blast has eleven open positions today because a different customer pushed a run yesterday.

Meanwhile the billing cycle is running. This customer is on an anniversary storage tariff, meaning each lot bills from its own receipt date rather than on a calendar month, at a rate per hundredweight, with a first month minimum, plus in and out handling, plus a blast charge, plus a case pick fee for a pick they did on Tuesday. Nobody in the industry finds this exotic. It is simply what a warehouse tariff is. And almost no general warehouse management product can express it, which is why the invoice is built in a spreadsheet by a person who knows the customer.

That is the structural problem. Datex FootPrint, Extensiv 3PL Warehouse Manager and Made4net are real products, and for dry goods third party warehousing they do a competent job. Temperature controlled public warehousing is a different business wearing the same clothes. You are holding someone else's food, with regulatory holds and release conditions attached, at a temperature you are liable for, and you bill on a tariff that behaves more like a utility rate schedule than a price list. Two of the three core objects, the inventory record and the billing engine, carry direct financial exposure, and off the shelf tools treat both as configuration on an ordinary warehouse.

Problem one: catch weight is not a field, it is a second unit of measure

Catch weight means an item is tracked in two units at once: cases and pounds, or pallets and kilos. A customer orders 40 cases and receives 40 cases weighing 2,163 pounds. You inventory both numbers. You bill storage on weight and handling on cases. You allocate in cases but ship on the actual weight picked, and the shipping document must carry the real number because your customer's own invoice depends on it.

Products that bolt catch weight on as an attribute break in the places that matter. A partial pick has to reduce both units correctly. A repack changes the relationship. A cycle count has to reconcile in two dimensions and tell you which one is wrong. A general warehouse system that has one authoritative quantity and a secondary weight field will drift, and once weight drifts you are billing storage on a number that does not match the freezer. A custom build makes both units authoritative from the schema up and moves both on every transaction, because your storage revenue is calculated from one number and your customer's inventory position from the other.

Problem two: tariff billing is a rate engine, and spreadsheets are hiding it

Ask an operator to describe their tariff and you get a document, not a price. Storage is charged per hundredweight or per pallet, per month or per half month, on an anniversary cycle or a split calendar cycle, often with a first period minimum that means goods received on day 28 still pay a full period. Handling is charged in and out, sometimes separately, sometimes as a combined rate. Then there are accessorials: blast freezing, tempering, case picking, palletising, repacking, labelling, recouping, container unloading, detention, and after hours receiving. Different customers have different schedules, and the big ones negotiated exceptions.

Billing therefore takes a person several days per cycle and depends on that person's memory of exceptions. Unbilled accessorials are the quiet leak in refrigerated warehousing, invisible precisely because the work is performed by floor staff and captured on paper.

What a custom build does is make the tariff executable. Rates are versioned data with effective dates by customer, commodity and service. Every billable event is emitted by the operation that caused it, so a blast charge is created when the pallet enters blast rather than when someone remembers, and a case pick fee is generated by the pick confirmation. The billing run becomes a review of exceptions rather than a construction project, and the cycle that took four days takes an afternoon. This is usually the feature that pays for the build outright.

Problem three: blast freeze is a capacity constraint nobody models

Blast cells are finite, they are the most energy intensive asset in the building, and product has a required residence time to reach core temperature that depends on the product and how it was loaded. A customer who ships hot product on a Friday afternoon and expects it available Monday is making a capacity claim on your building, and if you accept it without checking, you either fail the residence time or you displace another customer's run.

General warehouse products treat blast as a location you move a pallet into and out of, with no capacity model, no scheduling and no residence enforcement, so the schedule lives on a whiteboard beside the cell and the supervisor is the scheduler.

A build worth paying for treats blast as a resource with capacity, a queue and a rule set. Requests are booked against available capacity, residence time is a property of the product and the load pattern, and the system will not release a pallet to storage before its time is served without a supervised override that is logged. It also gives you something you have never had, which is the true utilisation of your most expensive asset, and therefore a defensible basis for what a blast charge should actually be.

Problem four: holds are regulatory events, not inventory statuses

Product goes on hold for reasons that come from outside your building. A federal or state agency places a hold. A customer places their own quality hold. A temperature excursion in transit triggers an investigation and the receiving lot cannot ship until it is resolved. A hold may cover a lot, a production date range, or everything from one supplier.

A status flag on a pallet does not survive this. You need holds as objects in their own right, with a scope that can be expressed as a query, an owner, a reason, a document trail and an explicit release with a signature. You need the hold to bind product that arrives after the hold was placed if it falls in scope, which a flag cannot do. And when an inspector asks how a specific pallet was released, the answer has to be a record rather than a recollection.

Traceability sits alongside this. The federal traceability rule under the Food Safety Modernization Act, commonly called FSMA 204, has a compliance date of July 2028 and applies to foods on the FDA Food Traceability List, and cold storage operators sit squarely in the chain for many of those foods. Whether your specific customers' products are covered is a question for a food safety consultant rather than a blog. What is not in question is that your customers already ask for lot level trace on request.

What a custom cold storage build has to include

• Dual unit of measure inventory where cases and weight are both authoritative and every transaction moves both.
• Lot level receiving with production date, supplier lot, temperature at receipt and the receiving document images attached.
• A tariff engine with versioned, effective dated rates by customer, commodity and service, covering anniversary and split cycle storage plus first period minimums.
• Billable events emitted by the operation that caused them, so accessorials are captured at the point of work rather than remembered at month end.
• Blast and tempering as scheduled resources with capacity, queueing and enforced residence time.
• Holds as scoped objects with owner, reason, document trail, forward binding to newly received product and a signed release.
• Temperature monitoring integration with excursion alerting tied to the affected lots rather than only to a zone.
• A customer portal showing live inventory in both units, order status, appointment booking and downloadable trace reports, because this is the feature that retains accounts.

What this costs and how long it takes

A focused first release, meaning catch weight lot receiving, put away and picking, hold handling and the tariff engine for storage and handling, runs $80,000 to $160,000 and ships in 12 to 16 weeks. That is a system the floor and the billing clerk both use on day one. A full platform adding blast and tempering scheduling, dock appointment scheduling, the customer portal, trace queries and accounting integration runs $200,000 to $450,000 phased over 6 to 12 months.

What drives the number up in this sector specifically: the number of sites and whether stock transfers between them; the variety of your tariffs, because ten customers on similar schedules is a different build from forty with negotiated exceptions; electronic data interchange, since each grocery trading partner implements warehouse documents its own way and is real weeks of work; and radio frequency hardware in a freezer, because scanners, labels and gloves at minus 20 behave differently from scanners in an office.

What keeps the number down: start with one site, your top ten customers by revenue and your current tariff exactly as written. Do not redesign the tariff during the build. Rationalise it afterwards.

When buying off the shelf is the right answer

Buy if you are a single site operator under roughly 10,000 pallet positions with flat monthly storage rates, a handful of customers and no blast capacity to schedule. Datex FootPrint or Extensiv will hold your inventory, and your billing is small enough for a spreadsheet. Buy also if you are a private warehouse holding your own product, since without third party billing the hardest part of this build vanishes.

Build when two or more of these are true. Your billing cycle takes more than two days and depends on one person's knowledge of customer exceptions. You know you are performing accessorials that never reach an invoice. Blast capacity is scheduled on a whiteboard and customers get told yes before anyone checks. You hold product for customers who ask for lot level trace and your answer takes a day or more. You run more than one temperature controlled site and inter site transfers are managed by phone. At that point the coordination between inventory, temperature, holds and the rate schedule is your business, and it should not sit in a spreadsheet next to a product built for dry goods.

How to choose a developer for cold storage software

Ask them to whiteboard the inventory model before you sign. A team that has done food warehousing draws the lot, the pallet, both units of measure and the hold scope, and they will tell you unprompted that catch weight cannot be a secondary field. A team that draws products and quantities has built ecommerce fulfilment and is about to learn refrigerated warehousing on your budget.

Ask them to model one page of your actual tariff during the sales process, including the anniversary cycle and the first period minimum. It is a two hour exercise and it separates people who have done this from people who are merely confident.

Ask what hardware they have deployed in a freezer. Scanner choice, label stock that survives condensation, and screens usable with cold weather gloves are not afterthoughts.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to work on it. At Digital Heroes the client owns the code from the first commit, and in a business where the software is the billing engine for the facility, any other arrangement is a dependency.