MSP Billing Configuration

Billing for managed service providers (MSPs) in Ternary is built on a parent–child tenant model that defines where cloud billing data is ingested, how costs are surfaced, and how access is scoped across MSP and customer environments. Billing behavior varies based on how cloud accounts are connected and whether billing responsibility is managed centrally or by individual customers.

Tenant model in Ternary MSP Platform

MSP (Parent) Tenant

The parent tenant serves as the operational control plane for the MSP. It is used by internal MSP teams to manage customers, configure shared capabilities, and maintain visibility across all child tenants. From the parent tenant, MSP users can navigate into individual customer environments without duplicating access or configuration.

Customer (Child) Tenant

Each child tenant represents a single customer environment and maintains a strict one-to-one relationship with that customer. Users within a child tenant can only access data, reports, and configurations associated with their own environment. Child tenants isolate customer billing, usage, and access while still allowing the MSP to manage oversight and governance from the parent tenant.

Billing deployment models in the Ternary MSP Platform

Ternary supports two billing deployment models for MSPs. The appropriate model depends on how cloud integrations are owned, where billing data is ingested, and how much autonomy is provided to customer tenants.

Integrated Billing

In an integrated billing model, cloud integrations are owned and managed centrally by the MSP.

• Cloud provider integrations are configured in the MSP parent tenant and ingest billing and usage data at the source. Child tenants do not establish direct connections to cloud provider APIs. Instead, they reference specific projects, accounts, or subscriptions that are already connected at the parent level.
• Billing data is maintained in both the parent and child tenants, enabling centralized oversight while still allowing customers to view their own cost and usage data.
• Custom labels defined in the parent tenant are automatically available to all child tenants, ensuring consistent reporting dimensions across customers.

This model is commonly used when the MSP retains operational responsibility for cloud billing, reporting, and optimization.

To learn about MSP Bill Splitting with Ternary, view MSP Bill Splitting.

Separate Billing

In a separate billing model, each customer manages its own cloud integrations.

• Cloud provider integrations are configured directly within each child tenant. Billing and resource data is ingested and managed independently by the customer tenant, with full feature access available locally. The parent tenant receives only summarized data rather than the full billing dataset.
• Custom labels defined in a child tenant remain local and are not propagated to the parent tenant.

This model emphasizes tenant autonomy and is typically used when customers require direct ownership of cloud integrations and billing access.

How utilization metrics are collected for MSP billing

Utilization metrics are always collected from the customer’s cloud environment, regardless of the billing deployment model in use.

Resource utilization data (such as CPU, memory, or disk usage) is generated within the customer’s cloud projects and stored in the customer’s native monitoring and logging services. To access this data, the Ternary service account must be provisioned in the customer’s cloud environment. This service account is also provisioned in the MSP’s cloud environment to support centralized ingestion and analysis.

User access behavior in the MSP tenant model

• Users added to the MSP parent tenant are not automatically added to child tenants. They can navigate into any associated child tenant through the Ternary MSP Dashboard.
• Users added to a customer (child) tenant are restricted to that tenant and cannot access the parent tenant or other customers.
• Roles assigned within a child tenant are limited to Tenant Admin or lower.
• Access to multiple child tenants requires separate user creation for each tenant. Users added to the parent tenant do not receive an email invitation to join.
• Users added to a child tenant receive an email invitation to join.

This model provides centralized visibility for MSP staff while maintaining strict isolation between customer environments.