Where a Fishbowl Work Order Gets Its Cost, and Where That Cost Goes
“Our manufactured cost is wrong” is never a simple support ticket. A finished good’s cost isn’t a number sitting in a field somewhere. It gets assembled at one specific moment, out of several sources, and which numbers get used depends on your costing method. Once you can see the whole path, the weird numbers stop being weird.
We’ve spent years tracing this for manufacturing clients, so here’s how cost actually moves through a Fishbowl work order, and the handful of setup choices that cause most of the confusion.
Scope: this describes Fishbowl Advanced, the desktop product, verified against current 2026 releases. Fishbowl Drive, the newer cloud product, behaves differently in several areas; if you’re on Drive, some of this won’t map.
The path in one picture
Cost comes together when you finish the work order. Not when you create the manufacture order, not when you issue materials to the floor, at finish. At that moment Fishbowl adds up the raw materials actually consumed, plus labor, plus overhead, and rolls the total into the cost basis of the finished good it’s putting into inventory.
Then it sits. That cost stays parked in the finished good’s inventory value until the item sells. Only on the sale does it become cost of goods sold. So the labor you paid last month and the steel you consumed last week don’t hit your P&L as COGS until the thing you built with them goes out the door.
One consequence surprises people: Fishbowl has no work-in-process account. Cost jumps straight from raw-material inventory to finished-goods inventory at the instant of finish. There’s nothing in between, by design, and we’ll come back to what to do about that if your auditors expect a WIP balance.
Labor: it’s a part, and you adjust the hours
Labor in Fishbowl is a non-inventory part with a cost field. (On screen it’s labeled cost; underneath it’s the same standard-cost value everything else uses.) You put that labor part on the bill of materials, and it flows onto the work order like any other line.
The step people miss is at finish: you adjust the hours to what actually happened. Say the BOM calls for two hours per unit and you built ten, that’s twenty projected hours. If the job really took twenty-four, you set it to twenty-four. The labor part’s cost field times those hours gives you the total labor dollars, which get added into the finished good and divided across what you actually produced. Straightforward once you know the hours are the lever.
Some companies don’t put labor on the BOM at all and track material only. That’s a choice, and honestly it’s a question for their accountant, not for Fishbowl. If you’re doing a lot of labor you’re generally not supposed to just expense it, but Fishbowl can’t force labor onto a bill of materials because it has no way to know what your labor actually is. And “all your labor” doesn’t mean the janitor and the bookkeeper, so somebody has to decide what belongs in the build. That somebody is you, not the software.
The messy version we see: people trying to true up their labor lines to actual payroll hours for the prior period after the fact. It works, but it’s a bodge, and it’s worth knowing going in that Fishbowl won’t reconcile your labor to payroll for you.
Overhead: you can’t use a percentage, so here’s the trick
Overhead works the same way as labor, and it comes with a hard limitation: you cannot apply overhead as a percentage. Fishbowl only multiplies a standard cost by a quantity. If you want a percentage burden, the software won’t give it to you directly.
The workable approach most shops land on is an overhead rate based on labor hours. It’s easy to calculate, easy to get right, and easy to apply when the work order finishes. Whether you end up over- or under-absorbed depends on how efficient the actual run was, which is the normal behavior of any applied-overhead system.
There’s also a useful trick when you need to push a specific dollar figure through: set the overhead part’s cost to one dollar and set the quantity to the number of dollars you want to collect. One dollar times a quantity of 218 nets $218 of overhead. It reads a little strangely on the BOM, but it lets you collect an exact amount instead of reverse-engineering a per-unit rate.
Co-products: Fishbowl makes you decide at the wrong moment
Some processes yield more than one finished good, a high-quality output and a lower-quality one that’s still worth something, from the same build. Now you have to decide how to split the build’s cost between them, and this is a spot where I think Fishbowl falls short.
The split isn’t defined on the bill of materials. It’s decided when the work order is finished, which means whoever’s at the work-order screen is effectively making a costing-policy call. That’s backwards. The division should be delineated up front, clearly: either by output quantity, when the outputs share a unit of measure, or by value. Fishbowl gives you those two options, “evenly” distributes by quantity and “weighted” distributes by value, and the same build can come out very differently depending which you pick. Say a run costs $1,000 and yields 80 units of a main grade and 20 units of a lower grade that’s only worth a quarter as much:
| Output | Evenly (by quantity) | Weighted (by value) |
|---|---|---|
| Main grade (80 units) | $800 | $941 |
| Lower grade (20 units) | $200 | $59 |
| Total | $1,000 | $1,000 |
Same $1,000, two very different per-unit costs and margins. Fishbowl leaves that decision to the moment of finish rather than baking it into the recipe, and there are GAAP rules about how joint costs should be allocated, so Fishbowl essentially punts by handing you the options and letting you sort it out. My advice is to decide the rule as a controller, write it down, and don’t leave it to the floor.
By-products, a low-value output alongside the main one, are rarer in practice, at least in what I see. If you want to know where a build’s cost actually landed, the finished-good reports show it clearly. A common and defensible approach is to let the main finished good absorb the whole cost and bring the by-product in at essentially zero. Whatever you choose, two rules hold: don’t create value out of nothing, and don’t double-count. Pick a method, keep it consistent, and make sure your controller signs off.
The zero-material finished good
Here’s a failure mode that quietly poisons costs. Fishbowl won’t let you finish a work order with no items allocated at all, but that guard is weaker than it sounds, because non-inventory and labor lines count as “picked” even though nothing physical moved.
So this happens: a work order should have consumed $1,000 of materials, but the crew, wanting to just close the order, finishes it with only $100 of labor recorded and no materials. Fishbowl has no idea anything’s wrong. It can’t validate that the build was supposed to eat materials it didn’t. Access rights control whether users can push through shortages at the pick level, and someone can even edit the work order so it doesn’t require physical items at all. The software will let you. It simply can’t tell that you shouldn’t.
The result is a finished good sitting in inventory at a fraction of its real cost, which becomes an absurd margin when it sells, or a mystery when someone finally reviews inventory value. If your finished-goods costs occasionally come out impossibly low, this is the first place to look.
Cleaning it up depends on your costing method. On average costing you edit the cost to recover it, just watch the journal entries that produces and correct as needed. On standard costing you edit the standard and fix the journal entries, and you’re fine. FIFO is the real pain: the bad work orders have added layers, you might have six months of inventory stacked up, and correcting it means surgery on the cost layers plus fixing the offending manufacture order. The guardrail I hold to throughout: you can’t make dollars appear from nowhere. If no material was actually consumed, I won’t just add $1,000 to a layer to make it look right. We pull the string to find what caused the gap and where the dollars legitimately come from before adjusting anything.
How costing method changes what you’ll see
The four methods surface manufacturing mistakes very differently.
Average is the most obvious, because it’s a single figure per part. If it’s wrong, it’s usually visible. Standard is more complex, its whole story is about hitting or missing the standard, which is a deep enough topic that it gets its own deep dive. LIFO, nobody really uses anymore.
FIFO is the one that hides problems. If a team member closes a week of work orders incorrectly, the damage gets buried in the cost layers and stays invisible until you actually consume those layers, weeks or months later. Then the numbers get strange, and how strange depends on your inventory turnover and how big the original error was. No costing method fixes bad work-order discipline. It just adds another wrinkle on top of the original mistake, which is that the work orders weren’t finished correctly in the first place. Somebody has to actually watch the cost and escalate when it stops making sense.
Projected cost is not booked cost, and that’s fine
The manufacture-order cost report is a projection, and it will not equal what eventually books. That’s expected, not a defect.
Projected cost is just projected. On FIFO you don’t even know which layers you’ll consume until you hit finish. On standard it’s fairly stable week to week unless someone changes the standard. On average it’s a moving target that drifts as activity flows through. You can run the projected-cost report, save it, finish the work order, save the actual, and compare, we do this to explain the gap to clients. A reasonable month-to-month variance is normal. What’s not normal is a build cost outpacing inflation by thirty percent; that’s a signal to investigate. A typical culprit: a material that’s still listed on the BOM “for planning” but no longer actually used, so it’s continuously under-consumed and quietly knocks a few percent off every build.
Multi-level BOMs: the seam is the part
When you chain sub-assemblies into a parent, each level behaves and executes independently, then rolls its cost up into the next. The thing to understand is where the handoff happens: the seam is the part. Whatever a given part’s cost state is at that moment, its average, its standard, or its FIFO layers, is what feeds the level above it.
That’s why you often don’t see a problem until the top-level finished good completes and you’re suddenly twenty percent over or under. To find out why, you investigate the layers and the input costs at each level along the way, keeping in mind that not everything lives on the same BOM, some parts get used directly. It’s a spot-the-difference exercise between what you expected and what happened. Comparing two versions of the data is exactly the kind of tedious reconciliation where modern tools help, feeding two reports or even two screenshots into an AI to OCR and diff them can genuinely surface “this part showed up here and wasn’t there before” faster than doing it by hand.
One inventory account or several?
Whether to split raw materials, WIP, and finished goods into separate asset accounts is really a question about your business, not your software.
If you’re capitalized on owner equity, one inventory asset account is usually plenty. Splitting starts to earn its keep when your capital is large and your raw-to-finished conversion is long, long enough to cross accounting periods. A multi-month process might touch three periods at once, and then watching WIP dollars on the balance sheet tells you something real about how efficiently you’re converting materials into product. The other driver is outside pressure: businesses capitalized with debt or investment often have backers who demand finer reporting.
In practice I see category-level accounts, and sometimes clients get creative, splitting raw/WIP/finished across product families until they’ve got thirty asset accounts. My own bias as a practitioner is to keep it to one account and do the breakout through reporting in Fishbowl instead. It’s cleaner and, for planning, more accurate. Reasonable people disagree, but that’s where I land.
Scrap and the three numbers
Fishbowl does track scrap. It can auto-scrap the units that didn’t pass, you built forty, two failed inspection, scrap two. Or you can just build thirty-eight and call it good, though then you may have consumed more material for those thirty-eight than the plan assumed, and that shows up.
The key is keeping three numbers straight:
| Number | Where it lives | The example |
|---|---|---|
| Planning number | The manufacture order | Planned to build 40 |
| Work-order number | What you actually transact against | Consumed 42 units of material |
| Finish number | What you end with | Finished 38 good units |
That spread, planned 40, used 42, finished 38, is the math you have to interpret. Is it genuine inefficiency? Bad batching? The data’s there to answer it, and Fishbowl’s BI Script reports are getting better at framing those perspectives.
Giving your auditor a WIP balance without a WIP account
Since there’s no WIP account, how do you show a work-in-process balance when an auditor expects one?
The reason it doesn’t exist is deliberate: a real WIP account would require Fishbowl to post journal entries on every finish and void, and Fishbowl’s model is that accounting activity happens only when a transaction completes. No law requires a WIP account, so they skipped it. I wish they’d included one, but the workaround is solid.
WIP becomes a convention based on location. Designate your manufacturing-area location, by location type or a naming convention, as WIP. Then build a report that takes all inventory, buckets it by part and asset account, and separates out anything sitting in a WIP-state location. A million dollars of inventory might break down like this:
| Bucket | Value |
|---|---|
| Finished goods | $300,000 |
| Work in process (manufacturing-area locations) | $100,000 |
| Raw materials | $600,000 |
| Total | $1,000,000 |
As long as the buckets don’t double-count and sum to the total on-hand value, that satisfies the auditor and gives you a clean WIP figure without asking Fishbowl to do something it wasn’t built to do.
What we’d tell a manufacturer
- Cost is captured at finish, not before. The manufacture-order projection is an estimate; the real number lands when you finish the work order and depends on what was actually consumed.
- Labor and overhead are parts, and you adjust them at finish. Set labor by actual hours; collect overhead via a labor-hour rate or the one-dollar-times-quantity trick, since Fishbowl won’t do a percentage.
- Decide co-product cost splits as policy, not at the work-order screen. Write the rule down, by quantity or by value, and don’t leave it to whoever’s finishing the order.
- A zero-material finish is a real risk. Non-inventory and labor lines let a work order close with no materials consumed. Watch for finished goods that cost suspiciously little.
- FIFO hides bad work-order discipline. Errors sit in the layers until you consume them. Watch cost as you go rather than waiting for it to surface months later.
- WIP is a location convention. There’s no WIP account; designate a location and report on it, and keep the buckets from double-counting.
This piece comes out of years of client work on Fishbowl, verified on current versions: costing cleanups, manufacturing implementations, and the reports we’ve had to build to explain where a finished good’s cost really came from. If your manufactured costs are doing something you can’t explain, that’s the kind of thing we untangle.