How to process a catch-weight credit memo without losing track of the weight

A frozen seafood distributor receives salmon fillets by the case, forty pounds nominal, priced per pound against whatever the dock scale reads when the case actually comes in. Most weeks the variance between nominal and actual is small enough that nobody looks twice — a case runs 38.6 lb instead of 40, the invoice bills the real number, everyone moves on. Then a pallet arrives from a new vendor with six cases visibly under-filled, ice glaze cracked off two of them in transit, and the receiving clerk flags all six for a claim instead of just logging the short weight and moving on.

The vendor agrees fast — too fast, in a way that should have been a signal. Three days later a credit memo lands in the inbox: "$187.40 credit, 6 cases salmon fillet, damaged in transit." No weight. No line reference to which PO or which receiving ticket. The bookkeeper applies it as a credit against the vendor balance and closes it out. The warehouse, working off the same claim, does something different: they zero out all six cases from inventory, on the assumption a credited case is a returned case. Now the ledger says six cases were returned in full. The receiving record says six cases arrived at a partial, but real, weight and were kept — nobody sent product back on a truck. Physical inventory has salmon sitting in the freezer that the system thinks doesn't exist.

Why the ambiguity is the actual problem

The credit memo itself wasn't wrong — the vendor really did owe $187.40 for six damaged cases. What broke was that the document never specified what kind of adjustment it was: a credit against the case count (as if the goods were never received at all) or a credit against a weight shortfall (goods were received, weighed, and billed short). Those are two completely different transactions. One reverses a receiving line entirely. The other adjusts the price on a line that still has real inventory behind it. A credit memo that doesn't say which one it is gets interpreted by whoever touches it next, and accounting and the warehouse floor don't always guess the same way.

This is a catch-weight problem specifically, not a general returns problem. On a fixed-unit product, a credit memo for "6 units" is unambiguous — six units came back, or six units' worth of price got adjusted, and either way the count matches. On catch weight, the case count and the weight are two different numbers that only line up by coincidence, so a credit memo that references cases without referencing weight is missing exactly the field that would have told the warehouse what actually happened.

Where it compounds

Six cases is a rounding error. It's not the sixth case that matters — it's the pattern. Once a distributor is running credit memos through as case-level adjustments by default because that's the field everyone fills in on the claim form, every future short-weight dispute with that vendor gets logged the same way: full case reversed out of inventory, even when the goods stayed on the shelf. A few months in, the physical count and the system count for that vendor's product diverge by a meaningful margin, and nobody can point to a single event that caused it. It looks like shrinkage. It looks like theft, sometimes, if someone goes looking. It's actually an accumulation of credit memos that were never tied back to a specific weighed receiving line, each one silently subtracting inventory that was never removed from the building.

The accounts payable side has its own version of the same failure. If a credit memo isn't linked to the exact invoice line and receiving record it adjusts, a second, unrelated dispute with the same vendor can get matched against the wrong line, netting out a price correction against a shortage claim that has nothing to do with it. The vendor's real balance and what the ledger shows for them drift apart, and untangling it later means pulling every invoice and every credit note for that vendor for the quarter and matching them by hand.

What actually fixes it

The fix is a rule, not a form field: every catch-weight credit memo has to specify, explicitly, whether it credits a case (goods reversed, remove from inventory at the receiving weight actually logged) or a weight (goods kept, price adjusted against a shortfall). Practically, that means:

• Never accept a credit memo without a unit type. If a vendor's claim form doesn't ask for it, add the question to your own dispute log before it goes to AP: case-level or weight-level.
• Link every credit note to the specific receiving line and its logged actual weight, not just a PO number or a vendor invoice total. The receiving record is the only place the real weight was captured; the credit memo should point straight at it.
• Only reverse inventory when the credit is case-level. A weight-level credit adjusts cost, not quantity — the product is still there, and zeroing it out creates the exact phantom-loss pattern above.
• Reconcile AP and inventory off the same transaction, not two separate processes that both interpret the same claim independently. If the bookkeeper and the warehouse are working from the same linked record, they can't disagree about what happened.
• Track credit memos by vendor over time. A vendor whose claims run consistently case-level when the physical goods were clearly kept is a vendor whose claim process needs tightening, and that pattern only shows up if the data is structured enough to query.

iotoms ties every credit note to the original receiving line and its measured weight, so a case-level reversal and a weight-level price adjustment can't be confused with each other — inventory and the vendor ledger move together, off the same record, instead of two people guessing at the same ambiguous claim.