Amazon Edi 820

What This Is

The Amazon EDI 820 is the X12 remittance advice/payment order transaction used to communicate payment information from Amazon to its suppliers. An 820 contains the payment amount and the remittance details that map payments to specific invoices or open items, typically using segments such as BPR, TRN, N1, and RMR. For Amazon vendors, correctly interpreting the 820 is essential to reconcile accounts receivable and post payments into accounting or ERP systems.

This guide provides actionable, technical instructions for parsing Amazon EDI 820 files, extracting the fields you need, transforming them into CSV, and resolving the typical validation and mapping errors that cause reconciliation mismatches. You will get multiple code examples (realistic 820 snippets), a CSV mapping example, a conversion workflow, and explicit troubleshooting steps designed for EDI analysts, developers, and AP/AR teams.

Who This Is For

This guide is for EDI analysts, integration engineers, accounts receivable staff, and ERP integrators supporting Amazon vendor operations who need to convert, validate and reconcile incoming Amazon EDI 820 files into accounting systems.

Key Segments Explained

• BPR — Beginning Segment for Payment Order/Remittance Advice

  The BPR segment contains the payment amount, payment method (ACH, check), and effective payment date. For Amazon, BPR01 denotes the transaction handling code (e.g., 'C' for payment), BPR02 is the payment amount, BPR03-BPR05 indicate payment method and bank routing. BPR errors are the most common cause of misapplied payments because a missing or malformed amount prevents posting.

• TRN — Reassociation Trace Number

  TRN provides a unique trace for the payment (e.g., check number or ACH trace). TRN02 typically carries the payer trace number. Duplicate or missing TRN values cause duplicate posting prevention logic in ERPs to fail or incorrectly suppress entries.

• N1 — Name

  N1 segments identify payer and payee. For the 820, you will typically find an N1*PR (Payer) and N1*PE (Payee) pair. Elements N101 (entity identifier code), N102 (name), and N103 (ID code qualifier) plus N104 (ID) are used to match vendor IDs in your AP master file. If your system expects a different ID qualifier (e.g., DUNS vs. Vendor Code), you must map qualifiers correctly.

• RMR — Remittance Advice Accounts Receivable Open Item Reference

  RMR is the core segment that maps payments to invoice numbers and applied amounts. RMR01 identifies the reference qualifier (usually 'IV' for invoice), RMR02 is the invoice number, RMR03 is the invoice date, and RMR04 or nested elements indicate the payment amount applied to that invoice. Missing RMR entries mean payments are unapplied and can create unapplied cash.

• REF & DTM — Reference and Date

  REF segments frequently carry the customer purchase order or internal reference numbers and sometimes the check number qualifier (e.g., REF*CK). DTM gives additional dates (posting date, invoice date). Map these to your ERP's date fields to preserve accurate aging.

Example EDI Snippet

ISA*00*          *00*          *ZZ*AMAZON         *ZZ*VENDORID       *210328*1700*U*00401*000000905*0*P*:~
GS*RA*AMAZON*VENDORID*20210328*1700*905*X*004010~
ST*820*0001~
BPR*C*1500.00*C*CHK************20210328~
TRN*1*123456789*AMZPAY~
REF*TN*CHK12345~
DTM*003*20210328~
N1*PR*AMAZON INC*FI*123456789~
N1*PE*ACME SUPPLIES*FI*ACME123~
ENT*1~
RMR*IV*INV10001*1500.00*20210215~
SE*11*0001~
GE*1*905~
IEA*1*000000905~

Line-by-line explanation:

• ISA... — ISA envelope; verify element separators and control number consistency with IEA.
• GS*RA* — Functional group for remittance advice; check GS control number matches GE.
• ST*820*0001 — Transaction set header for 820; ST02 is the transaction control number.
• BPR*C*1500.00*C*CHK************20210328 — Payment type 'C' (payment), amount 1500.00, method CHK, payment date 20210328.
• TRN*1*123456789*AMZPAY — Trace number for reassociation.
• REF*TN*CHK12345 — Reference with transaction number (check number).
• DTM*003*20210328 — Date qualifier 003 (posting date) with date value.
• N1*PR*AMAZON INC*FI*123456789 — Payer entity: Amazon, financial institution ID given.
• N1*PE*ACME SUPPLIES*FI*ACME123 — Payee entity: your vendor ID.
• ENT*1 — Start of entity loop (one payee/payor relationship).
• RMR*IV*INV10001*1500.00*20210215 — Apply 1500.00 to invoice INV10001 dated 2021-02-15.
• SE*11*0001 — End transaction set with segment count and ST control number.
• GE/IEA — Functional group and interchange trailers; control numbers must reconcile.

CSV Output Example

Step-by-Step Conversion Process

1. Pre-Validation (validate envelopes and delimiters)
   1. Check ISA segment position and element count; confirm ISA16 for component element separator and ISA11 for repetition separator if present.
   2. Verify the segment terminator (usually ~), element separator (*) and component separator (: or ^)—mismatches will break parsers.
   3. Confirm IEA and GE control numbers match ISA/GS; if not, reject the interchange and request retransmission.
2. Segment Parsing and Extraction
   1. Tokenize by segment terminator and split elements by the element separator.
   2. Identify BPR for payment amount and method, TRN for trace, N1 loops for payer/payee mapping.
   3. Extract all RMR records; there can be multiple RMR per ENT loop describing multiple invoice applications.
3. Data Normalization
   1. Normalize dates to ISO (YYYY-MM-DD). For example, convert 20210328 to 2021-03-28.
   2. Normalize numeric formats (remove leading zeros, ensure two decimal places for currency).
   3. Map Amazon ID qualifiers to your vendor master (e.g., if Amazon sends an FI qualifier but your system uses Vendor Code, perform a lookup table match).
4. CSV Mapping & Flattening
   1. Create a CSV row per RMR (invoice application) so every applied invoice is a separate row.
   2. Populate header-level fields (PaymentDate, PaymentAmount, PaymentMethod, Check/Trace) for each row derived from the header BPR/TRN.
   3. Include payer/payee identifiers and any reference qualifiers needed for reconciliation.
5. Validation Against Accounting Rules
   1. Confirm total of RMR applied amounts equals BPR02 payment amount; if not, flag and hold for manual review.
   2. Check invoice numbers exist in AR system and that invoice amounts match expected outstanding balances.
6. Post-Processing & Posting
   1. Produce the final CSV and import into your ERP using the ERP’s staging process. If your ERP requires a unique import format, map fields accordingly.
   2. Create reconciliation reports showing payments applied and unapplied balances. Log ST/SE control numbers for audit traceability.
7. Automated Reconciliation and Exception Handling
   1. For unapplied amounts, create an exception queue with reason codes (missing invoice, partial payment, invalid ID qualifier).
   2. Use PlainEDI validation before importing to catch structural and semantic errors; upload the EDI to PlainEDI for pre-checks.

Common Errors and Fixes

• Error: ISA/IEA Control Number Mismatch — Symptom: Parser rejects interchange. Fix: Re-request file or correct the IEA/ISA numbers if you're the sender. Check that your VAN/AS2 did not alter control numbers. PlainEDI pre-validation will detect mismatches on upload (PlainEDI).
• Error: Missing or Malformed BPR Segment (Validation Code: 820-BPR-01) — Symptom: Missing payment amount or method. Why: Downstream systems use BPR02 to post payments; if absent the record cannot be posted. Fix: Reject the transaction and ask Amazon (via vendor support) to resend or parse a secondary segment (REF) if payment info is present there. Use PlainEDI to validate presence and format of numeric fields.
• Error: RMR Applied Totals Don’t Match BPR02 (Validation Code: 820-RMR-Total) — Symptom: Sum(RMR AppliedAmounts) != BPR PaymentAmount. Why: Amazon sometimes issues an 820 that includes partial applications or unapplied items. Fix: Flag for manual reconciliation; create an exception row and ask for remittance detail clarification. Consider storing unapplied cash as a suspense account and reconcile after receiving adjustment 820 or statement.
• Error: Missing Payee Identifier / ID Qualifier Mismatch (Validation Code: 820-N1-ID) — Symptom: The N1*PE ID qualifier doesn’t match vendor master keys. Why: Amazon may use a different qualifier (e.g., FI vs. SU) than your ERP expects. Fix: Build qualifier mapping table (qualifier->vendor field) and implement a fallback lookup using payee name. Log unmapped IDs into an exceptions queue for manual mapping.
• Error: Duplicate TRN or Duplicate SE/ST Control Numbers (Validation Code: 820-TRN-DUP) — Symptom: Parser blocks second receipt of same TRN; ERP rejects duplicate payment. Why: Retransmissions or duplicate file submissions. Fix: Use the TRN and ST/SE control numbers to deduplicate incoming payments. If a legitimate retransmission, mark as duplicate and skip posting. PlainEDI can detect duplicate trace numbers on upload to /upload.
• Error: Segment Terminator or Element Separator Mismatch (Validation Code: EDI-DELIM-001) — Symptom: Parser fails to break segments. Why: File transferred with altered delimiters by VAN or text editor. Fix: Detect delimiters from ISA (positions 3, 104) and enforce reading accordingly. Do not open and resave EDI files in editors that change characters. Use PlainEDI pre-validation to auto-detect incorrect terminators.
• Error: Partial Payments Not Listed per RMR (Validation Code: 820-RMR-PARTIAL) — Symptom: RMR lists applied amount less than invoice open amount, but no remittance reason. Fix: Generate a partial payment workflow: post partial payment to invoice, leave remainder open, and create a ticket to request clarification. If Amazon issues an explanation via REF or additional RMR entries, reconcile accordingly.

Related Resources

• understanding EDI 820 payment remittances
• amazon-vendor-central-edi-processing
• reading 997 functional acknowledgments
• how-to-parse-amazon-edi-invoice-files
• integrating-edi-with-erp-systems
• converting-edi-files-for-accounting-software

Why These Errors Happen — Root Causes

Understanding the underlying causes helps you prevent recurring issues:

• Envelope Alteration — VANs or file transfers that treat EDI as text may change delimiters or control numbers. Always use AS2/VAN transports that preserve binary fidelity and validate envelopes on receipt.
• Vendor Mapping Differences — Amazon's ID qualifiers and terminologies vary by program and geography; without robust qualifier mapping you'll misidentify payees.
• Partial Payment Business Logic — Amazon sometimes allocates payments in aggregated batches. If your AR system expects one-to-one payment-invoice mapping, rework the posting logic to allow multi-line applications.
• Human Intervention — Manual edits to EDI files (opening in Notepad or Excel) frequently introduce invisible characters. Use EDI-aware tools for viewing and validation.
• Timing & Reconciliation — Amazon’s payment file may arrive before invoices are recorded in your AR system. Implement staging and asynchronous reconciliation to handle timing differences.

Practical Case Studies

Case Study 1 — Duplicate TRN Detection

A mid-market supplier received two identical 820s due to an AS2 retransmission. Their ERP blocked the second posting, but the team lacked deduplication logs and manually investigated a day. Solution: Implement TRN+ST dedupe logic in the import script to automatically discard retransmissions. After adding this rule, manual intervention dropped by 95%.

Case Study 2 — ID Qualifier Mismatch

A supplier's ERP expected vendor codes but Amazon sent financial institution numbers under N104 with qualifier FI. The import failed to match vendor master entries. Solution: Build a mapping table linking Amazon FI codes to internal vendor codes; use a fallback name match on N102. Pre-validate all incoming 820s with PlainEDI to surface missing mappings quickly.

Amazon-Specific Notes and Penalties

Amazon's vendor programs maintain compliance requirements around remittance and ASN accuracy. Last updated: 2025-12-28. Amazon enforces penalties for failures in compliance programs such as OTIF and chargeback rules; verify current penalties in your Vendor Central portal. If you encounter consistent 820 issues, open a ticket in Vendor Central and reference the file ST/SE numbers and TRN trace values for faster resolution.

Automation Tips & PlainEDI Integration

Integrate PlainEDI into your inbound pipeline to run validations on ISA/GS/ST, required segment presence (BPR, TRN, RMR), numeric formats, and totals reconciliation. PlainEDI can reject malformed files before they reach your ERP, preventing mis-postings. Use PlainEDI validation rules to enforce:

• Presence of BPR02 and numeric currency format
• Sum(RMR AppliedAmounts) == BPR02 or create an exception if not
• Mapped N1 ID qualifiers exist in your vendor master before import

Upload EDI directly to PlainEDI for automated checks and generate a CSV export that matches your ERP mapping.

FAQ

Q: How do I know if the EDI 820 is intended as a payment or only an advice?

Check BPR01 (transaction handling code) and BPR03 (payment method). If BPR01 indicates a payment ('C' for payment) and a payment amount exists in BPR02, the 820 is a payment. If BPR02 is zero or missing but remittance information exists, treat as advice-only. Validate this with a reconciliation rule: if BPR02 <= 0 and RMR entries exist, flag as advice-only.

Q: What should I do if RMR applied amounts don’t sum to BPR02?

Flag the transaction and create an exception record. Reconcile partial applications by posting applied amounts to invoices and leaving remaining balance in a suspense account. Request clarification from Amazon via Vendor Central with the ST/SE control numbers and TRN trace. Use PlainEDI pre-checks to detect this mismatch before import.

Q: My ERP rejects files because N1 identifiers don't match vendor master. How to fix?

Implement a mapping table between Amazon ID qualifiers and your vendor master keys. Add fallback matching by vendor name (N102) and create a manual review queue for unmapped entries. Over time, add mappings for frequently encountered IDs to automate processing.

Q: How to handle partial payments and unapplied cash?

Post the applied amounts from RMR entries and leave unapplied remainder in a suspense account. If unapplied cash arises often, build a reconciliation job that attempts to match unapplied amounts to subsequent 820s, 822s, or 823s. Notify AR for manual follow-up and request additional remittance detail from Amazon if necessary.

Q: Can I automate deduplication so retransmissions don’t cause double-posting?

Yes. Use the combination of TRN (transaction trace) and ST/SE identifiers as a dedupe key. Maintain a short-term index of recently processed TRNs; if a duplicate arrives within your dedupe window, skip posting. Record the decision in an audit log and notify operations if repeated duplicates occur.

Q: What are the best practices for delimiter detection?

Parse the ISA segment to detect delimiters: ISA element uses fixed-width positions where the element separator is the character after the ISA segment fields, and the component element separator is ISA16. Do not assume defaults. If delimiters don't match expected values, reject the file and request re-send. Use PlainEDI for automatic delimiter detection on /upload.

Q: Where can I find more Amazon-specific EDI handling guidance?

See the Amazon vendor central integration guide and the EDI 820 remittance guide linked in Related Resources. Also reference the Amazon Vendor Central EDI processing guide for program-specific qualifiers and instructions.

Q: How should I store audit references for Amazon remittances?

Store ISA/GS/ST control numbers, TRN trace values, and the raw EDI file hash in your payment posting logs. This enables fast lookups if Amazon disputes a payment or if you need to trace the original interchange during reconciliation.

Final CTA

Ready to validate and convert your Amazon EDI 820 files automatically? Upload your EDI files to PlainEDI for pre-validation, CSV conversion, and error reporting that prevents posting issues and speeds reconciliation.