MSP billing with customers as organizations
A provider that operates systems for several customers receives one invoice from WhaTap and rebills each customer for their share. This guide shows how to model that structure with organizations and groups, and how to pull out the amount per customer each month.
- An MSP that monitors systems on behalf of several customers
- A distributor or SI operator that signs customer contracts under its own name
- A shared operations team that has to allocate infrastructure costs across business units
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 groups.
Before you start
- A WhaTap account created and billing information registered
- A list of customers, and of the environments and systems each one will use
- 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. If rebilling per customer is the goal, make the customer one such unit.
Hierarchy
Lay out the hierarchy like this.
The MSP provider is an account. Not an organization or a group. One account receives the invoice, and customers are divided into organizations beneath it.
An organization is a customer. Putting the customer in an organization lets you bundle billing and permissions per customer at once.
A group is an environment or a system inside the customer. Production and staging, AWS and Azure, the axis the customer divides itself by. When a customer asks for a breakdown by environment, you can hand it over as it is.
This arrangement has three benefits.
The invoice shows one row per customer. The organization view becomes the customer list itself. The organization criterion does not appear at all in an account with no organization.
You assign the billing owner once per customer. The billing owner is looked up from the project upward, through the group to the organization. Assign it on the organization and the groups and projects beneath inherit it without being assigned separately. Adding environments to a customer takes no extra work.
The owner assigned on the nearest level wins. If an owner is assigned on the project, the group and the organization are not consulted.
A customer that pays directly is handled as an override. If only one customer pays for itself, assign that organization's owner to the customer's account. Leave the rest on the MSP account.
Limits of this structure
You switch organizations every time you move between customers. The screen shows only the groups and projects under the organization you picked, and changing it reloads that list. The same switch happens on the monitoring screens too, not only on the billing screen. If one person moves between several customers in a day, the waiting adds up.
Organizations grow with customers. The number of organizations to manage grows in proportion to customers, so this structure becomes hard to sustain beyond a few dozen. At that point, move to the arrangement with customers as groups.
A project belongs to exactly one group. So nothing is double counted when you add up per-customer amounts, and the rows sum exactly to the total billing amount.
① Creating an organization per customer
- Select the profile icon at the top right of the Home screen, then select Organization management
- Create one organization per customer
- Name the organization after the customer
The organization 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.
Details: Organization management
② Dividing groups by environment and system
Create groups under the customer organization to divide environments or systems.
- By environment: production, staging, development
- By infrastructure: AWS, Azure, on-premises
- By service: commerce, settlement, back office
Match the axis the customer wants to see its own costs by. If the customer does not ask for a breakdown, a single group is enough.
Projects go under that group.
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. That account is billed for everything under the organization.
Assign the same MSP account to every customer organization and the charges arrive as one invoice. Assign the customer's own account only in the organizations where the customer pays directly.
Changing the billing owner goes through an approval step. It keeps the account that receives the charges from disappearing by accident. 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.
④ 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 Organization 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. Switch to the group criterion to see the totals per environment. 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 organization column. Check the confirmed amount on this screen.
Details: Billing and Payment History
⑥ Managing unassigned projects
A project that is in no organization and 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
- Each customer has exactly one organization, and the organization name matches the customer name in contracts and the accounting system
- Groups divide each organization by environment or system
- Every organization has a billing owner, with customers that pay directly as the only exceptions
- Every project belongs to a group, and the unassigned row is empty
- At month end you get the per-customer amounts in one query and move them straight into the accounting system
Once the structure is in place, the settlement method does not change as customers grow. You add one organization and put groups and 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 groups → MSP billing with customers as groups