EDI 810 Invoice: Every Required Segment, Explained

Updated July 14, 2026

For distributors working with big-box retailers, national chains and mid-market brands, the 810 is where the order-to-cash workflow succeeds or fails. A compliant, accurate invoice speeds up payment and protects the trading partner relationship. An error in a single segment — a mismatched PO number, a wrong party ID, a totals discrepancy — can stop payment, trigger a chargeback and flag your account for audit.

This guide walks through every required segment, the five chargeback patterns behind most deductions and a clean template structure you can adapt to any trading partner.

What Is the EDI 810 Invoice?

The EDI 810 is the electronic equivalent of a paper invoice. A supplier transmits it to a buyer after fulfilling an order to initiate payment. In a standard X12 workflow it's sent in response to the EDI 850 purchase order, follows the EDI 856 advance ship notice, and is usually acknowledged by an EDI 997 confirming receipt — completing the billing side of the transaction cycle.

What makes the 810 unforgiving is where it lands. It feeds directly into retailer accounts payable and ERP systems, so formatting errors aren't caught by a human reviewer — they trigger automatic payment holds, deductions or rejections at the system level. That's why the segment-level detail below is worth getting exactly right.

EDI 810 in the Distributor Order-to-Cash Workflow

The 810 sits at the center of order-to-cash. It flows system to system, automating how shipped product gets billed and how funds move. When it's accurate and compliant, it helps distributors:

• Shorten days sales outstanding (DSO) by speeding customer acceptance
• Avoid penalty chargebacks from retailers and OEMs
• Pass trading partner and internal control audits cleanly
• Reduce manual order matching, freeing up accounting and IT teams

Those benefits reverse quickly when an 810 misses a required segment or fails to echo a retailer's reference code — and the stakes rise for distributors scaling into new retail channels or continuously onboarding trading partners.

Required EDI 810 Segments

The segments below are required in most 810 implementations under ANSI X12. One caution before the table: the word "optional" in the base X12 spec means very little in practice. Most enterprise retailers mandate several of those segments in their implementation guides, and omitting one is a leading cause of invoice rejection. The implementation guide, not the base spec, is the document to build against.

Segment	Name	Purpose	Common Chargeback Trigger
ISA / GS / GE / IEA	Interchange & group envelope	Define sender/receiver, version and control numbers for the entire transmission	Incorrect formatting causes file-level rejection before any invoice data is read
ST / SE	Transaction set header & trailer	Open and close each invoice transaction; SE01 must equal the total segment count	Segment count mismatch in SE01 triggers automatic rejection
BIG	Beginning segment for invoice	States the invoice date, invoice number and PO number (BIG04); must echo the exact PO from the inbound 850	PO number mismatch is the single most common cause of invoice rejection
N1 Loop	Party identification	Identifies bill-to, ship-to and buyer using trading partner-supplied codes (GLN, store number, DUNS)	Outdated party codes cause misapplied cash and "invalid ship-to" chargebacks
REF	Reference identification	Carries vendor numbers, department codes or payment routing references	Omission or mismatch causes payment holds
ITD	Terms of sale	Specifies payment terms (e.g., Net 30, 2% 10 Net 30) used for AP scheduling and discounts	Incorrect terms can cause deductions or missed discount windows
DTM	Date/time reference	Provides service or shipment dates where partners require them	Missing when the partner guide requires it triggers compliance flags
IT1	Baseline item data	Line-level detail: quantity, item number, unit of measure and price; must align 1:1 with the 850 and the 856	IT1 mapping errors are the top source of chargebacks from large retail accounts
PID	Product/item description	Item descriptions, where partners require additional product information	Required by some retailers; omission can cause rejection
TDS	Total dollar summary	Invoice total; must equal the sum of all IT1 line extensions plus taxes and adjustments	Even minor rounding discrepancies trigger automatic payment holds
TXI	Tax information	Line and summary tax amounts; must be consistent across the document	Tax inconsistencies cause deductions and reconciliation disputes
SAC	Service, promotion, allowance or charge	Carries freight, promotional allowances and discounts using partner-approved codes	Non-approved SAC codes or header/line misallocation cause short-pays
CTT	Transaction totals	Count of line item segments; must match the actual IT1 count	Mismatch between CTT and actual line count triggers transmission errors

Common EDI 810 Chargebacks and How to Prevent Them

Retailer chargebacks on 810 invoices trace back to a small set of root causes, and nine times out of ten the problem lives in the template or the mapping — not in the product or the relationship. Here are the five patterns behind most deductions.

1. PO reference and line-level mismatches

Retail AP systems match on the PO number first. If BIG04 doesn't echo the inbound 850 exactly — because the reference was hand-keyed, or the ERP integration doesn't carry it through — the invoice lands in a rejection queue, and on high-volume accounts the per-invoice penalties compound fast.

The fix: copy the PO number from the inbound 850 into BIG04 programmatically, map IT1 line numbers and product IDs straight from order data, and validate every line against the PO before transmission.

2. Totals that don't match line items

This happens when TDS is computed anywhere other than the line data itself: a hand-keyed amount, an omitted SAC charge, or rounding logic that differs from the retailer's. When the total doesn't equal the sum of the lines, the AP system holds or short-pays the invoice without a human ever looking at it.

The fix: recompute TDS from mapped line-item data every time, and match each trading partner's rounding and tax calculation rules exactly.

3. Incorrect or missing N1 party IDs

Location code tables go stale. Retailers open stores, consolidate distribution centers and restructure networks, and a mapping table that was accurate at go-live quietly stops being accurate. The result is misapplied cash receipts and "invalid ship-to" deductions.

The fix: centralize location ID tables, validate N1 values against each customer's current code set before sending, and re-audit mappings whenever a retailer announces a network change.

4. ASN/invoice inconsistencies (810 vs. 856)

When shipping and invoicing run on separate data, a quantity corrected on the ASN doesn't make it onto the invoice, or vice versa — and the retailer now holds two documents that disagree about the same shipment.

The fix: drive both the 810 and the 856 from the same fulfillment source record, and build a cross-check that blocks transmission until the two reconcile.

5. Misused allowance, charge or tax codes

A single global template applied to every partner, or a well-meaning finance override using a code the retailer doesn't accept, produces short-pays and repeat deduction research every billing period.

The fix: lock SAC and tax codes to each trading partner's approved list, and make sure your AR and EDI teams know the quirks of every major account.

A Clean EDI 810 Invoice Template Structure

The structure below is widely accepted by distribution and manufacturing trading partners. Adapt it to each partner's published implementation guide — and remember that specs change, sometimes with little notice, so disciplined mapping validation is what keeps a template current.

Position	Segment	Description	Status
1	ISA	Interchange control header	Required
2	GS	Functional group header	Required
3	ST	Transaction set header (810)	Required
4	BIG	Beginning segment: invoice date, invoice number, PO number (BIG04)	Required
5	REF	Reference identification (vendor number, department code)	Required by most
6	ITD	Payment terms	Required by most
7	DTM	Date/time reference (ship date, service date)	Conditional
8	N1 Loop	Party IDs: bill-to (BT), ship-to (ST), buyer (BY)	Required
9	IT1	Line-item detail: quantity, UOM, price, item number (one per invoiced line)	Required
10	PID	Product description	Conditional
11	SAC	Allowances and charges (freight, promo, discount) — line level	Conditional
12	TDS	Total dollar summary (must equal sum of all IT1 lines + SAC + TXI)	Required
13	TXI	Tax information — summary level	Conditional
14	SAC	Allowances and charges — summary level	Conditional
15	CTT	Transaction totals (count of IT1 segments)	Required
16	SE	Transaction set trailer (SE01 = total segment count)	Required
17	GE	Functional group trailer	Required
18	IEA	Interchange control trailer	Required

Checklist: Fortifying Your EDI 810 for Chargeback Protection

For teams onboarding new large retail customers, the complete guide to EDI trading partner onboarding covers how to embed these protections from day one rather than cleaning them up downstream.

Why EDI 810 Invoice Mastery Pays Off for Distributors

Getting the 810 right isn't a one-time setup task. Retailer implementation guides change, trading partners update spec requirements and ERP migrations can silently break field mappings. Distributors who treat 810 compliance as a continuous discipline rather than a launch checklist consistently report fewer chargebacks, shorter payment cycles and cleaner audit outcomes.

And if your AR team spends part of every week untangling retailer deductions, the root cause is almost always upstream — in how your 810s are mapped, validated and monitored before they're sent.

---

Frequently Asked Questions

---