Third-Party Portal Timing: How MSP Billing Leaks After Invoice Freeze
An MSP can approve a clean recurring invoice on Friday and still incur unbilled vendor cost on Monday. The cause is not necessarily a bad price or a careless team. It is often a timing split: an EDR, backup or antispam service records new usage after finance has frozen the PSA invoice batch.
The vendor’s metering event and the MSP’s customer billing event now sit in different periods. If nobody compares them, the MSP carries the cost while the related revenue is delayed, manually back-billed or missed.
Key takeaways
- Invoice freeze is a control point, not the end of usage. Endpoint and user activity can continue after the billing batch is approved.
- Each recurring service needs a defined quantity source and effective date. Do not assume every portal follows the same rhythm as Microsoft licence data.
- The PSA should remain the system of record. Portal or managed-user quantities need to reach the relevant agreement or contract line before invoicing.
- Back-billing is an exception, not a primary control. It depends on detection, ownership, commercial judgement and follow-through.
- Custom licence billing and managed-user billing cover counts derived from supported Microsoft or managed-user data. They do not mean a billing tool reads every standalone vendor portal.
The invoice closes while the vendor keeps counting
Consider the last working day of the month. Finance has reviewed the recurring batch, resolved exceptions and approved the invoices. Two days later, a customer’s office expansion activates 60 new EDR endpoints.
Assume the vendor charges £6 per endpoint and the MSP resells the service for £12. The illustrative arithmetic is:
- 60 × £6 = £360 of vendor cost;
- 60 × £12 = £720 of client revenue that needs to be billed; and
- £360 = the gross-margin contribution sitting between those figures.
These are scenario inputs, not market averages. They show the commercial timing problem: £360 of cost can arrive in the current vendor cycle while the £720 charge reaches the next customer invoice at best. If the delta is not found, the entire client charge may be missed.
Nothing has to be “wrong” inside either system. The portal can meter according to the vendor contract, while the PSA invoices the quantity present when finance froze the batch. The gap exists because the two events were never reconciled against a common cut-off.
This matters beyond EDR. Backup agents, protected mailboxes, email security, DNS filtering, password management and other recurring tools may use different activation, reporting, minimum-commitment or billing rules. The exact rule is vendor-specific, so the control should record it rather than assume a universal cadence.
Why Microsoft-centric reconciliation habits leave a wider-stack gap
Microsoft licence reconciliation and third-party service reconciliation share a goal, but they do not always share a source or metering rule.
A Microsoft workflow may begin with tenant, subscription or managed-user data. A standalone security portal may count deployed agents. A backup provider may count protected workloads or mailboxes. An antispam service may use enabled users, domains or a contracted minimum.
The practical question is therefore not “Which portal is correct?” It is:
Which quantity, measured at which effective time, should update which recurring PSA line for this customer?
That definition belongs in the billing process. Without it, finance may compare a month-end spreadsheet with last month’s invoice even though the vendor charge is based on a later activation event.
PSA structures also preserve timing. For example, Autotask’s official documentation describes recurring service adjustments with effective dates and service units for specific date ranges. HaloPSA documents calculated recurring invoice quantities and a separate ready-for-invoicing area for pro-rata changes. The product mechanics differ, but both illustrate why quantity and effective date must be considered together.
How the timing split affects cash and margin reporting
The first effect is cash timing. The MSP pays or accrues the new vendor cost before collecting the related client revenue. When this happens across several services and customers, the business is funding the gap from working capital.
The second effect is period reporting. If cost lands this month and resale revenue lands next month, current-period gross margin appears lower. The next period may then contain revenue for an earlier usage event. A steady stream of cross-period adjustments makes it harder to see whether an account is genuinely becoming less profitable or merely suffering from timing noise.
The third effect is behavioural. Small deltas are easy to absorb because reopening an approved invoice can create more administration and client explanation than the individual charge appears to justify. Repeated small write-offs can then become normal operating practice rather than a visible exception.
A reliable control should distinguish three outcomes:
- Current-cycle adjustment: the quantity can still be added before the invoice is issued.
- Documented next-cycle charge: the amount is contractually billable later and is recorded with its service period.
- Approved write-off: an authorised person accepts the commercial impact and records why.
Silence is not a fourth outcome.
Why manual back-billing is a weak primary control
Back-billing sounds simple only after somebody has found the variance. Before that can happen, the team must:
- capture the vendor quantity for the relevant period;
- compare it with the PSA agreement or contract quantity;
- identify whether the invoice is open, approved or already sent;
- confirm the customer’s contract permits the adjustment;
- calculate the amount and service period;
- decide whether to amend, defer or write off the charge; and
- make sure the decision reaches the invoice.
That chain crosses service delivery, operations and finance. If ownership is unclear, a portal export can sit in a folder while each team assumes another team will act.
A mature process treats back-billing as a routed exception with an owner and due date. It does not rely on month-end memory or on one administrator recognising that a portal count changed after approval.
Build a pre-invoice and post-freeze control loop
A useful recurring-service control has five parts.
1. Define the quantity source
For every billable service, record whether the source is a standalone vendor portal, an endpoint count, a protected-mailbox count, a Microsoft licence, a managed-user population, a minimum quantity or a calculated rule. Include the vendor’s effective-date and proration terms.
2. Map it to the PSA line
Name the exact agreement, contract service or recurring invoice line that should receive the quantity. The PSA remains the commercial system of record; an accurate portal count that never reaches the correct billable line does not protect revenue.
3. Compare close to invoice approval
Run the comparison before freeze, then run a narrower post-freeze check for changes that landed during the gap. The second check should not silently edit sent invoices. It should create an exception with the quantity delta, service period and invoice status.
4. Show the commercial impact
Give the reviewer the vendor cost, intended resale price and timing outcome. Quantity-only alerts make every variance look equal. A commercial view helps finance prioritise material exceptions without ignoring small recurring patterns.
5. Route and record the decision
Assign an owner, threshold and permitted action. Preserve whether the item was added now, scheduled for the next cycle or written off with approval. That history helps explain customer charges and reveals repeated process gaps.
Where custom licence and managed-user billing fit
Some recurring services do not need a separate portal count. When support, Microsoft 365 backup, antispam, filtering or another supported service is billed from a Microsoft or managed-user population, custom licence billing can use that trusted count to drive related PSA agreement lines. Managed-user billing can apply the user population, minimums, exclusions, filters and customer-specific rules that define the billable quantity.
That is different from retrieving live usage from a standalone EDR, backup or security vendor console. If the authoritative quantity exists only in that third-party portal, it still needs its own supported capture and reconciliation process. Do not substitute a Microsoft-derived user count unless the contract genuinely defines billing that way.
The strongest design uses the right source for each service and keeps the resulting PSA quantities reviewable. Sync 365 can help align Microsoft-derived and managed-user recurring lines across supported PSA platforms, while the PSA continues to generate the invoice.
Before the next invoice freeze, choose one customer and list every per-user or per-endpoint service. For each line, write down the source, effective time, PSA destination and post-freeze owner. Any blank is a timing gap waiting to become a margin exception.