Acumatica and SPS Commerce integration

What moves between them

The main flow runs from SPS Commerce into Acumatica. ml-connector polls SPS for new retailer purchase orders (EDI 850) and creates each one as a sales order in Acumatica, mapping the trading partner and line items to the matching Acumatica customer and stock items. When an order ships and is invoiced in Acumatica, ml-connector reads the shipment and the sales invoice and pushes an advance ship notice (856) and an invoice (810) back into SPS Commerce, wrapped in the RSX envelope, for delivery to the retailer. Product activity and inventory advice can flow from SPS into Acumatica as supporting data. The retailer order originates in the retailer's own system, so ml-connector never sends purchase orders back to SPS.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two token flows: the SPS Commerce client-credentials grant against api.spscommerce.net, and the Acumatica instance OAuth grant against the customer's own URL, each refreshed when a call returns 401. It accepts the full Acumatica instance URL and the exact endpoint version per customer, since the version is part of the path and a mismatch returns 404. Because SPS webhooks are not production-ready, it polls SPS purchase orders on a schedule using the cursor returned by each page, and tracks the document number as a natural dedup key so the same EDI 850 is not loaded twice. On the Acumatica side it wraps every field value in a value object as the REST API requires, and uses a $filter on LastModifiedDateTime to find newly shipped or invoiced orders to send back. Trading partner IDs and item codes are mapped first so each retailer order lands on a valid Acumatica customer and stock item, and outbound invoices and ship notices are built in the RSX 7.7.7 envelope. Acumatica rate limits are license-tier based and return HTTP 429 near the licensed ceiling, so ml-connector backs off with jitter and retries, and every document carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods supplier with about 150 staff sells to several national retail chains and is required by each of them to trade documents over EDI through SPS Commerce. Before the integration, a customer service team printed retailer purchase orders out of the SPS portal and re-typed them into Acumatica as sales orders, then manually assembled the advance ship notice and invoice for each shipment, which caused late deliveries and chargebacks when a label or document was wrong. With Acumatica and SPS Commerce connected, each retailer purchase order becomes a sales order automatically, and the ship notice and invoice are generated from the actual Acumatica shipment and sent back to the retailer on time. Order entry errors drop, compliance chargebacks fall, and the team handles more retailers without adding headcount.

What you can do

• •Turn retailer purchase orders (EDI 850) from SPS Commerce into Acumatica sales orders automatically.
• •Send advance ship notices (856) and invoices (810) from Acumatica shipments back through SPS Commerce to the retailer.
• •Map SPS trading partners and item codes to Acumatica customers and stock items so orders land correctly.
• •Bridge SPS Commerce client-credentials auth and Acumatica instance OAuth, refreshing each token as needed.
• •Poll SPS on a schedule with cursor paging, document-level dedup, retries, and a full audit trail.

Questions

Which direction does data move between Acumatica and SPS Commerce?

The main flow is SPS Commerce into Acumatica for retailer purchase orders, which become sales orders. The return flow is Acumatica into SPS Commerce for advance ship notices and invoices once an order ships. The retailer order originates in the retailer's own system, so ml-connector pulls it from SPS rather than creating it there.

How does the integration handle SPS Commerce when webhooks are not yet available?

SPS Commerce publishes a webhook framework but its producer standards are still under development, so production integrations poll. ml-connector polls the SPS Transaction API on a schedule you set, using the cursor returned with each page to fetch only new documents. It uses the purchase order and invoice numbers as natural dedup keys so the same EDI document is never processed twice.

Why does ml-connector need the Acumatica endpoint version, and how is auth bridged?

Acumatica embeds the ERP version in the REST URL, such as /entity/Default/24.200.001, and a mismatched version returns HTTP 404, so ml-connector stores the exact version per customer. For auth it runs the Acumatica instance OAuth grant against the customer's own URL and the SPS Commerce client-credentials grant against api.spscommerce.net, keeping both tokens current and presenting the right one to each system.