Commercial Fishing Fleet Software: Electronic Reporting, Quota Ledgers, and Crew Shares That Actually Reconcile

The permit is the asset, and a reporting error can freeze it

A fleet manager sitting in a dockside office is not really managing boats. He is managing three ledgers that never agree. The first is the reporting ledger, what each vessel declared to the regulator for each trip. The second is the quota ledger, what the business holds, what it leased in, what it leased out, and what is left to catch before the season closes. The third is the money ledger, what the fish sold for, what the trip cost in fuel and ice and grub, and what each crew member is owed under that vessel's share agreement.

Those three ledgers describe the same trip and they are kept in three different places: a reporting app on the wheelhouse tablet, a spreadsheet on the office desktop, and a settlement template that one person understands. Nothing joins them. So the fleet finds out it overran a quota holding after the trip is landed, or a crew member disputes a settlement and there is no defensible line back to the fish tickets, or a late report puts a permit at risk over an administrative slip.

The stakes here are not efficiency. A permit is the licence to operate and in most fisheries it is the single most valuable thing the business owns. Reporting failures are a compliance matter, not a paperwork nuisance. Every fleet manager we have worked with can tell you about a week they spent unwinding a reporting mismatch that started with a tablet that could not sync.

Problem one: capture has to work with no connection, for days

This is the constraint that eliminates most software. A vessel is offshore for four days with no signal, sometimes eleven. Hauls have to be logged as they happen, with species, estimated weight, gear configuration, set and haul positions and times, and discards. That data cannot wait for the dock, because a skipper reconstructing four days of hauls from memory at 2am produces exactly the quality of data you would expect.

Offline first is not a feature you bolt on later. It changes the architecture: local storage that survives an app crash and a dead battery, conflict resolution for when the mate and the skipper both edit the same haul, queued sync that resumes on a flaky satellite link without duplicating records, and a hard rule that nothing is ever lost because a request failed. Any developer who describes this as caching has not built it. The right answer involves an event log on the device and idempotent sync, so the same haul submitted twice is still one haul.

Deckhand and Olrac eLogbook both handle the offshore capture problem properly, and that is exactly why they exist. If pure electronic reporting is your only problem, use one of them. The trouble starts one step later.

Problem two: regional reporting formats are all different, and they change

Reporting requirements are set fishery by fishery and region by region. A vessel working two fisheries in a year files into two schemes with different field sets, different species and gear code lists, different submission windows, and different tolerance for corrections after the fact. A fleet operating across regions multiplies that. The codes themselves are moving targets, updated by the managing authority on their own schedule.

What that means for software is that report generation must be data driven rather than hard coded. Field definitions, code lists, validation rules, and submission endpoints belong in configuration you can update without a release, with versioning so that a trip filed in March is still reproducible under March's rules in a dispute two years later. Systems that hard code a single region's format become obsolete the day a new fishery is added to the business, and that is the most common reason a fleet outgrows an off the shelf logbook.

Problem three: quota is traded, leased, and pooled, and spreadsheets lose it

Quota is the part off the shelf logbooks do not touch, and it is where the real money sits. Holdings are attached to permits, permits are attached to vessels but can be moved, allocations get leased in mid season at negotiated prices, overages have to be covered before they become violations, and in many fisheries the leases are traded between operators as a market. A fleet manager typically tracks this in a workbook with one tab per permit, updated by hand from landing reports.

What a build gives you is a live position: for every permit and species, opening allocation, plus leases in, minus leases out, minus landings to date, minus what is currently on the water and estimated, equals what is safe to catch. That last part is the useful one. Knowing that the boat currently steaming home has an estimated ten thousand pounds aboard that will push you two percent over on a stock is worth knowing while the boat is steaming, not at the dock. Alerts against a projected position, not a historical one, are the feature that pays.

The same ledger should hold lease economics so you can answer the question that actually matters: was leasing that allocation at that price worth it against the landed value of the fish it let you catch. Most fleets have a feeling about this. Very few have a number.

Problem four: crew share settlement is bespoke per vessel and done by hand

Crew are paid on a share of the trip, not an hourly wage, and the formula is set by each vessel agreement. Gross stock less common expenses, then a boat share, then the remaining pool split across the crew by position, with the captain on a bigger share and a greenhorn on less, and a list of deductions that varies: fuel, ice, bait, grub, gear, packing, offload. Some agreements deduct before the boat share, some after. Some cap fuel. Some treat the observer fee differently.

Off the shelf payroll does not model any of this and neither does a logbook. So it lives in a spreadsheet, one workbook per boat, maintained by whoever inherited it. When that person leaves, the fleet loses the ability to explain a settlement to a crew member, which is exactly when disputes happen. A build makes the share agreement a configurable rule set per vessel, pulls gross stock straight from fish tickets and settlement sheets from the buyer, pulls trip costs from fuel and supply records, and produces a crew statement that shows the arithmetic line by line. Crew trust it because they can follow it, and that alone reduces friction at the dock.

What a fleet platform must include

The spine is a trip object that everything hangs off: vessel, permit, crew list, departure and return, hauls with positions and catch, landings with fish tickets and prices, costs, and the reports filed. Around it you need a permit and quota ledger with lease transactions, a settlement engine configurable per vessel, a document store for permits, safety certificates, insurance, and crew credentials with expiry chasing, and a maintenance log against engine hours because a gearbox failure mid season costs more than the software.

Integrations matter less here than in a plant, but the ones that count are the buyer settlement sheets, which arrive as PDFs and spreadsheets in every format imaginable, and accounting, usually QuickBooks. Automated extraction of buyer settlement documents into structured landing lines is the single highest value automation in this category, because it closes the loop between what you caught, what you were paid, and what the crew is owed without a person retyping it.

Cost, timeline, and what drives the number

A first release covering offline trip and haul capture, report generation for your primary fishery, and a live quota position runs $60,000 to $130,000 over 10 to 16 weeks. Adding crew share settlement, buyer document ingestion, lease economics, document and certificate management, and maintenance takes the full platform to $150,000 to $380,000 phased across 6 to 12 months.

What increases cost: each additional fishery reporting scheme, which is real weeks of work each and needs ongoing maintenance as codes change. Satellite integration if you want hauls transmitted from sea rather than synced at the dock. Vessel monitoring and sensor feeds. Multi currency and multi country operation. What reduces it: starting with one fishery and one vessel class, and accepting dockside sync for release one.

When to stay with Deckhand or Olrac

Stay off the shelf if you run one or two boats in a single fishery and your reporting obligation is the entire problem. Both products do offshore capture and regulatory submission properly, they are maintained against changing requirements, and rebuilding that for a small operation is money set on fire. Stay off the shelf if quota is simple, meaning a fixed annual allocation you never lease, and if your crew share is one formula everyone already accepts.

Build when the reporting app has become the smallest part of the job. That threshold usually arrives with a sixth or seventh vessel, or when you start leasing quota actively, or when you operate across two regulatory regions, or when settlement takes a person a week every month. At that point what you need is not a logbook, it is an operating system for the business, and the logbook becomes one module inside it. Several fleets we have built for kept their existing electronic reporting tool and integrated it rather than replacing it, which is often the cheapest correct answer.

How to choose a developer for fleet software

Ask them to explain their offline strategy in detail, on a whiteboard, before anything else. You are listening for local event storage, idempotent sync, and explicit conflict handling. If the answer is that the app works offline and syncs later, keep asking until you hear how a duplicate submission is prevented on a satellite link that drops mid request. That one answer separates people who have built for sea from people who have built for offices.

Ask how reporting formats will be configured rather than coded, and what happens when the managing authority publishes a new code list in the middle of a season. Ask to see how a settlement rule is expressed, and try to break it with your most awkward vessel agreement while they are still in the room.

Get code ownership settled in writing before kickoff: the repository, the cloud accounts, and the right to hire anyone else. At Digital Heroes the client owns everything from the first commit. In a business where a software outage means a boat cannot legally sail, being locked to one supplier is an operational risk, not just a commercial one.