BigCommerce MSRP vs sale price: which should you edit, and when?

The single most common BigCommerce support question we field is some variation of: "I want to run a sale - do I edit regular price or sale price? Where does retail/MSRP fit in?"

The reason this question never goes away is that BigCommerce names its fields after their backend purpose, not their storefront effect. So merchants pick the wrong one, end up with no strikethrough, and assume the platform is broken.

This article maps each field to its storefront behavior, lays out which field to edit for each common scenario, and explains the MSRP-anchored sale strategy that some categories live by.

#The three price fields in BigCommerce

BigCommerce exposes three numeric price fields per product (and per variant). They all live in the same admin panel and they all accept numbers. Their behavior on the storefront is completely different.

#Regular price (price)

This is the default selling price. If you set nothing else, this is what the customer pays.

Storefront behavior:

• Displayed as the main price.
• Always shown.
• No strikethrough unless retail is set higher.

API field name: price

#Sale price (sale_price)

This is what the customer pays when set. It overrides the regular price for the checkout total. When set, the regular price renders as a strikethrough next to the sale price.

Storefront behavior:

• When set: customer pays this amount.
• When set: regular price shows with a strikethrough.
• When set: the product card gets a "sale" badge in most themes.
• When unset (or set equal to regular price): no strikethrough, no badge.

API field name: sale_price

#Retail price (retail_price) - also called MSRP

This is the anchor price. The customer never pays this amount. It exists purely to create perceived discount.

Storefront behavior:

• When higher than regular/sale price: rendered as a strikethrough above or next to the selling price.
• When equal or lower: not displayed.
• Does not affect checkout or pricing logic.

API field name: retail_price

#What the storefront actually shows

The strikethrough behavior trips up most merchants. Here is the decision the storefront makes when rendering each product:

1. If sale_price is set and lower than price: show sale_price as the active price, strikethrough price.
2. Else if retail_price is set and higher than price: show price as the active price, strikethrough retail_price.
3. Else: show price only, no strikethrough.

So the strikethrough source depends on what you set. This is the source of most confusion.

Three real scenarios:

That last row is the one most stores want for major promotions. It shows: $60 (strikethrough) → $40 sale price, with the customer paying $40. The implicit "saving $20" against your regular price is reinforced by "vs $60 MSRP".

#When to edit each field

The mapping from goal to field.

#"I want to run a temporary sale" → edit sale_price

Set the sale price below the regular price. Storefront shows the strikethrough automatically. When the sale ends, clear the sale price (or set it to 0). Regular price is unchanged so you do not need to remember the original to revert.

This is by far the most common scenario. If you only learn one thing about BC pricing, learn this: never edit regular price during a temporary sale. Edit sale_price.

#"I want a permanent price change" → edit price

You are repositioning a product. The new price is the new normal. Edit price. Leave sale_price and retail_price alone unless you want an anchor.

#"I want to show a strikethrough but no actual sale is running" → set retail_price above price

You want the perceived-discount feel for a product that has never been on sale. Set retail higher than the selling price. The strikethrough appears.

Caution: in some jurisdictions, displaying an MSRP that no retailer has ever actually charged can trigger consumer-protection complaints. Use the legitimate manufacturer MSRP if it exists. If you are the manufacturer, document the prior selling price you are anchoring to.

#"I want a sale AND a strong anchor" → edit both sale_price and retail_price

The combination above. Sale price below regular, retail above regular. Customer sees: MSRP $60, regular $50, sale $40. Two anchors reinforce the urgency.

#"I want a sale, but only on selected variants" → edit sale_price per variant

Variants inherit the parent's prices unless overridden. To discount only the XL size, set sale_price on the XL variant. The other sizes keep the parent's pricing.

Note: variant-level pricing is where most CSV imports go wrong. A spreadsheet autofill can populate sale_price on all variants instead of just XL. Our app handles variant-level discounts with SKU-pattern filters: SKU ends with "-XL" matches only the right variants.

#The MSRP-anchored sale strategy

For categories where customers shop by perceived discount (consumer electronics, sporting goods, branded apparel, premium home goods), setting MSRP at the manufacturer's stated value and using sale price for promotional drops is the highest-converting pattern.

The setup:

1. Set retail_price to the manufacturer's MSRP for every product. This is the anchor. It should rarely change.
2. Set price to your normal selling price (often below MSRP - a sustained "everyday discount").
3. For promotions, drop sale_price further. Now you have three tiers: MSRP $1,000 → everyday $850 → sale $720.

Why this converts: customers calibrate against the highest visible number. MSRP as the anchor justifies your everyday price as already a good deal. The sale price reads as additional savings, not as your normal price.

Where it backfires: if you set a fake MSRP that no one has ever charged, it reads as deceptive after the first comparison-shopping click. Customers who Google your product see the real MSRP nowhere except your site. This converts initially but tanks repeat purchase.

Implementation: if your catalog has 5,000+ products and no MSRP set, the right move is a one-time campaign that sets retail_price from a data source (manufacturer feed, supplier export, your historical max selling price). Bulk Price Editor's "Set retail = price" action does this in one campaign, then you can build sale campaigns on top.

#When MSRP is NOT the right strategy

Three scenarios where setting MSRP higher than your price hurts more than helps.

#1. Premium positioning

If your brand sells at a premium and competitors discount, the absence of a strikethrough is itself a signal. Apple does not show MSRP. Most luxury brands do not. A clean price reinforces "this is what it costs". A strikethrough cheapens that.

#2. MAP-restricted categories

If you sell brands with strict MAP (Minimum Advertised Price) policies, advertising below MAP can lose your dealer status. In this case, you typically set price at MAP, use sale_price carefully (only when MAP allows promotions), and use cart-stage promotions for the deeper discounts that legally apply at checkout.

#3. Trust-sensitive categories

For services, custom goods, or anything that does not have an established market price (custom embroidery, made-to-order furniture, hand-built bikes), an MSRP claim is unverifiable. Customers know it. Skip it.

#How Bulk Price Editor exposes all three fields

The reason we ship a separate app is that BigCommerce's native bulk-edit surfaces all three price fields one at a time, with one update each, no scheduling, no rollback.

In our app, a single campaign can act on:

• price (regular)
• sale_price
• retail_price

independently. The most common multi-field campaigns we see:

"Set MSRP across the catalog": action on retail_price = "set to price", scope = whole catalog. Done in one campaign. Creates the anchor for future sales.

"Run a sale with MSRP visible": action on sale_price = "decrease by 25%", action on retail_price = "no change" (if MSRP is already set) or "set to price" (to create the anchor if it is missing). One campaign, two simultaneous effects.

"Clearance with strong anchor": action on sale_price = "decrease by 40%", cent override .95, nearest-dollar on. The combination renders cleanly at $X.95 with the MSRP strikethrough still showing.

The full action set per field (17 total combinations across regular/sale/retail): increase or decrease by percentage, increase or decrease by fixed amount, set to fixed value, set to compare price, cent override with optional nearest-dollar rounding. The feature deep-dive on the home page lists every combination.

#What about MAP - is there a fourth field?

No. BigCommerce does not have a dedicated MAP (Minimum Advertised Price) field, even though many B2B catalogs need one.

The practical workaround:

1. Set price at your MAP value. This is your advertised price - the floor for what shows on the storefront, in feeds, and in Google Shopping.
2. Use sale_price carefully - only when the manufacturer's MAP policy explicitly allows promotions.
3. For deeper discounts that legally apply only at checkout, use BigCommerce Promotions (cart-level rules). These can drop the actual charged price below MAP without violating the advertised-price rule.

Some MAP-strict brands explicitly prohibit BigCommerce sale_price usage entirely. Read the dealer agreement.

#A quick MSRP audit you can run today

If you do not know what state your catalog is in, run this check in your BigCommerce admin:

1. Export your catalog as CSV.
2. Sort by retail_price ascending.
3. Count rows where retail_price = 0 (or blank).

If more than 30% of your catalog has no MSRP set, you are leaving a perceived-discount signal on the table. Setting MSRP across the catalog is a one-time campaign in Bulk Price Editor using the "set retail = price" action, then ramping it up over time as you collect real manufacturer data.

#Where to go next

• How to bulk edit prices in BigCommerce in 2026 - the foundational tutorial covering all three native methods and the app workflow.
• How to schedule Black Friday sales without the stress - the BFCM playbook that uses the MSRP-anchored strategy heavily.
• Install Bulk Price Editor on BigCommerce - 3-day trial covers a full MSRP audit and sale campaign.
• BigCommerce official catalog API documentation - canonical reference for the price, sale_price, and retail_price fields.

The three-field model is more powerful than most BigCommerce stores use. Get the storefront behavior straight first, then layer the strategy on top.