Fishbowl Inventory and EDI 856: Connecting Warehouse Operations to E-Commerce

Introduction

Most commerce teams think about order management from the storefront inward. An order is placed, payment is captured, a fulfillment team picks and packs, and a shipment goes out the door. The challenge is that in many real-world operations, the system that manages that physical fulfillment is not the same system that manages the commerce workflow.

That gap is where integrations like this one live.

Fishbowl Inventory is a widely-used warehouse management and manufacturing system. It handles inventory, purchase orders, work orders, manufacturing runs, and shipment processing for small and mid-sized businesses. When Fishbowl ships an order, it knows the tracking number, the carrier, the shipped quantities, the ship date, and which purchase order the shipment belongs to. The commerce platform — often a separate e-commerce system — needs all of that information to close the loop: mark the order as shipped, attach tracking, generate an invoice, and notify the customer.

The mechanism that bridges those two worlds is EDI 856, the Advanced Shipping Notice.

This article is a generalized technical overview. It does not describe any private client system, proprietary codebase, or confidential implementation detail. Everything described here is based on publicly documented standards and Fishbowl's published integration guidance.

What Is Fishbowl Inventory

Fishbowl is an inventory management and manufacturing platform popular among QuickBooks users and small-to-mid-market operations teams. Unlike a full ERP such as NetSuite or SAP, Fishbowl is purpose-built around warehouse operations: receiving, picking, packing, shipping, tracking, and inventory valuation.

Its main integration point with commerce platforms is not a REST API with real-time webhooks. It is a file-based exchange. Fishbowl can export data in structured CSV formats that downstream systems can consume on a schedule. That makes it accessible for companies that cannot afford or justify a full API integration layer but still need reliable data to flow between their warehouse and their online store.

Fishbowl is documented at fishbowlinventory.com and its CSV export formats are covered at fishbowlhelp.com.

What Is EDI

EDI stands for Electronic Data Interchange. It is a set of standards that allow business systems to exchange structured data without human intervention. The standards originated in the 1960s and became formalized through bodies like ANSI (American National Standards Institute) and GS1. Today, EDI is still the primary integration standard in retail, logistics, wholesale, and manufacturing — even as APIs have become more common in other parts of the technology landscape.

EDI transaction sets are identified by number. Common ones include:

Each transaction set defines a fixed structure: what fields appear, in what order, and with what meaning. Traditional EDI uses a proprietary wire format with segments and delimiters. Modern EDI-style integrations often implement the same business semantics using more accessible formats like CSV or XML, while keeping the same field semantics and row-type structure. That is exactly what Fishbowl does.

What Is an EDI 856 Advanced Shipping Notice

The EDI 856 transaction set is the standard way for a seller or warehouse to tell a buyer or commerce system: "This shipment just left our dock. Here is what is in it."

An ASN contains:

• which purchase orders are being fulfilled
• which items were packed and in what quantities
• how many cartons or packages were shipped
• the tracking number per package
• the carrier
• the ship date and time
• origin and destination address information

For a commerce platform, the 856 is the trigger to mark orders as shipped, attach tracking, and close out fulfillment. For a retailer or warehouse team, generating accurate 856s is often a compliance requirement when dealing with large trading partners.

Fishbowl implements its own CSV-based variant of EDI 856, documented at fishbowlhelp.com/files/csv/exportEDIShipping.html. This format is compatible with EDI translation services like True Commerce and SPS Commerce, which can convert it to full ANSI X12 EDI for trading partner compliance.

The Fishbowl EDI 856 File Format

This is where the integration gets specific. Fishbowl's EDI 856 export is not a standard flat CSV with column headers. It uses a multi-row-type structure: each row starts with a single letter that identifies the type of data it carries.

There are four row types:

The file has no header row. Column position is the only structure. A consumer reads the first column to know how to interpret the rest of the row.

Row S — Shipment

The S row carries shipment-level information. Key columns include:

Row O — Order

The O row links the shipment to a specific purchase order:

The PO number here is the critical link to the commerce platform. It must match an existing order reference on the receiving side.

Row P — Pack

The P row represents a physical carton or package:

Row I — Item

The I row carries the actual line item shipped:

What a File Looks Like

A minimal example with two line items across one package:

S	856SOPI		S100045-01				20250310	20250310	Sample Buyer	100 Example St		Example City	IL	62701		150.00	LB	2		Fulfillment Center	200 Example Ave		Origin City	IL	62702					CC		1430	CarrierX
O		100045	20250310		75.00				2
P		4							TRACK-000000001
I	SAMPLE-001		000000000001	Example Item A	5	EA	5			1
I	SAMPLE-002		000000000002	Example Item B	3	EA	3			2

Each group of S → O → P → I represents one shipping event. A single file can contain multiple shipments, each with its own S row followed by its subordinate O, P, and I rows.

Integration Architecture

Connecting Fishbowl's EDI 856 output to a commerce platform requires a few distinct capabilities.

graph TD
    A[Fishbowl ships an order] --> B[Fishbowl EDI 856 CSV export]
    B --> C[File delivery — SFTP or shared path]
    C --> D[Commerce platform file consumer]
    D --> E[EDI 856 parser]
    E --> F[Row grouping — S / O / P / I]
    F --> G[Order lookup by PO number]
    G --> H{Order found?}
    H -->|No| I[Log error — skip row]
    H -->|Yes| J[Create or update shipment]
    J --> K[Attach tracking number]
    J --> L[Generate invoice if configured]
    J --> M[Log success]

File Delivery

Fishbowl does not push files in real time. The export is typically triggered on a schedule or after a batch fulfillment run. The resulting files land on an SFTP server, a shared network path, or a cloud storage location. The commerce platform polls that location and picks up new files.

That polling interval defines the latency of the integration. In practice, most operations teams accept hourly or twice-daily sync cycles for shipment data.

Parsing the File

The EDI 856 row-type structure means a standard CSV parser is not sufficient. The consumer has to maintain state across rows:

1. When an S row is read, it becomes the active shipment context.
2. When an O row is read, it becomes the active order context.
3. When a P row is read, it captures the current tracking number.
4. When an I row is read, all active context is merged to produce one flat record — one line item with its associated shipment, order, and tracking data.

That merger is what allows the commerce platform to work with simple, item-level records rather than navigating a hierarchical structure.

Order Resolution

The PO # in the O row must be matched to an existing order in the commerce platform. If no match is found, that shipment cannot be created. A well-built integration logs this clearly — the failure is a data-quality issue, not a transport issue, and the operations team needs to know which PO numbers were unresolvable.

If the O row is missing a PO number, Fishbowl's format allows a fallback: the Shipment ID in the S row often encodes the order number in a predictable format (e.g. S100045-01 implies order 100045). A robust integration handles this edge case explicitly.

Creating the Shipment

Once order and items are resolved, the integration creates a shipment record in the commerce platform:

• line items with shipped quantities
• tracking number from the P row
• carrier name from the S row
• ship date and time from the S row (merged from Ship Date and Time Shipped)

Downstream from there, the integration can optionally generate a customer-facing invoice, mark the invoice paid, and send email notifications — all driven by configuration rather than hardcoded behavior.

What Makes This Integration Hard in Practice

The file format is not the hard part. The hard part is everything around it.

PO Number Alignment

The most common failure point is a PO number mismatch. Fishbowl tracks shipments against its own internal order records. The commerce platform has its own order reference scheme. If those two reference systems are not kept in sync — either through direct mapping or through a shared external ID — the integration fails silently or creates orphaned shipment records.

A reliable integration validates PO numbers before doing any shipment work. Orders that cannot be matched are logged with enough detail for an operator to investigate.

Partial Shipments

Fishbowl's Status field distinguishes between CC (complete) and PR (partial). A partial shipment means not all ordered items were shipped in this batch. The commerce platform needs to handle this correctly: ship only the items and quantities present in the file, leave remaining items open, and not close out the order prematurely.

Duplicate Prevention

If a file is processed more than once — during recovery, testing, or a restart — the integration must not create duplicate shipments. The Shipment ID in the S row is a natural idempotency key. Checking for an existing shipment by that ID before creating a new one is a minimum requirement.

Tracking Number Scope

A single package (P row) applies its tracking number to all I rows that follow it within the same shipment. An integration that processes I rows independently, without maintaining the current tracking context, will attach the wrong tracking number — or no tracking number — to shipment items.

Time Zone Handling

Fishbowl exports ship date as CCYYMMDD and time as HH:MM in local time. The commerce platform likely stores timestamps in UTC. Merging those two fields and converting to the correct timezone is a small but real source of bugs if it is not handled explicitly.

Why File-Based Integration Still Makes Sense

It is tempting to ask why Fishbowl would use file exports instead of a real-time API. The answer is operational reality.

Fishbowl targets small and mid-market businesses. Their fulfillment teams often run Fishbowl on-premise or in a hosted environment that is not easy to expose to the public internet. A scheduled file export to a shared SFTP directory requires no inbound firewall rules, no OAuth, no webhook infrastructure, and no real-time availability guarantee on either side.

Files can also be inspected manually, replayed after failure, archived for audit purposes, and handed off to a third-party EDI translation service without changing the upstream export at all. For operations teams that are not running a technology company, that reliability and debuggability is worth more than real-time latency.

The downside is that errors have longer feedback loops. A shipment that fails to import because of a bad PO number may not surface for hours, depending on polling intervals and alerting configuration. That is why logging quality matters so much in this kind of integration.

Lessons from Working with This Format

A few things consistently determine whether a Fishbowl EDI 856 integration is reliable in production.

Parse the row types explicitly. Do not try to detect row type by column count or column content. The row type letter in position 1 is the only reliable discriminator. Anything else introduces fragile heuristics.

Maintain S-O-P state across I rows. An item row has no standalone meaning. Its carrier, tracking number, ship date, and order reference all come from the rows above it. A parser that forgets context between rows produces incomplete or incorrect shipment records.

Log at the PO level, not just the file level. A file may contain twenty shipments. If three fail, the operator needs to know which three and why — not just that the file had errors.

Validate PO resolution before creating any records. A partial import where some shipments succeeded and some failed is harder to recover from than a clean early failure. Validating all order references up front gives operations a clear remediation path.

Store the original file for audit. File-based integrations are often the only source of truth for what was shipped and when. Retaining the original file — even for a short period — makes incident investigation much faster.

Conclusion

The Fishbowl EDI 856 integration pattern is a practical example of how warehouse operations connect to commerce platforms in real-world mid-market environments.

Fishbowl is not a cloud API. Its integration surface is structured file exports. The EDI 856 CSV format it produces follows a well-documented multi-row-type structure that encodes shipment, order, package, and item relationships hierarchically within a flat file. Consuming that file reliably requires stateful parsing, careful order resolution, tracking number propagation, and strong logging at every level.

That is the engineering work that makes a warehouse-to-commerce shipment integration something operations teams can depend on — not just a file parser, but a reliable closed-loop between physical fulfillment and digital order management.