The full document cycle exists in exactly one place, and it isn't your storefront

Written for ED-3 — the in-house supply-chain platform team — the engineering director defending an integration plan to an architecture review.

One thesis: the four-document transaction cycle — po, desadv, inv, recadv — exists as API objects in exactly one category of system, the top-tier ERPs, and nowhere else; so intake architecture is decided by where each reference type actually lives, not by which API is nicest to integrate — and a defensible integration plan is a coverage matrix, not a vendor preference.

The matrix, read row by row

From our verified connector census (primary documentation only, audited 2026-07-31), coverage of the four reference types by system:

• NetSuite — full cycle, by exact record name: purchaseOrder → po, itemFulfillment → desadv, itemReceipt → recadv, invoice (AR) and vendorBill (AP) → inv. All on the REST supported-records list.
• SAP S/4HANA — full cycle: the purchase-order API, the inbound delivery with goods receipt against it, the supplier invoice — plus the IDoc dialect carrying the same documents on the wire. Detail in the SAP post.
• Dynamics 365 Business Central — full cycle: purchaseOrders, salesShipments, purchaseReceipts, purchaseInvoices/salesInvoices, with item.gtin in the standard API.
• Amazon — full cycle only when you combine the seller and vendor surfaces; the vendor side alone is the EDI cycle in REST.
• Shopify (and ecommerce generally) — po-analog orders, desadv-grade fulfillments, rma-shaped returns, and no invoice object anywhere in the category.
• QuickBooks Online / Xero — po and inv only. Stated flat, because it surprises people: no shipment or ASN object, and no goods-receipt object at all. The small-business accounting tier cannot source desadv or recadv no matter how it is wired.
• The 3PL tier — ShipBob's Warehouse Receiving Order is the standout recadv source; ShipHero's inbound purchase orders and Extensiv's receivers are its category-mates.

The compressed census: the full cycle exists in four API surfaces (three ERPs, plus Amazon's two sides combined) and three standards rails (UBL/Peppol, GS1 XML/EANCOM, and X12 — dialects of the same fourteen-word vocabulary this layer already compiles). recadv as a first-class object exists in only seven surfaces total.

The two structural absences worth memorizing

Every intake architecture that fails, fails on one of two assumptions the matrix refutes.

Ecommerce has no invoice. Billing lives in the ERP or accounting system — a category law, not a platform quirk. A plan that expects inv context from the storefront ships a record with a hole where the billing join belongs.

Accounting apps have no logistics. QBO and Xero model money, not movement: purchase orders and invoices, never shipments or receipts. A plan that treats the accounting system as the system of record for the cycle cannot close the desadv→recadv loop, which means reconcile has nothing to reconcile.

Neither absence is a defect to work around with clever mapping. They are facts about where documents live, and the architecture that respects them outperforms the one that fights them.

Composition: three partial sources, one complete record

The practical consequence is that almost nobody gets the cycle from one system — and nobody needs to. The composition pattern for a mid-market brand:

1. ERP (NetSuite, BC, or SAP) — the po and inv authority, and the receiving close where goods flow through your own dock.
2. Storefront — the demand-side po-analog and outbound desadv volume for the DTC channel.
3. 3PL/WMS — the physical desadv and the recadv where fulfillment is outsourced, which for a co-manufactured brand is most of it.

Three partial sources, each contributing the references it actually possesses, compiled onto one spine — core CBV fields on conformant events, every join graded for identity strength, parcel telemetry attached as evidence rather than record. The record is complete even though no source was, and every reference on it traces to the system entitled to assert it. That last property is what an architecture review actually wants to hear: not "we integrated everything," but "every claim on the record has a source that could legitimately make it."

Reading the matrix for your own stack

The decision procedure, compressed to four questions:

• Which system holds your purchase orders as objects, not PDFs? That is your po authority.
• Where do shipments become documents — ERP fulfillments, storefront fulfillments, 3PL shipments, or partner ASNs over the EDI rail? That is your desadv intake, and there is usually more than one.
• Who observes receiving — your dock, your 3PL's receiving objects, or nobody yet? If the answer is nobody, that is the gap to close first, because recadv is the reference the whole reconcile story stands on.
• Where are invoices real objects? ERP or accounting — never the storefront.

Answer those four and the intake architecture writes itself; the compiled result is the record epcis.dev captures and visibility.cloud answers from.

This post is also, not coincidentally, the shape of our access flow: the questions it asks are the matrix's questions — which systems hold which documents in your stack — because the answer decides which connector branch gets built for whom, in what order. Walk through it; it takes about three minutes, and it ends when we know exactly which row of the matrix you are.

---

849 words. The access flow is at /get-access/; the family's event door is epcis.dev.