Written for the VP of Operations & Supply Chain who is one seat holding everything — ops, quality, logistics — at a brand where every product is co-manufactured and there is no engineering function and no EDI department, because there is nothing for either to be a department of.
The false premise arrives in every vendor conversation: "To get trading-document context into your traceability record, you'd need an EDI capability." You would not. You need the objects your stack already produces every business day.
The mapping, with real object classes
The standard vocabulary that trading documents compile into is CBV 2.0 §7.3's business-transaction types — po, desadv (the despatch advice, which the spec itself notes is "also called an 'Advanced Shipment Notice'"), recadv, inv — and CBV 2.0 §8.5 puts the bizTransactionList that carries them on every EPCIS event type. That is core spec, ratified June 2022, no extensions.
Now line up the systems a $50M–$1B co-manufactured brand actually runs. Every row below is a real, documented API object class on a platform in this segment's standard stack — not a hypothetical:
| Your system's noun | Real API object | Compiles to |
|---|---|---|
| Shopify order | Order (GraphQL Admin API) | po |
| Shopify fulfillment | Fulfillment on the order | desadv |
| ShipBob inbound receiving | Warehouse Receiving Order (WRO) | recadv |
| ShipBob / ShipHero return | Return object | rma |
| NetSuite or QuickBooks invoice | Invoice | inv |
| Business Central purchase order | purchaseOrder (API v2.0) | po |
Read the table's shape, not just its rows: the full purchase-to-receipt document cycle your retailers' EDI programs run on — order, ship notice, receipt, invoice — already exists in your stack as webhook-bearing JSON objects with self-serve API keys. The despatch advice you supposedly cannot produce without an EDI team is your 3PL's fulfillment webhook. The receiving advice is the warehouse receiving order your fulfillment provider already creates when your co-man's freight arrives.
visibility.cloud connects to those objects directly. The connectors read what your stack already emits, compile each document to its standard transaction reference, and attach it to the custody events it governs — so your receiving events cite the PO, your shipping events carry the ASN reference, and a retailer's traceability questionnaire gets answered from one record instead of four portals. The document rail itself is the family's transactions.dev; the executive read on why documents belong inside traces is ASN and PO context in traces.
What falls out for free
Once the documents and the events live on one spine, three answers stop being projects:
PO-cited receiving. The trace for any lot shows not just that cases arrived, but which purchase order they arrived against — the exact join an auditor asks for and spreadsheets reconstruct by hand.
ASN-shaped fulfillments. What your 3PL said it shipped becomes a reference on the shipping events themselves, so short-ships and substitutions surface as mechanical mismatches, not month-end surprises.
Reconcilable receipts. The warehouse receiving order and the receiving events answer each other. What was ordered, what was said to ship, what was seen — three documents, one record, zero swivel-chair.
The honest gaps, because they are the part vendors skip
Two things your commerce stack does not carry, and pretending otherwise would be the kind of claim that dies in one diligence question.
Party identity is free-text addresses. Shopify, your 3PL, and your accounting system identify parties by name and address strings, not by GLN — the GS1 party identifier the standard's source and destination fields want (the GS1 identifier machinery is worked at barcoding.dev). GLNs enter your world through the trading documents your larger retailers already exchange and through your own party master; the record compiles validly without them under scoped identifiers and upgrades in place when they arrive. Identity absence never blocks capture.
Product identity is a barcode field of varying hygiene. Shopify's barcode is free text; it holds a GTIN exactly as reliably as whoever typed it. Every identifier is checksum-validated on the way in, and every compiled join carries an identity grade — GTIN-grade, SKU-grade, tracking-grade — so anyone reading the record downstream knows exactly how strong the join is. An honest grade beats a confident guess.
The one-seat playbook
You buy outcomes and refuse projects, because there is nobody to staff a project. This is that posture, applied to documents:
- Connect what exists. The stack you already pay for is the integration. No middleware, no mapping team, no hire.
- Let the record accrue. Documents and events compile onto one spine as your ordinary operations run. Nothing about your day changes.
- Answer from capability. When the retailer questionnaire lands — and it lands on this seat, with a date — the answer is a record, not a scramble. The recall-drill version of the same seat's reality, run today on spreadsheets across a co-man boundary, is its own worked example.
The delta between you and an enterprise brand with an EDI department was never the documents. It was that their documents landed in a record and yours evaporated after transmission. That delta is now a connector, not a career.
If the next retailer requirement is already in your inbox, start the interview — five minutes, your operation's shape, and one promise about contact at the end.