Amazon Edi 810

What This Is

This guide dives deep into the X12 810 invoice as used for Amazon EDI invoicing. The Amazon EDI 810 is the electronic invoice used by suppliers and vendors to bill Amazon for goods and services. It follows the X12 810 transaction set structure but includes Amazon-specific expectations such as required segments, partner-specific element values, and enforcement rules. This guide focuses on practical parsing, conversion to CSV for accounting or ERP ingestion, and troubleshooting the common errors that cause rejections or payment delays.

You'll get line-by-line parsing examples, multiple real-world scenarios, and conversion patterns used by mid-market vendors and 3PLs that trade with Amazon. The content highlights why errors occur (not just how to fix them), explains EDI control structures (ISA/GS/ST), and shows validation checks you should implement. PlainEDI is referenced with practical validation features you can enable to catch issues before sending or after receiving an 810.

Who This Is For

This guide is for EDI developers, integration engineers, accounts payable specialists, and vendor operations teams who send or process Amazon EDI 810 invoices, or who convert Amazon 810s to CSV/ERP formats. If you support vendor invoicing to Amazon Vendor Central, this guide provides the operational detail and troubleshooting steps you need.

Key Segments Explained

Below are the key 810 segments you will encounter in Amazon invoices, with practical details on purpose, common pitfalls, and exact data expectations.

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

  The ISA (Interchange Control Header) and GS (Functional Group Header) wrap the transaction. ST begins the 810. Common issues: incorrect control numbers (ISA13/GS06/ST02), wrong delimiters, and mismatched counts in SE/GE/IEA. Always verify control numbers match across IEA/ISA and SE/GS.

• BIG (Beginning Segment for Invoice)

  BIG contains the invoice date and invoice number and is Amazon-critical. Amazon expects a unique invoice number (BIG02) and a date format CCYYMMDD. Missing or duplicate invoice numbers cause payment delays and rejection by the accounts payable automation.

• REF (Reference Identification)

  REF segments carry purchase order references (REF*PO*), vendor reference IDs, or contract numbers. Amazon often requires a REF qualifier for the PO number (REF*PO) or uses REF*IA for invoice adjustments in some flows. A mismatched PO in REF vs the PO in IT1 causes line-level reconciliation issues.

• IT1 (Baseline Item Data)

  IT1 is the line-item segment that includes quantity, unit price, and product identifiers (UPC/GTIN/ASIN). Amazon relies on exact matching between the PO line number and the IT1 qualifier. Common errors include inverted quantity/price or missing product identifiers; these produce reconciliation mismatches with the PO and can create chargebacks.

• TDS, AMT, TXI, SAC (Totals, Amounts, Tax, Charges)

  TDS is the total monetary amount for the invoice (in cents for standard X12). AMT and SAC communicate allowances, charges, and additional monetary adjustments. TXI is used for taxes. Incorrect math between IT1 line totals and TDS causes automated rejections or exception queues.

• N1/N3/N4 (Name and Address)

  N1 identifies Bill-to and Remit-to parties. For Amazon, remit-to identification and the correct vendor ID in N1*BT or N1*RE are critical for payment routing. Missing remit-to details or wrong vendor IDs will delay payment until manual resolution.

Example EDI Snippet

ISA*00*          *00*          *12*SENDERID      *12*AMAZONID      *210101*1253*U*00401*000000905*0*T*:
GS*IN*SENDERID*AMAZONID*20210101*1253*905*X*004010
ST*810*0001
BIG*20210101*INV12345**PO98765*20201231
REF*IA*ADJ987
N1*BT*Amazon.com
N3*410 Terry Ave
N4*Seattle*WA*98109
REF*PO*PO98765
IT1*1*10*EA*25.00**BP*1234567890123*VP*ASIN123
IT1*2*5*EA*15.00**BP*9876543210987*VP*ASIN456
TDS*325000
TXI*TX*26000
SAC*C*G830***5000
SE*14*0001
GE*1*905
IEA*1*000000905

Line-by-line explanation:

• ISA* envelope with sender and receiver IDs; ISA13=000000905 is the interchange control number.
• GS*IN* functional group for invoices; GS06=905 must match ISA13 in control pairing rules.
• ST*810*0001 begins the 810, transaction set control number 0001.
• BIG*20210101*INV12345**PO98765*20201231 - invoice date, invoice number, and related PO and PO date.
• REF*IA*ADJ987 - reference indicating an adjustment identifier.
• N1*BT*Amazon.com - bill-to name.
• IT1*1*10*EA*25.00**BP*1234567890123*VP*ASIN123 - line 1: quantity 10, unit price 25.00, buyer part identifiers.
• TDS*325000 - total invoice amount in cents meaning $3,250.00. (Standard X12 TDS is in cents.)
• TXI*TX*26000 - tax amount in cents: $260.00.
• SAC*C*G830***5000 - charges/allowances (e.g., freight, $50.00 in cents).
• SE, GE, IEA close the transaction, group, and interchange.

CSV Output Example

Below is a practical CSV output example showing how you should map the EDI 810 fields to flat CSV rows for ERP ingestion. Each invoice line becomes a row; header and totals are separate rows if required by your accounting system.

Step-by-Step Conversion Process

1. Validate the interchange and delimiters
   1. Read the first 106 characters for ISA to detect delimiters (ISA16 repeats the component element separator).
   2. Verify ISA/IEA control number pair and GS/GE pair. Reject if mismatched.
   3. PlainEDI tip: enable control-number validation to auto-fail mispaired envelopes. See PlainEDI.
2. Parse header segments and build invoice metadata
   1. Extract BIG for invoice number and date.
   2. Extract REF segments for PO references and link to the purchase order.
   3. Check for duplicate invoice numbers against stored records to avoid double billing.
3. Parse and validate line items
   1. For each IT1, extract line count, quantity, unit price, and product identifiers (BP/VP/IT1 qualifiers).
   2. Compute line totals using precise decimal arithmetic (no floating-point rounding errors) and compare to invoice line totals if present.
   3. Verify the PO line references match the vendor’s PO; if not, route to exception handling with a descriptive rejection code.
4. Calculate totals and reconcile
   1. Sum line totals and allowances/charges to compute expected TDS.
   2. Compare computed total to transmitted TDS and check tax TXI and charges SAC.
   3. If differences exist, apply a tolerance policy: either reject (recommended) or create a variance record for manual review.
5. Transform to CSV for ERP
   1. Map segments to your ERP schema; create header rows and line rows as shown in the CSV example.
   2. Normalize dates to ISO YYYY-MM-DD and amounts to decimal dollars (not cents) unless ERP expects cents.
   3. Include audit columns: ISA control, GS control, ST control, parsing timestamp for traceability.
6. Run validation and automated acknowledgments
   1. Generate a 997 functional acknowledgment for acceptance or detailed 824 if errors need partner notification.
   2. PlainEDI tip: use pre-send validation to detect missing mandatory segments and auto-generate a human-readable report. Use PlainEDI to run both syntactic and semantic checks in one pass.
7. Exception handling and reconciliation
   1. Route exceptions to a queue with descriptive codes and recommended fixes; annotate with links to the original EDI snippet for quick resolution.
   2. Maintain an audit trail in your database for dispute resolution with Amazon Vendor Central.

Common Errors and Fixes

Below are the most common Amazon 810 issues, error-like symptoms you will see in your processing logs or in 997 acknowledgments, why they happen, and precise fixes.

• Error: SE segment count mismatch (Runtime Code: SE-MISMATCH)

  Cause: The SE segment count does not equal the actual number of segments between ST and SE. Fix: Recompute the segment count at the end of ST..SE and update SE01; ensure no trailing line breaks add phantom segments.

• Error: ISA/IEA control numbers not matching (Runtime Code: ISA-CTRL)

  Cause: ISA13 does not match IEA02 or GS06 does not match GE02 due to manual edits or multi-system envelope assembly. Fix: Ensure your EDI VAN/AS2 stack preserves original ISA/IEA control numbers. Use PlainEDI control validation to fail on mismatch before further processing. See PlainEDI.

• Error: Missing or duplicate BIG invoice number (Runtime Code: BIG-DUP/MISS)

  Cause: BIG02 missing or duplicate across processed invoices. Fix: Enforce uniqueness constraint at intake; if duplicate, verify vendor intent (adjustment vs duplicate). Include a rejection reason back to the sender and require a new invoice number for resubmission.

• Error: TDS total mismatch (Runtime Code: TDS-MATH)

  Cause: Line-level totals, taxes, or charges do not sum to TDS due to rounding errors or omitted SAC/TXI. Fix: Recalculate using integer math (cents) and compare. If the vendor provided incorrect TDS, produce a detailed report showing the line-by-line math for vendor correction.

• Error: Invalid N1 qualifier or missing remit-to (Runtime Code: N1-MISSING)

  Cause: Missing N1*RE or wrong remit-to ID for payment routing. Fix: Validate N1 qualifiers against Amazon's required vendor remit IDs. If missing, request a corrected 810 or map payment route using a maintained vendor remit table.

• Error: PO number mismatch between REF and IT1 (Runtime Code: PO-MISMATCH)

  Cause: REF*PO has a different PO than the IT1 references or PO number absent on the PO line. Fix: Cross-check REF PO against IT1 references and the PO master. If mismatch, flag for manual reconciliation and reject until vendor corrects the PO reference.

• Error: Missing product ID qualifiers (Runtime Code: IT1-ID)

  Cause: IT1 missing BP/VP/UP identifiers or incorrect qualifier. Fix: Require at least one product identifier (BP for buyer part, VP for vendor part). Use a mapping table to translate ASINs/GTINs as needed.

Related Resources

Use these related guides to expand your implementation and troubleshooting knowledge. They contain complementary details on POs, ASNs, and acknowledgments used with Amazon EDI.

• amazon-edi-850 — How Amazon purchase orders are formatted (helps reconcile REF/PO)
• amazon-edi-855 — Purchase order acknowledgment patterns you should expect
• amazon-edi-856 — ASNs and how they must align with 810 lines for receiving and invoicing
• how-to-parse-amazon-edi-invoice-files — In-depth parsing strategies and examples
• reading-997-functional-acknowledgments — Understanding 997s so you can interpret accept/reject statuses
• resolving-edi-997-rejection-codes — Practical steps when you receive 997 rejections
• converting-edi-files-for-accounting-software — Mapping patterns for QuickBooks, NetSuite, and SAP
• plainedi-vs-full-edi-software — How PlainEDI fits into validation and lightweight EDI workflows

FAQ Section

Q: What exact elements in BIG are required for Amazon 810?

Amazon requires the invoice number (BIG02) and invoice date (BIG01). Include related PO references using REF*PO and ensure the invoice number is unique per vendor to avoid duplicate payment processing.

Q: How should I represent the TDS total in the 810?

TDS is represented in cents per the X12 standard (an integer). Many ERPs expect dollars with decimals; convert TDS by dividing by 100 when mapping to CSV/ERP. Always verify the expected format in your downstream system.

Q: What causes a 997 rejection for an 810?

997 rejections usually reflect syntactic issues (invalid segment order, missing mandatory segments) or control envelope problems (ISA/GS mismatches). For semantic errors (e.g., TDS mismatch), you may receive a 997 acceptance but an application-level rejection later. Read the 997 detail segments to identify rejection reasons and refer to the 997 guide for decoding.

Q: Should I include ASIN or UPC in the IT1 segment?

Include the identifier Amazon requires for the PO (ASIN is often used via VP qualifier). Always provide at least one standard product ID (GTIN/UPC) with correct qualifiers to ensure matching with the PO. If Amazon's PO uses ASINs, include ASIN with the VP qualifier.

Q: What tolerance should I use for rounding differences between computed totals and TDS?

Use integer cent math to eliminate floating-point rounding issues. If your business accepts minor variances, define a tolerance policy in your integration layer (e.g., $0.01) and document exceptions for manual review. For Amazon, prefer strict reconciliation and reject if totals differ to avoid payment disputes.

Q: How do I handle invoice adjustments or credit memos?

Send an 810 with REF qualifiers indicating the adjustment reason (e.g., REF*IA). Include negative line quantities or negative amounts as per X12 semantics, and ensure the invoice number and references map to the original invoice. Keep a clear note in NTE or REF for audit trails.

Q: What validation features should I enable on intake to prevent common errors?

Enable delimiter detection, ISA/GS/SE/IEA control number verification, required-segment checks (BIG, IT1, TDS), numeric and date format validation, and totals reconciliation (line totals vs TDS). PlainEDI provides these checks and can auto-generate human-readable validation reports during intake. Link: PlainEDI.

Q: Where can I verify Amazon-specific invoicing rules and penalties?

Verify Amazon Vendor Central for the latest invoicing rules and penalty policies. Amazon enforces chargebacks and vendor performance metrics (Last Updated: 2025-12-28). Verify current requirements with the Amazon Vendor Central portal as rules change over time.

Final Notes and CTA

Processing Amazon EDI 810 invoices reliably requires strict envelope validation, precise line-level math, and supplier-specific rules for identifiers like ASIN/UPC. Use structured validation and automated exception handling to reduce manual intervention and speed payment cycles. PlainEDI helps by running both syntactic X12 checks and semantic business-rules validation before invoices are forwarded to your ERP; enable control number checks, mandatory segment enforcement, and totals reconciliation in your PlainEDI setup.

Ready to validate and convert your Amazon 810s now? Upload a sample file and run validation using PlainEDI.