MSP billing with customers as groups
A provider that operates systems for several customers receives one invoice from WhaTap and rebills each customer for their share. This guide covers the structure that models organizations as business units and groups as customers.
Use this structure when you have dozens to thousands of customers. The number of organizations stays as small as the number of business units however much the customer list grows, and nothing reloads when someone moves between customers.
- An MSP that operates environments for a large number of customers
- A distributor or SI operator that signs customer contracts under its own name
- An organization where several internal business units each own a share of the customers
Choosing a structure
The WhaTap hierarchy has only two levels, organization and group. Where you put the customer decides whether any level is left for classification below the customer.
| Comparison | Customer = group | Customer = organization |
|---|---|---|
| What an organization means | A business unit of the MSP | A customer |
| Suitable number of customers | Dozens to thousands | Around ten |
| Classification below a customer | Projects only | One more level, the group |
| Moving between customers | Directly on the same screen | Switch organizations. Monitoring screens reload |
| As customers grow | Groups grow | Organizations grow |
| Where the per-customer total appears | The group criterion | The organization criterion |
If you have many customers and one person looks after several of them, put the customer in a group. The number of organizations stays as small as the number of business units, and no screen switch happens.
If you have few customers and each one needs an internal split such as production and staging, put the customer in an organization. That leaves one more level, the group, below the customer.
Switching organizations is not only about the billing screen. Changing the organization reloads the groups and projects beneath it, so the switch also happens on the monitoring screens you use every day. If one person moves between several customers in a day, that wait repeats daily.
For the other arrangement, see MSP billing with customers as organizations.
Before you start
- A WhaTap account created and billing information registered
- A list of business units, and of the customers each one owns
- The billing owner concept, from Pricing and billing
Register the billing information first. In an account without billing information, the toggle that assigns a billing owner is blocked. You avoid building the whole structure only to be stopped at the last step.
Units of calculation and units of billing
Separate two things before you design the structure.
| Type | Unit | Meaning |
|---|---|---|
| Fee calculation | Project, product | What was used, and how much |
| Billing | Account | Who receives the invoice |
WhaTap calculates fees per project and per product only. Organizations and groups do not generate fees. They are where a billing owner is assigned. An amount seen by organization or group is the sum of the amounts calculated for the projects beneath it.
So however you divide organizations and groups, the total does not change. What changes is the unit you can group that amount by.
Hierarchy
Lay out the hierarchy like this.
The MSP provider is an account. Not an organization or a group. One account receives the invoice.
An organization is a business unit. Create one per internal unit, such as a public sector unit or a financial sector unit. With no such split, one organization is enough.
A group is a customer. Create one group per customer owned by each business unit.
A project is a system or an environment of the customer. Split by production and development, on-premises and cloud, servers and databases.
Benefits of this structure
Organizations do not grow as customers grow. You need only as many organizations as business units. The management load does not scale with the customer count.
You move between your customers without a screen switch. The screen shows only the groups and projects under the organization you picked, and changing it reloads that list. If all the customers you own sit inside one business unit, that switch never happens.
Inviting a customer's user as a group member applies the same permission to every project of that customer at once. You do not have to invite them project by project.
The contracting party and the management unit line up. The contract is with the customer and the management is per customer, the group, so you can compare the contract against actual usage directly.
Hierarchy constraints
The hierarchy has two levels, organization and group. A group inside another group is not supported. If something below the customer needs dividing, divide it by project.
A project belongs to exactly one group. The same project cannot sit under several customers at once. That is why nothing is double counted when you add up per-customer amounts, and the rows sum exactly to the total billing amount.
The screen shows only what is under the organization you picked. Only the groups and projects in that organization appear in the list.
Create them in this order: organization, group, project.
① Creating an organization per business unit
- Select the profile icon at the top right of the Home screen, then select Organization management
- Create one organization per business unit or owning team
- Invite that unit's administrator as an organization member
With no business unit split, one organization is enough. Do not create as many organizations as customers. You would switch organizations every time you move between customers, and the list reloads each time.
Details: Organization management
② Creating a group per customer
Create one group per customer under the owning business unit's organization.
The group name appears in the billing details as it is. Match it to the customer name used in contracts or in your accounting system, so you do not have to map names again when you build the rebilling data.
Create projects under that group, per system or environment of the customer.
- By environment: production, development
- By infrastructure: on-premises, cloud
- By target: application, database, Kubernetes
Details: Group management
③ Assigning the billing owner
On the Member list screen, open the permissions of the member you want as the billing owner and turn on the BILLING permission.
Billing permission follows three rules.
- One person per unit. An organization, a group, and a project can each have exactly one, and one is required
- Handing it to another member releases the previous owner's permission automatically. A verification email is sent during the handover
- Billing is looked up from the project, through the group, to the organization. With no owner below, it looks above
The owner assigned on the nearest level wins. So assign it once on the business unit organization and every customer beneath inherits it. Assign separately on the group only for customers that pay directly.
For the procedure, see Transferring billing permission.
The owner is fixed in the early hours of the 1st of each month. The owner at the moment the billing data is built is recorded on that month's invoice, so changing the owner mid-month does not change that month's invoice. It applies from the next month.
④ Separating customer and MSP permissions
Several customers live in one account, so it matters that customers cannot see each other's data.
| Level | Who | Permission granted |
|---|---|---|
| Organization | Business unit administrator | Everything, including billing |
| Group | Customer administrator (MSP) | No billing. View, edit, member management |
| Group | Operator (MSP) | No billing. View, edit |
| Group | Customer user | No billing. View, edit |
| Project | A user who sees one system only | No billing. Granted per project |
Invite operators and customer users at the group level or below. Invited to the organization, they can see every customer under it. That is where another customer's data leaks.
If MSP staff own several customers together, you can also place only those people on the organization. Note that anyone on the organization sees every customer of that business unit, so narrow the invitation scope to match your internal security policy.
Permissions at each level inherit a default from the level above. You can choose inherit, allow, or deny again per group or per project.
Details: Member permissions, Integrated management
⑤ Checking per-customer amounts during the month
Select the profile icon at the top right of the Home screen, then select My usage. In the left menu, select Invoice Preview History. This is the amount aggregated from the 1st of this month up to the time you view it.
Click the Group button above the billing details table to get one row per customer. Each row shows the number of projects included, together with the amount.
Expanding a row shows the detail by project and product for that customer. Whichever criterion you use, the rows sum to the total billing amount.
Mid-month amounts are not final. Build the invoice you send the customer from the following month's confirmed figures.
Details: Invoice Preview
⑥ Building the rebilling data at month end
When the month closes, select Billing History in the left menu. You can check the confirmed amount for that month. The usage amount plus VAT, added to the unpaid amount, is the total billing amount.
Downloading a CSV from the monthly list is in preparation. For now, download this month's details as a CSV from Invoice Preview and aggregate by the group column. Check the confirmed amount on this screen.
Details: Billing and Payment History
⑦ Managing unassigned projects
A project that is in no group is not included in any customer's billing. The billing details group it separately as unassigned, and the fee is billed individually to that project's billing owner.
If you miss the group assignment when creating a project, you cannot bill that cost to the customer and the MSP absorbs it. This is the most common reason the numbers do not add up.
Make the group assignment the last fixed step of your project creation procedure. Checking that the unassigned row is empty, before anything else, is also a good habit when you review the monthly invoice.
Checking the result
- There are only as many organizations as business units, and they do not grow with customers
- Each customer has exactly one group, and the group name matches the customer name in contracts and the accounting system
- Projects divide each group by system or environment
- The business unit organization has a billing owner, with customers that pay directly as the only exceptions
- Customer users are invited at the group level or below and cannot see another customer's data
- Every project belongs to a group, and the unassigned row is empty
Once the structure is in place, the settlement method does not change as customers grow. You add one group and put projects under it, and that is all.
Next steps
- See every permission type → Member permissions
- Manage members across levels on one screen → Integrated management
- The arrangement with customers as organizations → MSP billing with customers as organizations