14.28. Sell and Track Prepaid Hour Blocks Without a Recurring Contract

Some clients need reliable access to your technicians but do not want a recurring agreement. A prepaid hour block lets the MSP sell a defined bundle of labor, record what remains, and draw approved work from that balance without creating a recurring contract solely to hold the allowance.

Blocks can stack, carry across month boundaries, expire on a calendar date, and work with Prepaid Balance Alerts. For offerings that cover several kinds of labor, a weighted bucket-hour pool can let multiple services share one allowance while consuming it at different rates.

---

Choose the right hour mechanism

Contract buckets, prepaid blocks, and weighted pools solve different commercial problems.

The month boundary is the practical difference MSP billing teams ask about most. A monthly contract bucket belongs to a monthly service period, even if its line permits rollover. A prepaid block is not replenished or reset by the calendar turning to a new month. Its remaining hours stay available under the block's own balance and expiration rules.

See 14.7. Add Fixed, Hourly, Usage, and Bucket Contract Lines with Reusable Presets for period-scoped contract allowances.

---

Set up a prepaid hour block

Agree the commercial terms before recording the block:

Figure 1: Blocks sold to a client, with remaining hours and status. A voided block stays visible so the history still reconciles.

• The number of hours being purchased.
• The services or work the block can cover.
• Whether the block is being sold through an invoice or granted without one.
• Whether it expires and, if so, the calendar expiration date.
• The prepaid balance threshold and the people who should be alerted.
• How work beyond the remaining balance will be billed.

Go to Clients > client > Billing Dashboard > Hour Blocks. The section says: "One-time prepaid hour blocks. Time that isn't covered by a contract line draws down these blocks, oldest expiration first." It shows Sell block and Grant block actions. Selling a block requires the billing:create permission.

In Sell block, enter Hours, Rate per hour, Expiration (optional), and Notes. Creating the sale produces a draft invoice and a pending block. Finalize the invoice to activate the purchased hours. A block created with Grant block is not invoiced and is active immediately.

Review the invoice and the resulting hour balance together before technicians begin drawing from a sold block. The billing document explains what the client bought; the hour-block details show what remains available for service.

---

How stacked blocks burn

A client can hold several prepaid blocks at once. AlgaPSA consumes eligible blocks in this order:

1. Earliest expiration date first, with never-expiring blocks last.
2. Oldest purchase first when the expiration dates are the same or both blocks never expire.
3. Oldest creation date, then the block identifier, as tie-breakers.

Purchase order is therefore not the primary rule when blocks have different expiration dates.

Suppose Cascade Manufacturing has these blocks, neither of which has an expiration date:

Cascade uses 5 hours in April. Because neither block expires, purchase order decides the sequence: the first 3 hours come from the January block and the next 2 hours from the March block.

The remaining 10 hours do not reset at the end of April. They continue into May because the balance belongs to the prepaid block, not to an April contract period.

Expiration takes precedence over purchase age. If an older block bought in January never expires and a newer block bought in March expires on April 30, the March block burns first because it has the earlier expiration.

When a client questions a balance, go to Clients > client > Billing Dashboard > Hour Blocks. The table shows Block, Remaining, and Expiration. Open the row actions to View details, Adjust hours, Edit expiration, Expire, or Void. Hour block details shows Total, Remaining, Used, Scope, expiration, and source. Consumption appears under Burn history; purchase, grant, adjustment, expiration, void, and reversal events appear under Audit trail.

---

Expiration uses the tenant's calendar

Expiration is a calendar-date rule evaluated in the tenant's timezone. A block set to expire on a given date does not shift a day earlier or later because a technician, client contact, or browser is in another timezone.

The block remains eligible through its expiration date and expires after that date has passed in the tenant's effective timezone. When you use Edit expiration, the dialog confirms: Credits are applied in order of expiration date (oldest first).

This matters for distributed teams. If Northwind Managed IT and Cascade Manufacturing work in different timezones, both should still see the same contractual expiration date. Use the date written in the agreement, and make sure the tenant timezone represents the business calendar your MSP uses for billing.

When several blocks are available, review their expiration dates before their purchase dates. A newer block with an earlier expiration burns before an older block that expires later or never expires.

Do not extend or replace an expired block informally. If the MSP agrees to restore hours or refund value, document the billing adjustment. See 14.23. Issue and Apply Credit Notes for MSP Client Billing for financial corrections.

---

Use prepaid balance alerts before the balance reaches zero

A Prepaid Balance Alert gives the account manager time to contact the client while some coverage remains. Choose a threshold that reflects the client's normal work pattern, the time needed to approve another purchase, and the risk of an active incident consuming the last hours.

The alert can notify only, create a draft top-up invoice and notify, or create, finalize, and email a top-up invoice. Keep a person in the loop when the next purchase requires scope review or explicit approval. Use an invoice-creating option only where the client has already agreed to an evergreen arrangement.

See 14.29. Monitor Prepaid Balances with Alerts and Automatic Replenishment for threshold and replenishment decisions.

---

Weighted bucket-hour pools

A weighted bucket-hour pool is useful when several services belong to one allowance but an hour of each service should not have equal impact. Standard support might consume one pool hour per hour worked, while after-hours support consumes 1.5 pool hours per hour worked.

Each participating service carries its own burn multiplier:

In this example, Cascade Manufacturing bought a 20-pool-hour allowance. The two services consume 23 pool hours, leaving 3 pool hours of overage.

How overage is apportioned

The overage does not land entirely on whichever service happens to be invoiced last. AlgaPSA apportions it according to each service's actual share of pool consumption:

The table rounds the displayed allocations for readability. The important rule is proportional responsibility: standard support caused 14/23 of the consumption and after-hours support caused 9/23, so each receives the same share of overage.

This keeps invoice results independent of processing order and makes the overage traceable to the work that consumed the pool.

---

Configure a weighted pool

Before setup, list every service that may draw from the pool and agree its multiplier. A multiplier should express the commercial weight of that service, not a technician's seniority unless the client agreement explicitly prices it that way.

Figure 2: A pool on a contract line. Member services list their multiplier, so an after-hours service can consume pool hours faster than standard work.

Go to Billing > Client Contracts > open contract > Contract Lines, then expand or edit a line. Under Bucket Pools, select Add Pool and configure Total hours, Overage rate ($/hr), and Allow rollover.

Use Member services and Burn multiplier (×) to define which services draw from the pool and at what weight. The scope text confirms either Covers all services on the line (members are multiplier overrides) or Member services only. For after-hours weighting, configure After-hours burn multiplier, Multiplier (e.g. 1.5), and Business hours schedule. If no services are attached, the pool shows no services attached — nothing burns from this pool.

Test a mix of standard and weighted work before the first live invoice.

Use 14.11. Inspect, Repair, and Troubleshoot Recurring Service Periods on MSP Contracts to understand the period boundary when comparing a weighted pool with a recurring contract allowance.

---

Operating checklist

• Confirm each block purchase created the expected starting balance.
• Check block expirations, then purchase dates, before explaining a draw-down.
• Review upcoming expiration dates in the tenant's timezone.
• Investigate time entries mapped to the wrong service before adjusting a pool balance.
• Recalculate a weighted example when service multipliers change.
• Treat prepaid balance alerts as a client-management workflow, not only a billing notification.

---

Related topics

• 14.7. Add Fixed, Hourly, Usage, and Bucket Contract Lines with Reusable Presets
• 14.11. Inspect, Repair, and Troubleshoot Recurring Service Periods on MSP Contracts
• 14.23. Issue and Apply Credit Notes for MSP Client Billing
• 14.29. Monitor Prepaid Balances with Alerts and Automatic Replenishment