BigCommerce price lists: trace context, currency and fallback

Check the store’s entitlement and pricing surface

As checked October 31, 2026, the public US BigCommerce comparison uses Core, Growth, Scale and Performance, with Price Lists checked only for Performance. Existing contracts and other regions require separate verification. Check the current pricing table and the store’s agreement instead of automatically renaming an old Enterprise entitlement.

Ask the account owner to confirm that price-list access is provisioned for the affected store and storefront. Keep that evidence with the trace. If the feature is unavailable, choose a supported pricing design or obtain an actual upgrade quote. A developer-documentation endpoint is not proof of purchased entitlement.

Also identify the surface being diagnosed: a storefront, an ERP export, a marketplace listing or a custom app. BigCommerce documents price-list assignments for storefront channels, not a blanket override for marketplaces such as Amazon or Facebook. Do not repair a marketplace feed by assuming storefront price-list behavior applies there. See the Price List API scope.

Freeze the complete shopper context

Copy the failing context into a row before editing anything. Use internal IDs alongside human labels where an authorized operator can retrieve them. A product name is not a variant identifier, and a domain label is not enough to prove the storefront channel.

Assignments can target a channel, customer group, or their combination; records specify variant and currency. BigCommerce documents these separately. Inspect every applicable assignment rather than guessing which one won. If overlapping assignments leave selection uncertain, preserve the case and have the pricing owner establish the actual selected list in a controlled environment before a broad edit.

Trace the primary list, then only the fallback layers actually enabled

With priority order enabled, current documentation allows up to five ordered fallback layers. Resolution uses the primary list first, then active layers in their configured order, then the catalog. The first available variant record wins. The primary must be active, and layered lists must share the tax type. Read the cascading price-list rules.

Do not assume that cascading is active in every store. Have the pricing owner confirm availability, priority-order state, the primary list and the actual ordered layer IDs. For each layer, record active state and whether the required variant/currency is present. “Fallback list exists” is not enough if it is inactive or never attached to this primary.

If there are no applicable configured layers, use the ordinary missing-record catalog fallback described in the Price List API guide. Keep currency mode explicit: transactional-currency pricing uses that currency’s records, while display-only currency uses conversion. If the relevant multi-currency price list is unavailable, the API guide describes automatic conversion of the catalog price. Do not assume the default-currency contract record is always converted. Record currency coverage and the observed source before treating a missing amount as a deliberate contract price.

The cheapest price is not the rule. If the first active layer with a matching record says $17 and a later layer says $15, the documented ordered model does not search for the lowest amount. The useful question is whether $17 is the intended source for this buyer. Correct the ownership or configuration after proving the mismatch; do not reorder layers simply to make a preferred number appear.

Separate record selection from the final cart calculation

Product bulk tiers do not apply to variants with price-list records, and customer-group discounts do not apply to price-list prices. Price-record bulk tiers are a separate mechanism. Modifiers, promotions, coupons and tax can affect the eventual amount. See BigCommerce’s order of operations and record bulk-pricing notes.

This distinction explains a common false diagnosis: the product price is correct, but the operator expected an additional group discount or the catalog’s bulk tier. Identify the exact rule that was expected to apply and whether that rule belongs to catalog pricing or the selected record. Do not copy the catalog discount into the record until the pricing owner approves the resulting commercial terms.

For the first comparison, isolate the case from optional adjustments in a controlled test configuration. Then reintroduce the merchant’s real conditions one at a time: record sale/bulk amounts, option modifiers, promotion eligibility, coupon and tax treatment. Keep quantity and selected options unchanged when comparing product, cart and checkout. A line subtotal, tax-inclusive display and order total are different values, so label the amount being compared.

Also check a mixed basket if the business relies on quantity tiers across variants. Do not infer tier eligibility from the visible item count alone. Ask the owner to record which items qualify under the relevant pricing mechanism and verify the cart result. Preserve any unproven rule as an open acceptance item.

Run a small context matrix before a broad price import

Begin with the failing actor and exact item. Then add controls that change one input at a time. A useful minimum is guest versus wholesale on the affected storefront, wholesale on the second relevant storefront, the same variant in each supported transactional currency, and a second variant with a known record. Add a quantity below and at the relevant tier boundary.

For every row, write the expected record source and expected amount before observing the result. Capture the product selection, cart line and checkout line under the same context. Use synthetic data and your authorized test/release process; do not place a real paid order merely to fill a worksheet. If checkout completion is necessary, agree on the controlled transaction and reconciliation separately.

A row passes only when the expected source, amount and permitted access agree. A public shopper seeing the right retail total does not prove wholesale prices are isolated. Test a disallowed actor as well as an allowed buyer where confidentiality is a requirement. If the UI hides a price but another permitted public surface exposes it, the access requirement remains unresolved.

Save the candidate list/assignment snapshot and the evidence timestamp. That separates a deterministic pricing-rule problem from a source update that arrived between your two observations. Rerun the whole affected context set after a repair, including one previously correct control.

Use the first divergence to choose the repair owner

Price-list changes do not fire product or SKU webhooks; assignment events are separate. Do not build freshness assumptions around a product event that is not emitted. The webhook notes explain this boundary. Have the integration owner document how record updates are acknowledged and reconciled, with source and destination times.

If the correct record never reached BigCommerce, investigate the update path. If it arrived and the wrong record is selected, investigate context. If selection and cart are right but a page is stale, investigate the display path. These observations prevent a pricing import from masking a synchronization incident.

Repair one layer and leave a reconciliation record

Have the responsible owner propose the smallest correction, its affected groups/channels/variants/currencies and the prior values needed for recovery. Obtain the normal commercial approval for changed terms. A technical mismatch does not authorize a new discount or a different negotiated price.

Apply the candidate through the store’s established process, rerun the affected matrix and compare the correct control. Record expected and actual totals, source record, update acknowledgement, date and accepted limitations. If the change crosses an ERP boundary, reconcile both systems before closing it. A one-way update acknowledgment is not proof that the buyer sees the intended amount.

Your next action is to fill one failing row, including the selected list and fallback evidence. If you cannot identify that source yet, keep the price unchanged and scope the diagnosis. Once the source is clear, the repair and its acceptance conditions become much smaller.