On Hand, Available, Committed: What Fishbowl's Inventory Numbers Actually Mean
“There are ten of them sitting right here on the shelf, and the system says I have zero available. Why can’t I sell them?”
Every Fishbowl site eventually has some version of this argument. It’s usually sales against the warehouse, with both sides sure the software is broken. It usually isn’t. The stock is real and the number is right; they’re answering different questions. Fishbowl’s inventory figures each count something specific, and the trouble starts when someone reads one number as if it answered a different one.
Below is what each number counts, why they diverge, and which one is safe to promise a customer.
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.
Two numbers you see, several underneath
For all the quantities floating around, Fishbowl really puts two in front of a user: On Hand and Available to Sell (sometimes labeled available for sale). Almost everything else, allocated, committed, available to pick, not available, is machinery underneath those two. Which one a given person even sees depends on their module options, specifically whether they’re allowed to see inventory across every location group or only the one tied to the transaction they’re working on.
Under the hood, only two numbers are actually stored. On Hand for a given bucket of stock, and the committed portion of that bucket. Every other figure is calculated on the fly from those two plus your open orders. That matters, because a calculated number is only as good as the data feeding it, and most “the numbers are wrong” complaints turn out to be a data problem, not a math problem.
Available to Sell is accurate; your data might not be
The formula behind Available to Sell is sound. On Hand, minus what’s already spoken for by open orders, with a couple of adjustments. Ask Fishbowl what you can sell and, if your on-hand count is right and your allocations are right, it gives you the right answer.
The catch is that “if.” The most common way this number lies has nothing to do with the formula. It’s latency. You’ve got saved sales orders that haven’t been issued yet, all about to lay claim to the same stock. You’ve got orders living in another system that a human still has to key into Fishbowl. So Fishbowl is answering honestly based on what it knows, but it’s four or five days behind on data entry. It tells you there’s plenty available, the backlog gets entered, and suddenly there’s nothing. Garbage in, garbage out. The math is fine; it’s working from a stale picture.
So before you blame the number, ask whether the number has current information. A lot of the time it simply doesn’t yet.
Allocated vs Committed: demand vs a physical claim
These two get conflated constantly, and the distinction is the key to everything else.
Allocated is demand. It’s summed from your open order lines, sales orders, the raw-material side of work orders, transfer orders, not from the stock itself. When a sales order is issued, its quantity becomes allocated. Nothing physically moves; it’s pure demand math against your on-hand total.
Committed is a physical claim on a specific bucket of stock. It goes up only when a pick assigns actual tags to a line. Committed is the system saying “these exact units, in this exact location, are reserved for this order.”
So an order allocates the moment it’s issued, and commits later when someone picks it. On Hand doesn’t actually drop until the goods ship. Hold onto that sequence, because it explains the paradoxes.
Here’s the whole cast on one card, with the rough arithmetic behind each:
| Number | What it counts | Roughly |
|---|---|---|
| On Hand | What’s physically in stock | The sum of what’s on your tags |
| Allocated | Demand from open orders | Summed from open sales, work, and transfer order lines |
| Committed | Stock physically reserved by a pick | Tracked on the tag itself |
| Available (to Sell) | What you can still promise a customer | On Hand − Allocated * |
| Available to Pick | What a pick can actually grab right now | On Hand − Committed |
* The full formula also subtracts stock in not-counted locations and adds drop-ship back out, but On Hand minus Allocated is the part that matters ninety percent of the time.
Two things to notice already. Available and Available to Pick subtract different numbers, Allocated versus Committed, which is why they routinely disagree. And nothing here caps demand at what you physically own, which is what makes the next section possible.
Why Available can go negative while stock is on the shelf
Available subtracts all your open demand from what you have. There’s no rule that demand can’t exceed supply. Put one unit on hand and issue ten sales orders that each want one, without allocating any of them, and your Available is negative nine. That’s not a glitch. That’s an honest statement: you’ve promised nine more than you have.
It’s easier to see stepping through a single part’s day. Watch how the two “available” numbers move as orders come and go. (On Hand only drops at ship; Available = On Hand − Allocated; Available to Pick = On Hand − Committed.)
| Event | On Hand | Allocated | Committed | Available | Avail. to Pick |
|---|---|---|---|---|---|
| Receive a PO for 100 | 100 | 0 | 0 | 100 | 100 |
| Issue a sales order for 30 | 100 | 30 | 0 | 70 | 100 |
| Pick and commit that 30 | 100 | 30 | 30 | 70 | 70 |
| Ship the 30 | 70 | 0 | 0 | 70 | 70 |
| Enter a work order needing 50 | 70 | 50 | 0 | 20 | 70 |
| Issue more sales orders for 20 | 70 | 70 | 0 | 0 | 70 |
| Issue one more order for 10 | 70 | 80 | 0 | −10 | 70 |
Look at the last two rows. There are seventy units physically on the shelf, and Available reads zero, then negative ten, because every one of them (and then some) is already promised to an open order. That’s the “empty shelf that isn’t empty” from the top of this article. Notice too that Available to Pick stays at seventy the whole way down: nothing has been committed by a pick yet, so from the picking engine’s point of view all seventy are still grabbable, even as Available insists you have nothing left to sell. Same stock, two honest answers, because they’re counting different things.
In practice this confuses people less than you’d expect once they see it laid out, because the picking module tells the same story from the other side. All the orders look pickable right up until you pick the first one. Then the rest turn red and go non-pickable, because the stock they were counting on just got committed to someone else. The place it genuinely bites is when someone has orders sitting in one location group and inventory in another, and keeps trying to sell from the group that has none. That’s a setup problem, not a math problem.
Available to Pick promises stock it can’t always deliver
Here’s a real limitation worth knowing. Available to Pick is essentially On Hand minus Committed. What it does not do is check whether the stock is in a location you’re actually allowed to pick from. Inventory sitting in an inspection area or a locked bin still counts toward Available to Pick, even though no pick can pull it.
This is a spot where Fishbowl could stand to improve as a product. Different companies want different rules, exclude anything in inspection, or only count storefront and consignment locations, and Fishbowl doesn’t give you that granularity out of the box. So Available to Pick can quietly promise stock that the pick engine will refuse to source, and you won’t know until the pick comes up short.
The two location flags that bend everything
Every location carries two independent on/off flags, and implementers set them without always understanding the split.
Counted as available controls whether stock in that location shows up in Available. Pickable controls whether the pick engine can pull from it. They’re separate, so you get four combinations, and all four have legitimate uses. The one you’ll meet most is counted-as-available but not pickable.
The usual reason: a warehouse wants people picking from the lower rack locations, so it makes the upper pallet-rack locations non-pickable to force someone to bring a pallet down before picking from it. Reasonable. The problem is that it’s a fixed rule, not a flexible one. It makes sense when a customer orders a full pallet, just pull from the top. It makes no sense when you’re picking a single each and the system won’t let you break down a top pallet that happens to be closest. I’ve watched people follow that rule to the letter instead of the spirit, walking past usable stock because a flag said so. Worth knowing which combination you’ve set and why.
Time is the number’s blind spot
This is the one that causes the most planning grief, and it’s structural: Fishbowl’s allocation math ignores time entirely. It takes every issued job, every issued sales order, every issued demand, subtracts the whole pile from your current on-hand, and hands you a number. It does not care that half that demand is due next week and half is due in three months.
So a planner who drafts and issues a whole month of work orders at once will watch inventory apparently vanish, even though the real demand arrives week by week. Fishbowl sees all of it at once and reports a shortage that isn’t real yet. If you date your demand out and only look at a window, you’re fine. If you look at the raw allocated number, you’re staring at a year of demand against a week of stock.
The trap is subtler than just “it looks scary.” It tells you you’re fine today, because the big order is five weeks out and outside whatever window you’re eyeing. Next week that order is four weeks out, now inside the window, and suddenly you’re short and it’s a fire drill. This isn’t unique to Fishbowl; most systems compute allocation without a time dimension. The fix is reporting matched to how your business actually plans, usually an “allocated in the next 30 days” view, rather than trusting the timeless number.
Transfers and drop-ship: two special cases
Transfer orders allocate the sending warehouse. The destination team panics only if they’re looking at a company-wide report instead of one scoped to their location group. There’s also a setting most people miss: when you ship a transfer, you choose who owns the in-transit inventory, sender or receiver. Set it to the receiver and the stock shows up in the destination’s in-transit location, already over there in the numbers, just not on the right shelf yet. Which team sees the stock “coming” depends entirely on that setting and your transfer practices.
Drop-ship skips inventory altogether. Mark a sales order as drop-ship, raise a drop-ship PO, and when it’s received nothing hits inventory, no stock, no log. Fishbowl just books COGS against the vendor’s data and invoices the sale. Because that supply and demand are one-to-one and never touch your shelves, drop-ship lines get subtracted back out of allocation, they’d otherwise depress Available for stock that was never going to move. It’s not a bug; it’s the system refusing to let a drop-ship reserve inventory it doesn’t need. The thing to plan for is that drop-ship affects your sales numbers, not your inventory, so revenue projections need to account for it separately.
When two reports show two different On Hands
On Hand itself isn’t perfectly consistent. Depending on which internal path a screen or report uses, non-counted locations are sometimes included and sometimes not, so you can genuinely see two different On Hand figures for the same part.
My rule for building reports around this: pin down the truest On Hand number you can, then treat whatever would alter it as a separate figure, subtract, and report both. When someone asks “why does this say 99,” you can actually answer. The underlying math is never doing something wrong. It’s doing math you didn’t expect, usually because someone changed how they operate in Fishbowl, and the report is how you find out. Surfacing the two figures side by side turns “the system is broken” into “here’s exactly what changed.”
Void a pick vs cancel an order
These unwind differently and clients trip on it. Voiding a pick just undoes that one picking operation. The demand is still there. Go back to one unit on hand and ten orders: void the pick on one order and you’re still short nine, because voiding a pick doesn’t cancel anything, it just says “not this way, not right now.”
Canceling the sales order is what actually removes the demand. Cancel one of the ten and you’re down to nine demand, eight short. Cancel all ten and you’re back to one on hand, zero allocated, one available to sell. Voiding frees the physical commitment; canceling frees the demand. If someone expects a voided pick to put stock “back up for sale,” they’ll be surprised, and it usually takes walking them through the one-and-ten example for it to land.
The rare stuck-number cleanups
Occasionally a crash or a bad void leaves a tag’s committed quantity out of sync with what the orders actually justify. We keep a query for exactly this, comparing what should be committed, based on the transactions and their states, against what’s actually flagged committed on the tag, since the two are linkable. When they disagree, we reset the tag’s committed to the calculated value and, if On Hand is off too, dig into why. This used to be common in the mid-2010s versions of Fishbowl and is much rarer now.
Serialized parts can desync the same way, serial commit flags versus committed quantity, but only in genuine database-surgery situations after a crash. The approach is the same, just per serial: trust the transactions, figure out which serials a transaction actually wants, and fix the flags and quantities to match.
The one number to trust
If you’re deciding what to put on a dashboard or a sales rep’s screen, the answer is short.
Never show salespeople the raw On Hand number. Too many other calculations run against it, and it says nothing about what’s already promised to someone else. The conservative, trustworthy figure is Available to Sell. It already accounts for what you owe other orders, so it won’t have you promising a customer stock that’s spoken for.
Everything else in this article is machinery, worth understanding when you’re diagnosing a discrepancy or building a report. But when the question is simply “can I promise this to a customer,” Available to Sell is the number, provided, as always, that the data behind it is current.
This piece comes out of years of client work on Fishbowl, verified on current versions: reconciliations, inventory audits, and building the reports that explain why two screens disagree. If your inventory numbers are telling you something you can’t explain, that’s the kind of thing we untangle.