# Acumatica EDI Integration: 850 to Sales Orders > How Acumatica EDI integration works. Map inbound 850 to sales order types, generate 856 and 810, and connect any order format through the REST API. Acumatica Cloud ERP has no native EDI engine. EDI is added through ISV connectors or middleware that calls Acumatica's contract-based REST API. An inbound EDI 850 becomes a sales order using an order type configured on the Order Types screen (SO301000), and the 856 ship notice and 810 invoice generate from the shipment and invoice. Acumatica is a cloud ERP built around an open API, which makes it a natural fit for order automation. It runs sales orders, shipments, and invoices through configurable order types that control exactly how each document behaves. What it does not include is an EDI translator. When a retailer sends you a compliance guide asking for 850, 856, and 810 support, that translation layer has to come from somewhere. This guide covers how EDI maps into Acumatica, the role of order types, the integration methods available, and how orders that never arrive as EDI still land in the system without manual entry. ## Does Acumatica Have Native EDI? **Acumatica does not include a built-in EDI translator. EDI is added through an ISV connector or middleware that calls the contract-based REST API.** Acumatica's design centers on an open, well-documented API, so integration partners handle the [X12](https://x12.org/) and EDIFACT specifics and write orders through that API rather than a native EDI module. The contract-based REST API exposes SalesOrder, Shipment, and SalesInvoice endpoints, among many others. Acumatica documents it in its [help portal's REST API reference](https://help.acumatica.com/). An EDI provider maps an inbound 850 to the SalesOrder endpoint, then reads Shipment and SalesInvoice records to build the outbound 856 and 810. Raw X12 never touches Acumatica directly. A translator receives the 850 over AS2, SFTP, or a VAN, converts it to the JSON the REST API expects, and creates the order. To inspect what the source EDI segments contain before mapping them, the [free EDI Inspector](/edi-inspector) parses any X12 file with no signup. ## How Order Types Shape EDI Processing **In Acumatica, the order type set on the Order Types screen (SO301000) determines how a sales order processes and which documents it generates.** This is the piece that makes Acumatica EDI different from other ERPs. Before you map a single segment, you decide which order type inbound EDI orders will use, because that type controls the whole downstream flow. An order type defines the document sequence, the automatic operations, the inventory and accounting behavior, and whether the order allocates stock, creates a shipment, and produces an invoice. Many Acumatica EDI setups create a dedicated order type for EDI orders so the processing rules stay separate from manually entered orders. When the translator writes an inbound 850, it stamps that EDI order type, and Acumatica applies the configured behavior automatically. That mapping between the retailer's part numbers and your Acumatica inventory IDs is the other core task. Our [EDI 850 purchase order guide](/guides/edi/850-purchase-order) breaks down every segment the retailer can send, including the item identifiers your cross-reference has to resolve. ## How EDI Documents Map to Acumatica **An inbound 850 creates a sales order, and outbound 856 and 810 documents generate from the shipment and the invoice.** The mapping follows Acumatica's document flow, so each EDI transaction lines up with a step your operations team already runs. | Direction | X12 Transaction | Acumatica Document | Endpoint / Screen | |---|---|---|---| | Inbound | 850 Purchase Order | Sales order | SalesOrder API / SO301000 | | Inbound | 860 PO Change | Sales order update | SalesOrder API | | Outbound | 855 PO Acknowledgment | Order confirmation | Confirmed sales order | | Outbound | 856 Ship Notice (ASN) | Shipment | Shipment API / SO302000 | | Outbound | 810 Invoice | Sales invoice | SalesInvoice API / SO303000 | Acumatica's Commerce and Retail-Commerce editions add pre-built connectors to Shopify, BigCommerce, and Amazon, and larger retail deployments layer EDI on top through an ISV. The order type approach still governs each channel, which keeps EDI orders, ecommerce orders, and manual orders on separate, controllable processing paths. ## Integration Methods for Acumatica **Acumatica offers two practical EDI paths: an ISV connector from the Acumatica Marketplace, or middleware over the contract-based REST API.** Both write through the same API surface, so the difference is who owns the mapping and how changes get made. - **ISV EDI connectors**: partners like SPS Commerce (which acquired Data Masons in 2020) and TrueCommerce publish Acumatica connectors with pre-built trading partner maps. Fastest to a known retailer, but priced with monthly plus per-document fees, and spec changes often route through a support queue. - **Middleware over the REST API**: an external service reads and writes through the contract-based REST API. This keeps EDI logic outside the ERP and works well when you also process PDF and email orders through the same tool. Because Acumatica exposes a clean, versioned REST API, a modern integration can create sales orders and read shipments and invoices without heavy per-partner infrastructure inside the ERP. For the general connection patterns, see our guide to [ERP integration](/erp-integration), and for the tradeoff between direct EDI and API approaches, our [EDI vs API comparison](/blog/edi-vs-api). ## The Full Order-to-Cash Flow **A complete Acumatica EDI cycle moves an inbound purchase order to a sales order, then generates outbound EDI as each document processes.** Here is the sequence for a distributor selling to a retailer. 1. **Inbound 850**: the translator maps the retailer's purchase order to the SalesOrder endpoint, stamps the EDI order type, and creates the order. A 997 functional acknowledgment confirms receipt back to the retailer. 2. **Outbound 855**: on order confirmation, the integration sends the acknowledgment, flagging any line quantity or substitution changes. 3. **Outbound 856**: when you create the shipment, the integration reads it and builds the EDI 856 ship notice with carton and SSCC-18 detail. Retailers usually require the ASN before delivery, and a late one triggers chargebacks. Our [EDI 856 ship notice guide](/guides/edi/856-ship-notice) covers the structure. 4. **Outbound 810**: after the sales invoice releases, the integration produces the EDI 810, reconciling allowances and freight against the original 850 to avoid payment disputes. For the wider view of how this chain runs across systems, read our overview of [order-to-cash automation](/blog/order-to-cash-automation). ## How OrderSync Connects Orders to Acumatica **OrderSync creates Acumatica sales orders from inbound orders in any format, then syncs shipments and invoices back out as EDI.** The clean EDI partners are the easy accounts. The hard ones are the retail customers who email a PDF purchase order or send a spreadsheet, which still get keyed into Acumatica by hand. To connect orders to Acumatica with OrderSync, see the [Acumatica integration page](/integrations/acumatica). OrderSync ingests EDI 850s, PDF purchase orders, emailed orders, and CSV files through one pipeline. It maps buyer part numbers to your Acumatica inventory IDs, validates quantities and pricing, and creates the sales order through the REST API with the right order type. When you post the shipment and release the invoice, OrderSync generates the outbound 856 and 810 for the trading partner. PDF and email orders flow through the same automation instead of landing in a manual queue. Distributors on Acumatica almost always have a long tail of smaller accounts that will never adopt EDI, which is where a single multi-format pipeline pays off. See how the [multi-format order pipeline](/multi-format-orders) handles them. For teams comparing platforms, we also document [NetSuite EDI integration](/blog/edi-netsuite-integration) and [Dynamics 365 EDI integration](/blog/edi-dynamics-365-integration). ## Frequently Asked Questions ### Does Acumatica have built-in EDI support? No. Acumatica does not include an EDI translation engine. EDI is added through an ISV connector from the Acumatica Marketplace or middleware that reads and writes through the contract-based REST API. Acumatica's open API design leaves X12 translation to integration partners. ### How does an EDI 850 become a sales order in Acumatica? A translation layer receives the X12 850, maps the retailer's part numbers to your Acumatica inventory IDs, and creates the order through the SalesOrder REST endpoint. It stamps the EDI order type configured on the Order Types screen (SO301000), which controls how the order processes, and a 997 acknowledgment confirms receipt back to the retailer. ### What is the role of order types in Acumatica EDI? The order type set on screen SO301000 determines how a sales order processes and which documents it generates, including allocation, shipment, and invoicing behavior. Many EDI setups use a dedicated order type for inbound EDI orders so their processing rules stay separate from manually entered orders and other channels. ### Can Acumatica handle EDI and ecommerce orders together? Yes. Acumatica's Commerce and Retail-Commerce editions add connectors for Shopify, BigCommerce, and Amazon, and EDI is layered on through an ISV or middleware. The order type approach keeps EDI orders, ecommerce orders, and manual orders on separate, controllable processing paths within the same ERP. ### How does OrderSync handle non-EDI orders in Acumatica? OrderSync processes PDF purchase orders, emailed orders, and CSV files through the same pipeline as EDI 850s and creates Acumatica sales orders from all of them. Retail accounts that do not send EDI never require a separate translator or manual keying, which removes the long tail of orders that Acumatica EDI setups usually leave for staff to enter by hand.