One User Count, Five PSA Lines: How MSPs Automate Related Recurring Billing
A Microsoft licence count can be the starting point for several recurring-service quantities, but it should not be copied blindly. Safe MSP recurring billing automation defines a billable-user group, applies a separate rule to each service, holds exceptions for review, and updates the intended billing records before the PSA generates the invoice.
In practice, the chain is:
- Source metric: choose the count that matches the customer contract.
- Eligibility rule: decide who or what is included, excluded or filtered.
- Per-line rule: inherit the count, filter it, enforce a minimum or use another source.
- Review and PSA update: resolve exceptions, then confirm the resulting quantities in the PSA.
“One user count” therefore means one governed group of eligible users. It does not mean that support, backup, endpoint security, filtering and every other recurring service must always show the same quantity.
Why Microsoft licence sync stops too early
The Microsoft 365 line is only one quantity on an MSP’s recurring bill. The same customer may also pay for managed support, Microsoft 365 backup, antivirus or EDR, email or web filtering, and security awareness. Some of those services may be sold per managed user; others may be sold per mailbox, protected identity, endpoint or contracted minimum.
Updating the Microsoft line does not define those commercial units. If the related quantities still depend on a spreadsheet or somebody remembering which PSA records should move, they can drift independently even while the licence line is correct.
Five PSA lines also do not have to become five customer-visible invoice lines. An MSP may keep granular service quantities in its agreement or contract while presenting a bundle differently on the invoice. This article uses five destination records as an illustrative control model, not as a universal invoice design.
Basic licence sync is the starting control, not the whole recurring-billing policy.
Step 1 — Choose the source that matches the contract
Check the signed recurring-service schedule against the current source record: Microsoft licences, enabled Microsoft Entra users, PSA contacts, devices or vendor usage. The evidence is the contract’s stated billing unit plus a current export or record from that source. If they describe different units, that discrepancy means the source cannot safely drive the destination line without another rule.
| Candidate source | Use when | Do not use when | Typical exception |
|---|---|---|---|
| Microsoft assigned or consumed licence | The contract follows that Microsoft SKU or licensed population | The service is sold per person, mailbox or endpoint instead | Spare licences or disabled licensed accounts |
| Enabled Entra member user | The service follows active people and the definition is contractual | Guests, non-human identities or special groups need separate treatment | Leavers, contractors or excluded departments |
| PSA contact marked billable | The PSA contact state is deliberately governed as the source | Microsoft state can change without a matching PSA update | Stale contacts or rehires |
| RMM or device count | The service is genuinely priced per managed endpoint | A user can have several devices or no managed device | Shared devices, servers or BYOD |
| Vendor seat or usage count | The vendor's unit should control the resale quantity | The MSP sells a broader bundle or contracted minimum | Delayed usage or unmapped products |
The easiest count to retrieve is not necessarily the right count to bill. In particular, an endpoint-security line should not inherit a user count merely because the user count is available. If the vendor entitlement and customer contract are per device, use a device or vendor source.
Step 2 — Define who belongs in the billable-user count
Check each identity category against the signed agreement and the service’s entitlement rules, then record the decision in a short policy owned by operations or finance. The evidence is the customer’s contract, relevant Microsoft or vendor state, and approved exceptions. If an identity has no documented treatment, the discrepancy means the eligible-user group is incomplete and should not yet drive automated updates.
| Identity or category | Default treatment | Contract or vendor condition | Rule owner | Review trigger |
|---|---|---|---|---|
| Enabled member user | Decide whether included | User receives the billed service | Operations | Joiner, role or service change |
| Disabled user or leaver | Define removal timing | Offboarding, retention and notice terms | Operations | Disable date or contract end |
| Guest or contractor | Decide individually or by group | Actual support and protection scope | Service owner | Access or contract change |
| Shared or resource mailbox | Keep separate from people by default | Mailbox protection or licensing rule | Billing owner | Licence, size or feature change |
| Service account | Exclude unless explicitly covered | Named security or support entitlement | Technical owner | Purpose or ownership change |
| Excluded department, domain or office | Apply the documented filter | Service scope or separate billing destination | Operations | Attribute or structure change |
| Temporary manual exception | Record an owner and expiry | Approved commercial exception | Finance | Expiry or next invoice run |
| Contracted minimum | Apply after the live count | Signed minimum quantity and dates | Finance | Count falls below the floor |
A Microsoft-licensed user is not automatically a billable managed user. Microsoft itself distinguishes mailbox type from licence need: its shared-mailbox guidance explains that a shared mailbox can operate without a separate licence up to stated limits, while larger capacity and some advanced features require licensing. That Microsoft rule still does not decide whether an MSP should charge for backup, support or security. The customer contract and service entitlement do.
If this definition is the main difficulty, document the managed-user billing rules before mapping any destination lines.
Step 3 — Map one approved user count to five recurring PSA lines
Check a mapping worksheet against the current tenant/customer, service and destination PSA records. The evidence comes from the approved eligibility rule and the actual company, agreement or contract, product/service, minimum and approval configuration in the PSA. A blank, inactive or overlapping mapping means the affected line should be held rather than guessed or posted elsewhere.
Illustrative quantity calculation
This hypothetical Customer A calculation shows the smallest useful test. It is not a Sync 365 default or a customer result. At the 31 July 2026 billing cut-off, an Entra export contains 47 enabled member users. Customer A’s signed service schedule and approved exclusions remove three contractors and two users in an uncovered division, leaving 42 eligible users. The calculation then applies a separate contract or entitlement rule to each line.
| Line | Source evidence | Rule | Calculated quantity | PSA record to inspect | What a mismatch means |
|---|---|---|---|---|---|
| Managed support | 31 July Entra export plus the approved eligibility rule: 42 eligible users | Direct: every eligible user receives support | 42 support units | Customer A — managed support recurring record | The source, eligibility rule or mapping is wrong. Hold this line for correction. |
| Microsoft 365 backup | The 42 eligible users plus the protected-user list at the same cut-off | Filter: two eligible users are not covered by backup | 40 protected users | Customer A — Microsoft 365 backup recurring record | The coverage filter or protected-user evidence differs. Hold this line. |
| Endpoint security | 31 July RMM or security-vendor endpoint export | Different source: the contract bills protected endpoints, not users | 58 endpoints | Customer A — endpoint security recurring record | The device mapping, endpoint state or vendor count does not reconcile. Do not substitute 42. |
| Email or web filtering | The 42 eligible users plus an approved customer exception | Override: one covered user is billed under a separate division | 41 filtering users | Customer A — filtering recurring record | The exception, its owner or its destination has changed. Hold this line. |
| Security awareness | 42 eligible users plus the signed 45-user service minimum | Minimum: bill the greater of the live count or 45 | 45 awareness units | Customer A — security awareness recurring record | The minimum or contract dates are not reflected. Hold this line. |
The record names above are worksheet labels, not native product screen names. In a live setup, inspect the actual configured agreement addition, contract service or recurring line. A mismatch on one line does not justify blocking or changing all five: correct that affected line or record an authorised exception, then confirm its quantity in the PSA.
The destination vocabulary varies:
- ConnectWise Manage: company, agreement and agreement addition/product.
- Autotask PSA: account, recurring service contract, service and contract service units.
- HaloPSA: customer, recurring line item and recurring-invoice workflow.
These are translation aids, not claims that all three platforms behave identically. Effective dates, proration and record behaviour depend on the platform and configuration. See the current supported PSA workflows for product-level integration detail.
Step 4 — Decide what happens when the count changes
Check the signed timing rule against a test change in the destination PSA configuration. The evidence is the agreement’s effective-date or proration wording and the PSA’s resulting charge or credit. If the test result differs from the contract, that discrepancy means the quantity should be held for review until the timing rule is corrected.
| Contract or PSA rule | Quantity treatment | Review question |
|---|---|---|
| Next-cycle change | Apply at the next billing cycle | Does the signed agreement support delayed changes? |
| Full-period change | Apply the new quantity for the full period | Is this how the contract and destination PSA are configured? |
| Prorated change | Use the supported effective-date and proration behaviour | Does the PSA calculate the intended charge or credit? |
| Manual exception | Hold for an authorised decision | Who approves it, and where is the reason retained? |
No timing method is universally correct. The signed agreement and destination PSA govern the treatment. A live count of 28 can therefore produce a billable quantity of 30 where a contracted minimum applies, or remain at the old quantity until the next cycle where the contract requires it.
Step 5 — Automate stable rules and review exceptions
Check source freshness, mapping status, calculated quantity and the final PSA record before invoice generation. The evidence is the current source data, approved rule, update result and PSA-side quantity. Any difference that cannot be explained by a documented filter, minimum, effective date or override means the affected line should remain a manual exception.
Automatic update versus review is a risk decision, not a badge of sophistication. Stable mappings with predictable changes may suit configured automatic updates. New mappings, unusually large changes, stale data or temporary commercial exceptions warrant human review.
The practical review triggers are stale source data, broken mappings, unexplained changes, invalid overrides, timing differences and a final PSA mismatch. The complete pre-invoice checklist below shows what to inspect. It is an operator recommendation, not a claim that a named PSA or billing product provides a native queue or these exact statuses.
What this looked like for Cleva Group
Public customer evidence shows the model can extend beyond a handful of Microsoft licence lines. In Cleva Group’s custom billing workflow, support, backup, antivirus, web filtering, security and related services could follow Microsoft user-count logic. Department splits, minimum quantities and customer-specific rules were part of the workflow.
For one complex Cleva Group customer, roughly 25 of 30 invoice lines were pulled through Sync 365. This is a customer-specific result, not an average, benchmark or guarantee.
How Sync 365 fits the model
Sync 365 helps MSPs reconcile Microsoft 365 licence quantities and apply configured managed-user or custom recurring billing logic to supported PSA records. A Microsoft, managed-user, filtered, minimum or calculated count can drive related recurring lines where the service and configuration support it.
Verified examples include managed support, backup, antivirus, web filtering and security tooling, with filters, exclusions, minimums and customer-specific splits where configured. The exact destination records and behaviour depend on ConnectWise Manage, Autotask PSA or HaloPSA and the MSP’s configuration.
This is the difference between Microsoft licence reconciliation and custom recurring-service quantity rules: the licence line can be the beginning of the workflow rather than its stopping point. Sync 365 aligns configured billing records; it does not replace PSA invoicing. The PSA remains the system of record.
Pre-invoice checklist for multi-line recurring billing
Use this recommended control immediately before the invoice run. Each check compares the current source, approved rule or mapping with the resulting PSA record. A failed check means the affected line needs correction or an authorised exception before invoicing.
- Source sync is current for the intended billing cut-off.
- The eligibility policy still matches the signed agreement.
- Customer and service mappings resolve to the intended destination records.
- Filters do not overlap, and no destination is mapped twice.
- The destination agreement, contract or recurring line is active.
- Large increases and decreases have been explained.
- New users are covered by every applicable service rule.
- Contracted minimums and approved overrides have been applied.
- Effective dates and proration produce the intended treatment.
- Final approved quantities are present in the PSA before invoice generation.
Frequently asked questions
Can one Microsoft user count update several PSA agreement lines?
Yes, when the same approved user group genuinely applies to configured, supported lines. Each destination still needs its own mapping, filter, minimum, timing rule and exception treatment. The safe pattern is one eligible-user group with several explicit transformations, not one raw number copied everywhere.
Should support, backup, antivirus and filtering always have the same quantity?
No. They may share an eligible-user group, but the final quantities can differ because of mailbox protection, endpoint entitlement, excluded groups, customer minimums or vendor rules. A service with a different commercial unit should use the appropriate source rather than an artificial multiplier.
Who counts as a billable managed user?
The customer contract and the MSP’s documented policy define the eligible-user group. Enabled members, guests, contractors, leavers, shared identities, service accounts and excluded departments are decisions to record. There is no universal Microsoft user state that determines every support, backup or security charge.
How do minimum quantities work when the live user count falls?
Apply the contracted minimum to the destination line if it is valid for that service and period. For example, a live eligible count of 28 may remain billable at 30 under a signed minimum. The effective date, credit and proration treatment still depend on the agreement and PSA configuration.
Does Sync 365 generate the invoice?
No. Sync 365 applies configured billing logic and aligns supported PSA billing records. ConnectWise Manage, Autotask PSA or HaloPSA remains the invoicing system of record for the supported workflow.
Does the workflow behave identically in every supported PSA?
No. The control model is portable, but object names, effective dates, proration and record behaviour vary by PSA and configuration. Validate the destination records and timing for the MSP’s actual platform before enabling automatic updates.
Validate one real customer before scaling the workflow
Scalable recurring billing governs the eligible-user group, each destination rule and the exceptions. Basic licence sync can keep the first line aligned; the wider operational win comes from controlling the related services without pretending they all have the same billing unit.
Book a custom billing workflow demo and bring one real customer’s user-count rule plus the recurring PSA lines it should drive. See how the eligibility rule, minimums, exclusions, mappings and approval path would work for your PSA configuration.
Or explore custom licence billing before the call.
Sources
- Microsoft Learn: About shared mailboxes — Microsoft, accessed 18 August 2026.
- Cleva Group custom billing automation case study — Sync 365, accessed 18 August 2026.
- Managed-user billing for MSPs — Sync 365, accessed 18 August 2026.
- Custom licence billing for MSP recurring services — Sync 365, accessed 18 August 2026.