The Multi-Brand Operator Playbook

Why processor freezes keep happening to multi-brand operators

Every operator we talk to has a Stripe freeze story. The version that lands in our inbox most weeks goes like this: a holdco running six consumer brands has been clean on one Stripe account for three years — low disputes, clean auth rates, reasonable refund velocity. Then one of the six brands runs a Q4 promotion that converts too hard, attracts a bad cohort, and the chargebacks land in January. The portfolio ratio tips to 0.94%. By Wednesday, the entire Stripe account is frozen. All six brands. $340k in-flight. The support ticket takes eleven days to get a human.

This is not a Stripe bug. It's what the 0.90% chargeback threshold is designed to do: protect the acquirer from systemic risk. The problem is that the operator's architecture — six brands on one MID — looks systemic to the acquirer even when it isn't. There's no concept of "Brand A is the problem, freeze just Brand A's funds." The freeze is per merchant account, not per descriptor.

We've seen this flavor of incident fifty-plus times now across our operator book. The pattern is consistent: somebody — usually a junior growth lead — runs an aggressive acquisition push on the brand with the lowest AOV. That brand has always had marginal dispute hygiene. The holdco's finance team doesn't see the spike for three weeks because Stripe's dashboard shows aggregated metrics across the six brands, and the five healthy ones dilute the one bad one in the reporting view. By the time the ratio crosses the line, the damage is already in the pipe.

The 72-hour freeze playbook is a real document operators should have on file before they need it. But the deeper problem is the account architecture. There are essentially three ways multi-brand operators land in this trap:

• One MID, many brands. Cheap, fast, reconciliation hell. One bad brand sinks the fleet. This is 80% of multi-brand operators under $10M/yr.
• Many MIDs, many Stripe accounts. One Stripe account per brand. Safer on freeze risk (one brand freezing doesn't touch the others), but now you have 12 dashboards, 12 reconciliation flows, and 15 Stripe accounts worth of operational overhead. Reconciliation cost explodes. Rates don't improve.
• One parent acquirer, many descriptors. Harder to set up. Nearly impossible to undo a freeze at the descriptor level if the parent still views you as one merchant. Requires either a friendly acquirer relationship or an orchestration layer that isolates ratios per descriptor on your books even when the acquirer aggregates them on theirs.

The reason freezes keep happening isn't that acquirers are hostile. It's that the acquirer sees a merchant account, and the operator sees brands. Those are not the same unit. A brand is a descriptor, a customer-facing identity, a P&L center. A merchant account is an underwriting relationship with a bank. When you conflate them — by stuffing six brands into one MID — you inherit the acquirer's unit of measurement whether you wanted to or not.

The fix is not "be more careful with your worst brand." The fix is architectural. You need a layer between your brands and your acquirer that tracks ratios per descriptor on your books, flags outliers three weeks before the acquirer sees them, and can route traffic away from a degrading descriptor before the aggregate crosses a threshold. That layer is what people mean when they say "payment orchestration" — though the word gets used for at least four different things, which we'll untangle next.

Before we do, one more thing on freezes: the operators we've seen handle them best have all had the same three artifacts ready before the call. A descriptor-level dispute timeline (showing which brand's ratio drove the aggregate). A reserve-math model that shows what a reasonable hold looks like versus what the acquirer is proposing (see our reserve-math tool). And a signed letter from a backup acquirer stating conditional willingness to pick up the portfolio. None of these are guarantees, but operators who walk into a freeze call with all three get unlocked in 5-6 days instead of 11-14.

The orchestration layer: what it is, what it isn't

"Payment orchestration" is the most abused word in this space. Depending on who's talking, it means four different things, and operators waste months evaluating tools that solve the wrong one of the four. Here's how we draw the lines, and why the distinction matters when you're running 3+ brands.

The four things people call orchestration:

• Acquirer switching. Route traffic across Stripe / Adyen / Braintree based on auth-rate heuristics. Solves auth optimization for enterprise DTC. Does not solve multi-brand reconciliation. (Adyen sells this as "Pay by Link," Braintree ships "smart routing," Spreedly is the independent version.)
• PSP abstraction. A single API that speaks to fifteen PSPs so you can swap acquirers without rewriting checkout. Valuable for enterprises launching in new geos. Irrelevant for most multi-brand holdcos under $50M, who mostly just need one parent acquirer that doesn't freeze.
• Payout fan-out and ledger. The money comes into a parent, splits by brand/entity, pays out to the right LLC on the right cadence. This is what multi-brand operators actually need and what the word "orchestration" should probably mean.
• Full aggregation (Stripe Connect, Adyen MarketPay). You become the merchant of record for everyone below you. Regulatory burden skyrockets. PCI scope expands. Good for marketplaces. Almost always wrong for multi-brand operators who are not a marketplace.

We wrote a longer breakdown of the orchestration-vs-aggregation distinction, and it's the single most-cited piece on our site for a reason: operators who choose aggregation when they needed orchestration spend eighteen months unwinding it. The giveaway: if your sub-brands each have their own LLC, their own tax return, and their own bank account — you don't need aggregation. You need a ledger layer.

The orchestration layer that actually matters to multi-brand operators does five things, and if the tool you're evaluating doesn't do all five, it's solving a different problem:

1. Parent-account routing. Every charge lands in one merchant account — your existing Stripe, Square, or Authorize.net — but carries the sub-brand's descriptor. The customer sees their brand on their statement. Your finance team sees one ledger.
2. Per-descriptor ratio isolation. The orchestration layer tracks disputes, refunds, auth rates per descriptor even when the acquirer aggregates them. This is the early-warning system for freezes.
3. Attribution at the SKU + brand level. Coupons, affiliate payouts, and subscription renewals all thread through the ledger with brand + SKU context intact. No more "which brand did that $34 belong to" after the fact.
4. Payout fan-out to legal entities. When Stripe deposits the net settlement, the orchestration layer splits it — by brand, by entity, by whatever your cap table demands — and fans out deposits on your cadence. This is the line between "we're running 12 brands" and "we're actually running 12 businesses."
5. Webhook reliability + dead-letter handling. If your orchestration layer drops a webhook when Stripe retries three times and gives up, you've got a silent revenue leak. The retry + dead-letter pattern is table stakes, not a feature.

What orchestration is not: a BI tool. A CRM. A checkout replacement. A new merchant account. Every operator we've seen make a successful multi-brand transition kept their existing Shopify / Woo / headless checkout, kept their existing acquirer, kept their CRM, kept their support stack. They added one layer on top — the ledger — and deleted approximately seven spreadsheets.

The reason this architecture wins is that it respects the two axes that actually matter. From the acquirer's perspective, you're one merchant — which means you get volume pricing, underwriting continuity, and one relationship to negotiate. From the customer's perspective, each brand is independent — which means descriptors, refund policies, and support channels stay per-brand. The orchestration layer is what translates between those two views.

If you're evaluating tools and you're not sure which of the four flavors a given vendor is selling, ask them one question: "If brand A gets frozen, does brand B keep processing?" A true orchestration layer on a parent acquirer answers "yes — we'd route brand A's traffic to a backup acquirer within 24 hours, but brand B's flows are untouched because the ratio is scored at the descriptor level on our books before it hits the parent's." Aggregation platforms answer "no, we'd freeze both because you're on one sub-merchant account." PSP abstractions answer "we don't manage ratios, that's on you." That one question sorts the category in about ninety seconds.

There's one more category confusion worth flagging explicitly: "payment gateway" vs. "orchestration layer." A gateway (Authorize.net, NMI, USAePay) is the connection between your checkout and the acquirer — it tokenizes cards, encrypts the transmission, and forwards the auth request. Gateways do not do ledgers, do not do multi-brand reconciliation, do not do descriptor isolation. They're plumbing. Operators who evaluate "NMI vs. multiflow" are comparing a wrench to a hardware store. A gateway is a prerequisite for processing, but it's not a substitute for an orchestration layer, and it doesn't solve any of the six problems we laid out above. If your vendor says "we're a gateway that also does orchestration," ask them how disputes are attached to SKUs. If the answer is "via webhooks you'd configure," they're a gateway. If it's "auto-attached at settlement with SKU, coupon, and affiliate-ID context preserved," they're an orchestration layer. The distinction is not semantic — it shows up the first time a dispute comes in and somebody needs to answer it.

The reconciliation math — where operators actually lose 6+ hours/week

Ask a multi-brand operator where their time goes and you'll get the same answer in some version: "Mondays are a write-off." When we dig in, the breakdown is always the same. Here's what we measured across 34 operators in our book running 6-20 brands on mixed acquirer stacks in Q1 2026.

Most of those 6.2 hours don't go to adding numbers. They go to reconciling — matching Stripe payouts to internal orders, mapping descriptors to brands, untangling refunds that came in three weeks after the original charge, chasing a $340 variance that turns out to be a chargeback fee that landed on a different date than the dispute. The work is not hard. It's just endless, and it's all downstream of one architectural mistake: the ledger lives in seven different acquirer dashboards, and the "join" operation is being done by a human with a spreadsheet.

The reconciliation playbook we publish goes deep on the mechanics. The short version: every charge has three IDs that need to stay linked for the life of the transaction. The order ID (from your cart). The charge ID (from your acquirer). The brand/descriptor ID (which tells finance which P&L it hits). When any of those three gets dropped — and they drop constantly, via refunds, chargebacks, manual adjustments, Stripe's own batching — reconciliation becomes detective work.

The other pathology we see: operators who try to solve reconciliation with a BI tool. They pipe Stripe data into Snowflake, bolt on Looker, and think they've solved it. They haven't. BI tools are great for reporting on reconciled data. They're terrible at doing the reconciliation. The reconciliation still has to happen upstream — at the moment the charge lands — or it has to happen manually downstream, and Snowflake doesn't save you from either.

What reconciliation looks like when it's done right: every charge lands in the parent ledger with all three IDs attached, immediately, atomically. Refunds reference the original charge and carry the brand tag through. Chargebacks attach the dispute evidence to the original order automatically. Payouts fan out already split, with a per-entity bordereau attached. Finance opens the dashboard on Monday, sees one consolidated view, and either signs off in fifteen minutes or flags a specific descriptor for follow-up. There's no spreadsheet. There's no cross-dashboard tab-surfing. There's no "which brand did this belong to."

We audited a 14-brand DTC group in March. Pre-orchestration, they had a two-person finance team spending 40% of their combined hours on reconciliation — roughly $62k/year of fully-loaded cost. Post-orchestration, reconciliation dropped to 1.8 hours/week, both people redeployed to analysis and dispute management, and the operator added two more brands that quarter without hiring. That's the real ROI of orchestration, and it's not marketing. It's spreadsheet math you can do on the back of a napkin.

The other cost that nobody models is the cost of being wrong. Manual reconciliation doesn't just take time — it produces errors, and those errors compound. One of our operators found a $47k attribution error from Q3 2024 in early 2025. It had been sitting on the books, miscoded to the wrong brand, for eight months. The discovery triggered a K-1 amendment that cost $14k in accounting fees and spooked a potential buyer enough to knock 0.3x off the multiple during diligence. On a $4M EBITDA business, that's $1.2M of enterprise value evaporated because of one reconciliation error.

If you want to run the full financial close math on what a 20-brand portfolio costs in reconciliation time plus error risk plus deferred diligence, we have a longer treatment. But the headline is that reconciliation is not a back-office chore. It's a strategic liability that shows up on the Day 1 of every diligence process, every tax filing, every investor update. The operators who clean it up early don't just save Mondays. They preserve enterprise value.

One pattern we see consistently in post-mortems: the "reconciliation is fine, we have a process" operators are always the ones with the biggest hidden variances when somebody finally audits. The process feels smooth because nobody is looking for errors — the finance lead is matching charges to orders, but nobody is matching refunds to the right brand, chargebacks to the original dispute, or affiliate commissions to the correct attribution window. By the time it surfaces — usually when an outside auditor or a diligence team pulls a sample — the variance is six or eight months old and the original context is gone. Fixing it is expensive; defending it to a buyer is worse.

The other reconciliation trap nobody talks about: refund timing. Refunds in Stripe carry their own timeline. A charge that settled Monday might get refunded on Friday and the negative appear in the next day's payout. If your reconciliation model doesn't handle T+N refund reversals, you'll book the original revenue in week 1 and discover a "mystery" $2,400 negative in week 2 that nobody can trace without pulling the original charge IDs. Multiply that by 12 brands and 4 refunds each per week and you've got 48 mystery adjustments per week for finance to chase. This is exactly the kind of work that disappears when the ledger attaches refunds to their original charges at write time — and exactly the kind of work that never stops when it doesn't.

Chargeback ratio pooling: how one bad brand sinks the fleet

Chargeback ratio pooling is the most expensive architectural mistake multi-brand operators make, and nobody warns them about it at onboarding. It works like this: when you stuff multiple brands onto a single merchant account, the acquirer calculates your chargeback ratio at the MID level — not the descriptor level. Every brand's disputes add to the same numerator. The denominator is total transactions across every brand. If Brand A has 0.4% disputes and Brand B has 0.5% disputes, you're at 0.45% and everything is fine. If Brand A spikes to 1.8% one month, the pooled ratio jumps, and the entire account — all six or ten or fifteen brands — gets flagged.

This is the mechanism behind 80% of the multi-brand freezes we see. The operator did nothing wrong on most of their brands. One brand — usually the newest, usually the one with the most aggressive acquisition push — had a bad month. The acquirer doesn't care. The acquirer sees one MID, one ratio, one risk event. Freeze.

The chargeback-ratios-across-sub-brands analysis we published in February is the single most downloaded doc on our site — because this math is real and most operators haven't run it. Here's the napkin version for a 6-brand portfolio:

The math is brutal and most operators find out when it's already too late. If your portfolio median ratio is 0.51%, a single brand spiking to 3.5% for one month — which is not unusual after a bad promo — can push the pooled ratio past 0.90%. Every other brand in your portfolio, even the ones at 0.2% disputes, gets swept up in the freeze.

There are three architectural defenses against this, and operators should understand the tradeoffs before choosing:

• One MID per brand. Ratios are isolated. Freezes are isolated. But you're running 12 MIDs, 12 underwriting relationships, 12 reconciliation flows. Operational cost explodes. Rates don't improve (you never hit volume tiers on any one MID). This works for very small portfolios and almost nobody above 6 brands.
• High-risk dedicated acquirer for the problem brand. Isolate the one bad brand on a high-risk processor — something like NMI, Authorize.net with a high-risk ISO, or a direct acquirer relationship. The rest of the portfolio stays on a low-cost acquirer. This is the pragmatic middle ground for operators with one or two problem brands.
• Orchestration layer with descriptor-level ratio tracking. The layer monitors disputes per descriptor on your books, flags degrading brands 2-3 weeks before the acquirer does, and automatically routes degrading traffic to a backup acquirer before the pooled ratio trips. This is what we sell. It's also what operators running 10+ brands eventually build themselves if they don't buy it.

The second-order effect of chargeback pooling is that it also pools the reserves. When the acquirer decides your portfolio has elevated risk, they don't increase the reserve on Brand A — they increase it across the whole MID. We've seen operators go from 0% rolling reserve to 8% across a 12-brand portfolio because one brand's ratio tripped a review. That 8% on a $2M/mo portfolio is $160k of locked-up working capital, every month, until the ratio normalizes. The reserve math tool models exactly this scenario.

The operators who handle this best do three things, early: they instrument per-descriptor ratios on their own books (don't wait for the acquirer dashboard), they set an internal alert at 0.6% — well below Visa's 0.9% — so there's a margin of safety, and they have a pre-negotiated backup acquirer relationship they can route degrading traffic to within 24 hours. That third piece is the hardest to build from scratch and the most valuable part of what an orchestration layer actually provides.

One more note: chargeback ratio pooling is worst on Stripe and Square, because both are aggregators that run very tight risk models designed for single-brand merchants. It's milder on direct acquirer relationships (Fiserv, Worldpay, Elavon via ISO) where you can sometimes negotiate per-descriptor ratio tracking into your underwriting agreement. If you're serious about running 10+ brands long-term, a direct acquirer relationship is almost always the endgame — but the path there is more work than Stripe, which is why most operators start on Stripe and migrate when the cost gets real.

A related failure mode worth naming: the "CE 3.0 representment trap." Visa's Compelling Evidence 3.0 rules, effective April 2023 and expanded in 2025, give merchants a path to auto-win friendly-fraud disputes if they can prove the customer had prior non-disputed transactions with matching IP, device ID, email, or billing address. This is a huge lever for multi-brand operators — one customer buying across Brand A, Brand B, and Brand C creates cross-brand fingerprint evidence that wins disputes at 70%+. But you can only use it if your orchestration layer tracks those fingerprints across brands. Operators running separate Stripe accounts per brand can't invoke CE 3.0 because the evidence lives in separate silos. Operators on a parent ledger win disputes they'd otherwise lose — and that win-rate directly improves the dispute ratio, which directly improves the freeze risk. It's the same data loop, solved once, benefiting every chapter of this playbook.

Rate negotiation: the three levers acquirers actually move on

Multi-brand operators leave 40-90 basis points on the table because they negotiate on the wrong things. They ask for "a better rate" without bringing data. They compare Stripe's list price to Adyen's list price without understanding that both are negotiable by 30-50% above $500k/mo. They accept "blended" pricing that hides interchange markup inside a flat rate. And they do all of this without ever reading a full interchange-plus statement.

Acquirers move on three levers, and only three. Everything else — the "merchant advocate" pitch, the "we'll match Stripe's rate" promise, the "exclusive nonprofit rate" — is theater. The three real levers:

Lever 1: Volume commitment with teeth

Acquirers care about committed volume, not aspirational volume. "We'll do $10M this year" is worthless unless it comes with a take-or-pay clause or a minimum monthly floor. The operators who cut the biggest rates bring a 12-month volume commitment with penalty clauses if they drop below 80% of projection. That commitment is what unlocks interchange-plus pricing at 8 bps above cost instead of the blended 2.9% + 30 that Stripe quotes publicly.

For multi-brand operators, the trick is aggregating volume across the portfolio for the commitment. Each individual brand might be $400k/yr — not enough for a volume discount on its own. But the portfolio is $5M/yr combined. Commit on the portfolio, route all traffic through one parent acquirer, and you're pricing at enterprise tiers from day one. This is the single biggest economic reason to collapse to a parent-acquirer architecture — you get 30-50% better rates because you're one $5M merchant instead of twelve $400k merchants.

Lever 2: Auth-rate data they don't already have

Acquirers make money when charges authorize. They lose money when they have to re-try, chargeback, or issue refunds. If you can demonstrate that your portfolio has auth rates 2-3% above the vertical median, you're worth more to the acquirer than the list-price customer. But you have to bring the data. "Our auth rates are good" means nothing. "Our 12-month auth rate across Visa credit is 94.3% vs. vertical median of 91.1% — here are the CSV exports from Stripe" is a negotiation chip worth 15-25 bps.

The data most operators can't produce easily: decline reason codes by type, retry success rates, issuer-specific auth rates, soft-decline recovery percentages. If your orchestration layer tracks these per descriptor, you can produce them in fifteen minutes for a negotiation. If you're running on raw Stripe dashboards, producing this data is a week of work and most operators give up. That's how acquirers keep rates high on portfolios that deserve lower ones.

Lever 3: Interchange-plus disclosure and the "fake fees" conversation

Read one statement. Any statement. From Stripe, Square, Fiserv, anyone. Now find interchange. Then find the markup. You can't — because most acquirers blend interchange, assessments, and markup into a single rate or into a handful of opaque line items. The statement audit we published walks through exactly what's hidden in a typical statement. The short version: there are usually 6-11 line items on a multi-brand merchant statement. Only 2-3 of them are real pass-through interchange. The rest are markup, some of which is negotiable and some of which is outright fabricated (we call these the "fake fees" — monthly gateway fees, PCI non-compliance fees even when you're compliant, "enhanced reporting" fees, etc.).

The negotiation lever here is to demand interchange-plus disclosure in writing, with every fee line-itemed. This alone usually surfaces 15-30 bps of negotiable markup that the acquirer will cut when asked directly. We've seen operators go from blended 2.8% + 30 to interchange + 25 bps + 15 cents — on the same volume, with the same acquirer — just by insisting on the breakdown and pushing back on fabricated fees.

One note on Adyen: Adyen does publish interchange-plus by default, which makes it easier to negotiate but also makes it easier to compare. We've seen operators cut 20-30 bps by just moving from blended Stripe to interchange-plus Adyen at similar volume tiers — not because Adyen is cheaper (it's not, list-for-list), but because the pricing structure is more negotiable. The Adyen enterprise negotiation guide goes deeper on what levers work there specifically.

A fourth lever worth naming even though it's less common: reserve terms. Acquirers quote rates and reserves as if they were independent, but they're not — an acquirer willing to accept a higher rolling reserve will often cut the headline rate by 15-25 bps. For operators with strong cash positions and low working-capital sensitivity, trading 2-3% rolling reserve for 20 bps lower rate is a net-positive over any reasonable holding period. Run the math on your own cost of capital: if you're deploying into inventory at 18-25% ROIC, every dollar tied up in a reserve is costing you more than the rate savings. If you're cash-rich and the capital is sitting in T-bills at 4%, the trade is almost always worth it. Operators rarely run this calc because rate and reserve land in different conversations with different people at the acquirer, and nobody ties them together. The reserve negotiation playbook walks through exactly how to package the trade.

The final piece of rate negotiation that multi-brand operators miss: the three-year review. Acquirer contracts escalate silently. The rate you negotiated in 2023 has drifted up 12-18 bps on average by 2026 via "scheduled assessment increases" and network fee pass-throughs that are legitimately pass-through but that also carry markup you didn't notice. Every 24-36 months, pull three months of statements, re-audit the line items, and either renegotiate or re-bid. Operators who do this save another 10-15 bps per cycle. Operators who don't wake up in 2028 paying 3.4% blended on a portfolio that should be at 2.1%.

Payout fan-out: legal entity accounting in 2026

If you're running multiple brands under multiple LLCs — which almost every serious multi-brand operator is — then payout fan-out is a legal requirement, not a feature. The money has to land in the right entity's bank account, with the right tax treatment, on the right cadence, attached to the right set of transactions. Getting this wrong is not a reconciliation problem. It's a tax problem, a K-1 problem, and in some structures a securities problem.

Most multi-brand operators we talk to set this up wrong at the start, because Stripe (and Square, and every other processor) only knows how to pay out to one bank account per merchant. The default setup: all revenue lands in the holding-co bank account, then the finance lead manually splits it and initiates ACH transfers to each entity on a weekly or monthly cadence. This works until it doesn't. The problems:

• Timing mismatch. Revenue lands on T+2. The split happens T+5 or T+7 depending on how fast finance moves. Each entity's bank balance shows a three-to-five-day lag on the real cash position. When the CFO of a sub-brand runs a cash-flow projection on Tuesday, they're working with Saturday's data.
• Manual ACH errors. Somebody typed the wrong account number. Somebody sent $47k to the right entity but the wrong period. Somebody booked it against Brand C when it should have been Brand C2. Every operator has at least one $30k+ transfer mistake sitting in a reconciliation queue somewhere.
• Tax reporting drift. 1099-K reports from Stripe go to the MID holder. If the MID is in the holding co but the economic substance is in the sub-brands, you're reporting revenue in the wrong entity. At tax time, this means restatement, K-1 amendments, and occasionally an IRS letter. We wrote the 2026 1099-K guide specifically because this is getting worse under the new reporting thresholds.
• Commingling concerns. If funds sit in the holding-co account for seven days before being distributed, some CPAs will flag this as commingling even if the economic substance is tracked properly in the ledger. For operators who have outside investors at the sub-brand level, this can create audit flags that take months to clear.

The right architecture is automated fan-out on T+2 or T+3, with per-entity bordereaux, mapped to per-entity bank accounts, with audit-logged movement. When Stripe deposits the parent-level net settlement, the orchestration layer immediately splits it into per-entity amounts based on the attributed transactions, and initiates ACH or RTP transfers to each entity on the cadence the operator sets. By Monday morning, every entity's bank account reflects its actual cash position from the prior week's transactions. There's no manual split. There's no four-day lag. There's no commingling concern because the funds don't sit.

For operators with 10+ brands or complex cap tables, payout fan-out is often the reason they finally bite the bullet on an orchestration layer. The reconciliation time-savings are nice. The rate improvements are nice. But the legal exposure on mis-booked payouts is the thing that actually gets the CFO or the GC to sign the contract. We've closed deals on the back of a single 45-minute conversation where we walked a GC through how the fan-out works and the automated audit trail. That's the moment they realize their current setup is a ticking clock.

One operational detail worth naming: the cadence. Daily fan-out is expensive (ACH fees per transfer, sometimes ~$0.25-$1.00 depending on volume) but gives each entity real-time cash visibility. Weekly fan-out is the common compromise. Monthly is dangerous — by the time the split happens, reconciliation has diverged, and any error is four weeks old instead of four days. We recommend weekly for most portfolios, with a daily overlay for any entity that needs working-capital visibility.

One more layer that matters at scale: intercompany. If your holding structure includes management fees, licensing fees, or IP royalties flowing between entities — and most serious multi-brand structures do — the fan-out layer needs to handle that too. Revenue lands at the brand entity, a calculated management fee moves to the holdco, a licensing royalty might move to a separate IP entity. These are real intercompany transactions with real tax consequences, and they need to be booked against the right charges with the right timing. Operators who let these accrue and settle quarterly create the same reconciliation problem in reverse — intercompany positions that drift and need to be reconciled at year-end with weeks of accountant time. Automated fan-out with intercompany rules baked in eliminates that drift at origination. This is one of the things that separates "orchestration layer" from "payouts tool" — any payouts tool can split a lump sum, but an orchestration layer understands the full entity graph and books the intercompanies at the moment of settlement.

What operators should build vs. buy

Every multi-brand operator hits the build-vs-buy crossover somewhere between brand four and brand eight. Below that, you can glue things together with spreadsheets, a couple of Zapier flows, and a webhook worker your dev team maintains in their spare time. Above that, the glue breaks under its own weight, and you either invest in a real ledger or you watch reconciliation eat every Monday for the next decade. Here's how we draw the lines.

The crossover almost always happens at the reconciliation layer, and the reason is compounding cost. A 6-brand operator doing weekly reconciliation manually is losing 4-6 hours/week. At $60/hr fully-loaded, that's $18k/yr of pure reconciliation overhead — before you count error cost, deferred analysis, or finance-lead burnout. At brand 9, that number is closer to $45k/yr, and it keeps climbing roughly linearly with brand count. Meanwhile, a real orchestration layer costs somewhere between $500-$2500/month depending on vendor. The math tips hard somewhere between brand 5 and brand 8 for almost every operator.

The case for building (even at brand 10+) is narrower than people think. It makes sense if: (1) you have a full-time engineering team dedicated to finance infra, (2) you have genuinely unusual requirements that commercial tools don't solve (marketplace-like flows, regulatory frameworks that require custom attestation, etc.), or (3) you're building a business where the orchestration layer is the product. For everyone else, building is a false economy. We've seen three operators try to build it in-house at the 10-brand mark. All three came back to buy within 18 months, having spent $200k-$400k on engineering time and still not having the feature set of a mature commercial tool.

The case for buying: you get five years of feature velocity out of the box, you get the security posture (SOC 2, PCI scope reduction) that takes years to build internally, and you redirect your engineering time back to growth rather than finance infrastructure. The CFO math on orchestration ROI shows the payback period is almost always under 6 months for portfolios above $2M/yr.

One final note for operators who are on the fence: the switching cost of orchestration is low in both directions. If you buy a layer and hate it, you can migrate off in a couple of weeks — the acquirer relationship is yours, the descriptors are yours, the data is yours. If you build and then decide you'd rather buy, same deal. This is not a lock-in decision. Make it on the economics of the next 12-18 months, not on fear of commitment. Most operators wait too long, lose 4-5 hours/week they didn't need to lose, and wish they'd moved at brand 5 instead of brand 11. The reverse — moving too early — is rare, because the pricing scales with portfolio size. You pay for what you run.

The shortest version of this whole chapter: if your finance team talks about "Monday reconciliation" as a recurring meeting, you're past the crossover. If your CFO can't tell you per-brand margin in real time, you're past the crossover. If you've had one processor freeze in the last 18 months, you're past the crossover. Buy the layer. Redirect the engineering time. Let finance redeploy to analysis. Add two more brands with the capacity you just freed up.

A word on vendor selection, since we've watched operators burn months in evaluation cycles. The four questions that actually matter: (1) Does it sit on top of our existing acquirer, or does it force a migration? (Migration is expensive, risky, and usually unnecessary.) (2) Does it isolate dispute ratios at the descriptor level, or only at the account level? (Descriptor-level is the whole point.) (3) Does payout fan-out support the legal-entity graph we already have, or does it assume a single bank account? (Multi-entity fan-out is mandatory for holdcos.) (4) What's the SOC 2 / PCI posture, and are we inside or outside the cardholder data environment after install? (You want outside — scope reduction is a real security and compliance win.) If a vendor stumbles on any of those four, walk. We've yet to meet an operator who regretted being strict on these four questions; we've met plenty who regretted being soft.

Closing the loop on this chapter: the real question isn't "build or buy" — it's "what's the compounding cost of not having a ledger by brand 10?" Every week of reconciliation debt compounds. Every freeze you didn't see coming compounds. Every rate you didn't renegotiate compounds. Every payout that landed in the wrong entity compounds. The operators who are still on 15 Stripe accounts and 7 spreadsheets in 2026 aren't there because they made a careful build-vs-buy decision. They're there because they never revisited the architecture. Revisit it. If you cross the threshold, move. The operators three years ahead of you wish they'd moved sooner.