How to Validate EDI Files Before Sending

Validating EDI files before sending to trading partners prevents costly rejections, chargebacks, and compliance penalties. A comprehensive validation process includes syntax checks, segment validation, data element verification, and trading partner-specific requirements. This guide covers best practices for validating EDI 850, 856, and 810 files before transmission.

The 5-Layer EDI Validation Model

Effective EDI validation happens in five layers, from basic syntax to trading partner-specific rules:

Layer 1: Syntax Validation

Syntax validation ensures the EDI file is structurally correct and can be parsed by the receiver's EDI system.

1.1: Delimiter and Terminator Validation

What to Check:

• Element Delimiter: Typically asterisk (*) - separates data elements within a segment
• Segment Terminator: Typically tilde (~) - marks the end of each segment
• Sub-element Delimiter: Typically colon (:) or greater-than (>) - separates sub-elements within composite elements

ISA*00*          *00*          *ZZ*SENDER         *ZZ*RECEIVER       *250115*1430*U*00401*000000001*0*P*>~
GS*PO*SENDER*RECEIVER*20250115*1430*1*X*004010~
ST*850*0001~
BEG*00*SA*PO123456*********20250115~
SE*4*0001~
GE*1*1~
IEA*1*000000001~

Validation Rule: Verify that delimiters are used consistently throughout the file. Mixed delimiters (e.g., using * and | interchangeably) cause parsing errors.

1.2: Control Number Matching

What to Check:

• ST.02 = SE.02: Transaction set control numbers must match (ST*850*0001~ → SE*4*0001~)
• GS.06 = GE.02: Group control numbers must match
• ISA.13 = IEA.02: Interchange control numbers must match

1.3: Segment Count Validation

What to Check: The SE.01 (segment count) must equal the total number of segments in the transaction set, including ST and SE.

ST*850*0001~
BEG*00*SA*PO123456*********20250115~
N1*ST*SHIP TO NAME*92*1234567890123~
PO1*1*100*EA*12.50*PE*BP*012345678901~
SE*5*0001~

Validation: Count segments: ST (1) + BEG (2) + N1 (3) + PO1 (4) + SE (5) = 5 segments. SE.01 = 5 ✓ Correct.

Layer 2: Segment Validation

Segment validation ensures all required segments are present, in the correct order, and meet minimum occurrence requirements.

2.1: Required Segment Presence

EDI 850 (Purchase Order) Required Segments:

• BEG: Beginning segment for PO (mandatory)
• N1: Name/Address segment (at least one N1*ST for ship-to)
• PO1: Baseline item data (at least one line item)

EDI 856 (Advance Ship Notice) Required Segments:

• BSN: Beginning segment for shipment notice (mandatory)
• HL: Hierarchical level (Shipment, Order, Pack, Item)
• TD5: Carrier details (required for shipment level)
• REF: Reference numbers (BOL, PO, etc.)
• N1: Name/Address (ship-to, ship-from)
• MAN: Marks and numbers (SSCC-18 barcodes) - required by Walmart, Target, etc.

EDI 810 (Invoice) Required Segments:

• BIG: Beginning segment for invoice (mandatory)
• N1: Name/Address (ship-to, remit-to with DUNS)
• IT1: Baseline item data (at least one line item)
• TDS: Total invoice amount (mandatory)

2.2: Segment Order Validation

Validation Rule: Segments must appear in the order specified by the X12 transaction set specification.

Example: In EDI 850, the BEG segment must come before N1 segments, and N1 segments must come before PO1 segments.

2.3: Element Requirements Within Segments

Validation Rule: Certain segments require at least one element within a group of elements to have a value.

Example: The REF (Reference Identification) segment requires at least the 2nd or 3rd element to contain a value:

REF*BM*1234567890~  (2nd element present - BOL number) ✓ Valid
REF*BM**1234567890~  (3rd element present - additional reference) ✓ Valid
REF*BM~~             (No 2nd or 3rd element) ✗ Invalid

Layer 3: Data Element Validation

Data element validation ensures that individual data fields contain properly formatted values.

3.1: Date Format Validation (DTM Segment)

Standard Format: Starting from X12 version 4010, all dates are represented in CCYYMMDD format (8 digits: Century + Year + Month + Day).

• CC: First two digits of the calendar year (20 for 2000s, 19 for 1900s)
• YY: Last two digits of the calendar year
• MM: Month (01-12)
• DD: Day (01-31)

DTM*002*20250127~  ✓ Valid (January 27, 2025)
DTM*002*20251327~  ✗ Invalid (Month 13 doesn't exist)
DTM*002*250127~    ✗ Invalid (Only 6 digits, should be 8)
DTM*002*01272025~  ✗ Invalid (Wrong format - MMDDYYYY instead of CCYYMMDD)

DTM Segment Format Qualifier: Use DTM.06 = D8 to specify CCYYMMDD format.

Exception: The ISA.09 (interchange date) only supports YYMMDD format (6 digits), regardless of X12 version.

3.2: UPC/GTIN Check Digit Validation

What to Check: The last digit of all GTIN formats (GTIN-8, GTIN-12, GTIN-13, GTIN-14) is a check digit - a mathematically calculated number that validates the GTIN and eliminates data substitution errors.

GTIN Formats:

• GTIN-12 (UPC-A): 12 digits (e.g., 012345678905)
• GTIN-13 (EAN-13): 13 digits (e.g., 0012345678905)
• GTIN-14: 14 digits (e.g., 10012345678902)

Check Digit Calculation (MOD 10):

1. Starting from the right (excluding the check digit), multiply every other digit by 3, and every other digit by 1
2. Sum all the results
3. Subtract the sum from the nearest multiple of 10
4. The result is the check digit

Example Validation: UPC 012345678905

Validation Tool: Use online check digit calculators (GS1, GTIN.info) or PlainEDI's EDI to CSV converter to extract and verify UPCs before sending.

3.3: SSCC-18 Barcode Validation

What to Check: The SSCC (Serial Shipping Container Code) is an 18-digit identifier assigned to logistics units (pallets, cartons). It includes a MOD 10 check digit.

SSCC-18 Structure:

Validation Rules:

• SSCC must be exactly 18 digits
• Check digit (last digit) must be valid using MOD 10 calculation
• SSCC must appear in the MAN*GM segment of EDI 856 ASN
• SSCC in EDI must match SSCC printed on GS1-128 barcode labels

3.4: Character Length Validation

Validation Rule: Each data element has a maximum allowed character length defined in the X12 specification. Exceeding this length causes EDI 997 rejections.

Common Character Limits:

• N1.02 (Name): Maximum 60 characters
• N3.01 (Address Line 1): Maximum 55 characters
• N4.01 (City): Maximum 30 characters
• REF.02 (Reference Identification): Maximum 50 characters

How to Fix: Truncate or abbreviate data to fit within the allowed length. For example, "Distribution Center #6023" (29 characters) can be abbreviated to "DC 6023" (7 characters).

3.5: Numeric Field Validation

Validation Rule: Numeric fields must contain only digits (0-9) and optionally a decimal point. No commas, dollar signs, or other characters are allowed.

PO1*1*100*EA*12.50~       ✓ Valid (decimal point allowed)
PO1*1*100*EA*$12.50~      ✗ Invalid (dollar sign not allowed)
PO1*1*1,000*EA*12.50~     ✗ Invalid (comma not allowed)
PO1*1*1000*EA*12.50~      ✓ Valid (no comma separator needed)

Layer 4: Business Logic Validation

Business logic validation ensures data consistency across related segments and documents.

4.1: Three-Way Match Validation

What to Check: Verify that the purchase order (850), advance ship notice (856), and invoice (810) match exactly:

• PO Number: Must match across all three documents
• SKUs/UPCs: Product identifiers must match
• Quantities: Shipped quantity (856) ≤ PO quantity (850), invoiced quantity (810) = shipped quantity (856)
• Prices: Invoice prices (810) must match PO prices (850)

How to Validate: Use PlainEDI to convert all three documents to CSV, then compare them side-by-side in a spreadsheet.

4.2: Hash Total Validation

What to Check: The TDS (Total Invoice Amount) segment in EDI 810 must equal the sum of all IT1 line item totals.

IT1*1*100*EA*25.00~  (100 × $25.00 = $2,500.00)
IT1*2*50*EA*15.00~   (50 × $15.00 = $750.00)
TDS*325000~          (Total: $3,250.00 in cents = 325000) ✓ Valid

Common Error: TDS amount doesn't match the sum of line items due to rounding errors or missing line items. Always verify totals before sending invoices.

Layer 5: Trading Partner Validation

Trading partner validation ensures compliance with retailer-specific requirements beyond the standard X12 specification.

5.1: Walmart-Specific Requirements

• MABD Date (DTM*002): Must be present in 850 PO, used to calculate OTIF compliance
• SSCC-18 (MAN*GM): Required in 856 ASN at pack level for all shipments
• Department Number (REF*DP): Required in 810 invoice
• GLN (N1*ST): Must match Walmart DC GLN exactly

5.2: Target-Specific Requirements

• ASN Accuracy: BOL format, item attributes must match PO
• Perfect Order Program: $0.75/carton fee for late/missing ASNs (effective May 2025)
• SSCC Barcodes: Required for carton-level tracking

5.3: Amazon Vendor Central-Specific Requirements

• DUNS Number (N1*RI): Required in 810 invoice remit-to segment
• 24-Hour Invoice Submission: 810 must be sent within 24 hours of shipment confirmation
• SSCC Barcodes (MAN*GM): Required in 856 ASN to prevent shortage deductions

5.4: Home Depot-Specific Requirements

• TMS Ship ID (REF*CN): Required in 856 ASN, $100 penalty if missing
• ASN Timeliness: 100% accuracy required, $1,000 for missing ASN / $250 for late ASN
• Barcode Quality: $5-$10/carton penalty if over 1% unreadable

Validation Workflow: Step-by-Step

Follow this workflow to validate EDI files before sending to trading partners:

Common Validation Mistakes and How to Avoid Them

Mistake 1: Skipping Visual Inspection

Problem: Relying only on automated EDI validators without visually inspecting the data can miss business logic errors (e.g., wrong GLN, incorrect prices).

Solution: Always convert EDI files to CSV with PlainEDI before sending. Visual inspection catches errors that automated validators miss.

Mistake 2: Ignoring Trading Partner Requirements

Problem: Assuming the standard X12 specification is sufficient. Retailers like Walmart and Target have additional requirements beyond X12 standards.

Solution: Maintain a checklist of trading partner-specific requirements and validate against it before every transmission.

Mistake 3: Not Testing SSCC Check Digits

Problem: Generating SSCC-18 barcodes without validating the check digit leads to unreadable barcodes at receiving and costly chargebacks.

Solution: Use a MOD 10 check digit calculator to verify every SSCC-18 before including it in the 856 ASN and printing GS1-128 labels.

Mistake 4: Not Validating Three-Way Match

Problem: Sending invoices (810) without verifying they match the PO (850) and ASN (856) results in invoice rejections and payment delays.

Solution: Build automated three-way match validation in your ERP system or use PlainEDI to manually compare all three documents before invoicing.

Automated Validation Tools and Resources

PlainEDI: Visual Validation via CSV Conversion

Convert EDI files to CSV instantly to validate:

• 850 Purchase Orders - Verify PO numbers, quantities, prices, MABDs, department numbers
• 856 ASNs - Verify SSCC-18 codes, UPCs, GLNs, carrier details, tracking numbers
• 810 Invoices - Verify prices match PO, quantities match ASN, TDS totals match line items

GS1 Check Digit Calculators

Use GS1's official check digit calculator to validate UPC/GTIN and SSCC-18 check digits:

• GS1 US Check Digit Calculator
• GTIN.info Check Digit Calculator
• Barcode Graphics Check Digit Calculator

EDI Mapping Guides

Consult trading partner EDI mapping guides for specific requirements:

• Walmart EDI Mapping Guides (available in Supplier Hub)
• Target EDI Specifications (available in Vendor Portal)
• Amazon Vendor Central EDI Guides (available in Integration tab)
• Home Depot EDI Specifications (available through EDI Onboarding)

Best Practices Summary

Related Guides