B2B account hierarchies for products that sell to teams

Why flat accounts break when bigger customers arrive

A flat account model works when each customer is one team with one budget and one admin. It starts to fail when a customer is really a group of business units, regional offices, or subsidiaries that need to work separately but still buy together.

Sales closes one deal with a parent company. Then rollout begins, and users don't arrive as one neat group. Marketing wants its own space. Finance needs tighter access. Three subsidiaries want local admins because they run their own day-to-day work.

If your product supports only one account per customer, you usually end up with two bad choices. You put everyone into the same account and pile on messy permission rules, or you create separate accounts and lose a clean way to manage the customer as one organization.

That's when billing, permissions, and reporting start pulling against each other. Finance wants one invoice. Department leads want control over their own users. Security wants clear boundaries between teams. Procurement wants usage and spend reports at the parent level, not ten unrelated exports.

The problem gets worse when contracts and product behavior drift apart. The contract says one company bought access for several subsidiaries, but the product treats each signup as a separate customer. Or the product forces every team into one shared account even though the buyer expects local ownership.

That is why account hierarchies matter early, not after the first large rollout goes sideways. Once customer success starts patching the gaps by hand, the model already has the wrong shape. Every manual invoice, custom permission tweak, and spreadsheet report is a warning sign.

It is much cheaper to define parent accounts, child accounts, and shared controls before those assumptions spread into billing logic, admin screens, and contract terms.

Map the customer structure before you model it

Most account problems start with a bad assumption: the company chart and the product account shape are the same thing. They often aren't. A parent company may sign the deal while five regional teams use the product in very different ways.

Write down the real actors before you design anything. That usually includes the parent company, subsidiaries, internal departments, outside agencies, and contractors who log in for limited work. Skip this step, and the hierarchy can look clean on paper but still fail the first time a customer asks for separate data, billing, or admin control.

Legal structure matters, but daily behavior matters more. Some companies buy once at the top and let each business unit manage itself. Others let each department pay from its own budget, even when they sit under one legal entity. You need both views: who owns the contract, and who uses the product every day.

A short discovery pass usually clears this up:

• Who signs the agreement?
• Who receives and approves invoices?
• Who needs daily access to do work?
• Which groups must stay separate inside the product?

That last question saves a lot of pain later. Separate groups often need their own customer data, security settings, reporting, or usage caps. A finance team may want one billing view while each subsidiary wants its own workspace and admin. An agency might need access to only one client area, not the whole parent account.

A simple example helps. Imagine a holding company buys your software for three brands. The CFO signs the contract. Each brand has its own operations team, support queue, and monthly usage budget. One outside agency manages marketing for only one brand. That setup is not a single flat account, even if one company name appears on the contract.

Map those relationships early, and later decisions about parent and child accounts get much easier.

Decide what belongs at the parent level

A parent account should control the small set of things that need one answer for the whole customer. Start with billing ownership, contract terms, tax details, renewal dates, and company-wide policies. If every child account can change those, support gets messy fast and invoices stop matching the deal.

Global rules belong here too when they must stay consistent across subsidiaries. That can include security requirements, data retention rules, approved domains, or a default purchase order process. Keep this list short. The parent account should act as a control point, not a storage closet for every option in the product.

Visibility needs a clear rule early. Some customers expect the parent to see all usage, spend, seat counts, and audit history across child accounts. Others want each subsidiary to keep some privacy. Pick a default model, then decide whether parents can view only roll-up totals or full child-level detail. If you leave this vague, sales will promise one thing and the product will do another.

A few actions usually need parent approval:

• adding or removing child accounts
• changing the billing owner
• accepting contract changes
• raising spending limits or seat caps
• turning on global policies

That boundary saves time later. A local admin can manage daily work inside a child account, but they should not change terms that affect the whole organization.

Resist the urge to put every shared setting at the top. Teams often push parent accounts into becoming a giant settings page because it feels tidy at first. It usually creates the opposite result. Admins can't tell what applies everywhere, what overrides locally, and what nobody uses anymore.

A simple rule works well: if a choice affects money, legal terms, or every child account, put it at the parent level. If it changes only how one team works, keep it local.

Set rules for subsidiaries and child accounts

A child account should exist for a real business reason, not because one customer asked for a neat org chart. Create one when a subsidiary has its own users, its own data boundary, or its own admin team. If none of that applies, an extra workspace usually adds clutter and support work.

A simple test helps. Give a subsidiary its own workspace if it needs at least two of these:

• separate user management
• separate data or reporting
• local settings or integrations
• a local admin who should not control other teams

That gives child accounts room to work like separate teams without turning every department into its own mini tenant.

Each child account should have clear local control. Local admins should manage their own members, groups, projects, and routine settings. They should also own local data, so one subsidiary can export reports or set naming rules without changing the experience for everyone else.

Inheritance needs firm limits. Parent accounts should push down the rules that must stay consistent, such as identity policy, audit settings, and compliance controls the customer expects across the company. Child accounts can usually change settings that are local by nature, like default notifications, project templates, or optional integrations.

Write those inheritance rules down in plain language. If a setting starts at the parent level, say whether the child can override it, request an exception, or never touch it. Ambiguity creates support tickets fast.

Team moves matter more than most products expect. People switch regions, business units merge, and a subsidiary may get sold. Your model should let an admin move a user or team to another child account without losing history that must stay attached to the company record.

Set rules for what moves and what doesn't. Access rights should change right away. Old managers should lose control. Shared records need a clear owner after the move. Decide this early and you avoid a painful rewrite later.

Handle shared billing without confusion

Billing causes arguments faster than most product bugs. When one company pays for several teams, your product should always answer three questions: who owns the bill, who receives the invoice, and which account created the usage.

Pick one billing owner for each paid relationship. That owner can be the parent company, one subsidiary, or a regional group. Don't let two accounts share billing ownership for the same subscription. It sounds flexible, but it gets messy when payment fails, a plan changes, or finance asks who approved the spend.

If a parent pays for child accounts, keep payment central and usage visible at the local level. Finance may want one invoice each month, but local admins still need to see their own seat count, storage, API usage, and extra charges. If they can't see that detail, every billing surprise turns into an internal dispute.

Some groups need separate invoices even inside the same hierarchy. One subsidiary may have its own budget, legal entity, or purchase order. In that case, keep the parent and child accounts connected for access and reporting, but split invoicing cleanly. The parent can still oversee the whole group while each child keeps its own tax details, invoice history, and renewal record.

A billing setup like this usually needs a few fields from day one:

• billing owner
• invoice contact
• purchase order number or reference
• budget cap or approval rule

You may not expose every field in the first version, but your data model should have room for them. Larger buyers often ask for invoice contacts, spending limits, and purchase order tracking late in the sales cycle. Adding them after launch is much harder.

A common example is simple. Headquarters buys 200 seats for five subsidiaries. One subsidiary uses far more than planned in the first two weeks. The finance team should see the total spend in one place, while that local admin should see exactly what their team used and why the bill changed. This is where account hierarchies stop being abstract and start saving support time.

Design delegated admin roles that make sense

Too many roles create support tickets. Too few push everyone into a single all-powerful admin account, and that gets messy fast. Most products do better with a short role set that matches how companies already operate.

• Parent admin manages the account tree, creates child accounts, and controls parent-level policies.
• Billing admin manages invoices, payment methods, tax details, and contract settings.
• Local admin runs one child account, invites users, assigns seats, and handles daily settings for that team.
• Member uses the product without changing account structure.

Parent admins should control structure without owning every local decision. They may need to create a new subsidiary, move a team under another branch, or apply a policy across the whole customer account. They usually don't need to approve every invite, rename every workspace, or edit settings for each local team.

Local admins need room to run day-to-day work. Let them invite people, remove former employees, manage groups, and change settings inside their own child account. That keeps work close to the team that knows the users and avoids a queue of small requests at the parent level.

Risky actions need tighter rules. Deleting an account, merging subsidiaries, changing billing ownership, or exporting all user data should sit behind the right role. If a change affects money, contracts, or the full customer structure, require a parent admin or billing admin to approve it.

A simple example makes this easier. A parent company owns three regional subsidiaries. The central IT team should create the structure and manage shared billing. Each regional operations lead should invite staff and manage local settings. If the Europe team can change global billing, or if central IT has to approve every new user in Asia, the model will frustrate both sides.

Plain role names help more than clever ones. People understand "billing admin" and "local admin" right away. They shouldn't need a training session to figure out what a role can do.

Build the model step by step

Good account hierarchies usually fail for a simple reason: the team starts with tables, IDs, and permissions before it understands how the customer actually buys and works.

Start with a few real customer stories instead. Who signs the contract? Who pays the invoice? Who invites users? Who needs to see reports across multiple subsidiaries, and who should only see one team?

A simple sketch often beats a week of schema debates. Put the parent account at the top, child accounts below it, and write the rules next to the lines. Keep it to one page. If you can't explain the model on one page, engineering will build different versions of it in different places.

A practical build order

1. Pick two or three customer stories that match real deals. For example, one company with a single team, one with a parent company and two subsidiaries, and one where finance pays for everyone.
2. Write the account rules in plain English before anyone touches the database. Decide what the parent can control, what children can edit, and what data must stay separate.
3. Test the full flow in one pass. A user invite should affect access, billing, and reporting in ways that make sense together.
4. Add edge cases only after the basic version works for actual customers.

That third step matters more than teams expect. Many products test invites in one ticket, billing in another, and reporting much later. Then they find out that a parent admin can pay for a child account but can't see its usage, or a subsidiary manager can invite users who end up on the wrong invoice.

A better approach is to run one end-to-end scenario. A finance admin at the parent account buys seats, a regional admin invites users into one subsidiary, and leadership checks a roll-up report. If any part feels awkward, the model is still too loose.

This is where experienced technical leadership helps. The goal isn't to predict every strange enterprise request. The goal is to lock down the small set of rules that cover most deals, then extend them without breaking old accounts.

Keep the first version boring. Boring models survive growth better than clever ones.

A simple customer example

Picture a holding company called Northstar Group. It owns three subsidiaries: Northstar Retail, Northstar Logistics, and Northstar Energy. They all buy the same SaaS product, but each company runs its own team and handles its own records.

Northstar Group is the parent account. The parent signs the contract and gives one central finance team control over invoices, payment methods, and renewal details. Finance can pay for all three subsidiaries from one place, split charges by company, and download one clean billing history. They don't need access to every workspace or every user inside the product.

Each subsidiary gets its own child account. Northstar Retail manages store staff, user access, and retail data inside its own space. Northstar Logistics manages warehouse users, shipment records, and its own settings. Northstar Energy keeps its operational data separate as well. Users in one subsidiary should not see users or data from the other two unless someone at the parent level allows a specific exception.

Now add Maria, a regional operations manager for Northstar Retail. She needs to invite new team members, remove old accounts, and fix permissions when a store changes staff. She should manage Retail only. She should not open Logistics data, touch Energy users, or change parent billing settings. A delegated admin role gives her enough control to do her job without opening the whole structure.

This setup creates clear boundaries:

• the parent manages contracts and shared billing
• each subsidiary manages its own users and data
• finance sees costs across the group without seeing day-to-day work
• Maria can act as an admin for Retail only

If Northstar buys a fourth company next quarter, the model still holds. You add another child account, connect it to the same parent, and keep billing centralized. That's much easier than rebuilding the account model after a large customer already depends on it.

Mistakes that lead to a rewrite

The fastest way to break an enterprise account model is to treat different ideas as the same thing. A legal entity is not a team. A team is not a permission group. If one field tries to hold all three, your data gets messy fast.

That mess shows up everywhere. Finance wants one structure for invoices. Account owners want another for parent and child accounts. User access needs something else again. When the model blurs those lines, every new customer request turns into a workaround.

Another common mistake looks harmless at first: giving every admin full control because it's easier to ship. That choice usually sticks around long after the first release. Then a customer asks for one person to manage billing, another to invite users, and a regional lead to view several subsidiaries without changing settings. If your only role is "admin," you will end up patching permissions by hand.

Billing causes some of the worst problems. If you tie billing rules to the user model, changes get expensive. People leave. Finance contacts change. A parent account may pay while several child accounts use the product. Keep payment responsibility, invoice settings, and spending rules attached to accounts and account relationships, not to a single user record.

One-off exceptions create the biggest rewrite risk. A large prospect asks for something unusual, the sales process gets tense, and the team hardcodes a special path to close the deal. Six months later, another customer wants a similar setup, but not the same one. Now you have two special cases and no clean rule.

A quick test helps:

• Can this rule work for more than one customer?
• Does it map to accounts, not individual users?
• Can you explain it without naming one company?
• Will support understand it without reading code?

If the answer is no, stop and reshape the model. A clean design feels slower in week one. It saves months later, when a bigger customer asks for shared billing, delegated admin roles, and subsidiaries under one parent.

Quick checks and next steps

Before you ship anything, make sure sales, support, and engineering use the same words. If sales says "account," support says "workspace," and engineering means "tenant," the model will drift before the first large rollout finishes.

A short review now can save months of cleanup later. These systems usually break on naming, permissions, and billing boundaries, not on database tables.

Use this quick pass before you build more:

• Ask each team to define parent account, child account, subsidiary, admin, and billing owner in plain language. If the definitions differ, fix that first.
• Check whether a parent can pay for everyone without getting automatic access to each subsidiary's users, reports, or data. Many companies want shared billing and separate control.
• Sit in the seat of a local admin and test daily work. They should be able to add users, manage routine settings, and handle common requests without opening support tickets.
• Run one realistic customer scenario with real permission rules. Give headquarters billing control, give a central IT admin cross-account setup rights, and give each subsidiary its own local admin. Then verify who can see and change what.

This is usually the point where small product gaps become obvious. Maybe billing belongs at the parent level, but audit logs stay local. Maybe the parent can suspend an unpaid child account, but can't read its private data. Those choices need clear rules, or your team will make them ad hoc during onboarding.

If larger B2B deals are already in the pipeline, get an outside review before engineers lock the model in place. A short architecture review from an experienced Fractional CTO can catch expensive mistakes early, especially around parent and child accounts, delegated admin roles, and shared billing for SaaS. Oleg Sotnikov at oleg.is works on exactly these kinds of product and infrastructure decisions, so that kind of review can be very practical.

A rewrite usually starts with one rushed enterprise deal. A solid review starts with four plain questions: who owns billing, who owns data, who manages users, and who can act across account boundaries.