---
title: "Autotask service bundles: how to balance simple pricing, reconciliation and profitability"
description: How Autotask service bundles affect MSP pricing, service quantities, licence reconciliation, profitability and accounting, with practical design options.
image: https://benspector.uk/hubfs/BS%20Consulting%20Website/Featured%20Images/bs-consulting-autotask-service-bundles-featured-1200x630-v01.jpg
---

[Skip to main content](https://benspector.uk/insights/the-challenge-of-bundling-services-and-accurate-reconciliation-in-psa-systems-for-msps#main-content)

[![BS Consulting Logo](https://benspector.uk/hs-fs/hubfs/Website%20Files/Logo/BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png?width=135&name=BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo")](https://benspector.uk/)

- [Services](https://benspector.uk/tactical-support-for-msps)
  
  Services

    - [MSP Revenue Operations](https://benspector.uk/tactical-support-for-msps)
    - [AI agents for MSPs](https://benspector.uk/ai-agents-for-msps)
    - [Autotask consulting](https://benspector.uk/tactical-support-for-msps/autotask-consulting)
    - [HubSpot for MSPs](https://benspector.uk/tactical-support-for-msps/hubspot-consulting)
    - [HubSpot consulting for service businesses](https://benspector.uk/hubspot-consulting)
    - [Zomentum consulting](https://benspector.uk/tactical-support-for-msps/zomentum-consulting)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [How I work](https://benspector.uk/tactical-support-packages)
  
  How I work

    - [Revenue Operations Blueprint](https://benspector.uk/revenue-operations-blueprint)
    - [Implementation projects](https://benspector.uk/implementation-projects)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [Insights](https://benspector.uk/insights)
- [About Ben](https://benspector.uk/about)
- [Book a discovery call](https://benspector.uk/contact/#book)

[![BS Consulting Logo](https://benspector.uk/hs-fs/hubfs/Website%20Files/Logo/BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png?width=135&name=BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo")](https://benspector.uk/)

- [Services](https://benspector.uk/tactical-support-for-msps)
  
  Services

    - [MSP Revenue Operations](https://benspector.uk/tactical-support-for-msps)
    - [AI agents for MSPs](https://benspector.uk/ai-agents-for-msps)
    - [Autotask consulting](https://benspector.uk/tactical-support-for-msps/autotask-consulting)
    - [HubSpot for MSPs](https://benspector.uk/tactical-support-for-msps/hubspot-consulting)
    - [HubSpot consulting for service businesses](https://benspector.uk/hubspot-consulting)
    - [Zomentum consulting](https://benspector.uk/tactical-support-for-msps/zomentum-consulting)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [How I work](https://benspector.uk/tactical-support-packages)
  
  How I work

    - [Revenue Operations Blueprint](https://benspector.uk/revenue-operations-blueprint)
    - [Implementation projects](https://benspector.uk/implementation-projects)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [Insights](https://benspector.uk/insights)
- [About Ben](https://benspector.uk/about)
- [Book a discovery call](https://benspector.uk/contact/#book)

[![BS Consulting Logo](https://benspector.uk/hs-fs/hubfs/Website%20Files/Logo/BS%20Consulting%20Logo%20-%20Blue%20(Transparent%20Background)%20-%20Cropped.png?width=160&name=BS%20Consulting%20Logo%20-%20Blue%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo")](https://benspector.uk/)

- [Services](https://benspector.uk/tactical-support-for-msps)
  
  Services

    - [MSP Revenue Operations](https://benspector.uk/tactical-support-for-msps)
    - [AI agents for MSPs](https://benspector.uk/ai-agents-for-msps)
    - [Autotask consulting](https://benspector.uk/tactical-support-for-msps/autotask-consulting)
    - [HubSpot for MSPs](https://benspector.uk/tactical-support-for-msps/hubspot-consulting)
    - [HubSpot consulting for service businesses](https://benspector.uk/hubspot-consulting)
    - [Zomentum consulting](https://benspector.uk/tactical-support-for-msps/zomentum-consulting)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [How I work](https://benspector.uk/tactical-support-packages)
  
  How I work

    - [Revenue Operations Blueprint](https://benspector.uk/revenue-operations-blueprint)
    - [Implementation projects](https://benspector.uk/implementation-projects)
    - [Retained consulting and mentoring](https://benspector.uk/retained-consulting)
- [Insights](https://benspector.uk/insights)
- [About Ben](https://benspector.uk/about)
- [Book a discovery call](https://benspector.uk/contact/#book)

# Autotask service bundles: how to balance simple pricing, reconciliation and profitability

 7 Oct 2026

![Picture of Ben Spector](https://app.hubspot.com/settings/avatar/7e455e13d1e7fbbeb836e1625311739c) [Ben Spector](https://benspector.uk/insights/author/ben-spector)

![A simple managed-service package connects to separate user, device and server quantities, then to itemised billing and financial reporting.](https://benspector.uk/hubfs/BS%20Consulting%20Website/Featured%20Images/bs-consulting-autotask-service-bundles-featured-1200x630-v01.jpg)

**Autotask service bundles** can make an MSP package much easier to sell and much cleaner for a client to understand. The difficulty starts when the same bundle is also expected to carry accurate licence quantities, costs, profitability and useful accounting data.

**“Should we bundle our managed services?” is too broad.**

There are several separate decisions hiding inside it: what the client buys, what Autotask needs to track, what appears on the invoice, and what finance needs to report. Those layers may use the same structure, but often they should not.

## Start by separating the four jobs a bundle is being asked to do

| Layer | What it needs to answer |
| --- | --- |
| **Commercial package** | What has the client bought, and how do you want to price it? |
| **Autotask service model** | Which services, quantities and costs need to be tracked? |
| **Invoice presentation** | How much detail should the client see? |
| **Accounting and reporting** | Which types of revenue, cost and margin does management need to distinguish? |

A package can be commercially simple while its underlying delivery model is quite detailed. Problems tend to appear when one Autotask structure is expected to solve all four jobs at once.

## What does an Autotask Service Bundle actually do?

Autotask's current documentation describes a Service Bundle as a group of Service items that are [priced and billed as one component of a Recurring Service contract](https://www.autotask.net/help/developerhelp/content/apis/REST/Entities/ServiceBundlesEntity.htm). The customer is billed for the bundle rather than each component Service separately.

When a bundle is placed on a recurring contract, its contract quantity is a quantity of *bundle units*. Autotask manages changes to that quantity through bundle adjustments and bundle-unit records. The underlying Services still exist as components of the bundle, but one bundle quantity does not magically become a separate user, device, server and site count. [Autotask documents the bundle association and quantity model separately](https://autotask.net/help/developerhelp/Content/APIs/REST/Entities/ContractServiceBundlesEntity.htm).

That distinction is where many MSP package designs become awkward.

## Before building bundles, classify what is actually in the package

One of the more useful exercises I have been doing with MSPs recently is to stop treating every line in a package comparison sheet as the same type of thing.

A typical MSP brochure mixes three very different categories:

| Package item | How I normally treat it | Why it matters |
| --- | --- | --- |
| **Labour entitlement** | Work types, contract inclusions and exclusions | Determines whether technician time is absorbed or billable |
| **Product or recurring service** | Autotask Service or Service Bundle component | Needs quantity, cost, supplier and billing treatment |
| **Service promise** | Process, workflow, recurring ticket or management control | Needs to happen, but may not belong on the billing record at all |

For example, “unlimited remote support” is a labour entitlement. Endpoint security is a recurring product. A quarterly technology review is a service promise.

They may all appear as ticks in the same sales brochure. They should not automatically become three lines in the same Autotask bundle.

This classification also helps keep contract design understandable. Labour entitlement can be handled through [work types, exclusions and fallback contracts](https://benspector.uk/insights/how-to-structure-autotask-contracts-so-billable-work-never-falls-off-contract). Products and recurring services belong in the service catalogue. Service promises need an operational mechanism that makes them happen consistently.

## One commercial package can have several quantity drivers

Imagine an MSP sells a single managed-user package. The client has:

- 30 users;
- 42 endpoints;
- 3 servers; and
- 1 site.

The package may reasonably be priced at 30 user units. But that does not tell you that endpoint security needs 42 licences, server backup needs 3 units, or a site-level service needs 1.

This is why I increasingly build a product matrix before I build the Autotask bundles. For each underlying recurring item I want to know:

- the actual product or service;
- the supplier;
- the quantity driver: user, device, server, site or another unit;
- the current unit cost;
- the intended individual selling price where relevant;
- which package or packages include it; and
- which system is authoritative for the quantity.

That matrix gives you something concrete to reconcile. A glossy package name does not.

## Package design and reconciliation are different problems

Sales quite reasonably wants a simple offer.

Nobody wants a proposal containing 17 security, backup, monitoring and support lines when the commercial message is simply “Managed IT - £X per user per month”.

Operations and finance need different information. They may need to know:

- how many Microsoft 365 licences are being billed;
- how many endpoints should be protected;
- how many servers have backup;
- the supplier cost of each component;
- whether quantities have changed since last month;
- whether the client is under-billed; and
- where the package margin is actually coming from.

I would not throw that data away simply because the customer-facing package is simpler.

The package the client understands and the internal records needed to run the service do not have to look identical.

## Accounting is often where the compromise becomes obvious

Suppose an MSP sells one £3,000 monthly package containing managed support, Microsoft 365, cybersecurity and backup.

From the client's perspective, one package line may be exactly right.

Internally, those are different types of revenue and cost. Managed support is largely internally delivered service revenue. Microsoft 365 and security products have direct supplier costs. Backup may have another margin profile again.

If the whole £3,000 is pushed into one generic managed-services revenue category while the costs remain separated, you may still be able to calculate overall client or contract profitability.

You will have a much weaker answer to questions such as:

- Is our cybersecurity category actually profitable?
- How much margin do we make on cloud licences?
- Is the managed-support element carrying products that should be repriced?

I have rejected apparently neat package structures for exactly this reason. The client-facing result looked good, but management wanted financial information the model could no longer produce.

That does not make the bundle wrong. It means you need to decide what level of profitability you genuinely intend to manage.

## Decide how much profitability you actually need

There is a big difference between asking:

**“Is this client or contract profitable?”**

and:

**“Is our cybersecurity service profitable independently from Microsoft 365, backup and managed support?”**

If contract-level profitability is sufficient, a more aggregated revenue model may be perfectly reasonable.

If you plan to manage product categories independently, review vendor margins, change pricing by category or understand which services make money, then the revenue and cost structure needs more granularity.

There is little benefit building elaborate service-level accounting that nobody will use. There is equally little benefit spending months cleaning up a chart of accounts and then collapsing every recurring service back into one revenue bucket.

## Three structures I normally consider

### 1. One complete package bundle

The simplest model is one bundle containing the components of the managed-service package.

This works best when the components largely share the same quantity driver and management mainly cares about overall client or contract profitability.

It gives the client a very clean recurring line. The compromise becomes greater as the component quantities, renewal terms and financial categories diverge.

### 2. Individual tracked services behind a simple commercial offer

The second approach keeps the underlying Services separate in Autotask so quantities, costs and service categories remain explicit.

The commercial offer can still be presented to the prospect as one managed-service proposition. Invoice presentation is a separate design decision and should be tested separately rather than forcing the service catalogue to mimic the invoice.

This is often where I start when reconciliation is the primary problem.

### 3. A small number of category-level bundles

This is often the useful middle ground.

Instead of one enormous bundle or 20 client-facing lines, use a few meaningful commercial categories such as:

- Managed support;
- Microsoft 365;
- Cybersecurity; and
- Backup.

That can keep the invoice understandable while retaining more useful quantity, revenue and margin boundaries.

It also stops you pretending that every component of an MSP package behaves in the same way.

## Be careful with zero-priced component services

A tempting design is to place all package revenue on one bundle while retaining other Service records at zero selling price so you can still hold quantities or costs elsewhere.

That can be useful operationally. It can also make service-level profitability look nonsensical if all the revenue sits on one record and the costs sit on several others.

At overall contract level the numbers may still work. At component level they no longer describe the commercial economics.

That is acceptable if it is intentional and nobody treats component profitability as authoritative. It is a bad design if the finance team later opens a service-margin report and assumes every individual line represents reality.

## Integrations can force the design

Before settling on a bundle structure, check the systems that are supposed to maintain its quantities.

Autotask exposes Services, Service Bundles, contract bundle quantities and bundle adjustments as distinct records in its API. A bundle quantity represents units of that bundle on the contract. [Its bundle-unit documentation describes quantity changes at bundle level](https://www.autotask.net/help/developerhelp/content/apis/REST/Entities/ContractServiceBundleUnitsEntity.htm).

So if a distributor, vendor, RMM or licence-management integration is expected to keep quantities correct, verify the exact record it can update before designing the catalogue around it.

“It integrates with Autotask” is not specific enough.

You need to know whether it updates a standalone Service quantity, a bundle quantity, a contact count, an asset count or something else entirely.

## Do not use invoice appearance to design the operational data

This is another pattern that appears repeatedly in billing projects.

An MSP quite reasonably wants the invoice to hide internal detail or “secret sauce”. That leads to a temptation to flatten the data model until Autotask itself contains the same limited detail shown to the client.

I would separate those decisions.

First decide what Autotask needs in order to make billing, reconciliation and profitability dependable. Then decide how labour and recurring charges should be presented on the invoice.

The same principle applies to technician time. I would not deliberately classify project, consulting and support time identically because a ticket-only invoice roll-up looks cleaner. Classify the work correctly first. Decide how much of that detail the client sees afterwards.

## Test one representative client before rebuilding the whole catalogue

Before migrating hundreds of recurring-service lines, build the proposed model for one representative client.

Choose someone complicated enough to expose the weaknesses.

1. Set up the package, Services or Service Bundles.
2. Add realistic quantities for users, devices, servers and any other drivers.
3. Change one quantity mid-period.
4. Generate the Autotask invoice.
5. Check what the client would actually see.
6. Push or transfer it into the accounting process.
7. Check where the revenue lands.
8. Review the contract and profitability reports management actually plans to use.
9. Test one excluded or overage scenario.
10. Confirm how vendor or distributor quantities would be reconciled.

That test normally exposes the trade-offs quickly.

It is much cheaper than creating hundreds of contracts and then finding that the model cannot answer the question finance originally wanted it to answer.

## Questions I ask before building Autotask service bundles

1. What does the client believe they are buying?
2. What determines the commercial price: user, device, site, server or something else?
3. Which underlying quantities need regular reconciliation?
4. Which system is authoritative for each quantity?
5. Which component costs need to be visible in Autotask?
6. Does management need profitability by client, contract, category or individual service?
7. Which revenue categories need to reach the accounting platform separately?
8. How much detail should appear on the client invoice?
9. Can the relevant vendor, distributor and quoting integrations maintain the proposed records?
10. Which items in the package are actually labour entitlements or service promises rather than recurring products?

If those questions do not have answers, I would not start by building the bundle.

## Keep the layers separate

A client can buy one simple managed-service package while your systems maintain several underlying quantities, costs and operational rules.

Likewise, your client invoice does not have to mirror the internal service catalogue line for line.

The useful design decision is to decide what information must survive each stage:

**the sale → the Autotask contract → reconciliation → the invoice → accounting and profitability.**

If one bundle is being asked to act as the sales package, quantity model, invoice format and accounting category simultaneously, that is usually where I start challenging the design.

If you are rebuilding recurring services, packages or accounting mappings in Autotask and the model is making reconciliation harder rather than easier, my [Autotask consulting](https://benspector.uk/tactical-support-for-msps/autotask-consulting) work covers the contract, service, billing and reporting design around it.

Related: [MSP systems and revenue operations](https://benspector.uk/tactical-support-for-msps/), [fixing MSP billing and profitability in Autotask](https://benspector.uk/insights/fixing-msp-billing-and-profitability-in-autotask-a-12-month-roadmap), and [the MSP revenue stack](https://benspector.uk/insights/the-4-tools-every-msp-needs-to-grow-their-business).

*Originally published in February 2024. Comprehensively rewritten with updated Autotask documentation and further first-hand consulting experience.*

### Share:

[Share on Facebook](http://www.facebook.com/share.php?u=https://benspector.uk/insights/the-challenge-of-bundling-services-and-accurate-reconciliation-in-psa-systems-for-msps&utm_medium=social&utm_source=facebook) [Share on LinkedIn](http://www.linkedin.com/shareArticle?mini=true&url=https://benspector.uk/insights/the-challenge-of-bundling-services-and-accurate-reconciliation-in-psa-systems-for-msps&utm_medium=social&utm_source=linkedin) [Share on X](https://twitter.com/intent/tweet?original_referer=https://benspector.uk/insights/the-challenge-of-bundling-services-and-accurate-reconciliation-in-psa-systems-for-msps&utm_medium=social&utm_source=twitter&url=https://benspector.uk/insights/the-challenge-of-bundling-services-and-accurate-reconciliation-in-psa-systems-for-msps&utm_medium=social&utm_source=twitter&source=tweetbutton&text=Autotask%20service%20bundles:%20how%20to%20balance%20simple%20pricing,%20reconciliation%20and%20profitability)

[Autotask](https://benspector.uk/insights/tag/autotask), [MSP revenue operations](https://benspector.uk/insights/tag/msp-revenue-operations)

## Related posts

Search [AEO for MSPs: how to get found, cited and considered in AI search](https://benspector.uk/insights/aeo-for-msps-how-to-get-found-cited-and-considered-in-ai-search)

![BS Consulting Logo](https://benspector.uk/hs-fs/hubfs/Website%20Files/Logo/BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png?width=160&name=BS%20Consulting%20Logo%20-%20White%20(Transparent%20Background)%20-%20Cropped.png "BS Consulting Logo")

MSP revenue operations and HubSpot consulting that connects sales, quoting, service delivery and billing.

- [Services](https://benspector.uk/tactical-support-for-msps)
- [How I work](https://benspector.uk/tactical-support-packages)
- [About Ben](https://benspector.uk/about)
- [Book a discovery call](https://benspector.uk/contact/#book)
- [Privacy policy](https://benspector.uk/privacy-policy)
- [Terms and Conditions](https://benspector.uk/terms)

[Connect on LinkedIn](https://linkedin.com/in/benspector1)

© BS Consult Ltd (registered in England and Wales 12932128)