Walmart Chargeback Code 12: Invoice Incorrectly Extended

Executive Summary & Quick Answer

Executive summary: Code 12 is Walmart's arithmetic check. If any invoice line's extended amount doesn't equal unit cost × quantity — or the lines don't sum to the header total — Walmart recalculates and deducts the difference. It sounds trivial; at EDI scale, rounding rules, unit-of-measure conversions, and manual re-bills make it a steady leak for suppliers who don't validate before transmission.

Quick answer: Walmart Chargeback Code 12 is an accounts-payable deduction taken when an invoice is incorrectly extended — the line's extended amount doesn't equal unit cost × quantity, or line totals don't match the invoice total. Walmart recalculates the correct amount and deducts the difference automatically.

---

Deep Dive: What Triggers Code 12

Walmart's AP system re-computes every 810 invoice three ways:

1. Line extension: IT1 unit price × IT1 quantity = extended amount for that line.
2. Invoice roll-up: sum of line extensions (± SAC allowances/charges) = TDS total.
3. Unit-of-measure sanity: the quantity billed in the UOM stated (eaches vs cases vs inner packs).

Fail any of the three and Walmart pays its own recalculated number, tagging the difference Code 12.

Where it actually breaks:

Failure	Typical mechanism
Rounding	Unit cost carried at 4 decimals internally, billed at 2 — extensions drift by fractions of a cent that compound across large quantities
UOM conversion	PO in cases, invoice in eaches (or vice versa); qty × price uses mismatched units
Header mismatch	A line edited after totals were computed; TDS never recalculated
Currency/format	Implied-decimal EDI fields mapped wrong (price ×100 or ÷100)

The implied-decimal mapping error is the ugly one: an 810 map that writes 1050 intending $10.50 but the trading-partner spec reads it as $1,050.00 (or $1.05). It produces spectacular Code 12s on day one of a new EDI integration — which is why extension validation belongs in the map test plan, not just production monitoring.

---

Business & Financial Impact

• Deduction = the recalculated difference. Often small per invoice — but systematic (a rounding rule or UOM error hits every invoice the same way).
• Signal damage: chronic math errors flag your invoices for closer AP scrutiny, slowing payment on everything else.
• New-integration risk: mapping errors can produce large one-time deductions during EDI onboarding or 810 map changes.
• Labor: each Code 12 forces a line-by-line reconciliation to find which of the three checks failed.

---

Root Causes (Ranked)

1. Rounding rules mismatch — internal precision (3–4 decimals) vs billed precision (2), compounding on high quantities.
2. Unit-of-measure conversion errors — cases/eaches/inner-pack confusion between PO, pick, and invoice.
3. Manual invoices and re-bills — keyed corrections that skip system math validation.
4. 810 map defects — implied decimals, truncation, or TDS computed before final line edits.
5. Allowance interaction — SAC amounts applied at line level but not reflected in the header total (or vice versa).

---

Step-by-Step Prevention Workflow

810 generated ──► self-audit BEFORE transmit:
                   ├─ each line: price × qty == extension?
                   ├─ Σ lines ± SAC == TDS total?
                   └─ UOM on 810 == UOM on 850?
                          │
              any failure ─┴─► block + fix source ──► regenerate ──► transmit

1. Validate extensions at generation, not after remittance. A pre-transmit assertion (price × qty = extension, lines = total) costs nothing and kills the entire code.
2. Standardize precision. Bill at the precision Walmart's item file carries; round half-up consistently at the line level, then total — never round the total independently.
3. Lock UOM through the chain. The 810 must bill in the UOM the 850 ordered. Convert once, at order entry — not at invoicing.
4. Kill manual invoices. Route corrections through the EDI flow so math validation applies; if a manual bill is unavoidable, require a second-person extension check.
5. Regression-test 810 map changes with known-total fixture invoices before go-live.

---

Supplier Checklist

• Pre-transmit validation: line extension + header total + UOM
• One rounding rule, applied at line level, documented
• UOM converted once at order entry; 810 bills PO's UOM
• Manual invoices routed through EDI validation (or double-checked)
• 810 map changes regression-tested with fixture invoices
• Weekly remittance sweep: repeat Code 12 → inspect map/rounding, not the clerk

---

FAQs

What is Walmart chargeback Code 12? A deduction taken when invoice math is wrong — a line's extended amount doesn't equal unit cost × quantity, or lines don't sum to the invoice total. Walmart recalculates and deducts the difference.

How is Code 12 different from Code 10 and 11? Codes 10 and 11 are price disagreements (vs item file and PO respectively). Code 12 is pure arithmetic — the numbers on your own invoice don't reconcile with each other.

Can I dispute a Code 12? Only if Walmart's recalculation itself is wrong, which is rare. If your extension was wrong, the deduction is correct — fix the billing system and move on.

Why do I get tiny Code 12 deductions on almost every invoice? Almost always a rounding-precision mismatch between your internal cost (3–4 decimals) and the billed cost (2 decimals), compounding across quantity. Standardize the rounding rule at line level.

Which EDI segments matter for Code 12? On the 810: IT1 (price, quantity, UOM), the line extension, SAC (allowances), and TDS (total). The invoice must internally reconcile across all of them.

---