ERP Business Analyst in Seattle

Fishing vessel settlements: crew shares and trip expenses as requirements

Much of the North Pacific fishing fleet is home-ported in Seattle, and many crews are paid by share rather than by wage. Arrangements vary by vessel and fishery, but the shape is familiar: gross earnings from a trip or season, minus certain shared expenses such as fuel, food, bait and ice, are divided between the boat and the crew, with the skipper and sometimes senior hands taking larger shares. Advances paid during the season, gear purchases and other personal charges are then deducted from individual settlements.

Those calculations usually live in a spreadsheet that one person fully understands. When an owner asks whether an ERP can take them over, the honest answer depends on the detail, so the detail has to be written down. I record which expenses are shared and which the boat carries alone, how shares are assigned, how partial trips and crew changes are handled, how advances are tracked and what each crew member's settlement statement must show.

Every rule gets a worked example taken from a past settlement, with the expected result. That turns a vague request into something a vendor must demonstrate. Some platforms manage it through configuration, others need a small custom calculation, and some owners keep a dedicated settlement tool connected to the ledger. Tax treatment of crew pay sits with your accountant, and the requirements simply ensure the ledger holds the detail that person will ask for. The requirements gathering service explains the method.

Seafood buyers and processors: dock prices, deductions and later adjustments

On the other side of the dock, buyers and processors deal with many independent boats. Each delivery is recorded, often on a landing record known as a fish ticket, with species, weight and grade. In some fisheries the buyer pays a base price at delivery and settles an adjustment once the season's markets are clearer. Fuel, ice, groceries and gear bought from the buyer during the season may be charged to the fisherman's account and deducted from what is owed, and some boats receive advances before they fish.

A generic purchase-to-pay process does not describe any of this. The requirements have to cover price schedules by species, grade and period, the link between each delivery record and the payable it creates, running balances per boat, the rules for post-season adjustments and the statement each fisherman receives. Tender vessels that collect fish from smaller boats add another layer, because the vessel making the delivery and the person being paid are not always the same.

I write these flows as process maps and numbered requirements, and I ask your controller how expected adjustments should be accrued, since that is an accounting judgment rather than a system one. Landing reports filed with fishery agencies are matched against the ERP so the two can be reconciled. Processing yields, lots and cold storage are covered on the Seattle ERP consultant page, so this work stays focused on money owed to and by the fleet.

Kent Valley warehouses: turning rate cards into billing requirements

The Kent Valley and the corridor running south toward Tacoma hold a dense cluster of warehouses serving the ports, the airport and regional retail. Many are run by third-party logistics firms that store and ship goods for several clients at once. Their revenue depends on billing every service they perform, and their contracts rarely look alike.

A typical rate card lists charges for receiving by pallet or carton, storage by pallet position or cubic volume, picking by order and line, kitting, labeling, cross-docking, special handling and monthly minimums. When billing is assembled from spreadsheets at month-end, services slip through and disputes follow. An ERP or warehouse system can capture billable events as they happen, but only if someone has defined them first.

I build a catalog of billable events, each linked to the scan or transaction that proves it and to the contract term that prices it. Requirements then cover how rates are stored per client, how storage is measured on a given day, how minimums and extra charges apply, what backup each invoice must carry and who approves exceptions. Client-owned inventory brings needs of its own, such as stock separated by owner, client visibility through a portal and cycle count results reported back.

With that catalog in hand, vendors have to show a month of billing for one of your real clients rather than a generic demo. The warehousing ERP page covers the operational side in more depth.

Washington tax data your advisor will ask the system for

Washington's tax structure surprises owners who know other states. The state leans heavily on a business and occupation tax charged on gross receipts rather than on profit, and the classification of revenue matters: retailing, wholesaling, manufacturing and services can be treated differently, and one company may report under several. Several cities in the region, Seattle among them, levy their own business taxes, which can require revenue to be assigned by location. Sales tax generally follows where goods are delivered, and sellers making wholesale sales keep a record of the state permit that lets each buyer purchase for resale.

I do not decide how any of this applies to you; that belongs to your CPA or tax advisor. What I do is turn their guidance into data requirements. Typical items include an activity classification on each revenue item, the delivery address and location for each taxable sale, resale permit details on wholesale customers with renewal dates, a record of use tax owed on purchases made without sales tax, and reports that summarize revenue the way the returns are prepared.

Each item becomes a numbered requirement with a test case, such as a wholesale order shipped to a buyer with a valid permit or a retail delivery to another city. Requirements a platform can only meet with an add-on are marked as such in the fit-gap matrix. For the wider US picture, including sales tax requirements in general, see the US ERP business analyst page.

Starting from the spreadsheets and paper that run the business

In fishing companies, seafood buyers and warehouses alike, the real rules often sit in documents rather than in anyone's description of them: a settlement spreadsheet whose formulas grew over many seasons, a folder of landing records, a rate card amended by email, a stack of invoices with handwritten corrections. Interviews on their own tend to miss the exceptions these records reveal.

So the analysis starts with the records. I ask for a sample set, read the formulas and trace a handful of past settlements or monthly bills from source to result. Questions come out of that reading, which keeps the interviews that follow short and specific. Skippers and crew bosses who are away for long stretches can answer a written question list from port, or over a satellite connection where the vessel has one, while plant and warehouse leads review draft rules in shared documents.

The deliverables are the familiar ones, made concrete: process maps for each flow, a business requirements document with numbered rules and worked examples, a fit-gap matrix for the shortlisted platforms and UAT scenarios built from the same past records, so expected results are known before testing begins. Everything is done remotely and your team keeps the documents. The structure follows my guide on how to create an ERP BRD, and the Seattle freelance ERP consultant page covers wider advisory roles.