Which direction does data move between QAD and Stedi?

Purchase orders move from QAD out to Stedi, which generates X12 850 documents and delivers them to suppliers. Inbound 810 invoices and 856 ship notices move from Stedi into QAD, written as supplier invoices and goods receipt data matched to the originating purchase order. QAD stays the system of record, since Stedi is a translation and routing layer and holds no canonical business objects.

How does the integration receive inbound EDI given QAD has no webhooks?

Stedi pushes inbound transactions as transaction.processed.v2 webhook events, and ml-connector returns 2xx within the five-second timeout, then processes the payload asynchronously. The event carries a document download URL that ml-connector fetches with the Stedi API key to get the full translated JSON. On the QAD side, which has no webhooks, ml-connector polls for new purchase orders on the schedule you set and posts them to Stedi.

How does this respect QAD's three-way match?

QAD matches a supplier invoice against the purchase order and the goods receipt before it clears, so receipts must post first. ml-connector writes the 856 ship notice into QAD as goods receipt data and matches each inbound 810 invoice to its originating purchase order, so the receipt is in place when the invoice arrives. If a write into QAD fails, the record is retried and kept in the audit trail for replay rather than being lost.

QADStedi

QAD and Stedi integration

QAD Adaptive ERP runs manufacturing, procurement, and finance. Stedi handles EDI exchange with your trading partners. Connecting the two lets QAD purchase orders go out to suppliers as X12 850 documents and lets supplier invoices and ship notices come back into QAD without anyone re-keying EDI. ml-connector translates between QAD's business document APIs and Stedi's REST and webhook surface, and keeps each inbound document tied to the QAD purchase order it belongs to.

How QAD works

QAD Adaptive ERP exposes suppliers, purchase orders, supplier invoices, GL accounts, cost centers, items, and goods receipts through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so records are read by polling on a schedule.

How Stedi works

Stedi is an EDI Platform that translates JSON to X12 EDI and back, then delivers it to trading partners over SFTP, FTPS, or AS2. The developer-facing surface is REST with JSON bodies, authenticated by a Bearer API key passed in the Authorization header, with no OAuth flow. Outbound EDI is generated by posting JSON to a partnership generate-edi endpoint, and inbound transactions are pushed to your endpoint as transaction.processed.v2 webhook events rather than polled. Stedi is a translation and routing layer, not a data store, so it does not hold vendors, invoices, or GL accounts; the full translated payload is fetched from a document download URL using the same API key.

What moves between them

Purchase orders flow from QAD out to suppliers. ml-connector reads new and changed QAD purchase orders on a schedule and sends each one to Stedi, which generates an X12 850 and delivers it to the supplier connection. Inbound documents flow the other direction: Stedi parses supplier 810 invoices and 856 ship notices and pushes them as webhook events, and ml-connector writes the invoices into QAD as supplier invoices and the ship notices as goods receipt data, each matched to its originating QAD purchase order. Supplier and item reference data in QAD drives how documents are addressed and mapped. Stedi holds no canonical records, so QAD stays the system of record and ml-connector never treats Stedi as a source of truth.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the QAD tenant URL with its JWT or OAuth2 token, and the Stedi API key sent as a Bearer credential. Because QAD cloud has no webhooks, it polls QAD for new purchase orders on your schedule and posts them to Stedi's generate-edi endpoint with an Idempotency-Key so a retry never produces a duplicate EDI file. Inbound is the opposite: Stedi pushes a transaction.processed.v2 event, ml-connector returns 2xx within the five-second webhook timeout and processes asynchronously, then downloads the full translated JSON from the documentDownloadUrl using the Stedi API key. Each inbound 810 invoice is matched to its QAD purchase order so the supplier invoice posts against the right PO, which matters because QAD's three-way match needs the goods receipt from the 856 to post before the invoice clears. Partnerships and transaction settings are configured once in the Stedi portal, since there is no API to create them. Events are deduplicated on the Stedi eventId, rate-limit 429 responses are retried with backoff, and every record carries a full audit trail and can be replayed if a write into QAD fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP for procurement and finance and trades with a handful of large retail and distributor customers that mandate EDI. Before the integration, a coordinator printed QAD purchase orders and keyed them into a portal, then typed supplier invoices and ship notices back into QAD by hand, and month-end close stalled while AP chased invoices that did not line up with receipts. With QAD and Stedi connected, each QAD purchase order goes out as an 850 automatically, inbound 810 invoices and 856 ship notices post straight into QAD against the matching PO, and the three-way match has the receipts it needs before invoices clear. The manual EDI re-keying is gone and close starts with documents already reconciled.

What you can do

Send new and changed QAD purchase orders to Stedi as X12 850 documents for delivery to suppliers.
Write inbound 810 invoices from Stedi webhooks into QAD as supplier invoices matched to the originating purchase order.
Post 856 ship notices into QAD as goods receipt data so receipts land before invoices for the three-way match.
Bridge QAD tenant login with the Stedi Bearer API key and download each translated payload with that key.
Poll QAD on a schedule and handle Stedi webhooks within the five-second timeout, with idempotency, retries, and a full audit trail.

Questions

Which direction does data move between QAD and Stedi?: Purchase orders move from QAD out to Stedi, which generates X12 850 documents and delivers them to suppliers. Inbound 810 invoices and 856 ship notices move from Stedi into QAD, written as supplier invoices and goods receipt data matched to the originating purchase order. QAD stays the system of record, since Stedi is a translation and routing layer and holds no canonical business objects.
How does the integration receive inbound EDI given QAD has no webhooks?: Stedi pushes inbound transactions as transaction.processed.v2 webhook events, and ml-connector returns 2xx within the five-second timeout, then processes the payload asynchronously. The event carries a document download URL that ml-connector fetches with the Stedi API key to get the full translated JSON. On the QAD side, which has no webhooks, ml-connector polls for new purchase orders on the schedule you set and posts them to Stedi.
How does this respect QAD's three-way match?: QAD matches a supplier invoice against the purchase order and the goods receipt before it clears, so receipts must post first. ml-connector writes the 856 ship notice into QAD as goods receipt data and matches each inbound 810 invoice to its originating purchase order, so the receipt is in place when the invoice arrives. If a write into QAD fails, the record is retried and kept in the audit trail for replay rather than being lost.

Connect QAD and Stedi

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started