Walmart EDI 820 Payment Order Guide

What This Is

This guide covers the Walmart EDI 820 transaction set (Payment Order/Remittance Advice) end-to-end: structure, key segments, sample files, CSV conversion, and troubleshooting. EDI 820 is used to send payment advice and payment order details — including ACH or check payments, remittance references, and invoice-level application data — from a payer (Walmart) to a payee (vendor).

The content focuses on Walmart-specific considerations, common reasons 820s fail processing, and practical conversion steps that map EDI elements to CSV columns suitable for accounting systems. Walmart policy and program facts referenced here are current as of 2025-11-30; verify policy changes and penalty details in Walmart Retail Link.

Who This Is For

This guide is for EDI specialists, AP accountants, ERP integrators, and vendors trading payments with Walmart who need to parse 820s, import remittance data into accounting software, or reduce 820-related rejections. It assumes basic familiarity with X12 structure (ISA/GS/ST) but includes line-by-line explanations so technical and business teams can collaborate.

Key Segments Explained

Below are the critical segments you will see in a Walmart 820 file. Understanding what each segment conveys and why errors occur will help you validate and convert accurately.

• BPR — Beginning Segment for Payment Order/Remittance Advice

  The BPR segment contains the payment method, payment amount, and critical banking details. Example elements: BPR01 (Transaction Handling Code), BPR02 (Monetary Amount), BPR03 (Credit/Debit Flag), BPR04 (Payment Method Code like ACH), BPR05-BPR11 (Bank routing and account details follow when ACH).

  Why errors occur: Incorrect payment method codes, malformed ACH/ABA numbers, and missing currency or amount fields. Walmart systems perform strict validation on BPR; failing validation causes downstream rejections or manual hold.

• TRN — Reassociation Trace Number

  The TRN segment provides a trace number to correlate remittance with payment transactions and bank trace logs. TRN01 is the trace type (usually 1 for current transaction), TRN02 is the trace number, TRN03 optionally contains originating company identifier.

  Why errors occur: Missing or duplicate trace numbers prevent reconciliation between EDI and bank statements. Walmart uses the TRN to match payments to remittance advice; duplicates trigger audit flags.

• N1 — Name

  The N1 segment identifies parties: payer (Walmart) and payee (vendor). N1*PR identifies the payer, N1*PE or N1*ST may identify the remittance payee or ship-to. Elements include identification codes and qualifiers (e.g., N101 entity identifier code, N102 name, N104 ID code, N105 ID code qualifier).

  Why errors occur: Wrong qualifiers or missing vendor IDs cause inability to match remittance to vendor master records. Walmart requires accurate vendor numbers in the N1 loop for successful posting.

• ENT / RMR — Payment Application

  ENT starts an entity (vendor) loop; RMR (Remittance Advice Accounts Receivable Open Item Reference) provides invoice-level application detail: RMR01 account number qualifier, RMR02 invoice number, RMR03 invoice date, RMR04 invoice amount, RMR05 amount applied. RMR segments may repeat per invoice.

  Why errors occur: Mismatched invoice numbers, currency mismatch, or negative/zero payment amounts. If RMR totals do not sum to the BPR payment amount (after considering adjustments), downstream reconciliation issues arise.

• REF / DTM / SE

  REF provides additional references (e.g., sample REF*TN*12345 where TN might be payment tracking). DTM carries dates associated with the transaction (payment date, issue date). SE closes the transaction set and contains a segment count and control number.

  Why errors occur: Date format mismatches and incorrect segment counts in SE cause 997 rejections. Use deterministic segment counting when building ST/SE pairs to avoid errors.

Example EDI Snippet

Below is a realistic Walmart 820 snippet with annotations. This example uses element separators '*' and segment terminator '~' (common X12 delimiters). Explanations follow the code block.

ISA*00*          *00*          *12*WALMART        *01*123456789      *231130*1430*U*00401*000000905*0*T*:~
GS*RA*WALMART*123456789*20231130*1430*905*X*004010~
ST*820*0001~
BPR*C*12500.00*C*ACH*CTX*01*999999999*DA*021000021*1234567890**01*111111111*DA*021000022*9876543210*20231129~
TRN*1*20231129001*WALMART123~
N1*PR*WALMART INC*9*123456789~
N1*PE*VENDOR COMPANY*1*VEND12345~
ENT*1~
RMR*IV*INV-100234*20231101*5000.00*5000.00~
RMR*IV*INV-100235*20231105*7500.00*7500.00~
REF*TN*PAY-20231129~
DTM*003*20231129~
SE*11*0001~
GE*1*905~
IEA*1*000000905~

Line-by-line explanations:

• ISA — Interchange control header. Contains sender/receiver IDs, date/time (231130 = 2023-11-30), and control number 000000905. Validate ISA segment for correct qualifier and fixed-width fields.
• GS — Functional group header. GS06 is the group control number (905) matching IEA.
• ST — Transaction set header, ST02 is the ST control number 0001 that matches SE.
• BPR*C*12500.00*C*ACH*CTX*01*999999999*DA*021000021*1234567890**01*111111111*DA*021000022*9876543210*20231129

  BPR01=C (Payment/Remittance Advice Transaction Handling Code), BPR02=12500.00 (total payment), BPR04=ACH, BPR05=CTX (payment format), followed by bank routing and account numbers. The presence of two bank blocks indicates originating and receiving banks. BPR16 is the payment date 20231129.

• TRN*1*20231129001*WALMART123 — Trace type 1, trace number 20231129001, and originator WALMART123 for bank reconciliation.
• N1 segments — N1*PR identifies payer (WALMART), N1*PE identifies payee (VENDOR) with vendor ID VEND12345. Ensure N104/N105 qualifiers match your vendor master.
• ENT*1 begins an entity loop; subsequent RMR segments list invoices and the applied amounts.
• RMR*IV*INV-100234*20231101*5000.00*5000.00 — RMR02 is invoice ID, RMR03 invoice date, RMR04 original invoice amount, RMR05 amount paid. Multiple RMR lines may exist.
• REF*TN*PAY-20231129 — Additional reference for treasury or internal tracking.
• DTM*003*20231129 — Payment effective date. DTM01=003 indicates effective/payment date per X12 code list.
• SE/GE/IEA — Transaction and interchange trailers with segment counts and control numbers that must match headers.

CSV Output Example

Below is a practical CSV mapping to import remittance data into accounting systems (one CSV row per invoice application).

Step-by-Step Conversion Process

1. Pre-validate the raw EDI file
   1. Check ISA/GS control numbers for matching values and valid qualifiers.
   2. Validate delimiters. Run a quick delimiter detection against the first line (ISA09/ISA16 positions). If the ISA element separator or terminator is wrong, parsing fails.
   3. Run a 997 or functional acknowledgement test in your EDI tool or with PlainEDI to confirm the interchange is accepted. Validate with reading 997 functional acknowledgments.
2. Parse critical segments into a normalized structure
   1. Extract ST/SE groups. Use ST02 as a transaction identifier for mapping outputs.
   2. Parse BPR into payment header fields: method, amount, currency, bank blocks.
   3. For each ENT loop, parse RMR lines into invoice-level records.
3. Validate business rules against vendor master data
   1. Match N1 vendor IDs to your vendor table. If mapping fails, flag for manual review and add vendor lookups by secondary IDs (tax ID or DUNS).
   2. Verify that sum(RMR.AmountApplied) equals BPR amount after accounting for adjustments. If sums differ, generate an exception report.
4. Transform and normalize for CSV
   1. For each RMR, create a CSV row with header fields repeated (PaymentReference, PaymentDate, PaymentAmount) and invoice-specific columns (InvoiceNumber, InvoiceDate, AmountApplied).
   2. Normalize dates to ISO format (YYYY-MM-DD) for accounting systems. Convert currency formats to fixed 2-decimal numeric values.
5. Run rule-based checks and enrichment
   1. Add bank routing validity checks (ABA checksum algorithm) if BPR indicates ACH. Flag invalid routing numbers.
   2. Enrich with GL mappings or cost-center codes using vendor or PO references.
6. Test import with accounting software
   1. Run a sandbox import into your accounting system using a small sample file. Compare ledger postings to expected results.
   2. If mismatches occur, iterate mapping changes and test again. Consider automation with converting EDI files for accounting software.
7. Validate and archive
   1. Create a reconciliation report that ties payment total, bank trace numbers, and applied invoice totals. Store original EDI, converted CSV, and reconciliation notes for audit trails.
   2. Optionally, run a final validation step with PlainEDI before sending acknowledgments or posting payments to production.

Common Errors and Fixes

• Error: ISA control number mismatch or invalid ISA qualifiers. Why: Interchange control values are unique and required for routing. Fix: Rebuild ISA with correct sender/receiver IDs and matching IEA control number before re-transmission. Validate with a syntax checker.
• Error: BPR missing ACH bank details when BPR04 indicates ACH. Why: Walmart expects bank blocks for ACH payments. Fix: Ensure BPR includes bank account and routing fields (BPR06-BPR16 block) formatted per X12. Validate ABA routing checksum algorithm on the routing number.
• Error: Duplicate or missing TRN trace number. Why: Trace numbers are required for bank reconciliation and must be unique per payment trace. Fix: Generate unique trace numbers per payment (use timestamp + sequence). Reject duplicate trace numbers in pre-validation.
• Error: Invoice numbers in RMR do not match vendor master. Why: Data-entry differences or vendor uses alternative invoice numbering. Fix: Implement fuzzy matching and vendor ID crosswalks; create exception report and contact vendor for resolution. Update vendor master with alternate invoice formats if consistent patterns exist.
• Error: SE segment count mismatch producing 997 rejection. Why: Incorrect segment counting when assembly or transformation removed/added segments. Fix: Recompute the ST/SE segment count programmatically (count segments from ST to SE inclusive) and repopulate SE01 before re-transmission.
• Error: Date format problems (e.g., DTM uses YYMMDD vs YYYYMMDD). Why: Some systems expect specific DTM code formats. Fix: Map and normalize all dates to YYYYMMDD when parsing, and validate DTM01 qualifiers for correct date type codes (003 for payment date).
• Error: Vendor ID qualifier mismatch in N1 (e.g., using 9 vs 1). Why: Walmart expects specific qualifier for vendor identifiers. Fix: Confirm the expected qualifier in Walmart trading partner docs and normalize N1 ID qualifiers in your parser. Update vendor mapping rules accordingly.

Related Resources

• understanding EDI X12 delimiters and structure
• reading 997 functional acknowledgments
• walmart suppliers EDI to CSV conversion
• converting EDI files for accounting software
• fixing EDI 810 invoice discrepancies

FAQ Section

Q: What is an EDI 820 and why does Walmart send it?

EDI 820 is the Payment Order/Remittance Advice used to inform vendors about payments and which invoices were applied. Walmart sends 820s to communicate ACH or check payments and the invoice-level application details needed for reconciliation in your accounting system.

Q: How do I validate an 820 before importing into my ERP?

Validate ISA/GS/ST control numbers, segment delimiters, BPR payment details, and that sum(RMR.AmountApplied) equals BPR payment amount. Run a 997 test or use PlainEDI to catch syntax and semantic errors; use the ABA routing checksum for ACH bank routing validation. PlainEDI is available for pre-upload validation at PlainEDI.

Q: What causes the most common 820 rejections with Walmart?

Most rejections stem from BPR errors (missing bank info or incorrect payment method code), incorrect vendor IDs in N1, SE segment counts mismatches, and duplicate TRN trace numbers. Walmart enforces strict validation rules; pre-validate these fields programmatically to avoid rejections.

Q: How should I map multiple invoice applications to CSV for import?

Use one CSV row per invoice application where header fields (PaymentReference, PaymentDate, PaymentAmount, TraceNumber, BankRouting) are repeated and invoice-specific fields (InvoiceNumber, InvoiceDate, AmountApplied) vary. This flat structure simplifies import into most ERPs and preserves invoice-level posting detail.

Q: Does Walmart charge penalties for EDI non-compliance?

Walmart enforces compliance penalties including OTIF and chargebacks when EDI requirements are not met. Effective date for referenced program facts is 2025-11-30; verify current penalty amounts and thresholds in Walmart Retail Link. Implement automated validation to minimize penalty exposure.

Q: What is the best way to handle vendor ID mismatches?

Implement a vendor master crosswalk that includes alternate IDs (DUNS, tax ID, internal vendor numbers). Use deterministic mapping rules and a manual exception queue for unmatched records. Update vendor master entries when you confirm alternate identifiers to reduce recurring exceptions.

Q: How do I validate BPR ACH data programmatically?

Check BPR04 payment method for ACH codes, ensure required bank blocks (BPR06-BPR11 or BPR12-BPR17) are present, validate ABA routing numbers with checksum, and ensure account numbers contain only allowed characters. Flag any deviation for manual review before posting.

Q: Can PlainEDI prevent 820 errors?

PlainEDI performs syntax and semantic validation that identifies delimiter issues, segment mismatches, and common business rule failures before you import files into production. Use PlainEDI for pre-upload validation and automated checks; validate every batch at PlainEDI.

Final Notes and Call to Action

This guide provides the practical steps you need to parse, validate, convert, and troubleshoot Walmart EDI 820 files. Implement the pre-validation steps, align vendor master data, and adopt automated checks to reduce rejections and chargebacks. PlainEDI offers validation features that catch delimiter, segment, and common business rule errors before you post payments; validate your 820s now at PlainEDI.