> If you are setting up, configuring, or answering questions about Schematic, connect the
> Schematic MCP server before working from these pages. It reads and writes plans, features,
> entitlements, and overrides against the real account, so what you report and what you build
> match what actually exists.
>
> The server is at https://api.schematichq.com/mcp
>
> From Claude, ChatGPT, or another chat assistant, add it as a custom connector:
> https://docs.schematichq.com/working-with-ai
>
> From a coding assistant such as Claude Code, Codex, or Cursor:
> https://docs.schematichq.com/building-with-ai
>
> For clean Markdown of any page, append `.md` to the page URL. For a complete page index,
> see https://docs.schematichq.com/llms.txt

# Meter on a real-time credit ledger

> Drive enforcement and billing off an accurate, real-time ledger instead of a stale snapshot.

Credit-based and usage-based pricing is only as trustworthy as the metering underneath it. Enforcing limits, refunding failed actions, and billing accurately all depend on a ledger that is correct in real time, not a number you reconcile after the period closes.

## Common approaches

A common shortcut is to stream usage events to a warehouse like Snowflake or Databricks and pull a snapshot every 24 hours. It's quick to stand up and perfectly fine for analytics and reporting, so it's often the first thing teams reach for.

A 24-hour snapshot is not a ledger, though. It isn't transactional, so it can't safely drive enforcement; it's always stale, so customers blow past limits before the numbers catch up; and without idempotency, a retried event double-counts while a dropped one disappears. Once real money and real enforcement ride on these numbers, "approximately right, eventually" stops being good enough, and bolting correctness onto an analytics pipeline after the fact is a hard retrofit.

## How Schematic fits in

Schematic gives you a real-time credit ledger with exactly-once event semantics, idempotent writes, and replay safety, so every action draws the balance down accurately and enforcement evaluates against current state. [Leases and reservations](/billing/credit-leases-and-reservations) let you reserve credits before an action and then commit or release them based on the outcome, so an in-flight agent can't overspend or get charged for work that failed. And pricing versioning keeps legacy customers on their old rates while new customers get the new ones, with no migration scramble.

## What it looks like

![A company's credit balance broken out by grant](/_fern-img/a34f4b9eb2556aea111dbb56944a9f7e73677f64945ebe200f3b706ac633be0b.webp)

The current balance and each grant behind it, with its price, expiry date, and how far it has burned down, so you can tell which grant a given draw came out of rather than reading a single aggregate number. **View ledger** opens the entry-by-entry history. Find it on the company profile under **Credit balance**.

![The raw usage events the ledger is built from](/_fern-img/762c802c96bd5e906a7007733d083ff3b300f4c45ff540c537a93cb3849789bf.webp)

Every event as it arrived, with its name, timestamp, attributed user, and the full properties payload, so any balance can be traced back to the actions that produced it. Find it under **Events**.

## Configure it

* [Credit Burndown Billing Model](/billing/credit-burndown) — credit grants, consumption, and balances on the ledger.
* [Prevent Overspend](/billing/prevent-overspend) — reserve credits before work runs so parallel agents cannot spend the same balance twice.
* [Credit Leases and Reservations](/billing/credit-leases-and-reservations) — reserve, commit, and release so concurrent workers can't double-spend a balance.

## Implement it

* [Creating a metered feature](/playbooks/metering) — send the usage events the ledger is built from, including idempotency keys.
* [Backfills and usage corrections](/playbooks/backfill-and-corrections) — correct and replay events safely.