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

# Spend management

> Use alerts and limits to help customers manage and cap their spend.

Alerts provide the core signal for any spend‑control workflow.

## Subscriptions with prepaid credits

* A [**balance depleted** alert](/usage-alerting/balance-alerts) indicates that the customer's prepaid credit ledger has been depleted,
  and you should block product access or usage.
* To enforce a **hard cap** where the customer should always pay only for usage in advance, you must account for the brief delay between depletion and the alert:
  * Set the conversion rate for prepaid credits to **\$0** (this effectively means that you absorb the cost of the overage and do not pass it onto your customer), **or**
  * Charge the user for any overage per the assigned conversion rate of the price, **or**
  * Add credits effective a past timestamp to cover the overage charges. Orb will automatically apply those credits against existing usage by replaying the credits ledger.

See the implementation guide on [product access with prepaid credits](/self-serve/product-access) for more information.

## Subscriptions with in-arrears billing

* Respond to the [**cost exceeded** alert](/usage-alerting/subscription-alerts#subscription-cost) by blocking product access or usage.
* Configure a **maximum** amount as an adjustment in your subscription configuration in addition to an alert.
* In the event that there's a delay between the maximum being reached and the alert being sent from Orb,  the customer is never charged above the maximum
  and the maximum limit will still be honored on the invoice.

## Per‑tenant and per‑seat spend control

When a single subscription represents many of your own customers, seats, or workloads, use a [grouped cost alert](/usage-alerting/grouped-cost-alerts) to enforce spend limits per group rather than across the whole subscription. Group by the relevant event property (e.g. `seat_id` or `customer_id`), set a default threshold, and use per‑group `threshold_overrides` to raise caps for specific tenants or silence internal ones.

## Building spend management in your application

Keep the following in mind when building spend management in your application:

1. Allow users to define **soft** and **hard** spend limits, each with multiple thresholds. Warning thresholds
   should be used to notify the user that they are approaching the limit if hard limits are being used to block.
2. Provide a graceful **paused** state in your application when a limit is reached.
3. Send notifications—webhooks, email, or SMS—whenever a threshold is crossed.
4. Depending on your product contract, you may need to inspect the subscription state when you receive an alert to determine
   the end of the billing period. This may be important to know when product access should be ungated, or a piece of infrastructure should
   resume operation.

| Goal                              | Action                                                                                                |
| --------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Notify the user**               | Use the webhook to trigger a notification over email, SMS, or webhook.                                |
| **Block product access or usage** | Disable product functionality until the next billing period begins (based on the subscription state). |