> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Hour Rollover

> How hours carry over between months when work exceeds budget

When billable hours exceed a client's monthly allocation, the extra hours **roll over** to the next month. This keeps billing fair when work fluctuates.

## Why Rollover Exists

CharleOS uses a two-layer planning system:

| Planning Layer         | Uses                            | Purpose                                            |
| ---------------------- | ------------------------------- | -------------------------------------------------- |
| **PM Budget Planning** | Average estimates               | Determines what fits in the client's monthly hours |
| **Team Scheduling**    | Max or score-adjusted estimates | Ensures realistic capacity for delivery            |

This creates a gap: PMs plan using averages, but actual work may take longer (up to the max). Rollover handles this difference.

<Info>
  Clients aren't charged extra—they just use future allocation when work runs over in a given month.
</Info>

## How It Works

At the end of each billing period:

```
Rollover = Billable Hours − Allocated Hours
```

* **Positive rollover**: Client used more than allocated → deduct from next month
* **Zero or negative**: Client used less than allocated → no rollover (agency absorbs unused time)

<Warning>
  Under-delivery doesn't create client credit. If a client uses 80 hours of their 100-hour allocation, the remaining 20 hours stay with the agency—they don't roll forward.
</Warning>

## Example: Monthly Rollover

### Scenario

**Client:** Acme Corp
**Monthly allocation:** 100 hours
**Work planned:** 10 tasks at average estimates (totalling 100 hours)

### What Happens

| Task      | Average  | Max      | Actual   | Billable |
| --------- | -------- | -------- | -------- | -------- |
| Task 1    | 8h       | 12h      | 10h      | 10h      |
| Task 2    | 6h       | 8h       | 5h       | 6h       |
| Task 3    | 12h      | 16h      | 14h      | 14h      |
| Task 4    | 10h      | 14h      | 12h      | 12h      |
| Task 5    | 8h       | 12h      | 9h       | 9h       |
| Task 6    | 12h      | 16h      | 15h      | 15h      |
| Task 7    | 10h      | 14h      | 11h      | 11h      |
| Task 8    | 14h      | 20h      | 18h      | 18h      |
| Task 9    | 10h      | 14h      | 8h       | 10h      |
| Task 10   | 10h      | 14h      | 13h      | 13h      |
| **Total** | **100h** | **140h** | **115h** | **118h** |

**Result:**

* Allocated: 100 hours
* Billable: 118 hours
* **Rollover: 18 hours** (deducted from next month)

### Next Month

* Base allocation: 100 hours
* Rollover from last month: −18 hours
* **Available hours: 82 hours**

The PM now plans the next month knowing they have 82 hours, not 100.

## Why This Approach?

<AccordionGroup>
  <Accordion title="Fair to clients" icon="scale-balanced">
    Clients pay for the hours used, just spread across months. They're never surprised by a larger invoice—the work just comes off their future allocation.
  </Accordion>

  <Accordion title="Realistic scheduling" icon="calendar">
    Teams can schedule using max estimates (or score-adjusted) without worrying about artificial constraints. Work gets done properly rather than rushed to fit arbitrary monthly limits.
  </Accordion>

  <Accordion title="Encourages good estimation" icon="bullseye">
    If rollover consistently eats into next month's hours, it signals estimation issues. PMs learn to plan more conservatively or improve scoping.
  </Accordion>

  <Accordion title="Smooth workload" icon="chart-line">
    Some months naturally have more work. Rollover lets the team focus on delivery quality rather than artificial monthly boundaries.
  </Accordion>
</AccordionGroup>

## Two-Layer Planning in Practice

### Layer 1: PM Budget Planning (Averages)

When deciding what work fits in a month, PMs use **average estimates**:

* Client has 100 hours this month
* PM selects tasks totalling \~100 hours at average
* This is what the client "budgets for"

### Layer 2: Team Scheduling (Max or Score-Adjusted)

When scheduling the actual work, use **max estimates** or **score-adjusted estimates**:

* New clients (no history): Use max estimates
* Established clients: Use score-adjusted estimates based on their deliverability score

This ensures the team has realistic time to deliver quality work.

<Tabs>
  <Tab title="New Client">
    **No historical data available**

    * Use max estimates for scheduling
    * Expect some rollover initially
    * As tasks complete, scores build up
    * Future months become more predictable
  </Tab>

  <Tab title="Established Client">
    **Score available (e.g., 1.15 = 15% slower)**

    * Use score-adjusted estimates
    * Example: M task (avg 4.5h) × 1.15 = 5.2h for scheduling
    * More accurate capacity planning
    * Less rollover surprise
  </Tab>
</Tabs>

## Rollover Scenarios

### Scenario 1: Slight Overrun

**Month 1:**

* Allocated: 80 hours
* Billable: 88 hours
* Rollover: 8 hours

**Month 2:**

* Available: 80 − 8 = 72 hours
* PM plans work for 72 hours
* Team delivers, uses exactly 72 hours
* No further rollover

**Result:** Balance restored in one month.

### Scenario 2: Consistent Overruns

**Month 1:** Rollover 10 hours
**Month 2:** Rollover 12 hours (cumulative: 22 hours)
**Month 3:** Rollover 8 hours (cumulative: 30 hours)

**Warning signs:**

* Estimates are consistently too low
* Scope creep is happening
* Client needs may have outgrown their plan

**Actions:**

* Review estimation accuracy
* Discuss plan upgrade with client
* Tighten scope management

### Scenario 3: Under-Delivery

**Month 1:**

* Allocated: 100 hours
* Billable: 75 hours
* Rollover: 0 (not −25)

The agency absorbs the unused 25 hours. This might happen when:

* Work was blocked waiting on client feedback
* Priorities shifted mid-month
* Estimates were too conservative

<Note>
  Under-delivery doesn't give clients "banked hours" for next month. Each month resets to full allocation (minus any positive rollover).
</Note>

## Viewing Rollover

### Client Detail Page

The client sidebar shows:

* Current month allocation
* Rollover from previous month
* Effective available hours

### Hours Summary

When viewing a client's hours:

* **Allocated**: Base plan hours
* **Rollover**: Carried from last month
* **Available**: Allocated − Rollover
* **Used**: Billable hours logged this month
* **Remaining**: Available − Used

## Rollover Caps

To prevent excessive rollover accumulation, a cap may be configured:

* Rollover limited to X hours maximum
* Excess beyond the cap is absorbed by the agency
* Protects against runaway rollover situations

<Info>
  Contact your admin to check if a rollover cap is configured for your clients.
</Info>

## Best Practices

<CardGroup cols={2}>
  <Card title="Monitor monthly" icon="chart-line">
    Check rollover trends at month-end. Consistent positive rollover signals estimation or scope issues.
  </Card>

  <Card title="Plan conservatively" icon="shield">
    If a client has rollover, plan next month's work 10-15% under to recover.
  </Card>

  <Card title="Use scoring data" icon="brain">
    Check client deliverability scores. A score of 1.2 means work takes 20% longer—factor this into planning.
  </Card>

  <Card title="Communicate early" icon="comments">
    If rollover is building up, discuss with the client before it becomes a problem.
  </Card>
</CardGroup>

## Related

<CardGroup cols={2}>
  <Card title="Billing Model" icon="calculator" href="/concepts/billing/billing-model">
    How the billing formula works
  </Card>

  <Card title="Client Intelligence" icon="brain" href="/user-guide/clients/client-intelligence">
    View client deliverability scores
  </Card>

  <Card title="Retainer Plans" icon="file-contract" href="/concepts/billing/retainer-plans">
    How monthly allocations are set
  </Card>

  <Card title="T-Shirt Sizing" icon="ruler" href="/concepts/estimation/t-shirt-sizing">
    Understanding average and max estimates
  </Card>
</CardGroup>
