> ## 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.

# Billing Model

> How value-based billing works in CharleOS

CharleOS uses a value-based billing model that rewards efficiency while protecting clients from cost overruns. Instead of billing raw hours logged, a formula determines what's chargeable.

## The Core Formula

Every task requirement is billed using this formula:

```
Billable = MIN(maximum, MAX(average, actual))
```

Where:

* **average** = Midpoint of the t-shirt size range (the quoted estimate)
* **maximum** = Upper bound of the t-shirt size range (the cap)
* **actual** = Time actually logged by the team

## How It Works

The formula creates three possible outcomes:

<Tabs>
  <Tab title="Fast Completion">
    **Actual \< Average**

    Bill the **average** (not the actual).

    * Team worked 3 hours on a Medium task (avg 4.5h)
    * Client pays 4.5 hours
    * Agency banks 1.5 hours (efficiency profit)

    **Both win:** Client pays fair price, agency rewards efficiency.
  </Tab>

  <Tab title="Normal Completion">
    **Average ≤ Actual ≤ Maximum**

    Bill the **actual** time.

    * Team worked 5 hours on a Medium task (avg 4.5h, max 6h)
    * Client pays 5 hours
    * No banked time or overage

    **Fair outcome:** Work was within quoted range.
  </Tab>

  <Tab title="Overrun">
    **Actual > Maximum**

    Bill the **maximum** (capped).

    * Team worked 7 hours on a Medium task (max 6h)
    * Client pays 6 hours (the cap)
    * Agency absorbs 1 hour overage

    **Client protected:** Never pays more than quoted maximum.
  </Tab>
</Tabs>

## Per-Requirement Billing

Billing is calculated **per requirement**, not per task. Tasks often have multiple requirements (design + development), and calculating separately:

* Shows where efficiency gains happen
* Reveals which requirement types have issues
* Prevents masking problems (design wins hiding dev losses)

Each requirement has its own t-shirt size and independent billing calculation.

## Key Terms

| Term                   | Definition                                                 |
| ---------------------- | ---------------------------------------------------------- |
| **Quoted Minutes**     | Average of the t-shirt size                                |
| **Quoted Max Minutes** | Maximum of the t-shirt size                                |
| **Actual Minutes**     | Sum of logged time entries                                 |
| **Billable Minutes**   | Result of the formula                                      |
| **Banked Minutes**     | Efficiency gain (billable − actual when actual \< average) |
| **Overage Minutes**    | Non-billable excess (actual − max when actual > max)       |

## When Hours Are Deducted

Hours are deducted from the client's retainer **as work is logged**, using the billable amount (not raw logged time).

<Steps>
  <Step title="Time logged">
    Team member logs time to a task
  </Step>

  <Step title="Billing calculated">
    System applies formula per requirement
  </Step>

  <Step title="Balance updated">
    Billable hours deducted from monthly allocation
  </Step>
</Steps>

If billable hours exceed the monthly allocation, the excess rolls over to the next month. See [Hour Rollover](/concepts/billing/hour-rollover) for details.

## Cross-Requirement Borrowing

When a task has **delayed subtasks** (flagged via [Running Behind](/user-guide/tasks/running-behind)), the system applies cross-requirement borrowing to prevent unnecessary agency cost.

If one requirement exceeds its t-shirt maximum while another has surplus, the surplus offsets the overage — because the client agreed to pay up to the combined maximum across all requirements.

**Worked example:**

| Requirement | Max    | Actual | Overage | Surplus |
| ----------- | ------ | ------ | ------- | ------- |
| Design      | 6h     | 5h     | 0       | 1h      |
| Development | 2h     | 3h     | 1h      | 0       |
| **Total**   | **8h** | **8h** | **1h**  | **1h**  |

Without borrowing, the agency absorbs 1h of dev overage. With borrowing, the 1h design surplus offsets the 1h dev overage — the task stays within the combined 8h cap.

<Info>
  Cross-requirement borrowing only applies when a task has at least one delayed subtask **and** at least one requirement has overage. It does not change per-requirement billing — it adjusts the task-level totals.
</Info>

## Why This Model Works

<CardGroup cols={2}>
  <Card title="Rewards efficiency" icon="trophy">
    Teams that work smart create banked time (profit margin)
  </Card>

  <Card title="Protects clients" icon="shield">
    Maximum cap means no surprise overages on invoices
  </Card>

  <Card title="Encourages accuracy" icon="bullseye">
    Overruns hurt the agency, incentivising better estimation
  </Card>

  <Card title="Transparent" icon="eye">
    Clear formula that both sides understand
  </Card>
</CardGroup>

## Learn More

<CardGroup cols={2}>
  <Card title="Billing Examples" icon="list-check" href="/concepts/billing/billing-examples">
    Worked examples showing calculations step by step
  </Card>

  <Card title="Hour Rollover" icon="rotate" href="/concepts/billing/hour-rollover">
    How hours carry over between months
  </Card>

  <Card title="T-Shirt Sizing" icon="ruler" href="/concepts/estimation/t-shirt-sizing">
    Size definitions, ranges, and how to choose
  </Card>

  <Card title="Client Intelligence" icon="brain" href="/user-guide/clients/client-intelligence">
    Deliverability scores and scheduling accuracy
  </Card>

  <Card title="Efficiency" icon="bolt" href="/concepts/financial/efficiency">
    Deep dive into banked time and profitability
  </Card>

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