Target Edi 820

What This Is

This guide is a focused, practical reference for working with Target EDI 820 files — the X12 Payment Order/Remittance Advice transaction used to communicate payments and remittance details from Target to vendors. It explains why 820s are important for vendor finance and accounts receivable processes, how Target structures its 820s in practice, and how to reliably convert them into flat CSV files for posting to ERPs and accounting software.

The guide emphasizes real-world problems vendors encounter when processing Target 820s: incorrect delimiters, missing remittance line detail (RMR), inconsistent control numbers between ISA/GS/ST segments, and mapping issues that cause duplicate or missing invoices in vendor ledgers. You will get segment-level breakdowns, code examples with line-by-line explanations, CSV mapping examples, common error codes and proven fixes, and a step-by-step conversion workflow you can implement manually or automate with tools such as PlainEDI.

Who This Is For

This document is for EDI specialists, accounts receivable analysts, integration engineers, ERP implementers, and small-business vendors who receive Target 820s and need to parse, validate, and import payment and remittance data into accounting systems without reconciliation headaches.

Key Segments Explained

Below are the Target 820 segments you will see most often. Each explanation includes the critical elements to validate, typical pitfalls, and mapping guidance for CSV output.

• BPR — Beginning Segment for Payment Order/Remittance Advice

  What it is: Contains the payment method, amount, and currency. Key elements: BPR01 (Transaction Handling Code), BPR02 (Monetary Amount), BPR03 (Credit/Debit Flag), BPR04-BPR06 (Payment Method Details), and BPR16 (Date). Why it matters: BPR defines the check or ACH total you must reconcile to the sum of RMR lines. Target uses BPR to indicate ACH payment details or check numbers; validate BPR02 equals the total remitted.

• TRN — Trace

  What it is: Provides a trace/reference number for the payment and the payer-assigned reference. Key elements: TRN01 (Trace Type), TRN02 (Trace Number), TRN03 (Originating Company Reference). Why it matters: Use TRN02 as the check number or ACH trace when posting payment. Target populates TRN consistently for audit trails; mismatched or missing TRN values cause reconciliation errors in AR ledgers.

• N1 / N2 — Name and Additional Name Information

  What it is: Identifies payer and payee. Key elements: N1*PR commonly represents the payer (Target), and N1*PE represents the payee (vendor). Why it matters: Vendors map N1 elements to internal vendor IDs. If Target uses alternate tax IDs or GLNs in REF segments instead of standard vendor ID fields, map those values into your vendor master to avoid misapplied payments.

• ENT / RMR — Entity and Remittance Detail

  What it is: ENT starts an entity loop; RMR provides the invoice-level remittance details: invoice number, invoice date, applied amount, and adjustment amounts. Key RMR elements: RMR01 (Reference Identification Qualifier), RMR02 (Invoice Number), RMR03 (Invoice Date), RMR04 (Invoice Amount), RMR06 (Payment Amount). Why it matters: Most posting scripts rely on RMR02 to match invoices in the AR system. Target sometimes provides additional adjustment lines as separate RMR segments which must be aggregated per invoice before posting.

• REF / DTM — Reference and Date/Time

  What it is: REF supplies auxiliary references such as vendor invoice number types, check numbers, or remittance IDs. DTM carries dates relevant to the payment. Why it matters: Some accounting systems require specific date fields (transaction date vs. payment date). Target may put the payment date in BPR16 and the remittance date in a DTM segment; map both appropriately to your ERP.

Example EDI Snippet

ISA*00*          *00*          *ZZ*TARGET         *ZZ*VENDORID       *210101*1200*U*00401*000000905*0*P*>~
GS*RA*TARGET*VENDORID*20210101*1200*905*X*004010~
ST*820*0001~
BPR*C*1250.00*C*ACH*CTX*01*123456789*DA*987654321*151234567**01*20210101~
TRN*1*1234567890*TARGETREF~
N1*PR*TARGET STORES~~
N1*PE*VENDOR NAME*92*VENDORID~
ENT*1~
RMR*IV*INV-1001**250.00*0.00~
RMR*IV*INV-1002**1000.00*0.00~
SE*10*0001~
GE*1*905~
IEA*1*000000905~

Line-by-line explanation:

• ISA*...~ — Interchange header. Validate ISA13 (interchange control number) equals IEA02. Check ISA11 (component element separator) and ISA16 (segment terminator if present) for proper parsing.
• GS*RA*TARGET*VENDORID*20210101*1200*905*X*004010~ — Functional group header for remittance advice (RA). GS06 is the group control number; ensure GE01 equals GS06.
• ST*820*0001~ — Transaction set header. ST02 is the transaction set control number; SE segment later must match the number of segments and contain the same control number.
• BPR*C*1250.00*C*ACH*CTX*01*123456789*DA*987654321*151234567**01*20210101~ — BPR shows payment type (C = credit), payment amount $1250.00, ACH info: indicates Electronic payment with routing/account IDs. Map BPR02 to CSV PaymentAmount and TRN02 to Check/TraceNumber if BPR indicates check.
• TRN*1*1234567890*TARGETREF~ — Trace ID 1234567890; use as remittance reference or check number based on BPR03.
• N1*PR*TARGET STORES~ — Payer ID. Use to verify the file came from Target.
• N1*PE*VENDOR NAME*92*VENDORID~ — Payee vendor identification; REF qualifier 92 contains internal vendor ID—map to your vendor master.
• ENT*1~ — Start entity loop for remittance lines.
• RMR*IV*INV-1001**250.00*0.00~ — Remittance: invoice INV-1001, invoice amount 250.00. RMR field positions: qualifier, invoice number, invoice date (omitted here), invoice amount, adjustment amount. Aggregate RMR payment amounts to match BPR02.
• SE*10*0001~ — ST-SE trailer: segment count (10) and control number must match ST02.
• GE*1*905~ / IEA*1*000000905~ — Group and interchange trailers; validate counts and control numbers.

CSV Output Example

Below is an example conversion of the EDI 820 snippet into a CSV table suitable for ERP import.

Notes: The CSV repeats Payment-level fields (PaymentDate, PaymentAmount, PaymentMethod, TraceNumber) on each row for each invoice line. Some ERPs require a single payment header plus multiple detail lines; transform the CSV accordingly.

Step-by-Step Conversion Process

1. Detect and normalize delimiters
   1. Read the ISA segment to identify element separator (ISA01/ISA02 positions) and component element separator (ISA16). Confirm the segment terminator (commonly ~) by reading the end-of-segment character.
   2. If the file uses non-standard delimiters, normalize them to a canonical set (e.g., element separator *, subelement :, segment terminator ~) before parsing.
2. Validate interchange and group consistency
   1. Verify ISA13 equals IEA02. Validate GS06 equals GE02. Confirm ST02 equals SE02.
   2. Reject or flag files with control number mismatches. Use reading 997 functional acknowledgments and resolving 997 rejection codes patterns to handle returned acknowledgments.
3. Extract payment header data (BPR/TRN/N1)
   1. Parse BPR for PaymentAmount (BPR02), PaymentMethod (BPR03-BPR05), and PaymentDate (BPR16).
   2. Parse TRN for lookup keys: TraceNumber (TRN02) and OriginatorRef (TRN03).
   3. Confirm N1*PR equals TARGET or the expected payer ID; map N1*PE/REF qualifiers to vendor identifiers in your vendor master file.
4. Parse remittance detail loops and aggregate amounts
   1. For each ENT loop, extract RMR lines: invoice number, invoice date, invoice amount, payment amount, adjustment codes.
   2. Aggregate payment amounts per invoice; compute total applied across all RMR lines. Confirm that the aggregated total equals BPR02. If mismatch occurs, mark file for manual review and provide diagnostics (sum of RMR vs. BPR02, missing RMR entries, multiple entity loops).
5. Transform to CSV and reconcile
   1. Map fields into your CSV template. Include both payment-level fields (e.g., PaymentMethod, TraceNumber) and invoice-level fields for each row.
   2. Run reconciliation: ensure CSV total payment amount equals BPR02 and invoice totals match vendor ledger balances. Flag any invoice numbers not found in the vendor AR for manual resolution.
6. Validate against Target requirements and generate acknowledgments
   1. Target enforces remittance and payment rules. For compliance validation, cross-check file structure against Target's vendor spec. Record and resolve any variances before posting.
   2. When your system accepts the 820, generate necessary 997 functional acknowledgments. Use reading 997 functional acknowledgments for interpretation and resolving 997 rejection codes for corrections.
7. Automate and log with PlainEDI
   1. Upload Target 820 files to PlainEDI to run delimiter normalization, schema validation, and automatic 820-to-CSV conversion. PlainEDI validates totals, checks segment consistency, and produces diagnostic reports that reduce time-to-posting.
   2. Store audit logs, raw EDI, and converted CSV in your archive for audit and dispute resolution.

Common Errors and Fixes

Below are common errors when processing Target 820s, the typical reason they occur, and step-by-step fixes.

• Error: ISA/IEA control number mismatch (IEA02 != ISA13). Why: File truncated or interchange header modified. Fix: Reject file and request resend. If automated, log and halt posting. Use validation before sending to catch this prior to posting.
• Error: ST/SE segment count mismatch (SE01 incorrect). Why: Missing or extra segment lines during transfer or manual editing. Fix: Recalculate segment count by counting segments between ST and SE; correct SE01 or request corrected file. Use deterministic parsing as described in x12 parser comparison.
• Error: BPR total does not equal sum of RMR applied amounts. Why: Target includes adjustments or summary-level withheld amounts in extra segments, or file truncated. Fix: Recompute totals including adjustment segments (ADJ/RMR adjustment element). If still mismatched, flag for manual reconciliation and request remittance clarification from Target vendor support. PlainEDI validation reports these mismatches automatically when uploaded to PlainEDI.
• Error: Missing invoice numbers in RMR lines (RMR02 empty). Why: Target may use alternative identifiers in REF segments. Fix: Map REF qualifiers (e.g., REF*PO, REF*IV) to invoice numbers or vendor invoice references. Update mapping rules so REF values populate invoice lookup keys.
• Error: Invalid or unexpected delimiters cause parser failure. Why: EDI file stored or transferred through systems that replace characters (e.g., replacing ~ with newline). Fix: Inspect ISA segment to detect separators, normalize before parse. If file corruption is systemic, update transport or SFTP transfer settings to preserve binary integrity. See Excel won't open EDI file solutions for handling common representation problems.
• Error: Vendor ID mismatch — N1/REF does not match vendor master. Why: Target may send legacy vendor IDs or alternate qualifiers. Fix: Create alias table in your vendor master mapping Target vendor IDs (from REF with qualifier 92 or N1*PE) to your internal vendor numbers. Use weekly sync of vendor reference data against Target vendor portal.

Related Resources

• understanding EDI 820 payment remittances
• reading 997 functional acknowledgments
• how to validate EDI files before sending
• edi-to-csv-for-small-business-vendors
• integrating-edi-with-erp-systems

FAQ Section

Q: What is the primary purpose of a Target EDI 820?

The Target EDI 820 is a Payment Order/Remittance Advice transaction that communicates payment details (ACH or check) and remittance information (invoice-level applied amounts) to vendors. It provides the payment amount, payment method, trace number, and remittance lines required for accounts receivable reconciliation.

Q: How do I map BPR and TRN fields into my accounting system?

Map BPR02 to PaymentAmount, BPR03 and surrounding elements to PaymentMethod and bank routing/account info when ACH is used, and TRN02 to TraceNumber or CheckNumber. Include DTM or BPR16 for PaymentDate. If your ERP requires a header and detail format, create one header per BPR/TRN and multiple detail lines using RMR entries.

Q: Why does my BPR total not match the sum of RMR applied amounts?

Common causes: Target uses separate adjustment segments for discounts or chargebacks that are not represented within RMR applied amounts, file truncation, or misplaced amounts in REF segments. Recalculate including ADJ entries and check for truncated or missing RMR segments. Use validation tools such as PlainEDI to automatically detect mismatches.

Q: What should I check when a Target 820 is rejected by my EDI system?

Check ISA/IEA and GS/GE control numbers for consistency, ensure ST/SE segment counts match, confirm delimiter configuration, and verify required segments (BPR, TRN, at least one RMR) are present. If you receive a 997 rejection, inspect AK2/AK3/AK4 elements for segment and element-level error details and correct the original 820 accordingly.

Q: Does Target charge penalties for remittance or ASN issues?

Retailers, including Target, enforce penalties for compliance failures such as OTIF, ASN accuracy, and remittance problems. Effective date: 2025-12-14. Verify specific penalty amounts and thresholds through Target's vendor portal for current rates and program changes. Implement automated validation to reduce penalty risk.

Q: How do I handle RMR lines without invoice numbers?

If RMR02 is empty, check REF segments inside the same ENT loop for alternative invoice identifiers (qualifiers like REF*IV or vendor invoice references). Update your mapping rules to use REF when RMR is missing, and maintain a tolerance report for manual resolution of unmapped lines.

Q: Can I automate Target 820 validation to reduce manual reconciliation?

Yes. Automate delimiter normalization, schema validation, total reconciliation (BPR vs aggregated RMR), vendor ID mapping, and CSV generation. Use tools that provide diagnostics and audit logs. PlainEDI offers validation features that detect mismatches, missing segments, and mapping anomalies before posting.

Q: What are the best reconciliation checks to perform before importing an 820 into ERP?

Validate ISA/GS/ST control numbers, confirm BPR02 equals aggregated RMR applied amounts, ensure each RMR invoice number matches a vendor AR invoice, compare BPR payment date against bank deposit dates, and produce a variance report for any unapplied amounts or unrecognized invoice numbers.

Final Notes and Call to Action

Processing Target EDI 820 files reliably requires strict delimiter handling, control number validation, accurate mapping of RMR/REF values to your vendor ledger, and reconciliation between BPR totals and invoice-level details. Use the segment checks and mapping patterns in this guide to standardize your conversion pipeline, reduce manual work, and prevent penalties for compliance failures. Effective date for general Target program guidance referenced in this guide: 2025-12-14; verify any retailer-specific penalties or threshold changes on Target's vendor portal.

To automate validation, diagnostics, and EDI-to-CSV conversion for Target 820 files, upload your files now to PlainEDI for instant processing and error reports that accelerate posting and reconciliation.