ASC X12 (ANSI X12)

ASC X12 (formally the Accredited Standards Committee X12, chartered by ANSI) is a not-for-profit standards body that develops and maintains the X12 EDI standard, first published in 1979. "ASC X12" and "ANSI X12" are used interchangeably in practice — ASC X12 is the committee, ANSI is the accrediting body, and X12 is the standard itself. The committee organizes the standard into numbered transaction sets, each representing one type of business document. Common transaction sets used in B2B order and catalog workflows include 850 (Purchase Order), 855 (Purchase Order Acknowledgment), 856 (Ship Notice/Manifest, also called an ASN), 810 (Invoice), 832 (Price/Sales Catalog), and 997 (Functional Acknowledgment, a receipt confirming a document was received and syntactically valid).

Each transaction set is published under a release version (for example, 4010 or 5010), and trading partners agree in advance on which version and which optional segments they will use — X12 defines the grammar, not a single fixed layout every company implements identically.

An X12 document is plain text organized as nested envelopes: an Interchange Envelope (ISA/IEA) wraps one or more Functional Groups (GS/GE), which wrap one or more Transaction Sets (ST/SE). Inside a transaction set, data is organized into segments (a line representing a logical grouping, like a name and address), and each segment contains data elements separated by delimiters — typically an asterisk for element separation and a tilde for segment termination, though delimiters are negotiated per trading partner.

Transaction Set	Name	Typical Use
850	Purchase Order	Buyer sends an order to a supplier
855	PO Acknowledgment	Supplier confirms/adjusts the order
856	Ship Notice/Manifest (ASN)	Supplier notifies buyer of shipment contents
810	Invoice	Supplier bills the buyer
832	Price/Sales Catalog	Supplier sends product and pricing data
997	Functional Acknowledgment	Receipt confirming a document was received

A document is only valid EDI if it conforms to the segment and element rules for its transaction set and version — this is what an EDI mapping or translation tool validates before the data is loaded into an ERP or order management system.

X12 and UN/EDIFACT solve the same problem — structured, machine-readable business documents — but are separate standards with separate governance, and they are not directly interoperable without translation.

	ASC X12	UN/EDIFACT
Maintained by	ASC X12, accredited by ANSI	UN/CEFACT (United Nations)
Primary region	North America	Europe, Asia, and international trade generally
Document identifier	Numeric transaction set codes (e.g., 850)	Alphanumeric message types (e.g., ORDERS)
Structure	Hierarchical envelopes: ISA/GS/ST...SE/GE/IEA	Similar envelope concept: UNB/UNH...UNT/UNZ
Common in	US retail, healthcare (HIPAA transactions), logistics	International trade, European retail and manufacturing

A supplier selling into both US and European retail networks often has to support both standards, or route everything through an EDI provider that translates between them and the trading partner's preferred format.

X12 defines the document format, not how it travels. In practice, X12 documents are moved between trading partners over AS2 (a secure point-to-point transport protocol widely required by large retailers), a VAN, or increasingly SFTP or API-based EDI gateways. X12 is also distinct from the catalog and punchout standards used in procurement: cXML and OCI are used for real-time punchout sessions from a buyer's procurement system into a supplier's storefront, and GDSN is used to synchronize item master data across a data pool network. X12's 832 transaction set overlaps with these in purpose — sending catalog and pricing data — but is a batch, document-based exchange rather than a live catalog session or synchronized data pool.

For a distributor or manufacturer, this means product data often has to exist in more than one shape at once: an item master feeding a website and marketplaces, a cXML/punchout catalog for procurement buyers, and an X12 832 or 810/850/856 document set for EDI trading partners. Anglera's enrichment workflows normalize a single source item master so it can be mapped consistently into these different downstream formats, rather than maintaining the data separately for each channel.

Onboarding a new X12 trading partner is a mapping exercise, not a plug-and-play integration: each partner issues an EDI implementation guide specifying which version, which segments, which qualifiers, and which optional fields they require, and both sides typically run test transactions before going live. Because X12 is a syntax standard rather than a single fixed schema, two retailers can both send valid 850 purchase orders that differ in which segments are populated, so a mapping built for one partner rarely works unchanged for the next.

For catalog-ops teams specifically, the 832 Price/Sales Catalog transaction set is the one most likely to matter — it's how some large retail and distribution trading partners still expect product and pricing updates, alongside or instead of a flat file, cXML punchout catalog, or portal upload.