Produce Packing House Software: Settling Grower Pools When the Returns Do Not Add Up

Why a packhouse is really a settlement business with a cooler attached

The packing charge on a carton is a number your growers will argue about, and the shrink between what came in from the field and what shipped as a retail pack is the number they will argue about harder. A house takes in bins from thirty growers, runs them across a line, packs into four pack styles and two labels, sells into pooled programmes with different customers at different prices across three weeks, then settles back to each grower a return per bin that reflects their share of the pool minus packing, cooling, palletising, and a share of the culls. Every one of those steps involves a rule that is in your grower agreements and nowhere in your software.

The stack is usually Famous Software or Produce Pro doing the core, sometimes Silo where the finance and trading side matters most, plus a scale house, plus a line with a sizer that produces its own reports, plus spreadsheets doing the pool math because the pool math is where your specific agreements live. Those products are not weak. Famous has been running produce operations for a long time and its grower accounting is genuinely deep. Produce Pro is a serious distribution platform. Silo is well built for cash flow and trading visibility. The strain appears in the same place every time: your pool rules, your packing charge schedule, and your shrink allocation method are contractual terms specific to your house, and configuring them into a licensed product means either bending your agreements to the software or bending the software through the vendor, on the vendor's schedule, during your season.

The cost of that gap is concrete. Settlements that take three weeks after a pool closes rather than three days, which is a cash and trust problem with growers. Shrink that gets allocated by a rule of thumb because the true grade out per grower was never captured at the line, so good fruit subsidises poor fruit and the good growers eventually leave. And a settlement that cannot be explained line by line when a grower's own bookkeeper calls, which turns a routine question into a relationship problem in a business where next season's volume is a handshake.

Problem 1: the conversion from field bin to carton is where the truth is lost

Bins arrive with a grower, a block, a harvest date, and a weight. They get dumped, sometimes commingled with another grower's fruit on the same run because the line does not stop, then sized and graded into packs, culls, and juice. Somewhere in there the tie between the carton and the bin it came from either survives or does not. In most houses it does not survive commingling, so pack out per grower is computed as a share of the run rather than measured.

What a custom build does: model the run as a first class object with a start, an end, the bins fed into it, the line, and everything that came off it, including culls and juice by weight. When bins from several growers feed one run, the system knows the input proportions by weight and applies your stated allocation method, and the method is visible on the settlement rather than implied. Where you can run single grower blocks, it records true pack out, and after a season you have enough paired data to know how far the run average sits from each grower's real performance. That is the number that lets you fix the shrink argument with evidence instead of with a policy.

Problem 2: pool accounting is your contract and no vendor owns it

Pools differ by commodity, by customer programme, and by grower agreement. Some pools close weekly, some at the end of a variety window. Some carry a portion of unsold inventory forward, some write it off. Packing charges may be flat per carton, tiered on volume, different by pack style, or discounted for growers who deliver in the house's own bins. Some agreements guarantee a floor. Some allocate freight by pallet position rather than by carton.

What a custom build does: express pool rules as configuration you control, versioned and dated, with a settlement engine that computes from events rather than from a monthly summary. Every carton sold posts revenue to the pool, every charge posts against it, and each grower's share derives from their input weight adjusted by your allocation method. Then two things become possible that a spreadsheet cannot do: settle a pool in a day because the math is continuous rather than assembled, and run a preliminary settlement mid pool so growers can see where they stand. The second is a commercial advantage. Growers place volume with the house that tells them where they are.

Problem 3: PACA terms and price after sale make revenue a moving number

Produce sold under the Perishable Agricultural Commodities Act carries trust protections for sellers and specific expectations around prompt payment and record keeping, and licensed dealers operate under obligations that are worth taking seriously in how your systems record transactions. On top of that sits the ordinary reality of the trade: consignment sales that settle at whatever the receiver got, price after sale adjustments, rejections at the receiver's dock, and credits for condition on arrival.

What a custom build does: revenue lines carry a status, provisional or final, with adjustments recorded as events against the original sale rather than as edits. The pool holds a reserve you configure, so preliminary settlements are conservative and final settlements true up transparently. Rejections and condition credits attach to the specific lot and pallet, which means the pattern becomes visible: a particular customer rejecting a particular grower's fruit repeatedly is either a quality issue or a receiving issue, and until it is attributable nobody can tell which.

Problem 4: traceability breaks at the repack, which is where you need it most

FSMA 204, the traceability rule, applies to foods on the FDA Food Traceability List, which covers a large share of fresh produce, and the compliance date has been extended, so confirm the current date and your specific coverage with a food safety adviser rather than with a blog. Separately, retail customers already require Produce Traceability Initiative case labelling with a GTIN and lot, and they audit against it.

What a custom build does: treat every repack, re-label, and re-grade as a transformation event with inputs and outputs, so a carton's ancestry is a graph rather than a single parent. Case labels are generated from the system with the GTIN and lot encoded, printed at the line rather than typed, and the shipment record ties pallets to a specific customer, load, and door time. Then a recall query runs in both directions in seconds: from a block to every customer who received anything derived from it, and from a customer complaint back to the harvest date and the crew. In a category where an event is measured in trucks already on the road, the difference between minutes and a day is the size of the recall.

Problem 5: nobody knows the cost per carton by line, shift, or commodity

Labour is the largest controllable cost in a packhouse and it is usually accounted for as a weekly total. So the house cannot say what it costs to pack a given style on line two on a Saturday with a crew of twelve, versus line one on a Tuesday. Cooling and storage are similar: a pallet that sits four extra days consumed space and energy and lost value, and none of that lands against the pool that owned it.

What a custom build does: labour hours post to runs through the crew and shift record, so cost per carton comes out by line, style, shift, and commodity. Storage days accrue against the lot. Then the packing charge schedule can be set from evidence rather than from last year's number plus inflation, and the house can see which pack styles genuinely lose money at current charges. This is usually the report that pays for the phase two budget, because most houses discover at least one style they have been subsidising for years.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and this is the honest shape for a packhouse build. A first release covering receiving by grower and block, runs with grade out capture, packing charge schedules, and pool settlement runs $90,000 to $180,000 in 14 to 20 weeks. A full platform adding traceability through repacking, PTI labelling, cooling and inventory ageing, price after sale and rejection handling, a grower portal, and cost per carton reporting runs $220,000 to $520,000 across 9 to 15 months.

What drives price up specifically here: the number of commodities, because each one has its own grades, pack styles, pool behaviour, and season. Line and sizer integration, since equipment from different manufacturers exposes data in different ways and some of it comes off a PLC rather than an API. Scale house automation. Label printing at line speed, which is a real engineering concern rather than a formality. EDI with retail customers, where each trading partner's implementation is its own project measured in weeks. And accounting integration, because settlements have to land in your general ledger without a person re-entering them.

What keeps price down: one commodity, one season, and the top ten growers by volume. That covers most of the money and all of the rule complexity you actually have.

Build versus buy, and when buying is right

Do not build if you pack a single commodity, mostly your own fruit, with a handful of outside growers on simple flat rate agreements. Famous or Produce Pro will cover you, they encode years of produce practice, and a custom build would be an expensive way to reproduce it. If your pain is cash flow visibility and trading rather than the packhouse floor, Silo is a much cheaper answer than a bespoke platform.

Build when two or more of these are true. You settle pools for more than about twenty growers. You run more than two commodities with genuinely different pool rules. Your settlement process depends on a spreadsheet maintained by one person. You repack or re-label significant volume and your trace chain breaks there. Or growers are asking for mid pool visibility and you cannot give it to them without a week of work.

The tipping point is that a packhouse's product is trust in a number. When your competitive position depends on growers believing your settlement, and the settlement is computed outside your system by a person, you are one resignation away from a very bad season. That is a different risk from wanting nicer reports.

How to choose a developer for packhouse software

Ask them to model a run fed by bins from three growers producing two pack styles, culls, and juice, and then to explain how shrink attributes back. If they cannot draw the run as an object with inputs, outputs, and an allocation method, they are going to build you a warehouse system and you will do the pool math in Excel exactly as you do now.

Ask how a repack is represented. The right answer is a transformation event with multiple inputs and multiple outputs and an ancestry graph. If they describe a parent lot field on the carton, the trace will break the first time a pallet is rebuilt.

Ask who owns the code, the infrastructure, and the settlement logic, and get it written before kickoff. Your pool rules are commercial terms and they should not live inside somebody else's licensed product where a change waits on a release cycle in the middle of your season. At Digital Heroes the client owns the code from the first commit.