Target Edi 850

By Alexander Georges|Updated December 16, 2025
TL;DR: This guide explains how to read, validate, convert, and troubleshoot Target EDI 850 purchase orders with practical examples, step-by-step conversion to CSV, and real-world fixes for common Target PO issues. Use the included EDI snippets, segment explanations, CSV mapping, and troubleshooting checklist to prevent compliance penalties and streamline automated processing using tools like PlainEDI.

What This Is

This guide covers Target EDI 850 purchase orders: the X12 850 transaction set that Target sends to suppliers to request goods. You will learn the structure of Target's implementation expectations for the 850, the key segments and elements to watch, how to convert an 850 into a usable CSV for ERP or warehouse systems, and how to diagnose and fix the most common errors that cause processing failures or retailer chargebacks.

The examples focus on Target-specific realities: PO-level identifiers, item identification conventions (GTIN/UPC vs. Target item numbers), ship-to and bill-to handling, and ASN/OTIF expectations that can lead to penalties. The content is practical: annotated EDI code snippets, a line-by-line conversion to CSV, step-by-step processing logic, and prescriptive fixes for errors you will see in production.

Who This Is For

This guide is for EDI developers, integrators, supply chain analysts, and small-to-midsize vendors who receive Target 850 POs and must validate, convert, and load them into accounting, WMS, or ERP systems. It helps you automate parsing and ensure compliance with Target's vendor requirements.

Key Segments Explained

Below are the Target 850 segments you will encounter most often, what they mean, and why they are critical for correct processing.

1. ISA / IEA (Interchange Control Header and Trailer)

Purpose: Envelope-level control. Contains interchange sender/receiver IDs, control numbers, and delimiters.

Why it matters: Wrong ISA IDs or mismatched control numbers cause VAN or AS2 rejections before your application ever touches the PO. Target's VAN or trading partner setup expects exact ISA qualifier and ID values; any deviation triggers rejection.

2. GS / GE (Functional Group Header and Trailer)

Purpose: Groups related transaction sets. The GS provides application sender/receiver IDs and functional identifiers (e.g., PO for purchase orders).

Why it matters: GS/GE mismatches or incorrect functional IDs can cause downstream mapping errors. For Target 850s, verify the GS02/GS03 IDs match the values your account manager assigned.

3. ST / SE (Transaction Set Header and Trailer)

Purpose: Encapsulates each 850 transaction. ST01 contains the transaction set identifier code '850'. ST02 is the transaction control number; SE01 is the segment count.

Why it matters: Incorrect segment count in SE01 or duplicate ST02 values cause 997 rejects. Always compute SE segment counts from ST to SE inclusive.

4. BEG (Beginning Segment for Purchase Order)

Purpose: Declares PO type, PO number, and date. Typical structure: BEG*00*NE*PO12345**20251214.

Why it matters: Target uses the PO number in BEG03 for invoice matching. If your system changes the PO number format or truncates leading zeros, invoices will fail matching and incur deductions.

5. N1 / N3 / N4 (Name and Address Loops)

Purpose: Contains ship-to and bill-to party information. N1*ST identifies a ship-to; N1*BT identifies the bill-to.

Why it matters: Target uses specific location codes. Mapping the wrong N1 qualifier leads to shipments to incorrect DCs. Validate N102 (name) and N104/N045 (postal code/state) against your vendor portal records.

6. PO1 (Line Item Detail)

Purpose: Provides the line-level item quantity, UOM, unit price (if present), and product identifiers like UPC, GTIN, or Target item number using the PID/REF subsegments.

Why it matters: PO1 is the most critical segment for fulfillment. Quantity mismatches, UOM mismatches, and wrong item identifiers cause receiving exceptions and chargebacks.

Example EDI Snippet

ISA*00*          *00*          *ZZ*TARGET        *ZZ*SUPPLIERID    *231214*0900*U*00401*000000905*0*P*>~
GS*PO*TARGET*SUPPLIERID*20231214*0900*1*X*004010~
ST*850*0001~
BEG*00*SA*PO123456**20231214~
REF*IA*123456789~
N1*ST*TARGET DC 1234*92*1234567890~
N3*123 TARGET WAY~
N4*MINNEAPOLIS*MN*55400~
PER*BD*MERCHANDISE CONTACT*TE*6125551212~
PO1*1*12*EA*9.99**IN*111111111111~
PID*F****Red widget, model x~
PO1*2*6*EA*7.50**VN*ABC-9876~
CTT*2~
SE*13*0001~
GE*1*1~
IEA*1*000000905~

Line-by-line explanation:

  • ISA: Envelope with sender (TARGET) and receiver (SUPPLIERID). ISA13/ISA14 are control number and acknowledgement request flags.
  • GS: Functional group of PO transactions. GS06 is the group control number (1) and GS08 is the version '004010'.
  • ST: Start of an 850; ST02 '0001' must match SE02.
  • BEG: PO type '00' (original), transaction set purpose 'SA', PO number 'PO123456', PO date 20231214.
  • REF IA: Internal reference (vendor-assigned). REF qualifier 'IA' often carries buyer-assigned references.
  • N1 ST: Ship-to name with Target DC code in N104.
  • PO1: First line: line number 1, quantity 12, UOM EA, unit price 9.99, IN qualifier indicates UPC (111111111111).
  • PID: Free-text description for the first item.
  • PO1 (second): Second line with vendor item number qualifier VN and value ABC-9876.
  • CTT: Line item count total (2).
  • SE / GE / IEA: Trailers closing transaction, group, and interchange.

CSV Output Example

Below is a practical CSV mapping for loading the Target 850 into a WMS or ERP. The CSV contains both PO header and line-level fields in a flattened structure.

PO_Number PO_Date Line_Number Item_ID_Type Item_ID Quantity UOM Unit_Price Ship_To_Name Ship_To_DC
PO123456 2023-12-14 1 UP 111111111111 12 EA 9.99 TARGET DC 1234 1234567890
PO123456 2023-12-14 2 VN ABC-9876 6 EA 7.50 TARGET DC 1234 1234567890

Step-by-Step Conversion Process

  1. Ingest and Envelope Validation
    1. Accept the incoming EDI file through AS2, VAN, or SFTP.
    2. Validate ISA/GS IDs against your trading partner setup. Reject or quarantine if ISA qualifiers, ISA IDs, or GS02/GS03 values do not match expected values.
    3. Use PlainEDI to auto-detect delimiters and validate that ISA element separators match the file header. PlainEDI flags delimiter anomalies to prevent parsing errors.
  2. Transaction Set Parsing and ST/SE Checks
    1. Parse ST/SE blocks. Compute the number of segments between ST and SE inclusive; compare with SE01. If counts differ, flag as segment-count error and generate a functional acknowledgement 997 with appropriate AK9/AK4 data.
    2. Ensure ST02 equals SE02 for traceability.
  3. Header-level Mapping (BEG, REF, N1)
    1. Extract BEG03 as the canonical PO number. Normalize leading zeros if your ERP uses a different convention, but preserve the original value for acknowledgements.
    2. Map N1 loops to your ship-to master table. If the ship-to code in N104 is missing from your master, create a quarantine record and notify trading partner operations.
  4. Line-level Parsing and Business Rules
    1. For each PO1, extract line number, quantity (PO102), UOM (PO103), unit price (PO104) if present, and product IDs (PO1/REF/PID).
    2. Apply business rules: UOM conversion factors, minimum ship quantities, and pack-level splits. Fail the PO if business rules that affect fulfillment (like UOM mismatch) cannot be resolved automatically.
  5. CSV Flattening and Enrichment
    1. Flatten hierarchical PO into one CSV row per PO1 line. Enrich each row with header values (PO number, PO date, ship-to, bill-to).
    2. Normalize item IDs: prefer GTIN/UPC for barcode scanning, but include vendor item numbers in a secondary column for ERP reconciliation.
    3. Example: Use the column mapping in the CSV table above.
  6. Validation, Duplicate Detection, and Acknowledgement
    1. Run validation rules: required fields, allowed UOM values, quantity > 0. Use PlainEDI validation to run schema and business-rule checks automatically.
    2. Check for duplicate POs by BEG03 and ST02 pairs. If duplicate, reject with a business-level response and, where required, generate a 999 or manual response to Target via your VAN.
    3. Send 997 functional acknowledgements after successful parsing; include AK1/AK9 statuses for each functional group as required.

Common Errors and Fixes

  • Error: ISA control number mismatch — Symptom: Trading partner VAN rejects the file. Fix: Ensure ISA13/ISA14 values increment per interchange; set your translator to persist and increment the control number. Re-send after updating ISA control to the next expected integer.
  • Error: SE segment count mismatch (SE01) — Symptom: 997 reject or parsing failure. Fix: Recompute segment count including ST and SE; correct SE01 and re-emit. Use PlainEDI to auto-check segment counts during upload.
  • Error: Missing or invalid N1*ST ship-to code — Symptom: Ship-to not found in WMS; fulfillment delays. Fix: Validate N104 against your ship-to master; if missing, query Target Vendor Support and request the correct ship-to code. Temporarily route PO to manual queue and notify operations team.
  • Error: PO1 quantity or UOM discrepancy — Symptom: Receiving rejects goods for wrong UOM. Fix: Compare PO103 to your allowed UOM list and convert quantities using unit conversion rules. If conversion impossible, send a PO confirmation back to Target and log the exception.
  • Error: Invalid item identifier (wrong qualifier) — Symptom: UPC provided in vendor number slot, system cannot match item. Fix: Inspect PO1 qualifiers (IN vs VN vs UP). Update mapping rules to honor IN or UP as GTIN/UPC and fall back to VN for vendor SKU. Reprocess after updating lookup tables.
  • Error: Duplicate ST02 / transaction control number — Symptom: Receiving system treats a PO as duplicate. Fix: Ensure your translator sets unique ST02 per transaction. If duplicates are legitimate re-sends, include REF*SA or correct REF qualifier to indicate replacement.
  • Error: 997 AK9 Rejection Codes (e.g., AK9 R for reject) — Symptom: Functional group rejected. Fix: Read AK3/AK4 to find the segment/element causing the reject. Correct syntax, formatting, or missing required elements and resend the functional group. Use reading 997 functional acknowledgments for decoding AK segments.

Related Resources

Troubleshooting Case Studies

Case Study 1 — Missing Ship-to DC Caused Fulfillment Delay

Issue: A supplier received a Target 850 where N1*ST had a text name but no N104 code. Their WMS could not resolve an internal DC, so fulfillment stalled and the supplier faced chargebacks.

Fix: The supplier updated their parser to require N104 when N1*ST is present. Files without N104 are routed to a manual queue and an automated inquiry email is sent to trading partner ops. The change reduced manual lookups by 70% and prevented repeated chargebacks.

Case Study 2 — Incorrect UOM Conversion Created Quantity Shortages

Issue: PO1 used 'CT' for cases, but the supplier's system treated all quantities as 'EA', shipping single units instead of full cases.

Fix: Implemented UOM conversion table and pre-flight validation that rejects POs where UOM requires manual confirmation. Supplier added a business rule to refuse auto-processing for UOMs not in their conversion table and send back a confirmation to Target.

Target-Specific Compliance and Penalties

Target enforces vendor compliance programs that include penalties for failures in OTIF, ASN accuracy, and invoice matching. Vendors must follow Target's published shipping and EDI requirements and submit accurate 850 confirmations where required. This guide uses retailer information last updated 2025-12-14; verify current requirements in Target's vendor portal for any program changes.

Types of penalties include OTIF deductions, chargebacks for ASN accuracy or incorrect DC routing, and invoice matching failures. Best practices: validate N1 ship-to codes, ensure GTIN accuracy in PO1, and send timely ASN / 856s after shipping to reduce OTIF exposure.

How PlainEDI Helps Prevent Errors

PlainEDI provides delimiter detection, X12 schema validation, and business-rule checks for common Target 850 issues. When you upload an 850, PlainEDI flags ISA/GS mismatches, segment-count errors, missing mandatory elements (like BEG03), and invalid qualifiers in PO1. PlainEDI's duplicate detection prevents reprocessing the same PO number twice, and its CSV mapper exports ready-to-load files for ERPs.

Use PlainEDI during initial onboarding to run rule sets that match Target's trading partner constraints and maintain an audit trail of rejections and corrections for compliance reviews.

FAQ Section

Q: What is the single most important field to validate in a Target 850?

Validate BEG03 (the PO number) first. BEG03 is the canonical reference used for invoice matching and confirmations. If BEG03 is incorrect, everything downstream—acknowledgements, ASNs, invoices—will fail reconciliation.

Q: How do I handle PO1 lines with multiple product ID qualifiers?

Prefer GTIN/UPC qualifiers (IN or UP) for warehouse scanning. If GTIN is not present, fall back to vendor item number qualifiers like VN. Store both in your item master and map GTIN to barcode fields in your WMS.

Q: What causes SE segment count mismatches and how can I fix them?

SE mismatches occur when the translator miscounts segments or when extra segments are added/removed during manual edits. Recompute the count between ST and SE inclusive, update SE01, and re-emit. Automated tools like PlainEDI validate segment counts on upload to prevent this error.

Q: Should I accept POs with missing N104 ship-to codes?

No. Route such POs to a manual review queue and contact Target support to obtain the correct ship-to code. Processing without a validated ship-to increases the risk of shipping to the wrong DC and incurring chargebacks.

Q: When do I send a 997 functional acknowledgement for a Target 850?

Send a 997 after syntactic validation of the interchange and functional group. If the file fails on syntax (ISA/GS), do not send 997 until corrected. Your 997 should reflect AK1/AK9 statuses for each functional group and detail any segment-level AK4 errors if present.

Q: How should I handle duplicate POs appearing with the same BEG03 but updated quantities?

Check for REF qualifiers indicating a change or cancellation. If the PO is an official change, process per Target's change handling policy and reconcile differences. If duplicates are identical, treat as retransmissions and avoid double-fulfillment by tracking processed ST02 and BEG03 pairs.

Q: What do I do if Target sends item IDs I don't recognize?

Compare the provided identifiers (GTIN, Target item number) against your item master. If the identifier is new, create an inquiry to Target buyer/portal and hold the line in a manual exception queue until the correct mapping is confirmed.

Q: Can I convert Target 850 to CSV automatically for QuickBooks or my ERP?

Yes. Convert each PO1 into a CSV row that includes header fields (PO number, date, ship-to) and line fields (item ID, qty, uom, price). Use PlainEDI or your EDI translator to automate mapping and export CSV files formatted for your specific ERP import template. Confirm import field order and UOM expectations before bulk processing.

Final Checklist Before Production

  • Validate ISA/GS values against your trading partner agreement.
  • Verify ST/SE segment counts and unique ST02 values.
  • Confirm BEG03 PO number preservation and mapping to ERP.
  • Validate N1 ship-to codes against Target's vendor portal.
  • Normalize PO1 item IDs and ensure UOM conversions are in place.
  • Run 997 functional acknowledgements and resolve AK9/AK4 errors promptly.
  • Keep an audit trail of rejected POs and corrections for compliance.

Ready to validate and convert your Target 850 files? Upload an 850 to PlainEDI to run delimiter detection, schema validation, and export a CSV ready for your ERP or WMS.