Seafood Processing Software: Why Catch Records, Glaze Yield, and Vessel Settlement Never Live in One System

The 5:40am dock problem that no ERP (Enterprise Resource Planning) was written for

A boat is pumping totes of cod and haddock into the receiving bay. The grader is calling sizes over the belt noise, and a supervisor is writing vessel name, species, grade, and tote weight onto a clipboard that will be wet before it is typed. Inside, the fillet line is already running yesterday's landing. By the time that clipboard reaches the office, the plant has turned that fish into three retail packs, a food service block, and a bin of frames headed to the meal plant, and nobody can state with confidence which trip the five pound fillet packs came from.

That gap is the whole business. A seafood plant is not a food factory that happens to handle fish. It is a plant where the raw material arrives with a legal identity attached to it, that identity has to survive heading, gutting, filleting, skinning, trimming, freezing, and glazing, and the customer at the far end is buying the identity as much as the protein. Species, gear type, catch area, vessel, and trip dates are not metadata. They are the product.

Across processing projects we have delivered, the recurring leak is the same shape: two to four percent of raw material value disappearing into unexplained yield variance, one full day per quarter burned reconstructing a trace by hand for a customer or an inspector, and a settlement run that takes a person three days at month end because grade prices, trip advances, ice, and fuel deductions live in four places. None of that is exotic. All of it is a data model problem.

Problem one: catch weight, net weight, and glazed weight are three different numbers

Every seafood plant runs on catch weight, meaning each unit has its own weight rather than a nominal one. That much is well supported. What is not supported is the chain of conversions that follows. Round weight lands. Head off weight comes off the header. Fillet yield comes off the line. Then the frozen product picks up a glaze, and the net weight you declare on the carton is the deglazed weight, not what the scale said at the packer.

Get the glaze math wrong in the optimistic direction and you have a mislabeled net weight, which is a regulatory problem, not a rounding problem. Get it wrong in the cautious direction and you are giving away product on every pallet, quietly, forever. Most plants handle this with a per SKU glaze percentage typed into a spreadsheet once, then never revisited, while the actual glaze pickup drifts with water temperature, dwell time, and how the operator set the dip that morning.

A custom build makes glaze a measured event, not a constant. Sample weights before and after glazing feed a running actual by SKU and by shift, the system flags when the actual drifts more than a point off standard, and the declared net weight on the label comes from the measured figure. That single loop has paid for a project on its own in plants running high volume individually quick frozen shrimp and fillets.

Problem two: species identity is a legal claim you cannot reconstruct later

Species substitution is the exposure that ends careers in this industry, and most of it is not fraud. It is a lot of pollock and a lot of cod that got mixed on a line during a changeover, or a market name typed by someone who used the wrong one of several acceptable names for the same fish. FDA publishes acceptable market names and NOAA runs the Seafood Import Monitoring Program, which requires catch documentation for a defined list of imported species. Your buyer, meanwhile, wants a chain of custody claim they can defend, and if you are Marine Stewardship Council certified, the certified and non certified material must be provably separated through every step.

The failure mode is always the same: a production run on a shared line between two species with no forced changeover record, so the only evidence is what the line lead remembers. A build fixes this by making species, gear code, catch area, and vessel first class fields on the landing lot, propagating them through every conversion automatically, and enforcing changeover rules on the line rather than trusting them. If certified material is scheduled after uncertified material on the same fillet line, the schedule blocks or forces a signed cleandown task. That is a sequencing constraint, and no product level field can express it.

Problem three: yield tells you which vessel is actually profitable, and you are not measuring it

Two boats deliver cod at the same grade and the same price. One consistently yields three points better through the fillet line because of how the crew bled and iced it at sea. Over a season that difference is worth more than most plants spend on software. Almost nobody can see it, because yield is calculated in aggregate at month end against total raw material purchased, which averages the good boat and the bad boat into one meaningless number.

Real yield accounting means every production order consumes a specific landing lot and produces weighed outputs at every station: head off, gutted, fillet, trim, skin, plus the byproducts that actually have value, frames, collars, roe, and meal stock. Then yield is reportable by vessel, by trip, by grade, by species, by line, and by shift. Once a plant manager can see that, purchasing changes within a month. So does the conversation with the captain.

What Marel Innova and Aptean actually fail at

Marel Innova is a serious piece of software and it is very good at what it was built for: grading, batching, portioning, and line level data capture, tightly coupled to Marel equipment. If your problem is line performance and you run a Marel floor, it earns its money. What it does not do is the commercial half of a seafood business. Vessel settlement with per grade pricing, trip advances, and deductions is not its job. Catch certificate documents and import monitoring records are not its job. Neither is telling you the margin on a customer program after freight and cold storage.

Aptean Food and Beverage ERP handles catch weight, lot traceability, and allergen basics as a general food manufacturing system, and for a lot of processors that is a reasonable spine. The gap is that everything seafood specific sits outside its model. Gear and area coding, catch documentation, glaze yield as a measured value, species changeover rules on a shared line, and fisherman settlement all end up as customizations or as the spreadsheets the ERP was supposed to replace. You end up paying enterprise licence money and still running the plant on Excel for the parts that make you money.

What a custom build has to include

The data model is the project. A landing record carries vessel, trip, species, gear, area, grade, and the catch documentation attached as evidence. That landing becomes one or more raw lots. Production orders consume raw lots and emit output lots at each conversion step with actual weighed quantities, so yield is derived rather than typed. Pack, freeze, glaze, case, and palletise each create their own lot links, and cold storage locations are tracked by pallet so a recall pulls a location list, not a guess.

Around that spine you need: scale and grader integration so weights are read rather than keyed, a settlement engine that prices each landing by grade with the deductions each vessel agreement specifies and produces a statement the captain will accept, a document vault for catch certificates and health certificates that expires and chases missing paperwork before the container ships, and a trace query that runs both directions in seconds rather than days. Add EDI where your grocery buyers demand it, and a customer claim pack that assembles species, area, gear, certification status, and lot history into a single PDF on demand.

One place where machine learning genuinely earns its place: reading the pile of inbound documents. Catch certificates, health certificates, and supplier declarations arrive as scans in dozens of layouts, and an extraction pass that pulls species, area, vessel, and dates into structured fields, then flags mismatches against the purchase order, catches errors nobody currently has time to catch. That is a narrow job with a measurable hit rate, not a chatbot.

Cost, timeline, and what moves the number

A first release covering receiving with catch documentation, lot genealogy through the cut and pack steps, measured glaze yield, and vessel settlement runs $70,000 to $150,000 and ships in 12 to 16 weeks. A full plant platform adding cold storage management, customer programs and pricing, EDI, claim packs, and margin reporting by customer and by vessel runs $180,000 to $450,000 phased over 6 to 12 months.

What pushes it up: multiple plants with inter plant transfers, because transfer lots double the traceability model. Scale, grader, and portioner integration, which is real floor work with real hardware protocols in a wet environment. Every new EDI trading partner, measured in weeks each. Multi country regulatory documentation, since an EU health certificate and a US import filing are different problems. What pulls it down: one species family, one plant, and your top twenty SKUs by revenue for release one.

When you should not build

Do not build if you are a cold pack operation buying graded frozen blocks and repacking them. Your traceability is a purchase order and a case label, and a well kept spreadsheet plus a decent inventory tool is honestly enough. Do not build if all your fish comes from two suppliers on fixed contracts with no settlement math. Do not build if you already run a Marel floor and your only real pain is line performance, because Innova already solves that and duplicating it is expensive vanity.

Build when two of these are true: you buy from more than about eight vessels on a settlement formula, you carry a certification claim your customers audit, you run multiple species on shared lines, you handle glazed frozen product where net weight declarations matter, or you have ever spent more than a day answering a single trace question. At that point the coordination between landing, yield, identity, and settlement is your actual operating system, and it should not be a clipboard.

How to choose a developer for this

Ask them to draw the data model on a whiteboard before you sign anything. If they draw products and orders, they have built an ecommerce store. If they draw landing, raw lot, production order, output lot, and pack lot, and they immediately ask how you handle byproduct streams, they have done this. Byproduct is the tell, because frames and roe are where a naive model loses mass and the yield numbers stop balancing.

Ask how they will handle scale integration specifically, by manufacturer and protocol, not as a general capability. Ask whether settlement will be configurable per vessel agreement or hard coded, because every captain deal is a little different and you will add new ones. Ask what happens when the network drops on the receiving dock, because it will, and the answer must be local capture with sync rather than a blank screen.

Finally, get code ownership in writing before kickoff. You should own the repository, the cloud accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. A developer who hedges on that question is selling you a dependency with a software wrapper.