Walmart EDI 810 Invoice: Format, Fields, and Requirements

The EDI 810 is the invoice document that tells Walmart what to pay you and why. Every dollar Walmart pays a supplier flows through an 810. When the 810 is built correctly, invoices post to Accounts Payable and payment moves through the standard cycle. When the 810 has a data error, a mismatch against the PO, or a missing required field, it gets rejected or short-paid, and the recovery process starts.

Most suppliers treat the 810 as a standard EDI document. It is not. Walmart runs its own mapping guides, validation rules, and matching logic on top of the ANSI X12 810 standard, and the details are where compliance is won or lost.

What Is a Walmart EDI 810?

The EDI 810 is an electronic invoice sent from the supplier to Walmart in the ANSI X12 standard format. It represents the supplier's formal request for payment against goods that have shipped or been received.

Walmart requires every invoice to be submitted through EDI. Paper invoices, email invoices, and portal-typed invoices are not accepted for standard suppliers. The two delivery methods are:

• AS2 through the Global Enterprise Mailbox (GEM): for high-volume suppliers, integrated directly with the supplier's ERP
• WebEDI inside Retail Link: for suppliers below 5,500 documents per year, with manual invoice creation directly from the PO

Both methods generate the same 810 document. The difference is only in how it gets transmitted.

Why the EDI 810 is important in Walmart's Payment Cycle

The 810 is the trigger event for payment. Nothing gets paid until an accepted 810 lands in Walmart's Accounts Payable system and passes matching.

Walmart's payment cycle runs on a three-way match (for DC and Sam's Club shipments) or a two-way match (for direct store delivery). The 810 provides one of the three data inputs. The others come from the EDI 850 (Purchase Order) and the receiving record. When all three align, the invoice is paid. When they do not, the system generates an exception:

• Rejected invoice: returned to the supplier with an error code, no payment issued
• Short-paid invoice: partial payment, with the balance recorded as a claim or deduction
• Held invoice: payment blocked pending research

Because the 810 is where the supplier's data enters the match, errors on the invoice cause exceptions even when the underlying shipment was correct.

Walmart EDI 810 Required Segments and Fields

The 810 follows the ANSI X12 hierarchy of segments and elements. Walmart's mapping guide specifies which segments are required, which are conditional, and which values are acceptable.

The core segments every Walmart 810 must include:

• ISA (Interchange Control Header): identifies sender, receiver, and control numbers
• GS (Functional Group Header): groups related transactions
• ST (Transaction Set Header): marks the start of the 810
• BIG (Beginning Invoice Segment): invoice date, invoice number, PO date, PO number
• REF (Reference Identification): additional reference numbers as required by Walmart
• N1 loop: ship-to and remit-to party information
• ITD (Terms of Sale): payment terms
• IT1 loop (Baseline Item Data): line-level detail for each item (quantity, unit of measure, unit price, product ID)
• TDS (Total Monetary Value Summary): invoice total
• CTT (Transaction Totals): line count
• SE (Transaction Set Trailer): marks the end of the 810
• GE and IEA: functional group and interchange trailers

Each Walmart division (Walmart US, Sam's Club, Walmart Canada) has slight variations in its mapping guide. Always pull the specific guide for the division you are invoicing.

Critical Field Requirements That Cause Most Rejections

A handful of specific field errors account for the majority of 810 rejections. These are the ones worth double-checking before every transmission.

Invoice number uniqueness: The invoice number in the BIG02 segment must be unique for the vendor. Duplicating an invoice number Walmart has already processed causes an immediate rejection.

PO number match: The PO number in the BIG04 segment must exactly match the Walmart PO number as issued. Formatting variations, missing prefixes, or transposed characters all trigger rejection.

Invoice date logic: The invoice date in BIG01 cannot be before the ship date. Submitting an invoice dated earlier than the shipment causes a rejection.

Vendor number in the REF segment: Walmart's assigned six-digit vendor number must appear correctly. Errors here misroute the invoice to the wrong AP account.

Currency and payment terms alignment: The ITD segment must reflect the payment terms from the Supplier Agreement. Terms that do not match the agreement will not process.

Line-level unit of measure: The UOM in the IT101 segment must match how the item was set up in Walmart's item file. A mismatched UOM (each vs case, for example) triggers a quantity conversion error even when the raw numbers are correct.

Line-level cost: The unit cost in the IT104 segment must match the PO cost. Any variance flows into cost difference claim codes (10, 11, 13).

Total invoice value: the TDS segment total must equal the sum of the line-level extended amounts, less any adjustments. Math errors here cause immediate rejection.

The Two Ways Walmart Validates an EDI 810

Every 810 goes through two separate validation layers before it can be paid. Failing either one means the invoice does not proceed.

Technical Validation (EDI Standards)

Walmart's EDI translator first checks that the 810 conforms to ANSI X12 standards and Walmart's mapping guide. If required segments are missing, envelope control numbers do not match, or the syntax is broken, the invoice is rejected at the translator level.

Walmart sends back an EDI 997 Functional Acknowledgment to confirm receipt. An accepted 997 means the document was structurally valid. A rejected 997 means the 810 failed technical validation and was never ingested.

Business Validation (Data Matching)

Once the 810 passes technical validation, it enters Walmart's Accounts Payable system for business validation. This layer checks the invoice data against the PO, the item file, the supplier agreement, and the receiving record. Failures at this layer are reported through:

• EDI 824 (Application Advice): for business-rule violations that require correction
• EDI 864 (Text Message): for invoices missing required information that blocks AP processing

Suppliers who monitor only the 997 miss half the picture. The 824 and 864 are where the substantive rejections live.

Common EDI 810 Rejection Reasons

The rejection reasons that appear most consistently across Walmart 810 submissions.

Duplicate invoice number: the invoice number was previously submitted and processed. Fix by generating unique invoice numbers per submission.

PO number not found: the PO referenced on the invoice does not exist in Walmart's system, has been cancelled, or was formatted incorrectly. Fix by validating the PO number against Retail Link before invoicing.

Cost mismatch against PO: the unit cost on the invoice does not match the PO cost. Fix by confirming cost changes are effective in Walmart's item file before the PO ships.

Quantity mismatch against receipt: the invoiced quantity exceeds what Walmart received at the DC. This falls into shortage codes (22, 24, 25) rather than a straight rejection.

Invalid vendor or agreement number: the vendor or agreement referenced does not match Walmart's records. Fix by confirming vendor setup in Supplier One.

Missing required segment: a mandatory segment (BIG, IT1, TDS, CTT) is missing or empty. Fix by pulling the current mapping guide and comparing your 810 output against it.

Invoice date before ship date: the invoice date precedes the actual shipment date. Fix by aligning invoice generation timing with the shipment lifecycle.

Payment terms mismatch: the ITD payment terms do not match the Supplier Agreement. Fix by pulling the terms from the current agreement rather than defaulting to prior values.

Suppliers running high invoice volumes see the same handful of rejections repeat month after month, which is a strong signal that the fix is upstream in the ERP or EDI mapping, not in the individual invoice. Automated deduction platforms that pull EDI 824 and 864 messages directly and flag recurring rejection patterns typically surface the root cause faster than manual review.

Walmart EDI 810 Timing Rules

Timing controls whether the 810 gets paid on schedule or falls into an exception queue.

• Submit after shipment, not before: an 810 submitted before the shipment leaves the dock creates a receiving mismatch if the shipment is delayed or short
• Do not submit the same day the PO is received: this risks a false rejection if the PO has not yet reached Walmart's AP system. Wait one business day
• DC shipments: payment terms begin at receipt. Timing must account for transit
• Direct store deliveries: payment terms begin on the invoice date
• Sent Items check at 48 hours: invoices should move from Processing to Acknowledged within 48 hours. Rejected status includes the reason for rejection, which must be addressed before resubmitting
• 12-month cutoff: invoices over 12 months old cannot be paid by AP

Suppliers who submit invoices immediately after shipment loading, along with the ASN, minimize the timing gap and speed up payment. Batching invoices weekly or monthly adds days or weeks to the DSO.

What Happens After an EDI 810 Is Accepted

An accepted 810 does not automatically mean an on-time payment. The invoice still runs through matching, and matching outcomes determine what actually gets paid.

• Clean match: invoice matches PO and receipt within tolerance. Payment proceeds on schedule
• Match Out of Tolerance (MOT): invoice value or quantity differs from PO or receipt beyond tolerance. Payment adjustment (claim or deduction) applied
• No receipt found: invoice submitted but no matching receipt in the system. Invoice waits the extended time window, then either matches when the receipt posts or converts to a chargeback

Most suppliers do not track invoices through matching after submission. They see the payment or the deduction on the remittance and react to whichever came in. Reviewing the Sent Items page, the 824 dashboard, and the AP Inquiry System proactively catches issues in the days between submission and payment, when they are still fixable.

Turn Invoice Rejections Into Faster Payments

Here is the math that decides how much of your Walmart revenue you actually collect on time. Every rejected 810 delays payment. Every short-paid 810 becomes a claim or deduction. Every match exception becomes an AP research cycle. Across hundreds of monthly invoices, the small delays compound into serious DSO drag, and the deductions that get generated from 810 mismatches quietly accumulate as write-offs.

The break-even math flips when the 810 validation, tracking, and follow-up cycle gets automated. Platforms like iNymbus pull Walmart AP data (rejections, short-pays, deductions, and post-audit claims) directly from Retail Link and APDP, match each exception to the underlying PO, invoice, receipt, and EDI acknowledgment records from your systems, and route them to the right response (correction, dispute, or write-off) without manual queue work.

For suppliers running high 810 volume, that means invoice rejections get fixed faster, cost and quantity deductions get disputed inside the window, and the same infrastructure that pays attention to 824 and 864 messages catches the recurring patterns that would otherwise stay invisible.

If your team is spending time chasing rejected invoices and reconciling short payments one at a time, that is the exact problem this kind of automation solves.

See how iNymbus supports Walmart EDI 810 and deduction workflows, or request a free deduction audit to see what is recoverable in your current process.