The MSP Revenue Stack: What Should Each System Own?

Most MSPs do not have one system that can sensibly own the whole customer and revenue process. This guide explains what each system should own and what information needs to cross the boundary.

I originally wrote this article in 2022 around four broad tools: marketing CRM, sales and quoting, PSA and accounting. The principle still holds, but my view has become less tool-led after working on more connected MSP systems. The architecture matters more than the logo.

A practical MSP revenue stack

Marketing and sales
Capture the relationship, opportunity, activity and commercial context.
Quoting and approval
Turn the opportunity into an agreed scope, products, prices and terms.
PSA and service delivery
Create the operational records, contracts, projects, tickets, time and billing logic.
Accounting
Post invoices, collect and reconcile money, and maintain the financial record.

The important part is the handover.

A good stack has clear ownership. A bad one has several systems trying to own the same customer, product, price or revenue record and a team quietly reconciling the differences in spreadsheets.

Marketing and sales should own the commercial relationship

For many MSPs, HubSpot is a strong fit for marketing, pipeline management, account management and reporting. Other CRMs can do the same job. What matters is that this layer owns the information needed to understand the opportunity before delivery starts.

Who is buying and who is involved in the decision?
What problem and scope have been agreed?
What is the expected value, timing and probability?
What has sales promised that delivery needs to know?
Which products or services are being proposed?

The CRM should not become a second PSA. It does not need every ticket, configuration item or billing detail simply because an integration can copy them across.

Quoting should own the commercial document and accepted line items

The quoting and proposal platform sits between intent and delivery. This is where an opportunity becomes a specific commercial commitment.

Depending on the MSP, this may be handled in HubSpot, Zomentum, Kaseya Quote Manager, Quoter, Autotask or another platform. The decision should follow the sales process, document requirements and integrations rather than a blanket rule.

A useful quoting layer should answer:

What exactly has the client agreed to buy?
Which quantities and prices were approved?
What is recurring, one-off or usage based?
What has to be created in the PSA when the deal closes?
Which catalogue is authoritative for the transaction?

The PSA should own delivery, contracts, time and operational billing

For an MSP using Autotask, this is normally where the commercial promise becomes an operational structure. The PSA needs enough detail to deliver the work and bill it without reconstructing the proposal.

That includes contracts, recurring services, projects, tickets, work types, technician time, procurement and billing rules. This is also why bypassing the PSA and sending a quote directly to accounting often causes trouble. The invoice may exist, but the operational record needed to explain cost and profitability is missing.

Accounting should own the financial ledger

QuickBooks, Xero or another accounting platform should remain the accounting system. It should receive correctly classified invoices and costs from the operational process rather than become the place where service delivery is reconstructed.

A successful sync is not the same as a good design. If PSA billing codes, products and services map into the wrong accounting items or income accounts, the integration can automate bad management information very efficiently.

Who should own what?

Record or decision	Typical owner	Why
Lead source and marketing engagement	CRM	Needed for acquisition and campaign reporting.
Opportunity stage and commercial context	CRM	Sales needs one visible pipeline and history.
Proposal and accepted commercial terms	Quoting tool	This is the transaction the client approved.
Operational contract and inclusion rules	PSA	Delivery and billing need executable rules.
Technician time and project delivery	PSA	This is operational activity and labour cost.
Invoice ledger, receipts and statutory accounts	Accounting	The accounting platform remains the financial book of record.

Do you really need four separate systems?

No. The categories are more important than the count. HubSpot can cover marketing, sales and some quoting. Autotask can cover quoting as well as PSA functions. Smaller MSPs may sensibly consolidate more of the process.

The warning is about forcing one platform to own a process it handles poorly simply to reduce the number of applications. Fewer systems can mean less integration work, but only if the remaining systems can support the operating process without manual workarounds.

Build the stack backwards

Accounting first. You need to invoice, collect cash and keep proper accounts.
PSA next. Once delivery becomes difficult to manage informally, create a proper operational system.
Sales CRM next. When referrals and opportunities no longer fit in one person's head, formalise pipeline management.
Marketing automation when there is something worth scaling. Add volume after the commercial process can absorb it.

The architecture test I use

For every important record, ask four questions:

Which system creates it?
Which system is authoritative after creation?
Which other systems genuinely need a copy?
What should happen when the systems disagree?

If those answers are vague, the integration is not finished. The result will usually be duplicate entry, silent drift or a spreadsheet used to arbitrate between systems.

Need to untangle the stack?

If your CRM, quoting tool, PSA and accounting system all contain slightly different versions of the same commercial record, the problem is usually ownership rather than another sync. Book a discovery call and show me where the handover is breaking down.

MSP revenue operations

The MSP revenue stack: decide what each system should own