Walmart Chargeback Code 33: Wrong PO Number on the Invoice

Executive Summary & Quick Answer

Executive summary: Walmart's AP process is a matching engine: every invoice must find its purchase order. The PO number is the join key, and Code 33 is what happens when that key is wrong — Walmart issued PO #5678, your invoice cites PO #5679, and the match fails. Nothing about the goods, the price, or the math is in question; the invoice is simply orphaned. The unmatched amount sits deducted until you correct and re-submit, which makes Code 33 less a penalty than a payment stall you inflicted on yourself. Every root cause traces to one decision: letting a human type a PO number instead of carrying it electronically from the 850 to the 810.

Quick answer: Walmart Chargeback Code 33 is assessed when an invoice references the wrong purchase order number, so Walmart cannot match the invoice to the order. The unmatched invoice amount is deducted until the invoice is corrected and re-submitted. It is caused by manual entry errors, transposed digits, or invoices mapped to the wrong PO.

---

Deep Dive: What Triggers Code 33

Every Walmart order arrives as an EDI 850 carrying a PO number. Every invoice you send back is an EDI 810 that must reference that exact number. AP matches on it. When the number on the 810 doesn't exist — or points at a different order — the invoice can't be paid against anything, and the unmatched amount lands as Code 33.

Where the key breaks:

850 (PO #5678) ──► your order mgmt ──► 810 built
                                          │
              electronic carry-through ───┤─── manual re-keying
                        │                            │
                  810 cites #5678              810 cites #5679
                        │                            │
                  MATCH → paid                 NO MATCH → Code 33

Transaction	Role in the match	Failure mode
850 (PO)	Source of truth for the PO number	—
810 (Invoice)	Must cite the 850's PO number exactly	Typo, transposition, mapped to the wrong PO
AP match	Joins 810 to 850 on PO number	One wrong digit → orphaned invoice → Code 33

The failure is almost never exotic. A PO number gets re-keyed by hand and two digits swap. An invoice gets generated against the wrong open PO for that same buyer. A batch job maps invoice lines to a neighboring order. In each case the invoice itself may be internally perfect — right items, right prices, right math — and still unpayable, because the join key is broken.

What makes Code 33 distinctive among AP codes: it's fully self-correcting in your favor if you act, and fully self-punishing if you don't. The money isn't gone; it's stranded behind a wrong reference.

---

Business & Financial Impact

• Deduction = the unmatched invoice amount, held until corrected and re-submitted. This is stalled revenue, not a fee — but stalled is still unpaid.
• DSO damage: every Code 33 adds a correct-and-resubmit cycle to the payment timeline. At volume, a small manual-entry error rate becomes a permanent drag on days sales outstanding.
• Reconciliation fog: an orphaned invoice throws off both sides of your AR ledger — the PO shows unbilled, the invoice shows unpaid — until someone connects them.
• Silent until it isn't: unlike a shortage, nobody at a DC flags this. It surfaces in remittance data, often weeks later, as a deduction your AR team has to reverse-engineer.

---

Root Causes (Ranked)

1. Manual PO-number entry on the invoice — a human re-keys what the 850 already delivered electronically; typos are the tax on that decision.
2. Invoice mapped to the wrong PO — the invoice generation process attaches lines to a different open order, often for the same buyer or ship-to.
3. PO number transposed or mistyped — digit swaps (#5678 → #5679, #5687) that pass every visual check and fail the exact match.

One theme underneath all three: somewhere between the 850 arriving and the 810 leaving, the PO number stopped being carried electronically.

---

Step-by-Step Prevention Workflow

1. Pull the PO number from the 850 into the 810 — no manual entry, ever. The number Walmart sent is the number Walmart matches on. Any human touchpoint between the two is a defect source.
2. Validate before transmitting. A pre-send check that the 810's PO number exists among your open Walmart 850s catches typos and wrong-PO mappings while they're free to fix.
3. Automate PO-to-invoice matching on your side first. Run the same join Walmart will run — 810 against 850 — internally, pre-transmission. If your own match fails, Walmart's will too.
4. Alert on orphans immediately. An invoice that references no known PO should never queue for transmission; it should page someone.
5. Watch the correction loop. Track how many invoices needed correct-and-resubmit each month. That number is your manual-entry exposure, measured in delayed dollars.

---

Correcting a Code 33

1. Pull the deduction detail from the APDP in Retail Link: invoice number, amount, and the PO reference that failed to match.
2. Locate the correct PO — the 850 the shipment actually fulfilled.
3. Correct the invoice to cite the right PO number and re-submit.
4. Confirm the deduction clears once the corrected invoice matches and pays; escalate through the APDP if it doesn't.
5. Trace where the wrong number entered — manual keying, wrong-PO mapping — and close that path.

---

Code 33 Among the Invoice-Error Codes

Code	The story
33	Wrong PO number — the invoice can't find its order
12	Invoice incorrectly extended — the math (cost × qty) is wrong
90	Unauthorized charge — a fee Walmart never approved, removed

Same family, different defects: Code 12 is arithmetic, Code 90 is contractual, Code 33 is referential — the invoice is fine but points at the wrong order.

Related: Code 12 · Code 90

---

Supplier Checklist

• PO number flows 850 → 810 electronically; zero manual re-keying
• Pre-transmission check: 810 PO number exists among open Walmart 850s
• Internal PO-to-invoice match runs before Walmart's does
• Orphaned invoices blocked from transmission and alerted
• Monthly: count of correct-and-resubmit cycles tracked and driven down

---

FAQs

What is Walmart chargeback Code 33? A deduction assessed when the invoice references the wrong purchase order number — for example Walmart issued PO #5678 but the invoice cites PO #5679 — so Walmart cannot match the invoice to the order.

How much does Code 33 cost? The unmatched invoice amount is deducted until the invoice is corrected and re-submitted. It's stalled payment rather than a flat fine — but it stays deducted until you act.

How do I fix a Code 33 deduction? Find the correct PO the shipment fulfilled, correct the PO number on the invoice, and re-submit. Work the deduction through the APDP in Retail Link and confirm it clears once the corrected invoice matches.

What causes wrong PO numbers on invoices? Manual entry errors, transposed or mistyped digits, and invoices mapped to the wrong PO during generation. All three trace back to the PO number being re-keyed instead of carried electronically from the 850.

How do I prevent Code 33 entirely? Pull the PO number directly from the EDI 850 into the 810 with no manual entry, validate that the number exists among your open POs before transmitting, and automate PO-to-invoice matching on your side first.

Is Code 33 worth disputing? It's less a dispute than a correction: the deduction exists because the match failed, and it resolves when the corrected invoice matches. Use the APDP to track the deduction and confirm release after re-submission.

---