Most Shopify brands do not need an enterprise billing platform. They need one system that owns charge calculation. The threshold is commercial complexity, not revenue: contract pricing, usage charges, multi-entity invoicing, and mid-cycle changes your subscription app cannot version.
The question is never whether your billing can handle another customer. It is whether it can handle another exception without someone opening a spreadsheet.
Ecommerce subscription businesses run a median annual churn rate of 4.25%, and 1.38 points of that are involuntary, meaning the payment simply failed. Those figures come from Recurly network data published in July 2026. Read them together, and roughly a third of the subscribers an ecommerce brand loses never decided to leave. They were lost by the billing system.
That is the part of subscription commerce nobody puts in the launch deck. Standing up a subscription offer is genuinely easy now. You pick an app, build a monthly plan, and start charging on schedule. The difficulty arrives eighteen months later, when the same business is running three markets, two contract price lists, a usage based add on, a bundle, and a wholesale channel, and the question “what should this customer be charged this month” no longer has one obvious answer.
At that point billing has stopped being a checkout feature and has become a revenue operation, connecting product data, customer agreements, consumption records, invoices, payments, taxes, accounting, and customer service. This piece is for the operator standing at that line, trying to work out whether the fix is a better app, a dedicated billing layer, or a finance process nobody has written down yet. It is not an argument for buying the largest platform you can afford.
A recurring payment repeats a charge on a schedule, while subscription billing decides what the charge should be, when it applies, and why. That calculation can depend on a fixed fee, a quantity, a user count, consumption, a tier, a discount, a commitment period, or several of those at once. A payment processor solves the first problem. A data model solves the second.
Shopify models this more carefully than most merchants realize. In Shopify’s own developer documentation on selling plans, every selling plan carries four separate policies: billing frequency, delivery frequency, inventory behavior, and pricing. Those are four independent dials, and the moment your commercial terms need a fifth, you are outside what the plan object can express.
The detail worth internalizing is what happens next. Shopify creates a subscription contract when a customer checks out on a selling plan, and then detaches that contract from the plan that created it. Updating the selling plan does not modify contracts that already exist. This is correct behavior and it is exactly the versioning discipline enterprise billing suites charge six figures to provide: a new offer must not silently rewrite the agreement an existing customer signed. It also means that if you have changed your subscribe and save discount three times in two years, you are running three price populations right now, whether or not anyone has looked.
A single product store needs none of this examined. A brand selling a physical product on replenishment, plus a service plan, plus usage based extras, plus installation, under one customer agreement and across two tax jurisdictions, needs it examined before the next price change, not after.
Your subscription app has become the bottleneck the moment a human recalculates credits, prorations, or usage charges in a spreadsheet every billing cycle. Complexity grows quietly, so teams normalize the workaround long before anyone prices its operating cost. The signals below are the ones that show up first.
Before you conclude the architecture is the problem, check the cheaper explanation. In the Recurly data, involuntary churn runs at 1.30% a year for businesses in the $10 to $25 average revenue per customer band and falls to 0.18% above $250. Low ticket consumer subscriptions lose the most revenue to failed cards, and that is a dunning and retry problem, not an architecture problem. Recharge, Stay AI, Skio, and Appstle all ship retry logic and card updater tooling that will recover a meaningful share of it. If your leak is retention rather than rules, the fix lives in the subscription ecommerce growth and retention playbook, and no billing platform will do it for you.
A billing architecture has to do four jobs: version commercial rules, ingest and rate usage events, process lifecycle changes as one transaction, and produce invoices that trace back to the rules that made them. Any evaluation that does not test all four is a demo, not a diligence process.
Versioned commercial rules means a controlled definition of plans, bundles, add ons, contract terms, eligibility, price tiers, and discounts, with changes versioned so an updated offer does not alter agreements already in flight. Usage capture means the platform receives consumption records, validates them, removes duplicates, assigns them to the right account, and applies the correct rating rule before anything is billed. Get the deduplication wrong and you will bill twice, which costs more in support and refunds than the revenue was worth.
Lifecycle handling is where most stacks quietly fail. Customers pause, upgrade, downgrade, add seats, change quantities, and cancel, and each event touches entitlements, fulfillment, proration, invoice timing, and revenue recognition at once. Shopify’s documentation carries a worked example of how badly this can land: on a subscription anchored to the fifteenth of the month, if a payment fails and does not clear until the sixteenth, fulfillment slips to the fifteenth of the following month unless the app sets an origin time on the billing attempt. One declined card, one missing parameter, and a customer waits thirty extra days for a box they paid for. Nobody in that chain did anything visibly wrong.
Auditable invoicing is the fourth job and the one finance will care about at close. Every invoice should trace to the plan, contract, usage records, discounts, taxes, and adjustments that produced it, so exceptions can be investigated without rebuilding the calculation by hand. If your team cannot answer “why is this number this number” in under five minutes, you do not have auditable invoicing, whatever the vendor called it.
SAP BRIM fits organizations that already run SAP, because it is not a standalone billing app you attach to a Shopify store. That is the single most important thing for a merchant to understand before booking a demo, and it is rarely the first thing said.
SAP’s own onboarding documentation is direct about the dependency: an edition of RISE with SAP is required to use the package, and BRIM is technically part of SAP S/4HANA. The suite is four components, Subscription Order Management, Convergent Charging, Convergent Invoicing, and Contract Accounting, and it is built for high transaction volumes, complex pricing, receivables, and contract accounting across telecom, logistics, and similar operations. If your company is already on S/4HANA and your billing is the weak link, this is a serious answer. If you are a DTC brand on Shopify with QuickBooks behind it, the honest read is that you would be buying an ERP program to solve a billing problem.
Between the subscription app tier and the SAP tier sits the layer most scaling merchants actually need, and it has real names: Zuora, Chargebee, Recurly, Stripe Billing, and Maxio all handle contract pricing, usage rating, proration, dunning, and revenue recognition without requiring you to replace your ERP. Below that tier, the subscription apps built on Shopify’s own subscription APIs cover replenishment and simple memberships perfectly well, and Shopify’s first party subscriptions app costs nothing to run.
The threshold is complexity, not revenue. A $50M single SKU replenishment brand may never need more than an app. A $6M B2B merchant with negotiated contracts, metered services, and three legal entities can hit enterprise requirements years earlier. This is the same readiness test that decides whether a brand is ready for a dedicated wholesale platform, where the honest answer is usually to prove the channel natively first. The filter is not your revenue. It is whether you have the operation to feed the system you are about to buy.
Every major data object needs exactly one owning system, because two systems that can both change a price will eventually disagree about one. Unclear ownership is the root cause of most billing errors that get blamed on software quality, and it is a decision, not a feature.
A practical division looks like this. The ecommerce platform owns the shopping experience and online order capture. The CRM owns opportunities, account relationships, and sales activity. The CPQ or pricing layer owns complex configuration and negotiated commercial terms. The billing platform owns charge calculation, billing schedules, and adjustments. The payment service provider executes collection. The ERP and finance systems own accounting, receivables, and statutory reporting. The entitlement or fulfillment system controls what the customer actually receives. Integration then transmits approved events between them and preserves identifiers, so any transaction can be traced end to end.
This is the same failure pattern that shows up in inventory, one layer over. On the Fastlane podcast, Katana co CEO Ben Hussey described what happens when Shopify, Amazon, wholesale, and TikTok Shop all hold their own view of stock, and the estimate he works with is that a typical product brand loses around $21,000 a year to stockouts on best sellers alone. The full conversation on connected multichannel operations is worth an hour if you are drawing these boundaries now. Billing has the identical shape: the cost is not the software, it is the reconciliation nobody budgeted for.
If you sell B2B alongside DTC, draw the boundary before you build the channel rather than after. Account specific pricing, payment terms, and approval workflows all create new owners of the same fields, which is covered in more depth in this guide to B2B order management on Shopify.
Standardize the core and configure the edge: customer, product, contract, and accounting concepts stay identical across markets, while tax treatment, currency, invoice format, and payment preference become configuration. Brands that invert this end up with one manual process per country, and the process count grows faster than the revenue does.
International growth adds currencies, tax rules, statutory invoice requirements, language, payment preferences, and legal entities. Omnichannel growth adds marketplaces, sales representatives, distributors, and direct contracts. Each of those is a new source of billable events, and each one arrives with its own idea of what a customer record looks like. The design goal is that expansion changes configuration values, not billing logic, because logic changes need testing and configuration changes do not.
Channel constraints are real and specific, so check them before you promise a launch date. Selling subscriptions through Shopify POS requires Shopify Payments to be enabled, POS version 10.13 or later, and a subscription app that has built a POS user interface extension, which not all of them have. Mixed delivery methods are not supported on subscription checkouts either, so if a customer picks local pickup with a subscription in the cart, the whole order is local pickup. Neither limit is a dealbreaker. Both are the kind of detail that turns a two week rollout into a two month one when nobody checked first.
Migrate in cohorts, run both billing engines in parallel on real scenarios first, and never move every customer at once. A subscription migration is not a data import, because you are moving live financial agreements that will charge real cards while you work.
Start by inventorying every active plan, discount, contract type, and exception, then separate the standard products from the legacy arrangements that need special handling. Those legacy arrangements are the whole risk. Clean the customer, product, and contract data before anything moves, because a migration is the worst possible time to discover that two records describe one account. Then run the old and new calculations side by side on representative scenarios and reconcile the outputs: invoices, taxes, receivables, and the accounting entries behind them. Only then move customers, in cohorts, with a written rollback path and a support script for the week it is happening.
Test more than a clean monthly renewal, because a clean renewal is the one case that always works. Simulate mid cycle upgrades and downgrades, failed payments and the full retry sequence, refunds, usage corrections, contract renewals, tax rate changes, and cancellations. Edge cases are where revenue leakage and customer anger actually live. Pay particular attention to stored payment credentials, which are the one asset you cannot recreate from a spreadsheet export. If the new provider cannot accept your existing tokens, you are not migrating subscriptions, you are asking every subscriber to re enter a card, and a meaningful share of them will use the moment to leave instead.
Four metrics expose billing problems before revenue does: invoice accuracy, manual adjustments per billing cycle, failed payment recovery rate, and time to launch a new offer. Track those monthly and you will see the architecture straining a quarter or two before finance raises it.
Add the supporting set as your operation grows: time to resolve a billing dispute, revenue leakage, processing cost per account, reconciliation effort at close, and your involuntary share of total churn. That last one is the cleanest early warning in the whole list, because it is the one number that separates a retention problem from a payments problem. Ecommerce sits at 1.38 points of involuntary churn against 4.25 total in the Recurly benchmarks, so if your own split is materially worse than roughly a third, the fault is in your billing machinery rather than in your product.
None of this argues for installing the largest platform you can justify. The objective is a billing system appropriate to the promises you have actually made to customers. A lightweight tool validates the model. Stronger product governance, lifecycle management, integration discipline, and financial control become necessary as the promises get more complicated, and not one day before.
The best architecture makes complexity manageable rather than invisible. You should be able to explain every charge on every invoice, change your product catalog without breaking old contracts, and enter a new market without adding manual work at the same rate you add customers. When commercial rules, usage, invoices, payments, and accounting stay connected, new offers become a configuration decision instead of a project. That is the whole return, and it is worth more than the feature list you were shown in the demo.
A subscription app schedules and collects a recurring charge, while a subscription billing platform calculates what the charge should be from your commercial rules. Apps like Recharge, Skio, or Shopify’s own subscriptions app handle plans, skips, swaps, retries, and a customer portal, which covers replenishment and simple memberships completely. A billing platform adds contract level pricing, usage rating, proration across mid cycle changes, revenue recognition, and invoices that trace back to their inputs. The practical test is whether anyone on your team recalculates a charge by hand. If they do, your rules have outgrown your app, regardless of how much revenue you are processing.
Move when commercial complexity, not revenue, breaks the app, which usually shows up as manual calculation every billing cycle. Concrete triggers include negotiated contract pricing per account, usage or consumption based charges, prorated upgrades and downgrades that your app rounds wrong, multiple legal entities invoicing the same customer, and month end close that needs a spreadsheet to reconcile. A $50M single SKU replenishment brand may never hit any of them. A $6M B2B merchant with metered services can hit all five. Before you shop, write down every price exception a human touched last month. That list, not your revenue, is the specification you are buying against.
SAP BRIM can sit behind a Shopify storefront, but it assumes an SAP landscape you already own rather than integrating as a Shopify app. SAP’s onboarding documentation states that an edition of RISE with SAP is required to use the package, and that BRIM is technically part of SAP S/4HANA. In practice the storefront keeps owning discovery, conversion, and online order capture, while orders and billable events flow through integration into the billing and finance layer. For a merchant without SAP already in place, evaluating BRIM means evaluating an ERP program, which is a different decision with a different budget and timeline.
The main alternatives for mid market ecommerce are Zuora, Chargebee, Recurly, Stripe Billing, and Maxio, all of which handle contract pricing, usage rating, dunning, and revenue recognition without requiring an ERP replacement. Choose based on where your complexity actually sits. Usage heavy models favour platforms with strong rating and mediation. Contract heavy B2B models favour platforms with real quote to cash support. If your complexity is mostly retention rather than rules, stay on a Shopify subscription app and invest in dunning and portal experience instead, because a billing platform will not reduce voluntary cancellations.
Migrate in cohorts after running both systems in parallel, and confirm your stored payment credentials can transfer before you commit. Inventory every plan, discount, contract type, and exception first, separate legacy arrangements from standard products, then clean customer and contract data. Run the old and new calculations against representative scenarios and reconcile invoices, taxes, and receivables before any customer moves. Test mid cycle changes, failed payments, refunds, usage corrections, renewals, and cancellations, because clean renewals always pass. Keep a written rollback path and brief support for the transition week. If tokens cannot transfer, expect churn at the re entry step and plan the offer that offsets it.
