Sage EDI integration

Sage X3 has an EDI framework that exchanges flat and XML files by email or directory, without an X12 envelope, control numbers or acknowledgments. Sage Intacct has none, and takes orders through its Web Services API. We build the X12 side to your Sage company: 850s into sales orders, and 855, 856 and 810 out of your orders, deliveries and invoices, mapped per trading partner, hosted and run for you.

What Sage does natively

Sage sells several ERP and accounting products, and they differ on EDI. Two of them document enough to say exactly where the native part stops.

Product	Native part	Where it stops
Sage X3	EDI framework (activity code `EDIX3`): EDI partners, protocols, flows, message mappings; SOAP web services	Sequential or XML files by email or directory; no ISA/GS envelope, no control numbers, no 997
Sage Intacct	XML Web Services: Order Entry transactions, item cross references	No EDI section in the developer documentation
Sage 100, 300, 50	Each has its own import and API options	Checked per version before a build

A supplier that trades with a US retailer needs the 850, 855, 856 and 810 in X12, with the retailer's version, qualifiers and pack hierarchy. That part runs outside Sage. This page is the Sage side of our EDI integration; the same model on other ERPs is under NetSuite EDI integration and Business Central EDI integration.

Sage X3: what the EDI framework does, and where X12 starts

Sage X3's online help (version 12, published 8 September 2026) documents the framework through its tables and menus. It is generic: it maps X3 data to a file and moves the file.

Setting	Values in Sage X3	What a retailer's X12 needs on top
Protocol type	Emails, Directories	AS2, SFTP or a network mailbox, per partner
Message file format	Sequential, XML, None	X12 segments with qualifiers per element
Direction	Outbound, Inbound	The same, plus a 997 for every file received
Category	Purchase invoice, Sales invoice, Purchase order, Sales order, Sales delivery, Intrastat declaration, Sales delivery notification	850, 855, 856, 810 and 846 in the partner's version
Sequential file options	Field separator (up to 8 characters), record separator, decimal separator, character set, date format	ISA, GS and ST envelopes with matching control numbers and counts

The categories cover the documents a retailer exchanges: sales order for the 850, sales delivery and delivery notification for the 856, sales invoice for the 810. What the framework's tables have no place for is the X12 control layer: interchange and group control numbers, segment counts, the test or production flag, and the acknowledgment that answers each file. The integration either reads and writes the X3 framework's XML files in a directory and translates them to X12 per partner, or uses X3's web services directly when the framework is not set up.

Sage Intacct: an 850 as an Order Entry transaction

Sage Intacct creates orders with create_sotransaction, using a transaction definition such as Sales Order, and converts one transaction into the next with createdfrom. The diagram follows PO 4500018236, the example used on our document pages.

One purchase order through Sage Intacct Order Entry. The invoice is converted from the sales order, so the 810 refers to the same PO.

The order request, shortened to the first line:

<create_sotransaction>
  <transactiontype>Sales Order</transactiontype>
  <datecreated><year>2026</year><month>09</month><day>28</day></datecreated>
  <customerid>C-HARBOR</customerid>
  <customerponumber>4500018236</customerponumber>
  <termname>Net 30</termname>
  <sotransitems>
    <sotransitem>
      <itemid>10482</itemid>
      <quantity>24</quantity>
      <unit>Each</unit>
      <price>12.50</price>
      <donotshipafterdate><year>2026</year><month>10</month><day>06</day></donotshipafterdate>
    </sotransitem>
  </sotransitems>
</create_sotransaction>

Several 850 fields have a direct home. BEG03 goes to customerponumber. The retailer's requested dates in DTM go to donotshipbeforedate, donotshipafterdate or cancelafterdate on the line. An item cross reference lets the retailer's own item number resolve through itemaliasid. Line 2 carries 12 of the 16 ordered units of item 10499, so the order is 24 times 12.50 plus 12 times 8.75, which is 300.00 plus 105.00, so 405.00. When the goods ship, trackingnumber takes several numbers separated by commas, one per parcel, and the Sales Invoice converted from the order adds freight of 18.50 and a 2% trade discount of 8.10 for the 810 total of 415.40.

The technical reality of this pair

Concurrency, not a rate. Sage Intacct limits concurrent connections to its gateway per company. Its own example: with 100 concurrent requests, 5 might be processed while the other 95 are held for about 5 seconds, then served first in, first out. Too many requests in a short period return a 429 with gateway error GW-0010. The integration therefore sends orders from a queue a few at a time. A morning file of 120 purchase orders is 120 requests; at 5 in flight, that is 120 divided by 5, so 24 rounds, and at about 1 second per request the file is written in under half a minute.

Request size. Intacct advises fewer than 100 records changed per request and queries of fewer than 1,000 records, and a request can time out after 15 minutes while still processing. One 850 is one transaction, so EDI orders stay far inside that.

Idempotence. Intacct uses the request's uniqueid element, set to true, to enforce idempotence for the functions in that request. A retry after a timeout then does not create a second sales order for the same PO.

Sage X3 web services. X3 publishes SOAP web services in RPC/encoded style, each tied to an X3 object or program, through the Syracuse server. Two settings matter for an EDI flow. The number of web services child processes on the host defaults to 0, and until it is set every call returns HTTP 500 with "No Web services accepted". And the license limits the data volume exchanged through web services per day, month or year, with a grace margin (typically 10%) after which calls slow down. A partner with a daily file of large orders is sized against that volume before go-live.

Intacct access. XML Web Services needs a Web Services developer license with a sender ID, the Web Services subscription switched on in the company, the sender ID authorized there, and a Web Services user. These are set up once, by the company's administrator.

What Sage and X12 store differently

Units. An Intacct order line has a unit of measure. The 850 orders 24 EA or 2 CA of 12; the line is written in the unit the item is sold in, and the 855, 856 and 810 convert back to the partner's unit. See units of measure.
Dates. X12 dates are CCYYMMDD in a DTM segment with a qualifier. Intacct takes dates as separate year, month and day elements, and Sage X3's sequential files use the date format set on the file. Each partner's DTM qualifiers map to a named date field.
Item identity. The 850 sends a UPC in PO107 and often the retailer's own item number. Intacct's item cross references hold the customer's identifier per customer; the UPC lookup is kept in the integration when the item record does not carry it.
Cartons. Neither product holds the HL loop of an 856: which units went into which carton under which SSCC. That comes from packing, a warehouse system or the 3PL.

When it goes wrong

What happens	What the integration does
Intacct returns 429 (`GW-0010`)	The queue backs off and resends; `uniqueid` prevents a duplicate
A request times out	It is resent with the same `uniqueid`, or the PO is looked up first
An item in the 850 has no cross reference	The order is held with the PO1 line shown; the 997 has already gone out
An X3 flow drops no file into the directory by its time	An alert for that partner and document, before the retailer's window closes
The partner rejects an 810 with a 997	AK3 and AK4 are shown with segment and element; the corrected invoice goes out under a new control number

We build the integration to your Sage company and your trading partners, host it and run it, for a fixed build price and a monthly fee. A new partner starts as a dry run that creates nothing in Sage and sends nothing, and you approve the first documents. When a partner publishes a new guide or Sage changes an interface, we change the integration. More on the system side is under Sage Intacct integrations. Tell us which partners you trade with.

Frequently asked questions

Does Sage have native EDI?

Sage X3 has an EDI framework: EDI partners, protocols, flows and message mappings that write or read sequential and XML files for sales orders, deliveries and invoices, sent by email or to a directory. It does not produce X12 with an ISA envelope, control numbers or a 997. Sage Intacct's developer documentation has no EDI section; orders come in through its Web Services API.

Can the Sage X3 EDI framework talk to a US retailer directly?

Not on its own. A retailer expects X12 with its own version, qualifiers, envelope and acknowledgments, delivered over AS2, SFTP or a network mailbox. The X3 framework produces a flat or XML file per message. The integration translates between that file and X12 per partner, or writes to X3 through its web services instead.

Does this work with Sage 100, Sage 300 or Sage 50?

Yes. The X12 side is the same for every Sage product; what changes is how the integration reads and writes orders, shipments and invoices in the product. Which interface that is, and what it allows, is checked for your version and edition before the build.

Can EDI orders use our Sage item codes and units?

Yes. In Sage Intacct an item cross reference links a customer's own identifier to your item, so a retailer's item number resolves to the right item, and each order line carries a unit of measure. A UPC on the 850 is looked up in the integration or in a cross reference, and cases are converted to the unit the line is sold in.

Tell us what you need

Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.

You know the price and the timeline before you commit to anything
We work out the connection that takes the work off your hands
We handle the build, hosting, monitoring and maintenance
Your team has less information to retype and fewer discrepancies to chase

Name

1. Which systems need to talk to each other?

2. What's the volume?

Suppliers, products, orders per day, a rough estimate is fine.

3. What would you like us to take care of?

Store URL optional

Or email directly: carsten@syncmyshop.com