---
title: "Why multipack listings break wholesale margin math"
description: "A per-unit wholesale cost matched to a pack listing overstates ROI by N times the true ROI plus N minus one, so a six-pack under 500% naive ROI is a real loss."
question: "Why do multipack ASINs give wrong ROI numbers?"
cluster: amazon-mechanics
published: 2026-08-18
updated: 2026-08-18
tags: [multipack, pack-size, roi, catalog-matching]
related: [scan-wholesale-price-list-for-profit, why-supplier-catalogs-fail-to-match, calculate-net-roi-wholesale, upc-ean-gtin-mpn-differences]
---

Multipack ASINs give wrong ROI because the supplier prices one unit and the listing sells a pack, so the cost side of the calculation is divided by the pack size.

A per-unit cost on a six-pack listing sounds like an error of a factor of six. It is larger: ROI divides profit by cost, so understating cost inflates the numerator and shrinks the denominator.

## One supplier row, two ROI numbers

One supplier row scored two ways can return 591% or 15.2%, and the only difference is whether the cost side is multiplied by the pack quantity. A distributor lists a hand cream at $4.00 per unit; the listing that matched on brand and title is a six-pack at $39.99.

**Table: One supplier row scored two ways against a six-pack listing (illustrative fees, August 2026)**

| Line | Naive per-unit costing | Correct pack costing |
|---|---|---|
| Supplier cost applied | $4.00 | $24.00 |
| Listing sale price | $39.99 | $39.99 |
| Referral fee at 15% | $6.00 | $6.00 |
| FBA fulfillment fee, illustrative | $6.35 | $6.35 |
| Net proceeds | $27.64 | $27.64 |
| Net profit per sale | $23.64 | $3.64 |
| Net ROI | 591% | 15.2% |

Referral fees range from 5% to 45% by category with a typical $0.30 per-item minimum (sell.amazon.com/pricing, checked 2026-08-03); the fulfillment fee is illustrative, because Amazon publishes no FBA fee tables publicly. Nothing else is wrong — the identifiers matched, the price is live, the fees are right.

## How wrong the number is: the exact relationship

The error follows an exact identity rather than a rule of thumb, where N is the units in the listing's pack:

Naive ROI = (N x True ROI) + (N - 1)

Inverted, to repair a number you have been given:

True ROI = ((Naive ROI + 1) / N) - 1

Check the identity against the worked row: 6 x 0.152 + 5 = 5.91, the 591% the naive calculation produced. The second term is what makes multipacks dangerous: at zero true profit a six-pack still reads 500%.

**Table: What a naive per-unit ROI has to clear before a multipack row is actually profitable**

| Units in the listing pack | Naive ROI at 0% true ROI | Naive ROI at 10% true ROI |
|---|---|---|
| 2 | 100% | 120% |
| 6 | 500% | 560% |
| 12 | 1,100% | 1,220% |
| 24 | 2,300% | 2,540% |

Read the table the other way and it becomes an alarm: a naive ROI of 300% on a twelve-pack is a true ROI of minus 66.7% — the best-looking row in the file, losing two thirds of the money.

## The reverse error: a case price read as a unit price

Pack size can be wrong on the supplier side too, and that error runs the other way: it makes profitable rows look like losses, and a rejection makes no noise.

Suppose a supplier price of $22.00 covers a case of six and the matched listing sells one unit at $8.99. At a 15% referral fee and an illustrative $3.22 fulfillment fee, net proceeds are $4.42. The true cost of one unit is $22.00 divided by six, or $3.67, giving a real ROI of 20.4%. Costed at $22.00 per unit the same row returns minus 79.9% and is filtered out before anyone sees it. One correction handles both directions: true cost per sale equals the supplier price times the units in the listing, divided by the units the price covers. [How to calculate net ROI on a wholesale product](/docs/calculate-net-roi-wholesale) covers the rest of the cost stack.

## Detecting pack size on the Amazon side

Five signals reveal a listing's pack quantity, and no single one is reliable enough to trust alone.

**Table: Signals for the pack size of an Amazon listing**

| Signal | Where it lives | How far to trust it |
|---|---|---|
| Title tokens such as "pack of 6" | Listing title | Catches most packs; misses those the brand did not name |
| Item package quantity | Catalog attributes | Authoritative when populated, often empty on older listings |
| Unit count and unit count type | Catalog attributes | Good, but the unit is sometimes ounces, not pieces |
| Package weight vs the single-unit spec | Catalog attributes | Strong; a six-pack weighs roughly six times the unit |
| Price ratio vs a known single-unit listing | Two listings | Strong when both listings are live |

Title matching is where automated exclusion usually starts: it is cheap and catches the majority. Pair it with the package-weight cross-check for packs whose titles say nothing.

## Detecting pack size on the supplier side

The supplier file usually contains the pack quantity under a column heading nobody standardized — Case Qty, Inner, Pack, UOM, Units per Case, Master Pack — and any may be blank on the rows that matter most.

The harder question is the price basis: whether the price column is per each, per case, or per dozen. A file carrying both a price and a case-quantity column stays ambiguous until the supplier confirms the basis, and that answer belongs on the supplier record, not in someone's memory. Two checks catch the remainder. A GTIN-14 whose indicator digit describes a case means the barcode is for a carton — see [UPC vs EAN vs GTIN vs MPN for Amazon matching](/docs/upc-ean-gtin-mpn-differences). And a wholesale price above roughly 90% of the Amazon single-unit price usually means the basis is wrong, not that the deal is bad. Rows that never resolve belong in the pile in [why supplier catalog rows fail to match an Amazon ASIN](/docs/why-supplier-catalogs-fail-to-match).

## Exclude or correct: two defensible policies

Two policies work, and the right one depends on whether a human opens each surfaced row before money moves.

Exclude when the output feeds an automated shortlist: a surfaced number becomes a buying decision, and a wrong number is worse than a missing one. Forge Command takes this route: multipack listings are a hard filter on the sourcing engine alongside the 10% net ROI floor and the $1,000 per month ASIN revenue floor. Correct when a person reviews each row anyway: Analyzer.Tools detects multipacks and, since May 2026, allows bulk overrides of pack quantity across a scan; Price Checker 2 displays the detected pack quantity and adjusts net profit and ROI for it; Tactical Arbitrage's Wholesale Search handles multipacks with custom price modifiers (vendor pages checked 2026-08-03).

Exclusion has a real cost: multipack listings often carry the fewest competing sellers, and a hard filter hides them. A hand-reviewed workflow is better served by a scanner that corrects pack quantity than one that hides the row. [How to scan a wholesale price list for profitable ASINs](/docs/scan-wholesale-price-list-for-profit) covers where this step sits.

## Frequently asked questions

### Why does a multipack row show such a high ROI

Because ROI divides profit by cost, and a per-unit cost against a pack sale price understates the denominator while inflating the numerator. Naive ROI equals N times true ROI plus N minus one, where N is the pack size.

### Is a multipack ASIN ever worth buying

Yes, once the cost is normalized to the pack. Pack listings frequently carry fewer competing sellers than the single-unit listing, which is a real advantage. Multiply the cost side by the pack quantity first.

### Does the same problem happen with case pricing from a supplier

Yes, in reverse. A case price read as a unit price overstates cost and rejects profitable rows silently, which is harder to catch because a rejected row produces no output.