# Sage EDI Integration: X3, 100, and Intacct Orders

> How Sage EDI integration works across Sage X3, Sage 100, and Sage Intacct. Map inbound EDI 850 to sales orders via ISV connectors and REST APIs.

<QuickAnswer>
No Sage product ships with a native EDI translator. Sage X3, Sage 100, and Sage Intacct all rely on ISV connectors or middleware that call Sage's REST APIs to turn an inbound EDI 850 into a sales order. Outbound 810 invoices and 856 ship notices are generated the same way, from Sage shipment and invoice records. Each document conforms to the [ASC X12](https://x12.org/) standard.
</QuickAnswer>

You just landed a grocery chain as a customer. Their onboarding packet lists the EDI transactions they expect: 850 in, 855 back, 856 before the truck ships, 810 to get paid. You run Sage. Which Sage, and what actually connects the retailer's EDI to it, decides how hard this gets.

"Sage" is a family, not one product. Sage X3, Sage 100, and Sage Intacct are different systems with different order modules and different data models. None of them includes a built-in EDI translator. What they share is a set of APIs and an ecosystem of connectors that bridge X12 EDI to Sage. This guide covers how each Sage product structures orders, where EDI plugs in, and the trade-offs between the paths.

## The Sage Family: X3, 100, and Intacct

**Sage X3, Sage 100, and Sage Intacct each handle sales orders differently, and your EDI setup depends on which one you run.** Picking the right integration starts with knowing your order module.

- **Sage X3** is the mid-market and enterprise ERP. Sales orders live in the SOH table structure and purchase orders in POH. It suits manufacturers and larger distributors with complex operations.
- **Sage 100** (formerly MAS 90/200) uses a modular design. Order processing runs through the Sales Order module, a distinct module you add and configure.
- **Sage Intacct** is the cloud financial platform. Order handling runs through Order Entry and Purchasing, built on configurable document types, with native three-way matching between purchase order, receipt, and vendor invoice.

Sage's own help documentation at [help.sage.com](https://online-help.sagex3.com/) is the reference for each product's tables, modules, and API behavior. Confirm the specifics for your version there before you map anything.

## No Native EDI Translator in Any Sage Product

**None of the Sage products parses raw X12 EDI; integration happens through ISV connectors and Sage REST APIs.** This is the single most important fact to internalize before you scope a project. Sage does not read an 850 and build a sales order on its own.

Two mechanics do the work. First, an ISV connector or middleware layer receives the EDI file, parses the segments, and maps the retailer's item numbers to your Sage item codes. Second, that layer writes the mapped order into Sage through its REST API (or the module-specific import path for Sage 100). The same layer reads Sage shipment and invoice records to build the outbound documents.

Because Sage relies on this ecosystem rather than a bundled translator, the quality of your integration is entirely a function of the connector or service you choose. That is where the real decisions live.

## Mapping the EDI 850 to a Sage Sales Order

**An inbound EDI 850 becomes a sales order: X3 writes to SOH, Sage 100 to the Sales Order module, Intacct to Order Entry.** The translation follows the same shape regardless of which Sage you run.

1. The retailer transmits the EDI 850 over AS2, SFTP, or a VAN.
2. The connector parses the X12 and cross-references buyer part numbers to your Sage item codes.
3. It resolves the customer, ship-to address, warehouse, and pricing.
4. It writes the sales order through the Sage REST API into SOH (X3), the Sales Order module (Sage 100), or Order Entry (Intacct).
5. It returns a 997 functional acknowledgment, and an 855 if the partner requires order confirmation.

The item cross-reference is the slow part of every Sage EDI project. The 850's PO1 segments carry the retailer's identifiers; Sage needs yours. Building and maintaining that table across trading partners is where most of the onboarding time goes. Our [EDI 850 purchase order guide](/guides/edi/850-purchase-order) breaks down the segments you are mapping from, and the [free EDI Inspector](/edi-inspector) lets you paste a partner's file and read the parsed structure before you start.

## The 810 and 856 Flow Back Out

**Outbound 810 invoices and 856 ship notices are generated from Sage shipment and invoice records.** The return path reverses the inbound one.

When you ship in Sage, the connector reads the shipment record and builds an EDI 856 advance ship notice with the carton hierarchy and SSCC-18 labels the retailer requires. Timing is unforgiving. Most retailers want the ASN within 24 hours of shipment, some before the truck departs, and a late ASN draws a chargeback. See our [EDI 856 ship notice guide](/guides/edi/856-ship-notice).

When you invoice, the connector maps the Sage invoice to an EDI 810 and sends it to the retailer's accounts payable. The 810 must reconcile to the original 850, including allowances and freight. On Sage Intacct, the native three-way match between the purchase order, receipt, and vendor invoice helps on the buy side, but the outbound sell-side 810 still has to line up with what the retailer ordered. Our [EDI 810 invoice guide](/guides/edi/810-invoice) covers the reconciliation.

## Integration Methods for Sage EDI

**Sage EDI runs through ISV connectors, iPaaS middleware, or a managed service, all calling the Sage REST APIs.** Each path has a different cost and maintenance profile.

| Approach | Setup Time | Who Maintains Mapping | Non-EDI Orders | Best Fit |
|---|---|---|---|---|
| **ISV EDI connector** (SPS Commerce, TrueCommerce, etc.) | 8-16 weeks | Vendor (ticket queue) | No | Suppliers with many retail partners |
| **iPaaS via Sage REST API** | 2-5 months | Your team | No | Shops with technical staff |
| **Managed service (OrderSync)** | 1-3 weeks | OrderSync | Yes (EDI + PDF + email) | Distributors at realistic scale |

The ISV route gives you a ready trading-partner network and compliance monitoring at a higher monthly cost, with spec changes handled through a support queue. The iPaaS route gives you control over the REST API mappings if you have the staff to build and maintain them. Both assume every order is EDI, which rarely matches reality for a Sage distributor.

## How OrderSync Brings Orders Into Sage

**OrderSync creates Sage sales orders from any order format through the Sage REST APIs.** The inbound 850 becomes a sales order in X3, Sage 100, or Intacct. Shipment records flow back out as 856 ASNs and invoices as 810s. When a retailer updates their spec, we update the mapping. To connect orders to your Sage product with OrderSync, see the [Sage X3](/integrations/sage-x3), [Sage 100](/integrations/sage-100), and [Sage Intacct](/integrations/sage-intacct) integration pages.

The reason distributors pick a service over a pure translator is the non-EDI volume. Smaller accounts email PDF purchase orders, attach spreadsheets, or use buyer portals. A translator alone leaves those for someone on your team to key into Sage by hand. OrderSync reads EDI 850s, PDF POs, and email orders through one pipeline and writes them all into Sage, which fits distributors running a mix of large EDI partners and smaller manual accounts. See [multi-format order processing](/multi-format-orders) and how the [ERP integration](/erp-integration) connects to Sage.

Running more than one back-office system? Our related guides cover [EDI NetSuite integration](/blog/edi-netsuite-integration), [Infor EDI integration](/blog/edi-infor-integration), [Oracle EDI integration](/blog/edi-oracle-integration), and [JD Edwards EDI integration](/blog/edi-jd-edwards-integration).

> On Sage 100, confirm the Sales Order module is licensed and configured before scoping EDI. Order automation writes into that module, and a connector cannot create sales orders in a module you have not enabled.

## Frequently Asked Questions

### Does Sage have built-in EDI?

No. Sage X3, Sage 100, and Sage Intacct do not include a native EDI translator. EDI integration is done through third-party ISV connectors or middleware that parse the X12 files and call Sage's REST APIs to create sales orders and read shipment and invoice records.

### Where does an EDI 850 go in Sage X3?

An inbound 850 is parsed by a connector and written as a sales order into the SOH table structure through the Sage X3 REST API. The connector resolves the customer, item cross-reference, ship-to, and pricing first. Purchase orders in X3 use the parallel POH structure.

### How does EDI work with Sage Intacct?

A connector parses the EDI 850 and creates a sales order in Sage Intacct's Order Entry module through the API. Intacct uses configurable document types and provides native three-way matching between purchase order, receipt, and vendor invoice on the buy side. Outbound 810 and 856 documents are generated from Intacct records.

### What does Sage EDI integration cost?

ISV connectors like SPS Commerce or TrueCommerce typically run in the low thousands per month plus per-transaction fees, with longer onboarding. A flat-rate managed service runs lower and adds no per-document charges. iPaaS platform fees sit in between but add developer time to build and maintain the API mappings.

### Can OrderSync process non-EDI orders into Sage?

Yes. OrderSync reads EDI 850s alongside PDF, email, and spreadsheet purchase orders and writes all of them into Sage as sales orders through the same pipeline. Accounts that do not send EDI do not need a separate system or manual keying into the Sales Order module.