Managing Multiple Projects with Your Organization
If you manage several projects, your organization does the heavy lifting: one team roster, one subscription, one invoice.
Collective billing became the organization. A project of an organization always bills inside its own organization; it cannot be added to another organization's bill. Adding a project to a "collective bill" is now simply the project subscribing inside your organization: it joins the organization's subscription automatically. Existing collective-billing groups were converted to organizations; nothing changed on the invoice.
One subscription for all projects
When the first project of your organization subscribes, it creates the organization's subscription. Every further project that subscribes joins it: each project still picks its own plan, but everything lands on one invoice.
One invoice for several projects is included from the Growth plan upward. If the only subscribed project of your organization is on Free or Starter, a second project cannot join that invoice: put it in its own organization (choose "+ create a new organization" when you add it) so it gets its own subscription, or move one project up to Growth.
One team for all projects
Invite your team once, on the organization page. Members inherit into every project of the organization with the role you gave them (scoped if you like, for example one language across all projects).
- Organization members show a "via organization" badge on each project's users page.
- A direct project permission wins over an inherited work role (manager / publisher / user) — invite the member on that project with a smaller role to narrow them there. Organization admins and accountants always reach every project; change their role on the organization page instead.
- Externals (freelance translators, agency contacts) get a direct permission on exactly one project and never see the rest.
Tenants and branches
Tenants and branches follow the same rule: they are projects of your organization, so your members reach them. Someone who should work on exactly one of them gets a direct permission there; an organization member who should not work on it is blocked there.
A project's users page shows "via organization" (a member of your organization), "OVERRIDDEN" (a member with a different role on this project) or no badge (a direct permission, typically an external).
How this affects the user limit
- The organization's roster size counts against the most generous plan in the organization. Growth and above have unlimited users, so the limit matters only on the Free and Starter plans.
- On a single project, only direct permissions count. Inherited users (via the organization or via parent-project inheritance) are free there.
- Overridden users count as direct: revert them to "inherit" (three-dot menu → "INHERIT") if the custom role isn't needed.
- Tenant projects have no own plan at all: they are billed together with their parent project, so inherited users are simply free there too.
Key Points
- One organization = one subscription = one invoice; each project keeps its own plan.
- Invite your team on the organization; use direct project permissions for externals and exceptions.
- Inherited users never count toward a project's user limit; overridden ones do.
- Tenants and branches follow their parent project's organization and have no own billing.