A BigCommerce store running a bank transfer or purchase-order gateway sends every customer who chooses that option straight to the order confirmation page the moment the order is placed. No payment has been captured yet. BigCommerce's own support documentation for offline payment methods confirms the order sits in an Awaiting Payment status until someone manually updates it after the money actually arrives, but the customer still lands on the same confirmation page a paid card order would reach. Most GA4 and pixel integrations fire their purchase event on that page load, not on a later payment-confirmed status change, which means the store is reporting revenue for orders that may never get paid at all.
That single bug does not show up in a single result on page one for "bigcommerce audit checklist." Every ranking checklist runs the same generic template: page speed, Core Web Vitals, SSL, theme and app bloat, on-page SEO. Real issues, worth fixing, and completely blind to whether the numbers a dashboard reports are actually true.
Why the standard checklist never gets there
Public BigCommerce audit checklists are written for a general ecommerce audience, often the same template reused across Shopify, WooCommerce, and BigCommerce with the platform name swapped in the title. That's fine for speed and SEO, which genuinely don't vary much by platform. It's exactly why the checklist never asks a platform-specific question: where does this store's analytics script actually live, and does it fire on a confirmed order?
BigCommerce's architecture makes that question more complicated than it looks, for three reasons most guides never encounter because they're testing a single default storefront.
The checklist a measurement-first BigCommerce audit actually runs
1. Confirm the purchase event fires on a paid order, not a page load
Pull a sample of orders placed through an offline payment method, bank transfer, cash on delivery, or a manually processed gateway, and check whether GA4 or your pixel logged a purchase for each one. If the integration is listening for the order confirmation page rather than a payment-captured webhook or order-status change, it will have counted every one of them as revenue the moment the order was placed, whether or not the store ever got paid.
2. Check whether Script Manager is missing a second channel entirely
BigCommerce's Scripts API documentation confirms that Script Manager, the control-panel screen most teams use to install GA4 and GTM, is scoped to a single channel's settings. A store running more than one storefront, a secondary regional site, a B2B Edition buyer portal, or a second sales channel, needs the tracking script added separately to each one. Adding GTM to the main storefront channel does nothing for a second channel's traffic or orders; that channel keeps running, keeps taking orders, and stays invisible to whatever GA4 property the team actually checks.
3. Verify API-installed scripts and Script Manager aren't running two copies of the same tag
The same Scripts API documentation notes an ownership quirk worth testing directly: a script installed through the API can only be edited or removed by the API account that created it, while an authorized control-panel user can edit or delete any script, including ones the API installed, through Script Manager's own interface. That split means a developer-installed GTM container and a marketing-team-installed GTM container can both be live at once, with Script Manager showing only the one the UI knows how to manage. Check your network tab for two GTM container IDs loading on the same page, not just one green checkmark in Script Manager.
4. Confirm a headless or Catalyst storefront actually shows its scripts in Script Manager
If the storefront is headless, built on BigCommerce's Catalyst framework or a custom frontend on the Storefront API, don't assume an empty Script Manager list means no tracking is running. Catalyst didn't support rendering control-panel scripts until version 1.1 added script support through the GraphQL Storefront API; earlier builds, and most fully custom headless storefronts, fire analytics tags through code in the application itself. That code lives in a developer's repository, not anywhere a marketing team checks, so audit the actual rendered page source and network requests, not the admin panel.
5. Reconcile BigCommerce's own order export against what GA4, Meta, and Google Ads reported
Pull a fixed date range from BigCommerce's order export and compare total revenue against what GA4, Meta, and Google Ads each reported as purchase revenue for the identical window. Any platform more than a few percent off needs an explanation, not a shrug. This is the same reconciliation discipline behind a GA4 and Shopify revenue mismatch audit, and it's the step every free checker skips because it requires pulling real order data, not just confirming a tag fired once in a test.
6. Check whether a native BigCommerce integration and GTM are both sending the same event
BigCommerce ships a built-in Google Analytics connection alongside the option to install GA4 manually through GTM. Running both at once, without disabling the native integration, duplicates every page view and purchase event, inflating session counts and revenue in a way that can look like growth until someone reconciles against the order export. If your container is doing the real work, the native integration should be off.
7. Confirm consent settings aren't blocking tags for the wrong visitors
A consent management script sits in front of every tag on this list, and a scope mistake here is invisible until someone tests it directly. Test the accept and reject paths from more than one region before trusting the setup, the same verification a Google Consent Mode v2 rollout requires on any platform, BigCommerce included.
8. Re-check after any channel launch, checkout change, or Catalyst upgrade
A tracking audit done before a new storefront channel launched, or before a migration to BigCommerce's Optimized One-Page Checkout, is auditing a setup that no longer exists. Treat the reconciliation in step 5 as a standing check after any change that touches checkout, payments, channels, or the storefront framework itself, not as a one-time task finished when the first audit closes.
The one number that actually tells you if this is broken
Pull BigCommerce's order export for the last 30 days and compare total revenue against what GA4 reports as purchase revenue across every channel the store runs, not just the default one. That single percentage gap tells you more about whether your numbers can be trusted than any speed score or theme audit ever will. A small, explainable gap, from timezone differences or a known excluded order status, is normal. A gap that's wide, unexplained, or different per channel is the signal that a script, a channel, or an offline-payment flow is quietly miscounted.
If that number is wrong and nobody can say with confidence which script owns the purchase event or whether a second channel is even being tracked, a fixed-scope BigCommerce audit reconciles every tag source against the order data directly, starting at $500 and delivered in one to two days, with the fee credited toward implementation if you move forward within 60 days. For a broader read across tracking, CRO, paid media, and reporting together on the same platform, the full ecommerce audit service scopes all four in one fixed-price engagement on the same terms.
Platform-specific measurement gaps aren't unique to BigCommerce. The same discipline applies on Shopify and WooCommerce, each with its own version of the same underlying question: does the revenue number on the dashboard match what the store platform says actually happened.
