# Receiving Right in Fishbowl: PO Cost, Over-Receiving, and the Vendor-Bill Mismatch

> Most Fishbowl receiving problems aren't software bugs, they're the gap between what the PO says, what the truck brought, and what the vendor billed. Here's where that gap opens and how to keep it from turning into a cash-and-inventory mess.

Most of the receiving problems we get called into aren't software bugs. They're the gap between what the purchase order says, what actually showed up on the dock, and what the vendor billed you. Fishbowl gives you two steps, receiving and reconciling, to close that gap. Use them well and your inventory value and your payables stay honest. Use them carelessly and you end up paying for eighty units while sixty sit on the shelf.

Here's where the gap opens and how to keep it closed.

*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.*

## Receive and reconcile are two steps for a reason

When goods arrive, you receive them: the stock goes on the shelf and into inventory at the PO's cost. Later, when the vendor's bill comes in, you reconcile it: you confirm what you were actually charged and adjust if it differs from the PO. Two moments, because the truck and the invoice rarely arrive together.

You can also receive and fulfill in one motion, reconciling on the spot. People worry about this more than they need to. It's fine, as long as the PO cost is right and the documents match. If you're buying a nut and bolt at the dollar you agreed to, receiving and closing it out immediately is not a problem, because there's nothing to reconcile.

It becomes a problem when there's no substantiation, when the delivery paperwork or the bill doesn't match the PO. And that is a controls question, not a Fishbowl question: is your buyer setting up the purchase order correctly for what's actually happening?

## The most common gap: the vendor confirmed a different rate

The single most frequent receiving discrepancy has nothing to do with Fishbowl's mechanics. You issue a PO at one rate, the vendor confirms the order at a different rate, and nobody updates the PO. Now the PO says one number and the bill says another, and the mismatch surfaces at reconciliation as a surprise.

If your relationship with that vendor is one where you issue a PO and accept the current market rate on delivery, that's fine, but then someone has to update the cost at reconciliation so your records reflect what you actually paid. The failure isn't the software letting the numbers differ. It's a control gap where the confirmed rate never made it back onto the document. Rate mismatches like this are very, very common; the fix is a habit, not a feature.

## The cost delta when you sell before you reconcile

Sometimes goods come in, you sell or consume them, and *then* the real bill arrives at a different cost. Fishbowl can often handle this cleanly on its own: if the transactions are tidy and sit inside an open period, received on the first, sold on the fourth through sixth, real cost known by the ninth, it will make the cost adjustments for you.

Selling through the *entire* quantity is actually the easy case. Once it's all gone, any change in unit cost just pushes straight into cost of goods sold, which is accurate and done.

The mess is the in-between. You bring in six months of material, sell a month of it, and the cost turns out to be fifty percent higher than the PO said. You've already reported margins on the old number. Maybe you've already paid bonuses on those margins. Now the correction is surmountable but genuinely painful. And the real question at that point isn't a Fishbowl question at all, it's *why did it take a month to notice a fifteen percent change in your cost?* People make buying decisions on that number. The lesson is less about the mechanics and more about discipline: get your reconciliation data in within a reasonable window, because the cost of a stale cost compounds into every decision you make on it.

## Over-receiving: the batch trap

This one bites specific industries hard, and Fishbowl doesn't handle it as gracefully as it should.

If you buy anything produced in batches, you've probably signed a purchasing agreement that forces you to accept some percentage over what you ordered. Order a thousand feet of custom copper cable to spec, and the terms may say you have to take delivery of up to ten percent over, so you might get eleven hundred feet, and you're obligated to accept and pay for all of it. That's normal in batch manufacturing.

Fishbowl has no way to configure "allow over-receiving on this part because the contract says so," which would be the clean solution. What it does allow is over-receiving a PO line **once**. If eleven hundred feet shows up and you receive all eleven hundred in a single action, everything works: you get a bill for eleven hundred, you pay it, the inventory's correct, done.

The trap is receiving in two shots. If you receive exactly the thousand feet the PO called for, landing bang on the ordered quantity, and *then* need to receive another hundred, you're stuck. Once a line is fully received to its quantity, you can't receive more against it.

| You ordered 1,000 ft; 1,100 ft arrives | What happens |
|---|---|
| Receive all 1,100 in one action | Works. Bill for 1,100, pay it, inventory correct. |
| Receive 1,000, then try to receive 100 more | Stuck. The line is fully received; you can't add to it. |
| Fix: add a new PO line for the extra 100 | Lets you receive and pay the overage, but creates a duplicate line. |

The workaround, adding a line to the PO for the extra hundred, isn't elegant, but it is the right way to handle it. The habit that avoids the whole problem: when you know a delivery ran over, receive the full over-quantity in one pass rather than receiving to plan and topping up later.

## When someone edits the bill in QuickBooks

Here's a failure that starts as a favor and ends as a mystery. There's pressure to get a payment out the door, the numbers between Fishbowl and the accounting system don't quite line up, and someone edits what they know how to edit, a bill line in QuickBooks or Xero, to make it match so the check can go.

Sometimes that's harmless. An added freight or handling charge on the bill that you just want to expense rather than capitalize, fine. But sometimes they edit an item line: the bill says eighty units, you received sixty, and rather than investigate the difference, someone just pays the eighty. The cash goes out for eighty. Sixty is in inventory. Weeks later somebody asks why on-hand shows sixty when the payment was for eighty, and the thread starts to unravel.

There's no relinking these records after the fact. The fix is upstream: it's education and controls. Why are we editing bills to force a match? What's the motivation, and what's the procedure that should have caught the twenty-unit gap instead of paying past it? Cash that leaves the building without corresponding inventory is exactly the kind of quiet leak that a receiving discipline is supposed to prevent.

## The prepay gap

One scenario Fishbowl simply doesn't have a native flow for: prepaying a vendor before you receive inventory. In some deals you have to. A vendor producing ten thousand feet of custom copper over a four-month lead time may want the copper cost paid up front so they're not carrying the material risk if you don't take delivery.

Fishbowl has no transactional path for "pay now, receive later" on an inventory item. The workaround is to book the prepayment through a journal entry into a prepaid-inventory account, then, when the material actually arrives, receive it and clear the prepaid balance against it, keeping the real inventory value where it belongs in the inventory asset account, often settled with a vendor credit. It works, but it's a manual dance around a gap in the product. (This is an area where we lean on accounting specialists to get the entries exactly right; the point for a receiving audience is simply to know Fishbowl won't do it for you, so you plan for it instead of discovering it at go-live.)

## What actually goes wrong at the receiving screen

When people picture a receiving mistake, they imagine someone clicking the wrong button, receive when they meant reconcile. That's not really what we see.

The real-world error is a scanning one: an operator scans data into the wrong field. A ten- or fourteen-digit item number lands in the quantity field, and suddenly you've received a billion of something. It's obvious once it happens, and the fix is to void and correct, but it's worth knowing that's the failure mode, because it means your safeguard is a quick sanity check on quantities, not button-labeling.

## What we'd tell a receiving team

1. **Direct-fulfill is fine when the numbers agree.** If the PO cost is right and the documents match, receiving and closing in one step is not a shortcut you'll regret. The two-step flow exists for when they *don't* match.
2. **Update the PO when the vendor confirms a different rate.** The most common discrepancy is a confirmed rate that never made it back onto the document. That's a control, not a feature.
3. **Reconcile promptly.** Fishbowl can clean up cost differences on its own while transactions are fresh and the period's open. The longer you wait, the more decisions get made on a wrong cost.
4. **When a delivery runs over, receive the whole over-quantity in one pass.** Receiving to plan and topping up later dead-ends on a fully-received line and forces a duplicate PO line to fix.
5. **Never edit a bill in the accounting system to force a match.** Paying past a quantity difference sends cash out without inventory behind it. Investigate the gap instead.
6. **Sanity-check quantities after scanning.** The real receiving error is a scan into the wrong field, a billion units, not a wrong button. A glance at the quantity catches it.

---

*This piece comes out of years of client work on Fishbowl, verified on current versions: reconciliations, inventory audits, and untangling why the cash that went out doesn't match the stock that came in. If your receiving is doing something you can't explain, that's the kind of thing we untangle.*

---

*From Israel Lopez Consulting (ILC). Custom Fishbowl Inventory integrations and software, and Fishbowl experts since 2015. Written by Israel Lopez, published July 12, 2026. Questions about this topic, or want to reach the people who wrote it? Visit https://israellopezconsulting.com/contact*