Fishbowl 2026.9: reconcile entries now land in the right period, duplicate card charges closed off

Fishbowl released 2026.9 (26.9) on September 4, ten days after 26.8. It is a short release with no new client features. But one fix in it matters more than most of what shipped this summer. If you have ever tried to tie the Inventory Asset account in QuickBooks Online or Xero back to Fishbowl’s inventory valuation at month end and given up, read the first item.

The accounting fixes that matter

• The cost reconciliation journal entry is now dated to the shipment date. When you reconcile a purchase order after the goods have already shipped, Fishbowl posts a journal entry to true up cost of goods sold (COGS) on the affected sales orders. In QuickBooks Online and Xero, that entry was dated to the moment the export ran, not the shipment date. The invoice and the original COGS entry were on the ship date, but the correction landed whenever someone happened to export. That put revenue in one period and part of the cost in another, and it meant the general ledger Inventory Asset balance could not tie to Fishbowl’s valuation report on any given date. 26.9 dates the entry to the shipment date, the same date the invoice and COGS already use. QuickBooks Desktop was never affected. This does not fix entries already posted, so if you have a period where inventory and COGS refuse to tie, this is a plausible reason, and the fix is a reclass rather than a hunt.
• One QBO Automated Sales Tax failure no longer stops the entire export. A sales order on the QBO Automated Sales Tax rate with a future ship date failed to export, and that failure ended the whole export run, so nothing behind it went through either. It failed the same way every run until the ship date arrived. 26.9 exports these orders, keeps the ship date on the posted invoice, and lets the rest of the run continue if a single order fails. The result now names which orders were skipped and why. If your QBO export has been “stuck” for days at a time with no obvious cause, this was a likely culprit.

Fishbowl Payments: three ways a card could get charged or recorded twice

If you take cards through Fishbowl Payments, all three of these are worth your attention.

• Timeouts no longer risk a second charge. When the connection to the payment provider was unstable, a charge request could time out. Fishbowl reported a generic failure and recorded nothing, but the card might already have been charged. The payment window stayed open with nothing marked paid, so the next step was often to try again and charge the customer twice. Fishbowl now checks back with the provider to confirm the outcome. If the card was charged, the payment is recorded. If not, it says so clearly. If it genuinely cannot tell, it reports an unknown status and offers to keep checking or lets you verify in the provider’s portal.
• In-client payments are saved before the confirmation dialog, not after. Payments and refunds taken in the client used to be written to the database only after the user dismissed the confirmation message. If the scheduled Import Gateway Payments task ran in that gap, it imported the same transaction as a second record. That duplicate overstated the amount paid on the order and flowed through to the general ledger and your accounting system.
• The gateway import now only pulls payment link payments. The same root cause from the other side: the scheduled import could claim a card charge or refund taken in the client if it ran before that transaction was recorded. It is now limited to payment link payments.

If you use Fishbowl Payments and your payments clearing account has never quite balanced, these three fixes explain a lot of it. Duplicates created before 26.9 are still in your books.

REST API and legacy API

• Accounting export without a logged-in user. The legacy accounting export call can now be sent through the REST legacy wrapper as POST /api/legacy/external/QBExportRq. An external system or a scheduled job can kick off the export and get back the same status and message the client would show, including on failure. The call name says QuickBooks, but it runs whichever accounting integration is configured, Xero included. For anyone who has kept a client session open on a server just so exports run on a schedule, this is the replacement.
• Full work order detail. GET /api/work-orders/:id returns a single work order with its line items, the parts each item consumes, assigned users, and the bill of materials name. Add includeSteps=true for work instruction steps. Fulfilled work orders remain readable. This is the REST equivalent of the legacy call the mobile apps have used.
• Read-only status on work order and manufacture order search. Both searches now return a readOnly flag per row, matching what purchase order and sales order search already do. Before this, an integration could not tell which records the user was allowed to change.
• Purchase order memos are readable with read-only access. The memo endpoints returned a 403 error for users whose location group access was read-only. Reading now works. Create, update, and delete still require full access.
• Legacy API fixes for the mobile apps. Sales order line descriptions edited before saving were being replaced with the product default on save through SOSaveRq. Part on-hand from InvQtyRq now includes read-only location groups instead of silently omitting them. And reports printed through PrintReportRq now show Hide/Show columns whose default is a formula, so the Sales Order Invoice prints Unit Price, Total Price, and Type the same way it does from the client.

One sales fix

Kits using the Specify Kit Price option now show a margin on the kit header line, net of any kit adjustments. Before 26.9 no margin was calculated for these kits, so a rep had no way to see that a kit was being sold below cost. Kits without a specified price are unchanged.

Upgrade notes

The MySQL 8.0 deadline moved. Last month’s notes said 8.0 would be supported through the September release. 26.9 now says through the October 2026 release, so the auto-update still keeps your existing MySQL 8.0 installation. Everything else is the same: MySQL 5.7 is not supported, upgrades from 2025.9 or older need the server updated by hand first, and Fishbowl Anywhere users should stay on 2025.9.

Three releases in a row have now been mostly about the accounting connection, and this one closes some of the oldest gaps. The reconciliation date fix in particular removes a reason Fishbowl and your general ledger could disagree even when every transaction was correct. The entries posted before the fix are still dated wrong, though. If your Inventory Asset and inventory valuation have never tied and you would like to know whether this is why, get in touch.