How Fishbowl Actually Handles Units of Measure (and What Manufacturing Does to Them)
If you run Fishbowl long enough, a unit of measure will eventually surprise you. A pick that pulled one more than the math says. A received quantity that landed wrong. A BOM that demands a whole batch when you only asked for half of one. The help docs describe what UOMs are supposed to do; they don’t tell you what actually happens when a conversion is missing, a number comes out fractional, or a manufacture order gets resized.
We’ve spent years untangling these situations for Fishbowl clients and testing the behavior on current versions. Here’s how it really works.
Scope: this describes Fishbowl Advanced, the desktop product, verified against current 2026 releases. Fishbowl Drive, the newer cloud product, differs in several areas, most relevantly here it allows per-item UOM conversions, so the system-wide behavior below is specifically an Advanced trait. If you’re on Drive, read accordingly.
Fishbowl’s units are system-wide, and that’s the big design choice
Fishbowl handles units differently than most ERPs, and it helps to see the alternatives to understand the tradeoff.
Some inventory systems handle pack sizes with what amounts to phantom BOMs. A can of soda, a six-pack, a case, and a pallet are four separate items, with a hidden bill of materials between each level. Sell a pallet when all you have is cans, and the system quietly builds and executes a conversion order behind the scenes: consumes the cans, ships the pallet, all transparent. It works, but answering “how many total cans do we have?” means multiplying and summing across four item numbers.
Other systems put the conversion table on the item. NetSuite is the one we see most. Each item defines its own can, pack, case, and pallet ratios, so one product’s pallet can hold 400 cans and another’s 1,000. Useful, but verbose: every new item means setting up the whole ladder again.
Fishbowl Advanced does neither. Units and conversions are system-wide. There’s one global list of UOMs and one global list of conversion rates, and every part in the system shares them. What you lose: you can’t say “for this flavor, a case is 12; for that one, it’s 24” using the same two units. One rate between any pair of units, for everybody. What you gain: as long as the conversion exists, any part can transact in any unit, on a sales order, a purchase order, or a manufacture order. Selling online where a “2-pack” is just a pricing gimmick rather than a physical bundle? Define the 2-pack and 4-pack conversions once and every beverage in the catalog can use them. (Shopify has no ERP-style UOM conversion model, so consumer-goods companies create a separate Shopify product per pack size. On the Fishbowl side it’s all just conversions against one part.)
Keep that system-wide fact in your head. Most of the painful setup mistakes below come from fighting it.
One part, three units, on purpose
For any given part, you get to make three separate unit decisions:
The base UOM is the unit the part is stocked, counted, and costed in. On-hand inventory is always in this unit, and so is the part’s cost: stock in ounces and Fishbowl tracks cost per ounce.
The purchasing units are whatever your vendor’s paperwork says. If they sell you gallons, buy in gallons, so your documents match theirs.
The usage units are whatever’s practical on the floor or in the recipe. Cups, grams, whole gallons. Whatever people can actually measure without fiddling.
Buy in gallons, stock and cost in ounces, consume in cups: perfectly fine, as long as the conversions between all three exist. This freedom is genuinely useful. You match the vendor’s documents so your paperwork reconciles, cost in the unit your reports want, and batch in the unit the floor can measure. Expensive materials often want a small costing unit like grams or milliliters even when they’re bought by the drum. These are decisions, and they’re worth making deliberately per part rather than defaulting everything to Each.
The one rule that explains most surprises downstream: documents speak the document’s unit; the stockroom speaks the part’s base unit. Conversions happen at the boundaries. Receiving converts into base units to put stock on the shelf, picking converts back out to satisfy the order, and costing converts everything to per-base-unit before it touches your valuation.
Conversions: simple math, no shortcuts
A conversion rule is just a ratio between two units, in one direction. Two things about them matter more than the arithmetic.
Conversions don’t chain. If you’ve defined Gallon to Ounce and Ounce to Cup, that does not give you Gallon to Cup. Fishbowl only uses conversions defined directly between the exact pair of units involved. And an order line often needs more than one hop (the line’s unit to the product’s unit, then the product’s unit to the part’s unit), and every hop needs its own rule. When you set up a new part with multiple selling or purchasing units, define every pair you’ll ever transact in, both to and from the base unit, the same day.
A missing rule doesn’t always stop you. In some places, like receiving and work order consumption, a missing conversion halts you with an error naming the part. In other places we’ve watched quantities sail through unconverted: no error, just a wrong number that surfaces weeks later as an inventory discrepancy. This inconsistency is why “we’re off by a weird factor on that one item” is so often a UOM story.
And one thing people assume wrongly: the UOM types (Count, Weight, Length, Volume) don’t protect you. You can define a conversion from a count unit to a weight unit. Fishbowl shows a “different measurement types, proceed anyway?” warning, and if anyone ever clicked yes, that rule is live and in use. Sometimes that’s exactly what you want. Sometimes it’s how a nonsense rule got into your system three years ago.
Why implementations get this wrong
Here’s the pattern we see over and over during implementations: everyone wants to set up their items. Nobody wants to set up their unit of measure conversions, or even look at which conversions are actually in play.
There’s a reason. Most companies coming to Fishbowl are coming from QuickBooks, where inventory was tracked by dollars of expense, not units of asset. The unit math lived in somebody’s spreadsheet: here’s what we paid, here’s roughly what a finished good costs, we started the year with this much, bought this much, have this much left, so the difference is cost of goods sold. Periodic inventory, worked backwards. The spreadsheet quietly knew how to do the conversions. Or quietly didn’t, and nobody could tell. We’ve seen both.
Moving to Fishbowl is when the shenanigans surface, because now the system does the unit math on every transaction and the spreadsheet isn’t there to absorb the slop. So the least glamorous part of an implementation is also one of the most important: pull last year’s purchases, look at the units your vendors actually bill in, and decide part by part what the base unit is, what the purchasing units are, and what the manufacturing units are, before go-live. It’s one of the easiest steps to skip, and skipping it is how companies quietly set themselves up for failure.
The classic setup mistakes
These three account for a remarkable share of the UOM messes we get called into.
The “1 Each = 128 ounces” trap
Someone buys a gallon jug of flavoring. They set the part up as an Each, since it’s one jug after all, and then, wanting to use it in ounces on their recipes, they create a conversion: 1 Each = 128 Ounces. It works, for a while.
Then they buy a second flavoring from a different vendor, and that one comes in 32-ounce containers. They go to set up 1 Each = 32 Ounces and it blows up in their face, because conversions are system-wide and Each to Ounce already means 128. Fishbowl cannot hold two different rates between the same pair of units. There’s exactly one, shared by every part in the system.
The fix is to use real units in the first place. The gallon jug’s part should live in Gallons (or Ounces), and the 32-ounce product in Ounces or its own container unit, not Each. Each is for things that are genuinely indivisible: a phone, a serialized device, something you can’t have half of. The moment you catch yourself converting Each into a measurable quantity, stop. You’re borrowing a system-wide unit for a part-specific fact, and the second vendor will make you pay for it.
Specific gravity: volume is not weight
The other one: recipes written by weight, materials bought by volume. “My BOM is in grams, so I’ll convert gallons to grams.” Except how many grams are in a gallon depends on what’s in the gallon. Oil is lighter than water, syrup heavier. There is no correct system-wide rate from Gallon to Gram, and remember, system-wide is the only kind Fishbowl has. Set one anyway and everything looks right (quantities convert, orders flow) until you notice the costing is wrong, because every material with a different density is being misconverted through the same rate.
If your recipes are by weight, stock and measure those materials by weight. If they’re by volume, stay in volume. Crossing between the two is a per-material measurement decision, and Fishbowl won’t make it for you.
The $9 million of copper cabling
The third one is a data-entry trap rather than a setup trap, but the setup creates it. Say you stock expensive cabling, and because it’s expensive, someone sensibly configured the part in inches. A roll arrives, and whoever keys in the vendor bill types what’s on the paper: one roll, at the roll’s price. Except the part is configured in inches, so the system just recorded the entire roll’s cost as the price of a single inch. Depending on the roll, that’s 100 or 500 times the real unit cost. A few receipts later somebody runs a valuation report and asks why there’s $9 million of copper cabling in the database.
That one happens all the time. The document’s quantity and unit have to match what’s physically on the bill, in the unit the line is denominated in. It’s the flip side of “match your vendor’s documents”: if the vendor bills by the roll, either buy in a Roll unit with a conversion to inches, or make sure whoever enters bills knows the part speaks inches.
The reframe that unlocks the first two mistakes for most people: a BOM is a bowl. Fishbowl genuinely does not care that the recipe puts in ounces of water, grams of powder, and milliliters of extract. Each input line just needs its own sensible unit, the way a mixing bowl doesn’t care what goes in. Mix it, pour it out, and the output is a new thing in its own unit. Like a spreadsheet, the system holds whatever numbers you give it; making sure they mean something is on us. You don’t need to force a recipe into one common unit. You need each line’s unit to be honest.
Whole-number units round up
Units like Each are flagged as whole-number-only, and Fishbowl enforces that two ways.
If you type a fractional quantity yourself, you get stopped: “The quantity must be a whole number.”
If a conversion result comes out fractional (a pick, a resized manufacture order), Fishbowl rounds up. Always up, never to nearest. 10.08 Each becomes 11.
That ceiling rule is why picks on Each parts sometimes pull one extra, and why manufacturing over-plans rather than under-plans, which we’ll get to below. The rounded-up fraction isn’t tracked anywhere; it’s simply absorbed.
Where each number lives
Worth pinning above your desk. When you look at a quantity or cost in Fishbowl, this is the unit you’re looking at:
| What you’re looking at | The unit it’s in |
|---|---|
| On-hand inventory, anywhere | The part’s base UOM, always |
| Inventory valuation, average/standard cost | Per base unit |
| A purchase order line (qty and unit cost) | The PO line’s UOM |
| A receipt line | The receipt line’s UOM |
| A sales order line | The product’s (or line’s) UOM |
| A pick | The order’s UOM, unless the part is set to “pick in UOM of part,” then the base UOM |
| Reorder points | The part’s base UOM |
| A vendor’s cost for a part | The vendor’s UOM |
| A BOM line | Whatever UOM that line was written in |
If a custom report ever compares an order-line quantity to an on-hand quantity without converting, it will look almost right. That’s usually how these get found.
Manufacturing is where UOM behavior compounds
A BOM is a recipe, and recipes want to speak recipe units (ounces of filling, feet of wire, hours of labor) while the stockroom speaks base units. The good news, per the bowl principle above: Fishbowl lets every input line speak its own unit, and the finished-good line its own too. The requirements are simply that the BOM has at least one raw good and one finished good, that each line’s unit converts to its part’s configuration, and that the output unit squares with the finished part. Meet those and Fishbowl will run it.
A BOM line keeps its own unit, and nothing checks it when you save
Each BOM line can be written in whatever unit makes sense for the recipe. That’s the feature. The catch is that saving the BOM doesn’t verify a conversion actually exists between the line’s unit and the part’s base unit. The mismatch surfaces later, when a manufacture order gets resized or when someone on the floor tries to consume the part on a work order, as a “missing UOM conversion” error. If you’ve ever had a BOM that saved fine and blew up weeks later mid-production, this is usually why: the conversion was deleted, or never existed, and nothing at save time was ever going to tell you.
Implementer habit: when you build or import BOMs, check every line whose unit differs from the part’s base unit and confirm the conversion exists that day, not when the first work order needs it.
Creating an MO: multiply now, convert later
When you create a manufacture order for, say, 50 finished goods, Fishbowl scales the recipe by plain multiplication in each line’s own unit. A BOM calling for 2.5 oz per unit becomes an MO line for 125 oz. No conversion to base units happens yet; that waits until raw goods are actually issued and consumed on the work order. Reasonable design, but it means an MO can carry quantities that will fail to convert later, and nobody finds out until issue time on the floor.
Resizing an MO: the double round-up
Change the quantity on an existing MO and the recalculation gets more aggressive than you’d expect. For each line, Fishbowl rounds up twice when whole-number units are involved: once in the line’s own unit, and once more after translating to the part’s base unit. Both are ceilings, so each one can only push demand higher. On BOMs heavy with Each-type components, a resized MO can quietly ask for a little more material than creating a fresh MO at the same quantity would have. If your material demand looks inflated by ones and twos after order changes, this is where it came from.
Batch BOMs always round up to whole batches
The one-to-many setup, where a sub-assembly yields a batch (25 pie crusts, one kettle of filling) feeding a parent recipe, is where the ceiling rule becomes policy. Need 1.2 batches? Fishbowl plans 2. That’s correct for physical reality, since you can’t brew a fifth of a kettle, but it means batch-based parts systematically over-plan raw material, by design. Plan your purchasing around it rather than fighting it. And if the batch’s output unit differs from the unit the parent consumes it in, that specific conversion has to exist, or the resize stops with a missing-conversion error.
Work orders: the conversion happens at the last moment
Work order lines inherit the recipe’s units as written. The switch into the part’s base unit happens at the last possible moment: the instant raw goods are consumed is when the quantity converts and inventory actually comes off the shelf. Finished goods work the same way in reverse. The yield converts into base units right as the new inventory is created.
Two sharp edges to know about. First, the work order’s header quantity is a whole number. If your MO calls for a fractional finished-good quantity, the header shows it truncated, even though the underlying lines keep their decimals. Confusing on the floor, mostly cosmetic, worth warning your team about. Second (not strictly a UOM issue, but it lives in the same neighborhood), Fishbowl will let a work order finish without any raw goods recorded as consumed. The finished good comes in with zero material cost, and nothing objects. If your finished-goods costs occasionally come out absurdly low, look at whether the floor is skipping the consumption step.
Costing follows the base unit
Inventory value, average cost, standard cost: all of it is kept per base unit, and every manufacturing cost calculation converts quantities to base units before multiplying. The practical consequence is that if your conversions are right, costs flow through cleanly no matter what units your recipes speak. If a conversion is wrong (an Each standing in for a gallon, a density guess baked into a volume-to-weight rate, a factor someone “fixed” after years of use), the cost error propagates silently into every finished good downstream, because Fishbowl never re-validates a conversion that already exists.
Your costing method decides how bad a unit mistake gets
A wrong conversion or a wrong-unit entry doesn’t hurt everyone equally. How much it hurts, and how hard it is to fix, depends on which costing method you’re running.
Average costing is the most forgiving. Not of the error itself, but of cleaning it up: if a unit mistake skews a part’s average cost, Fishbowl lets you edit the average and make an adjustment. Whether the adjusted number is accurate is on you, but at least the repair is one field.
FIFO is less forgiving. The bad cost isn’t one number anymore; it’s baked into cost layers, and there’s no good way to edit those directly. Fixing it means cycling the bad layers out of inventory and receiving corrected ones back in. Doable, but a hassle that scales with how long the error ran.
Standard costing is the least forgiving, because now the journal entries get involved. If your finished-good standard doesn’t match reality, or your raw-good costs don’t add up to it, every build manufactures a variance. Here’s the insidious version: your inventory valuation can look perfectly correct. You’re producing units at a $4 standard and the balance sheet dutifully shows $4 a unit. Meanwhile the bill of materials is actually consuming $500 of inputs per unit, so $4 goes to inventory asset and $496 goes to the variance account, every single build, and nobody’s watching that account. A unit-of-measure error under standard costing doesn’t show up where you look; it shows up where you don’t. (Standard cost variances deserve their own deep dive; today is just units.)
What we’d tell every Fishbowl admin
- Treat the conversion list as production data. Conversions can be edited at any time, even while in use. (Deleting an in-use one is blocked; editing one is not.) An edited factor silently changes every future transaction that touches it. Review it like you’d review a price list.
- Reserve Each for the indivisible. Phones, devices, serialized things. Containers of measurable stuff get real units. The system-wide conversion list means an Each-to-Ounce shortcut works exactly until the second vendor shows up.
- Make the three unit decisions per part deliberately (stock/cost unit, buying units, usage units) and create every conversion between them the day you create the part. BOM save won’t check; the error arrives later, addressed to whoever is running the work order. During implementation, last year’s vendor bills are the source of truth for what units you’ll actually transact in.
- Train whoever enters vendor bills on which unit each part speaks. A roll price keyed against a part configured in inches is how you end up with $9 million of copper cabling on a valuation report.
- Don’t convert across density. No system-wide rate can turn gallons into grams correctly for both oil and syrup. Recipes by weight means stock by weight.
- Expect round-ups on Each. Fractional results on whole-number units always go up, in picks, in resized MOs, in batch counts. Demand inflated by ones and twos is usually this, not user error.
- Know which unit you’re reading. On-hand and costs are always base units; document lines are the document’s units. Any report or export comparing the two without converting will be almost right, which is worse than being obviously wrong.
- Audit for cross-type conversions. If anyone ever clicked past the “different measurement types” warning, that Count-to-Weight rule is live. Worth a periodic review, especially for the Each-to-volume shortcuts from rule 2.
This piece comes out of years of client work on Fishbowl, verified on current versions: reconciliations, inventory audits, and manufacturing cleanups that had to get the units right. If Fishbowl’s UOM behavior is doing something to your inventory or your books that you can’t explain, that’s the kind of thing we untangle.