What a Google Ads MCC is, and when you actually need one
It is an administrative layer, not an advertising account. Confusing the two is where the operational failures start.
A Google Ads manager account (Google's term is My Client Center, or MCC) is a container that administers multiple Google Ads accounts under one login, with consolidated billing, cross-account reporting and shared assets. No campaigns run in it directly. It becomes worth the setup at roughly five accounts, and becomes essential wherever separate locations carry separate budgets or separate accountability.
What an MCC is
A manager account sits above ordinary Google Ads accounts. It does not run ads. It administers the accounts that do: granting access, consolidating billing, reporting across the set, and sharing assets like negative keyword lists and conversion actions.
The distinction matters because people expect an MCC to change performance. It does not. It changes what is administratively possible, which is a different and slower kind of value.
One manager account can hold other manager accounts, which is how agencies separate client groups, and how franchise operators separate regions. Linking is additive rather than destructive: Google's documentation is explicit that when a manager account links an existing account, that account and its history remain unchanged. Nothing is migrated and nothing is lost, which is why the setup is reversible and low-risk to try.
Two limits from the same page are worth knowing before you design a hierarchy. An individual account cannot be directly managed by more than five manager accounts, and it cannot be linked to more than one manager account within the same hierarchy. Agencies that inherit a client already managed by several partners run into the first one, usually at the worst moment.
When it starts paying
Below about five accounts, an MCC is overhead. You can switch logins, and consolidated billing solves a problem you do not yet have.
Above that, three things start to hurt without one. Billing is administered per account rather than centrally. Rollup reporting has to be rebuilt by hand every month. And access is granted to individuals at the account level, so offboarding someone leaves standing permissions nobody audits.
The clearest signal is the third one. If you cannot answer "who has access to what, at which level" in under a minute, you have an access governance problem that an MCC layer is designed to solve.
The signal that arrives later, and hurts more, is inheritance. Every account created outside a manager account was created by someone, with a payment method belonging to someone, under a naming convention nobody wrote down. Consolidating them afterwards is a project. Creating them inside a hierarchy from the start is a checkbox.
The limits nobody reads until they hit one
Manager accounts have caps, and one of them is tied to spend in a way that catches growing operators. Google states that a manager account can be linked to 85,000 non-manager accounts in total, but the number of ACTIVE accounts is tiered by the highest monthly spend across the last twelve months: under $10,000 USD allows 50 active accounts, and $10,000 to under $500,000 allows 2,500.
Fifty is a number a franchise operator can reach. A group with sixty locations, each spending modestly, is under the first threshold in total and over the account cap, which is a combination the hierarchy has to be designed around rather than discovered inside.
Consolidated billing carries its own gate that the feature name does not advertise. Google requires a manager account and the monthly invoicing payment setting, with every account on one invoice sharing a currency and linked to a common paying manager. If you are on automatic card payments, consolidated billing is not available to you yet, regardless of how many accounts you run. That single condition changes whether an MCC solves your billing problem or only your access problem.
One account or an account per location?
| One account, location campaigns | Account per location | |
|---|---|---|
| Budget accountability | Shared, hard to attribute | Clean per location |
| Reporting effort | Low | Needs an MCC rollup |
| Franchisee visibility | Difficult to scope | Native per-account access |
| Suspension blast radius | Whole program | One location |
| Best for | Under ~5 locations, central budget | Franchise or P&L-per-site operators |
The suspension row is the one people underweight. If everything runs in a single account and that account is suspended, the entire program stops. Split across accounts, a suspension takes out one location while the rest keep running.
The reporting row is the trade you are accepting. Per-location accounts need an MCC rollup to report on. That is a solvable problem; a shared budget with no per-location accountability is not.
There is a hybrid people reach for and should mostly avoid: one account with a campaign per location and a manager account above it "for later". It gives you the reporting overhead of neither and the accountability of neither. Either the location owns a budget, in which case it owns an account, or it does not, in which case the campaign split is a reporting convention and should be labelled as one.
Access levels, and why offboarding is where estates leak
Google defines five access levels on a manager account: Administrative, Standard, Read only, Email only and Billing. Administrative is the only one that can manage the hierarchy itself, which is to say the only one that can link and unlink accounts.
Two of the five are underused and solve real problems. Email only exists for the person who needs the alerts and should not be in the interface, usually a client-side stakeholder. Billing exists for the finance contact who needs invoices and has no business editing campaigns. Handing both of those people Standard access, which is what usually happens, is how an estate ends up with more editors than it has people who edit.
The offboarding failure is the expensive one. Access granted at the individual account level has to be revoked at every individual account, and nobody has the list. Access granted at the manager level is revoked once. If you run more than a handful of accounts, that difference is most of the practical security argument for the layer.
The same gap reads differently from the advertiser's side. A business that has worked with three or four agencies over a decade often cannot say who currently holds Administrative access, or whether the account it has been spending through is one it owns at all. Establishing custody before changing anything is the first job in that situation, and what that looks like for long-established businesses along the Merivale corridor and through Barrhaven is set out separately.
What goes wrong at thirty accounts
A manager account holding thirty client or location accounts is an operational system, and it fails in operational ways rather than dramatic ones.
Promotional credits expire unclaimed, or land on the wrong account. Naming conventions drift because each new location was created under time pressure by whoever was available, so cross-account reporting cannot be automated. A policy disapproval goes unnoticed until a franchisee calls to ask why their phone stopped ringing, typically the second week.
Regulated verticals add a renewal calendar on top of all that. A healthcare or addiction treatment operator carries certifications with expiry dates, and a lapsed certification stops advertising in the restricted category outright. That is administrative decay with an immediate revenue consequence.
None of that is campaign management, and it is usually nobody's explicit job. That is the gap MCC management exists to fill: hierarchy design, naming standards, billing administration, policy monitoring and access governance.
Onboarding a new location without decay
New locations are where structure decays, because they get created fastest. A runbook replaces improvisation: create from a template, apply the naming convention, set labels for rollup reporting, attach billing to the consolidated profile, clone conversion tracking, grant access at the manager level, and add the location to the reporting register.
One step in that list gets skipped more than any other, and it is the one that matters. A cloned conversion action still pointing at the original location's thank-you page will report conversions cheerfully and attribute them to the wrong site for months.
Verify the clone. Then verify it again after a week of live traffic, because the failures that matter are conditional: the mobile form, the returning visitor, the booking flow that only redirects for one service type. That is the discipline behind GA4 and Tag Manager implementation generally.
Put the naming convention in the runbook rather than in a person. Encoding location, service line and match type mechanically is what makes rollup reporting a query instead of a monthly rebuild, and it is impossible to retrofit across thirty accounts without a rename project nobody will fund.
What an MCC will not fix
It will not improve performance. It will not repair conversion tracking. It will not make a badly structured account respond to budget: that is an account structure problem, and it lives one level down.
It will not prevent a suspension either, though it does contain one. A policy violation is judged at the account it happened in, and the manager account above it is an administrative parent rather than a shield.
What it will do is make thirty accounts administrable by one person without anything silently rotting. For a franchise operator with more than fifteen clinics, that administrative layer is what made automated per-location quarterly reporting possible at all.