Target Edi 855

What This Is

This guide focuses on Target EDI 855 — the X12 Purchase Order Acknowledgment used between suppliers and Target Corporation. An 855 confirms receipt of a Purchase Order (850) and communicates acceptance, rejection, partial acceptance, or proposed changes to line items, quantities, ship dates, and product identifiers. For Target vendor integrations, the 855 serves as the canonical record that reconciles your inbound PO and sets expectations for fulfillment, ASN preparation (856), and invoicing (810).

This guide is a practical reference for EDI developers, integration engineers, and vendor operations staff who need to parse, validate, map, and convert Target-specific 855 files into CSV or an ERP-friendly format. It includes real EDI examples, detailed segment-by-segment explanations, step-by-step conversion procedures, common error codes with fixes, and integration tips using PlainEDI validation and upload tools.

Who This Is For

This guide is for EDI analysts, integration engineers, vendor compliance teams, and 3PLs that exchange 855 Purchase Order Acknowledgments with Target and must convert them into CSV or system-specific records while maintaining compliance with Target vendor rules.

Key Segments Explained

• ISA / GS / ST (Envelope & Transaction Set Header)

  The ISA (Interchange Control Header) defines the interchange-level delimiters, sender/receiver IDs, and control number. The GS (Functional Group Header) wraps sets of transaction types (e.g., all 855s), and the ST starts an individual 855 transaction. Validate control numbers and element formats in ISA/GS/ST to ensure proper acknowledgement (997) and routing.

• BAK — Beginning Segment for Purchase Order Acknowledgment

  BAK contains the acknowledgment type and PO identifiers. Key elements: BAK01 (AckType: AC = Acknowledge - With Detail, AD = Acknowledge - No Detail, RJ = Rejected), BAK02 (ShipmentStatus), BAK03 (PO Number), BAK05 (Ack Date). For Target, ensure BAK03 matches the original 850 PO number exactly (same punctuation and leading zeros) to avoid reconciliation failures.

• PO1 — Baseline Item Data

  PO1 repeats per line and carries line-level quantities and identifiers: PO101 (Line Item Number), PO102 (Quantity Acknowledged), PO103 (Unit of Measure), PO104 (Unit Price), PO106/ PO107 (Product ID qualifier and ID like UPC/GTIN). For quantity changes, PO1 is where Target will expect an explicit acknowledgment quantity and code.

• ACK — Change Acknowledgment (if present as ACK segment in some implementations)

  Some trading partners use ACK segments for line-level status codes describing change reasons, e.g., ACK01 = Line Status, ACK02 = Quantity Accepted. If your map expects ACK but Target sends BAK/PO1 change flags instead, map both or normalize into your canonical fields.

• N1 / N3 / N4 — Party and Address

  N1 identifies parties: seller, buyer, ship-to, bill-to. For Target, N1 with qualifier ST indicates ship-to and must match the PO’s ship-to ID Target provided. N3 and N4 provide address lines and city/state/ZIP — required only if the ship-to differs from the PO or for special routing.

• REF — Reference Identification

  REF supplies secondary identifiers: REF*IA* may carry internal Target IDs; REF*DP may indicate department; REF*PD provides pickup/delivery references. Capture REF values into CSV columns if your ERP needs them.

• CTT / SE / GE / IEA — Trailer Segments

  CTT gives total line counts that must match the number of PO1 segments. SE gives the segment count for the transaction (ST ... SE). GE and IEA close the group and interchange. Discrepancies here are frequent causes of 997 rejections.

Example EDI Snippet

Below is a representative Target 855 transaction using standard delimiters: element separator *, component separator : (if present), and segment terminator ~. The sample shows a partial acceptance with quantity change on line 2.

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*TARGETID       *201214*1234*^*00501*000000905*0*P*:~
GS*PR*SENDERID*TARGETID*20251214*1234*905*X*005010~
ST*855*0001~
BAK*00*AC*PO12345678**20251214~
REF*IA*TARGET_INT_REF~
N1*ST*TARGET STORE 1234*92*1234567890~
PO1*1*100*EA*12.34**VN*ABC123*UP*000123456789~
PO1*2*50*EA*9.50**VN*DEF456*UP*000987654321~
ACK*2*IA*50~
CTT*2~
SE*10*0001~
GE*1*905~
IEA*1*000000905~

Line-by-line explanation:

• ISA: Interchange header. Contains sender/receiver and control number (000000905).
• GS: Functional group header identifying an 855 functional group (GS01 = PR sometimes used for Purchase Acknowledgment group).
• ST*855*0001: Transaction set 855, control 0001.
• BAK*00*AC*PO12345678**20251214: AckType AC (Accept with Detail), PO number PO12345678, Ack date Dec 14, 2025.
• REF*IA*TARGET_INT_REF: Target internal reference; parse into your reference column.
• N1*ST*TARGET STORE 1234*92*1234567890: Ship-to party with qualifier 92 for Target’s internal store ID.
• Two PO1 lines: line 1 accepted 100 EA at 12.34; line 2 acknowledged 50 EA at 9.50. If the original PO asked 60 for line 2, this is a partial acknowledgment.
• ACK*2*IA*50: Example ACK indicating line 2 has quantity 50 acknowledged; some partners use line-level ACK segments - normalize when mapping.
• CTT*2: Total line count 2. SE counts segments from ST to SE (10 in this example).

CSV Output Example

This table shows a typical flat CSV your ERP or order management system would expect after converting the EDI 855 above.

Step-by-Step Conversion Process

1. Detect and validate delimiters
   1. Read the first 106 characters of the EDI interchange to locate ISA and element separator (ISA16 is the component separator, ISA11 is the control version).
   2. Set the parser to the identified element separator and segment terminator (~ commonly). PlainEDI provides automatic delimiter detection during upload: PlainEDI validates and displays delimiters.
2. Envelope validation (ISA/GS/ST)
   1. Verify ISA sender/receiver IDs against expected Target partner IDs. Reject files with unexpected IDs for manual review.
   2. Confirm GS functional identifier and ST/SE segment count consistency. Use SE segment to validate transaction integrity before mapping.
3. Parse BAK and header-level fields
   1. Extract BAK03 as the canonical PO number. Normalize leading zeros and trim whitespace.
   2. Extract BAK01 to categorize acknowledgement type (Accepted, Rejected, Modified). Map to internal status codes.
4. Process PO1 loop(s) and line-level ACKs
   1. Iterate each PO1. For each PO1, extract line number, quantity acknowledged, UOM, price, and product IDs. If an ACK segment exists for that line, merge ACK values.
   2. Apply mapping rules: map vendor identifiers (VN, UP, etc.) according to your SKU master. If mapping fails, mark for manual resolution.
5. Business-rule validation
   1. Ensure sum of PO1 quantities does not exceed known stock constraints, and dates conform to planned ship windows (if present).
   2. Validate N1 ship-to ID matches the PO ship-to. If misaligned, flag and generate exception reports.
6. Generate CSV
   1. Map parsed fields to the CSV columns required by your ERP (see CSV example). Maintain consistent column ordering and quoting for numeric fields.
   2. Run schema checks: required columns populated, numeric formats valid, no illegal characters in numeric fields.
7. Validation and transmission
   1. Run the file through 997/999 simulation to detect potential rejections. PlainEDI provides preflight validation to detect missing mandatory segments and common syntactic errors: PlainEDI.
   2. If sending the 855 to Target, package the interchange with the correct ISA control numbers and send via your agreed protocol (AS2 or VAN). Keep archive of control numbers for reconciliation.

Common Errors and Fixes

• Error: ISA Control Number Mismatch — Symptom: Outbound GA/IEA control counts do not match. Fix: Ensure the ISA13/ISA14 control numbers are incremented per interchange. Recompute and re-send the interchange with a unique ISA control number.
• Error: SE Segment Count Incorrect (ST/SE mismatch) — Symptom: Trading partner returns a 997 rejecting the transaction. Why: SE must count all segments from ST to SE inclusive. Fix: Recalculate segment count programmatically before writing SE; run PlainEDI preflight validation to catch mismatches.
• Error: BAK03 (PO Number) Not Matching Supplier PO — Symptom: Your system cannot reconcile the 855 to an 850. Why: PO number formatting differences (leading zeros, special characters). Fix: Normalize PO number formats (trim whitespace, normalize leading zeros) and confirm Target-sent PO number format.
• Error: PO1 Quantity Discrepancy / Partial Acceptances — Symptom: ERP expects Qty Acknowledged = Qty Ordered. Why: Supplier or Target adjusted quantity causing partial acceptance. Fix: Implement business logic to accept partials: update downstream fulfillment and trigger exception workflow for backorder handling.
• Error: Invalid Product ID Qualifier — Symptom: PO1 contains unexpected qualifier (e.g., missing UP/GTIN). Why: Data mapping differences between supplier and Target. Fix: Map alternate identifiers (VN, SKU) to your master SKU table. If mapping fails, generate an item master mismatch report.
• Error: Missing N1 Ship-To or Incorrect N1 Qualifier — Symptom: Ship-to address not found in system. Why: N1 qualifier mismatch or missing store number. Fix: Extract N1*ST with qualifier '92' or 'ST' and reconcile against Target ship-to list. For missing values, escalate to Trading Partner onboarding.
• Error: 997 / 999 Functional Rejects — Symptom: Trading partner returns 997 with reject codes. Why: Syntax or situational errors (wrong segment order, invalid codes). Fix: Inspect 997/999 for reject codes, correct the specific segment, and re-submit after validation with PlainEDI.

Related Resources

• target-edi-850 — How Target formats purchase orders (850), useful when reconciling PO numbers.
• target-edi-compliance-requirements — Key compliance rules and what Target enforces for vendor EDI.
• how-to-validate-edi-files-before-sending — Validation checklist you should run before sending 855 acknowledgments.
• reading-997-functional-acknowledgments — How to interpret 997s so you can fix 855 syntactic errors.
• resolving-edi-997-rejection-codes — Mapping common 997 reject codes to fixes for 855 issues.
• plainedi-vs-full-edi-software — Compare PlainEDI validation against full translator platforms.
• edi-to-csv-for-small-business-vendors — Lightweight CSV mappings and examples for SMBs converting 855s.

Target Compliance and Penalties

Target enforces vendor compliance policies that cover ASN accuracy, OTIF (On Time In Full), and proper acknowledgment formats. When specific penalty amounts or program changes are referenced, include the effective date. For this guide, the vendor compliance status and enforcement guidance are current as of 2025-12-14. Verify current requirements on Target's supplier/vendor portal for up-to-date penalty amounts and thresholds.

Common types of penalties and compliance actions include chargebacks for inaccurate ASNs, OTIF noncompliance fees, and chargebacks for missing or incorrect acknowledgments. Implement validations to reduce risk: ensure 855s are returned within your SLA window, confirm line-level quantities, and provide accurate ship-to IDs.

Troubleshooting Case Studies

Case Study 1 — Partial Acceptance Causing Fulfillment Delay

Situation: A supplier sent an 855 with PO1 line reported as 50 acknowledged when the 850 requested 100. The ERP automatically scheduled a fulfillment based on the original 850, causing a shipment discrepancy. Root cause: Missing merging of ACK segment that explicitly declared the partial quantity. Solution: Update the parser to prioritize ACK values when present, and add a business rule to create backorder records for the unacknowledged quantity. Validate mapping using PlainEDI preflight to ensure ACK segments are recognized before CSV generation: PlainEDI.

Case Study 2 — Segment Count Rejection

Situation: Partner returned 997 functional reject citing SE segment count mismatch. Root cause: A downstream logging process appended an extra blank line that was counted as a segment. Solution: Normalize incoming EDI streams by trimming trailing whitespace and recalculating SE counts. Add automated tests to simulate ST..SE boundary counts as a gating step before accepting the file into production.

FAQ Section

Q: What is the purpose of an 855 for Target?

The 855 Purchase Order Acknowledgment confirms receipt and acceptance status of an 850 PO. For Target, it confirms whether you accept, reject, or partially accept each PO line, and it provides authoritative quantities and item identifiers used for fulfillment and ASN creation.

Q: Which segments in the 855 are most critical to match to the 850?

Match BAK03 (PO Number) exactly, and ensure PO1 line numbers and item identifiers (VN, UP, GTIN) match the 850. Also validate N1*ST ship-to ID against the PO ship-to. Mismatches cause reconciliation exceptions and potential chargebacks.

Q: How do I handle partial acceptances in the 855 when converting to CSV?

Capture both ordered quantity (from 850 lookup) and acknowledged quantity (from 855 PO1/ACK). Populate CSV fields for Qty Ordered and Qty Acknowledged and add an Ack Status column (Accepted, Partially Accepted, Rejected). Trigger downstream backorder logic for the difference.

Q: What validation does PlainEDI provide for 855 files?

PlainEDI offers automatic delimiter detection, X12 syntax validation (ISA/GS/ST/SE/IEA), mandatory-segment checks, and custom business-rule validation that can detect missing BAK, mismatched segment counts, and invalid element formats before you ingest or transmit 855 files. Upload files for preflight validation at PlainEDI.

Q: How should I map product identifiers in PO1 when Target uses GTIN but my ERP uses vendor SKUs?

Maintain a translation table that maps GTIN/UPC to your vendor SKUs. During parsing, attempt to match GTIN first and fallback to vendor part number (VN) if GTIN mapping fails. For unmapped items, generate an exception report and avoid automatic acceptance until resolved.

Q: What are the common reasons Target rejects an 855?

Typical rejections occur for invalid envelope control numbers, SE segment count mismatches, missing mandatory segments like BAK or PO1, invalid partner IDs in ISA/GS, and invalid codes in PO1 qualifiers. Validate with 997/999 feedback and correct the specific segments listed in the functional acknowledgment.

Q: Do I need to include shipment schedule dates in the 855 for Target?

Include shipment schedule dates when they differ from the PO or when you propose new ship dates as part of a change. Target uses shipment dates to reconcile expected arrivals and OTIF performance. If your 855 includes schedule changes, ensure date format uses CCYYMMDD and is placed in the appropriate scheduling segment (SCH or DT within the loop).

Q: How often should I send 855 acknowledgments to Target?

Send 855 acknowledgments within the timeframe agreed during onboarding. Timely acknowledgments ensure accurate OTIF measurement and reduce chargeback risk. Use automated monitoring to ensure every inbound 850 receives an 855 within your SLA.

Final Thoughts and Best Practices

Implement a multi-layer validation approach: syntactic X12 validation, business-rule checks (PO matches, quantities, ship-to IDs), and SKU mapping verification. Archive original EDI files with control numbers for traceability. Use preflight validation tools during development and production; PlainEDI reduces manual errors and provides actionable error reports during upload and conversion: PlainEDI.

Remember to verify Target compliance updates on the vendor portal. This guide references compliance status as of 2025-12-14; always confirm current penalty amounts and program changes directly with Target before dispute escalation.

Ready to validate or convert a Target EDI 855? Upload your file to PlainEDI for delimiter detection, schema validation, and CSV conversion automation.