Target Edi 810

What This Is

This guide is a comprehensive technical walkthrough for Target EDI 810 (Invoice) files. It focuses on how Target formats X12 810 invoices, what segments you must pay attention to for accurate posting and reconciliation, and how to convert those EDI invoices to CSV for downstream systems such as QuickBooks, NetSuite, or custom ERPs.

The guide includes real EDI snippets with line-by-line explanations, CSV mapping examples, a complete step-by-step conversion process, and a troubleshooting section that explains why errors occur, not just how to fix them. You’ll also get practical advice for avoiding Target compliance penalties (last updated: 2025-12-14) and instructions for using PlainEDI validation features that stop common issues before files are sent.

Who This Is For

This is for EDI developers, integration engineers, accounts payable specialists, and third-party logistics (3PL) teams who receive Target vendor 810 invoices or build pipelines to convert and post them into accounting systems. It assumes basic X12 familiarity (ISA/GS/ST/SE) and focuses on actionable steps and code-level examples.

Key Segments Explained

Target 810 invoices follow standard X12 810 structure. Below are the segments you must understand and validate for accurate conversion and compliance.

• ISA/GS/ST (Envelope headers) — These control envelopes contain authorization, interchange control number, sender/receiver IDs, and delimiters. If the ISA control number, GS/GE counts, or ST/SE segment counts are wrong, many EDI VANs and retailers will reject the file before document-level validation.
• BIG (Beginning Segment for Invoice) — Contains invoice number and date and often the purchase order reference. Example elements: BIG02 = Invoice Number, BIG03 = Invoice Date. This is the primary key for reconciliation and must match the vendor’s AP system.
• N1 / N3 / N4 (Name and Address) — Identifies the invoice billed-to and shipped-to parties. The N1 qualifier (e.g., ST, BT) determines whether the party is the ship-to or bill-to. Target requires correct qualifier codes; mis-qualifying addresses causes reconciliation and remittance issues.
• IT1 (Baseline Item Data) — Line-level detail including quantity, unit of measure (UOM), unit price, and item identifier (UPC, GTIN, or vendor item). For Target, the IT1 must include the exact Target item identifier in the correct element (commonly IT101-IT107 or via REF segments for alternate IDs).
• TDS (Total Monetary Value Summary) — Specifies the invoice total in cents. TDS is required and must match the sum of line totals plus allowances/charges and tax. A mismatch triggers financial reconciliation failures or chargebacks.
• CTT (Transaction Totals) — Contains the count of line items and total quantity; used to validate that the number of IT1 segments equals the count declared. Discrepancies often lead to automated rejections or manual investigations.
• SAC / REF / CUR (Allowances/Charges, References, Currency) — SAC carries discounts, promotions, freight, or other charges. REF carries reference numbers such as the vendor’s invoice control or remittance ID. CUR identifies currency; missing or incorrect currency can cause posting errors in ERPs.

Example EDI Snippet

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*TARGETID       *201214*1200*U*00401*000000905*0*P*:~
GS*IN*SENDERID*TARGETID*20251214*1200*1*X*004010~
ST*810*0001~
BIG*20251214*INV-100345*20251210*PO-98765**AB~
REF*IA*INVCTRL123~
N1*ST*TARGET STORE 123*92*12345~
IT1*1*12*EA*4.99**VP*012345678905*UP*012345678905~
IT1*2*5*EA*9.99**VP*012345678906*UP*012345678906~
TDS*89940~
CTT*2*17~
SE*11*0001~
GE*1*1~
IEA*1*000000905~

Line-by-line explanation:

• ISA*...~ — ISA interchange header. Elements include authorization info, sender/receiver IDs, date/time and control number (ISA13=000000905).
• GS*IN*...~ — GS functional group for invoices, includes group control number 1.
• ST*810*0001~ — Start of 810 transaction with control number 0001.
• BIG*20251214*INV-100345*20251210*PO-98765**AB~ — BIG segment: invoice date 2025-12-14, invoice number INV-100345, invoice creation date 2025-12-10, PO number PO-98765, invoice type AB.
• REF*IA*INVCTRL123~ — Reference: invoice control ID for vendor systems.
• N1*ST*TARGET STORE 123*92*12345~ — Ship-to: qualifier ST, name, identification code qualifier 92 and ID 12345 (Target location).
• IT1*1*12*EA*4.99**VP*012345678905*UP*012345678905~ — Line 1: line number 1, qty 12, UOM EA, price 4.99, vendor part number qualifier VP and value, UPC via UP.
• TDS*89940~ — Invoice total: cents value 89940 = $899.40 (sum lines plus tax/charges).
• CTT*2*17~ — 2 line items with total quantity 17.
• SE*11*0001~ — ST/SE segment count (should equal number of segments inside transaction +1).
• GE/IEA — End of group and interchange envelopes.

CSV Output Example

Step-by-Step Conversion Process

1. Ingest and detect delimiters
   1. Read the first 106 characters to parse the ISA header. Identify element separator (char at position 4), component separator (ISA16), and segment terminator (the character immediately following ISA16 sequence). Incorrect delimiter detection will corrupt the parse.
   2. Use a deterministic parser to split by segment terminator, then split elements by element separator. Libraries often fail on non-printable terminators; log the raw bytes for debugging.
2. Validate envelopes and control numbers
   1. Check ISA13 equals interchange control in your tracking system; confirm GS06 equals group control number and that IEA02 matches ISA13 expectations.
   2. Confirm ST02 matches SE02 and that the segment count in SE01 equals actual segments between ST and SE inclusive.
3. Parse and normalize key segments
   1. Extract BIG02 as invoice number and BIG03 as invoice date. Normalize date formats to YYYY-MM-DD for CSV.
   2. Capture BIG04 or REF for PO number. If PO is missing, flag as a compliance error for Target processing.
4. Process line items and monetary math
   1. For each IT1 compute LineTotal = Quantity * UnitPrice. Handle implied decimal conventions for prices if vendor sends cents in integer format.
   2. Aggregate the line totals, add SAC allowances/charges and taxes, then confirm TDS equals the computed invoice total. If mismatch, flag and attach calculation report for AP review.
5. Build CSV rows and enrich data
   1. Map each IT1 to a CSV row using columns from the CSV example. Include header-level fields (InvoiceNumber, InvoiceDate, PO_Number) on each row.
   2. Enrich SKU fields with vendor part mappings if the VP alternative ID is supplied; otherwise, use UPC or GTIN from IT1.
6. Validation and reconciliation
   1. Run structural validations (counts, control numbers), business rule checks (TDS matching computed totals, mandatory N1 qualifiers), and ledger rules (currency matches vendor account currency).
   2. Generate exceptions report for manual review and a clean CSV file for automatic posting if all checks pass. Use PlainEDI to automatically run many of these validations and create error reports.
7. Delivery and archiving
   1. Save raw EDI, parsed JSON, and final CSV to secure storage with unique filenames containing ISA/GS/ST identifiers. Keep audit metadata: timestamp, parser user, and validation results.
   2. Send acknowledgments or 997 functional ACKs if required. If using an automated VAN or AS2, confirm the transporter received the file.

Common Errors and Fixes

• Error: ISA control number mismatch — Symptom: downstream systems reject the interchange. Fix: Verify ISA13 and IEA02 control numbers match and increment control numbers per interchange. Use logging to detect duplicate ISA13 values. If you use PlainEDI, enable interchange duplicate detection.
• Error: ST/SE segment count error — Symptom: SE01 value does not equal actual segments + 1. Fix: Recalculate segment count after assembly and set SE01 to that value prior to transmission. Use unit tests in your EDI generator to fail builds where counts are off.
• Error: TDS mismatch (invoice total mismatch) — Symptom: Vendor sum doesn't match TDS. Why: rounding differences, missing SAC charges or tax. Fix: Recompute line totals with correct decimal precision; include SAC and TAX elements before validating TDS. If rounding rules differ, normalize to cents for integer math and present adjustments as SAC with explanatory REF.
• Error: Missing or wrong PO number (BIG04) — Symptom: Target cannot match invoice to PO. Fix: Ensure BIG04 or REF with correct qualifier (e.g., REF*PO*) is set. If your ERP requires PO lookup, implement a pre-validation that rejects invoices without PO for Target trading partner and notifies vendor.
• Error: Incorrect N1 qualifier (ship-to vs bill-to) — Symptom: Remittance address mismatch. Fix: Confirm N1 qualifiers BT for bill-to and ST for ship-to. Ensure associated N3/N4 address segments follow the N1 segment. Target enforces accurate qualifiers—fix mapping in your EDI generation layer.
• Error: Currency missing or wrong (CUR) — Symptom: ERP posts in default currency leading to incorrect values. Fix: Set CUR segment to the correct ISO currency code (e.g., USD). Validate vendor account currency prior to conversion.
• Error: CTT line count mismatch — Symptom: CTT count doesn't equal number of IT1 segments. Fix: Count IT1 segments and include aggregated quantity in CTT. Recompute CTT as final step before writing SE segment.

Related Resources

• edi-810-invoice-processing — Deep-dive on 810 structure and accounting posting rules.
• target-edi-compliance-requirements — Target compliance checklist and program requirements.
• how-to-validate-edi-files-before-sending — Pre-send validation steps to avoid rejections and chargebacks.
• reading-997-functional-acknowledgments — Handling and interpreting 997 ACKs for invoice acceptance/rejection.
• understanding-edi-x12-delimiters-and-structure — Technical refresher for ISA-level parsing and delimiter handling.
• converting-edi-files-for-accounting-software — Practical conversion tips and mapping patterns for QuickBooks and ERP systems.

Case Study — Resolving a Real-World TDS Mismatch

Scenario: A 3PL receiving Target 810 files flagged numerous vendor invoices where ledger totals did not equal TDS. Investigation revealed vendors used vendor-level rounding (round each line to dollars) while the 3PL aggregated raw extended prices then rounded totals differently. This caused a $0.30–$2.00 difference on large invoices and triggered manual holds at Target.

Resolution steps performed:

1. Normalized prices to cents and computed totals with integer math to remove floating point variance.
2. Detected when vendor rounding policies differed and created a mapping rule set per vendor (use vendor profile to apply line-level rounding before aggregation).
3. When discrepancy persisted, inserted an explanatory REF segment REF*ADJ*ROUNDRULE and communicated the rounding method to Target remittance team as required.
4. Automated the check in the EDI pipeline: if computed total ≠ TDS then create an exception CSV and block auto-posting until manual verification.

Outcome: The automated validation cut manual investigations by 80% and eliminated chargebacks associated with accidental rounding differences.

Best Practices and Prevention

• Always validate ISA/GS/ST counts and control numbers as a first step.
• Normalize date formats and use integer cents arithmetic to avoid floating point rounding errors.
• Keep vendor-specific mapping profiles (e.g., which element carries UPC vs GTIN vs vendor part number) to correctly populate SKU in CSV.
• Archive raw EDI, parsed data, and final CSV for auditability and dispute resolution; include full validation report with each invoice.
• Use PlainEDI to run pre-send validations, duplicate detection, TDS checks, and generate human-readable error reports.

Common Target Compliance Notes

Target enforces invoice and ASN accuracy and applies program penalties for non-compliance. This guidance references Target program changes last updated on 2025-12-14. Verify current requirements with Target Vendor Portal for the most recent penalty amounts and thresholds. Typical compliance areas include timely invoice submission, ASN accuracy, correct ship-to locations, and invoice-to-PO matching.

FAQ

Q: What is the most critical segment in a Target 810?

The most critical segment is BIG for invoice identification (invoice number and date) and TDS for invoice total validation. BIG links the invoice to your AP system and to the purchase order referenced; TDS is the monetary total your accounting system reconciles against.

Q: How should I handle decimal precision differences between vendors and my ERP?

Normalize all monetary values to integer cents during parsing and perform arithmetic with integer math to avoid floating point rounding errors. Apply vendor-specific rounding rules if the vendor explicitly rounds at line level, and record the applied rounding method in a REF or note field.

Q: What causes ST/SE segment count errors and how can I fix them?

ST/SE segment count errors occur when SE01 does not equal the actual number of segments within ST and SE inclusive. Fix by recomputing the count after fully assembling the transaction and writing the correct SE01 before transmission. Use unit tests to ensure your EDI generator increments counts correctly during development.

Q: Can I automatically post Target 810 data to my accounting system?

Yes, but only after running strict validations: envelope control checks, BIG and PO matching, TDS verification, currency confirmation, and N1 qualifier checks. Automate posting for invoices that pass all checks and route exceptions to AP for manual review. Tools like PlainEDI provide automated validation and CSV conversion templates to streamline this workflow.

Q: What do I do if I get a 997 functional acknowledgment rejection?

First, read the 997 to identify the rejection codes and segments referenced. Common causes include invalid syntax (ISA/GS problems), missing required segments, or incorrect data element formats. Use a 997 reader to extract the rejection codes and then cross-reference with the transaction to correct the segment or element indicated. For guidance, see reading-997-functional-acknowledgments.

Q: How do I map Target item identifiers in IT1 to my SKU system?

Target can supply GTIN/UPC or vendor part numbers. Build vendor-specific mapping rules: prefer Target’s item identifier (UP/GTIN) if present in IT1 or REF segments, and fall back to vendor part numbers with a lookup table in your master data. Maintain a cache of mappings and refresh with Target-provided catalog updates.

Q: What typical penalties does Target enforce for EDI non-compliance?

Retailers like Target impose penalties for OTIF failures, incorrect ASN or invoice data, and late/missing documents. This guide references compliance updates last updated 2025-12-14. Verify current penalty amounts and thresholds in the Target Vendor Portal. General best practice: fix data quality issues proactively to avoid chargebacks.

Q: What validation features should I enable in my EDI tool?

Enable ISA/GS/ST control validation, delimiter detection, ST/SE and GS/GE counts, TDS and CTT reconciliations, mandatory segment checks (BIG, N1, IT1 presence), currency checks, and vendor profile rule enforcement. PlainEDI offers built-in validations for many of these checks and produces clear error reports for remediation.

Call to Action

Ready to validate and convert your Target EDI 810 files into production-ready CSVs? Upload a sample file to PlainEDI for automated parsing, validation, and CSV conversion. PlainEDI will run envelope checks, TDS reconciliation, and produce human-readable error reports so you can fix issues before posting to your accounting system.