Sage 100 EDI: mapping X12 850, 856 and 810 to sales orders, shipments and invoices

Who does what in a Sage 100 EDI setup

Where Hundred fits: Hundred is a planned REST API for the Sage 100 side of that chain. It is not an EDI translator, a VAN or an AS2 service: it will not read or write X12, hold partner maps or connect to your trading partners. It is meant to work alongside one, for a translator or an in-house EDI system that would rather call one HTTPS endpoint than build and maintain its own component for Sage 100. A small Hundred connector would still run on the Sage 100 server. It is not built yet; nothing below is callable today.

850 purchase order to a Sage 100 sales order

A trimmed 850 (envelope segments left out) and the sales order it should become. Item and order numbers match the sales order example in Hundred's planned API reference.

BEG*00*SA*5512**20260927~
N1*ST*DC 14*92*0014~
TD5*****UPS GROUND~
PO1*1*4*EA*129.50**VP*1001-HON-H252~
PO1*2*1*EA*19.95**VP*6655~
CTT*2~

{
  "customerId": "01-AVNET",
  "customerPoNo": "5512",
  "shipVia": "UPS GROUND",
  "lines": [
    { "itemCode": "1001-HON-H252",
      "quantityOrdered": 4,
      "unitPrice": 129.50 },
    { "itemCode": "6655",
      "quantityOrdered": 1,
      "unitPrice": 19.95 }
  ]
}

Create the order through Sage 100's Sales Order business object, not by writing tables, so pricing, tax, credit checks and numbering run as they do for your staff. The BOI guide shows how.

This 850 is your customer's purchase order to you. Purchase orders you send to your own vendors, and the receipts of goods when they arrive, are Sage 100's Purchase Order module: Guide 08 covers them, with stock per warehouse.

856 ship notice: where the data lives in Sage 100

In Sage 100 a shipment is recorded against an S/O invoice. Shipping Data Entry, available when Enable Shipping is selected in Sales Order Options, takes the shipped quantities, freight and weight, and a Tracking button for tracking numbers. Those land in the unposted invoice tables. After the invoice is posted, the same data is in invoice history. An 856 announces a shipment before it arrives, so it is usually sent when the goods leave: read the unposted tables.

The tracking table has one row per package (InvoiceNo + PackageNo), but the invoice lines carry no package number in the fields above. If a partner wants a pack-level 856 (which item is in which carton), find out where your setup or EDI product stores that before you promise it.

Hundred: a shipments endpoint for this data is planned but not designed yet, so it is not in the API reference. The planned invoice endpoints read posted invoices only, which is too late for most ship notices.

810 invoice: where the data lives in Sage 100

Read the 810 from the same invoice: before posting from SO_InvoiceHeader and SO_InvoiceDetail, after posting from AR_InvoiceHistoryHeader and AR_InvoiceHistoryDetail.

Hundred: the planned GET /invoices reads posted invoices from invoice history, with invoiceNo, invoiceDate, customerId, salesOrderNo, invoiceTotal and dueDate; GET /invoices/{invoiceNo} adds the lines. Unposted invoices are not in the plan for launch, so with Hundred an 810 would go out after posting.

EDI providers that integrate with Sage 100

If you want one product to do the translation, the partner maps and the Sage 100 side, these providers describe a Sage 100 integration on their own pages. They are examples, not a complete list; Hundred has not tested them and does not endorse them.

• SPS Commerce: Fulfillment for Sage 100, built on Mapadoc, which SPS describes as "fully embedded within Sage 100cloud", for orders, invoices and ship notices. SPS Commerce: Sage 100.
• TrueCommerce: its Sage 100 integration creates Sales Order Entries from inbound 850s and reads Invoice Data Entry and Shipping Data Entry to generate 810s and 856s; the product page says it uses "the native Sage Business Objects interface". Integration overview, creating ship notices, product page.
• EDIconnect: lists X12 850, 855, 856, 810, 820 and 997, and says it connects Sage 200 and Sage 100 through "standard ODBC/Web API". EDIconnect: EDI for Sage.

If one of these already covers your partners, you do not need a separate API for EDI. A REST API on the Sage 100 side matters when the translator is yours, or runs in the cloud, and you would rather not build and maintain your own Sage 100 component.

Before you build

1. Start from the partner's implementation guide. Each trading partner publishes which segments and codes it requires. Where it differs from this page, the partner's guide wins.
2. Build the cross-references first: partner ID to customer, ship-to locations, buyer part numbers and GTINs to item codes, X12 units to Sage units, routing text to ship-via codes, terms codes to ITD values.
3. Make the 850 import safe to repeat: check CustomerPONo per customer before you create an order, and log the PO number next to the Sage order number.
4. Turn on Enable Shipping if you need 856s with tracking numbers, and make sure tracking numbers are entered or imported from your carrier system.
5. Check the version. Sage 100 2026 is 64-bit only; any EDI component on the Sage 100 server must be 64-bit (see the 64-bit guide).

Sources: Sage 100 file layouts for SO_SalesOrderHeader, SO_SalesOrderDetail, SO_InvoiceHeader, SO_InvoiceDetail, SO_InvoiceTracking, AR_InvoiceHistoryHeader, AR_InvoiceHistoryDetail and AR_InvoiceHistoryTracking; Sage 100 help, Enter Shipping Freight/Weight; Stedi's X12 reference for the 850, 856 and 810, and the product ID qualifiers.