Two of the most common MSP billing models charge for fundamentally different things: a licensed user, or a managed piece of hardware. Picking the right one, or the right mix, depends on what you're actually delivering.
Per-seat billing
Per-seat billing charges a fixed amount for each licensed user, most commonly for Microsoft 365, security tools, or helpdesk-style support that scales with headcount rather than hardware. It maps naturally onto how distributors like Pax8 and Microsoft 365 CSP bill you, seat-based, which makes reconciliation relatively direct: compare seat counts and per-seat pricing between the distributor invoice, your contract, and the client invoice.
The main risk with per-seat billing is seat-count drift and proration. A leaver's seat that isn't removed, or a new starter's seat added directly in a distributor portal, both create a gap between what you're billed and what the client pays. Mid-cycle changes compound this with prorated charges that flat per-seat pricing doesn't naturally account for.
Per-device billing
Per-device billing charges for each managed endpoint, laptop, desktop, server, regardless of how many users are on it. It fits naturally with RMM-centric MSPs, since device counts are already tracked for monitoring and patching purposes. It's also the natural fit for MSPs running without a formal PSA, since device data can drive pricing directly.
The main risk here is device count drift in the other direction, devices get decommissioned or replaced without the billing record being updated, so you either keep billing for hardware that's gone, or more commonly, undercount devices that were added without anyone flagging it for billing.
Which one fits your services
- Per-seat fits licence-heavy services: email, security suites, identity, anything tied to a user
- Per-device fits hardware-heavy services: patching, monitoring, endpoint management
- Most MSPs run both models simultaneously, seats for licences, devices for managed hardware
- The model should match what actually drives your cost, not just what's easiest to explain
Reconciliation gaps are model-specific
Whichever model, or mix, you use, the reconciliation checks differ slightly. Per-seat billing needs seat-count and proration checks against distributor data. Per-device billing needs device-count checks against RMM data, ideally checked against a rate card that reflects current device types and pricing. Running both models without checking either leaves two separate places for revenue to leak instead of one.
Reconciling both automatically
MSPBilling.cloud reconciles both models from the same platform, pulling seat data from distributors and device data from your RMM or PSA, and checking both against client billing. See the full picture in billing reconciliation.