At a glance
Per-channel revenue stacked by currency_code over the trailing 30 days. The merchant’s view of “which channels are bringing in which currencies”, essential for FX exposure planning, payment-processor configuration, and tax-jurisdiction routing. BigCommerce’s multi-currency support pairs naturally with channel-native sales; this card is the cross-product visibility merchants need to manage that stack.
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK skincare brand on BigCommerce Enterprise with multi-storefront (UK, US, EU) and B2B Edition. Snapshot for 1 Apr to 30 Apr 26.
What’s interesting:
- Most channels are mono-currency by design. Each storefront, each marketplace listing region, each POS terminal is currency-locked. The interesting row is the B2B portal, which carries 4 currencies because B2B Edition customer groups can be regionalised. That’s where FX exposure planning lives.
- B2B portal currency mix tells the wholesale-customer geography story. 62% GBP / 20% USD / 13% EUR / 5% AUD reflects the merchant’s wholesale customer book by country. If GBP suddenly drops to 40% MoM, the cause is usually a US wholesale customer placed an unusually large PO, not currency-trend movement. Always check absolute volumes alongside percentages.
- The headline GBP-equivalent total is FX-rate-sensitive. When USD strengthens 5% vs GBP, the total grows 5% just from FX without any volume change. For accurate revenue trend always view in either native-currency-only mode or constant-currency mode (using last-period FX rates). Configure under Settings → FX → Constant currency.
- Payment processor settlement gap. Merchant’s Stripe US account settled $108,500 on US storefront orders, matching this card. But the merchant’s Stripe UK account settled £179,890 on UK orders, less than the card’s £180,420. The £530 gap is Stripe’s currency conversion fees on a small sub-set of cross-border UK-storefront orders that processed through USD acquirer routing. Reconcile against payment processor before flagging as a data issue.
- EU storefront concentration is pure-EUR. Healthy from an FX-exposure standpoint, the merchant’s EU costs (some Lithuanian fulfilment) are EUR-denominated, so EUR revenue and EUR cost natural-hedge.
- For finance teams, view in native-currency mode for FX exposure planning; view in converted mode for board reporting.
- For the B2B portal specifically, watch for currency-mix shifts month-over-month, they signal customer-book changes.
- Reconcile against payment processor for each currency separately; the gateway’s FX fee creates a small structural gap.
- Pair with BC Revenue by Currency for the cross-platform currency rollup.
- For multi-storefront stores, this card is essential for understanding which storefront drives which currency exposure.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Settings → Currency shows the currencies configured on the store. Analytics → Sales shows revenue but doesn’t natively split by currency-and-channel; you need Reports → Custom to build the cross-tab. For multi-storefront: Storefronts → All storefronts shows per-storefront revenue; pair with the configured currency for each storefront. Why our currency split may differ from BC’s storefront analytics:
Cross-connector reconciliation (when payment processors are connected):
The per-channel currency mix view is BC-aligned with similar cards on Shopify (per
presentment_currency) and Adobe Commerce (per base_currency_code); merchant-facing semantics are equivalent though Adobe’s multi-currency model is stronger and Shopify’s is weaker than BC’s.