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

# Read your usage

> The billed number, the accounts behind it, and the two reads that let you check an invoice without asking anyone.

Two routes carry your firm's meter. One gives the number you are billed on; the other lists the
accounts that made it. They are computed from the same query the trdrs invoice is, so the second
always sums to the first — which is what makes them worth reading instead of a monthly email.

Both run with your partner key. They sit under
[Connect](/api-reference/connect/get-monthly-usage) in the reference because the meter is one
meter, whether the accounts arrived through a registration or you issued them yourself.

<Steps>
  <Step title="Read the month's number">
    [Get monthly usage](/api-reference/connect/get-monthly-usage) answers with the count, the
    price, and the total.

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/partner/usage?month=2026-07" \
      -H "Authorization: Bearer $TRDRS_PARTNER_KEY"
    ```

    ```json theme={null}
    {
      "firm": "yourfirm",
      "month": "2026-07",
      "basis": "rithmic-system",
      "activeAccounts": 128,
      "priceCentsPerActiveAccount": 200,
      "amountCents": 25600
    }
    ```

    Money is in cents and integral. A null price or amount means unpriced — never a zero bill.
  </Step>

  <Step title="Pull the accounts behind it">
    [List billed accounts](/api-reference/connect/list-billed-accounts) expands the same query into
    one row per account that counted, ordered by account number.

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/partner/usage/accounts?month=2026-07" \
      -H "Authorization: Bearer $TRDRS_PARTNER_KEY"
    ```

    Each row carries the `accountNumber`, the count of real `fills` inside the month, and
    `firstFillAt` / `lastFillAt` in UTC. Accounts are named by their venue account number — the
    identifier your firm issued. No trader identity fields appear on this surface.
  </Step>

  <Step title="Watch the month as it runs">
    Both routes default to the previous complete month — the one being invoiced. Naming the current
    month is allowed and answers month-to-date, which keeps moving until the month closes.

    ```bash theme={null}
    curl "$TRDRS_API_BASE_URL/api/partner/usage" \
      -H "Authorization: Bearer $TRDRS_PARTNER_KEY"
    ```

    `month` is `YYYY-MM` and months are UTC. A malformed month is a `400`, rejected rather than
    silently reset to a default — a typo in a reporting job should fail loudly, not quietly bill you
    for a different month.
  </Step>
</Steps>

## What the meter counts

In the contract's own words: `activeAccounts` is **the number of distinct accounts that took at
least one real fill inside the month**. Three consequences follow directly from that sentence.

|                                                  | Counts                                 |
| ------------------------------------------------ | -------------------------------------- |
| An account that traded once in the month         | yes — once, however many fills it took |
| An account that connected but never traded       | no                                     |
| An account whose only fills were simulated       | no                                     |
| The same account trading in two different months | once in each month, separately         |

There is no proration and no partial account: an account either printed a real fill inside the UTC
month or it did not.

## Reading `basis` before you read the number

`basis` says how the accounts were attributed to your firm, and it changes what the number means.

| `basis`          | What it means                                                             | What you get                                                                                                                                                                |
| ---------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `rithmic-system` | Accounts were matched to your system. The normal case.                    | A real count, and a real `amountCents` when a price is set.                                                                                                                 |
| `unattributable` | This deployment cannot attribute accounts to your firm on your connector. | `activeAccounts` is `0` by construction and `amountCents` is null, so it can never be mistaken for a real zero bill. The account list comes back empty for the same reason. |

The same care shows up in the refusals: a deployment without metering answers `404` rather than a
zero, and the accounts route answers `404` rather than an empty list that would read as "no
accounts billed".

## Reconciling an invoice

1. **Read the month's number** with `basis` and `activeAccounts`. If `basis` is `unattributable`,
   stop — the count is structural, not a measurement, and the invoice question is a commercial one.
2. **Pull the account list for the same month.** It always sums to `activeAccounts`, because it is
   the same query expanded. If it does not match your expectation, the difference is now
   account-by-account rather than a single disputed total.
3. **Diff it against your own records.** An account on our list and not on yours traded when you
   thought it was dormant. An account on yours and not ours took no real fill that month —
   connected-but-idle, or simulated only.
4. **Check the arithmetic.** `amountCents` is `activeAccounts` × `priceCentsPerActiveAccount`, in
   cents. A null price means no price is set on your firm, which is a contract question, not a data
   one.

Scope is your own firm and nothing else, on both routes. The firm is resolved from your key, not
from a parameter, so there is no argument that reaches another firm's accounts — and no way to
accidentally reconcile against somebody else's month.

## The refusals

| Status | When                                                                                                                                      |
| ------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `400`  | `month` is not `YYYY-MM`.                                                                                                                 |
| `401`  | The bearer is not a partner-scoped key for an active partner firm.                                                                        |
| `404`  | Metering is not enabled on this deployment, or no usage record exists for the firm. Never answered as a zero, and never as an empty list. |

## Where to go deeper

* [Issue evaluation accounts](/guides/issue-accounts) — the accounts that can become billable.
* [Register an account](/guides/register-an-account) — the other way an account arrives.
* [Record balance operations](/guides/record-balance-operations) — the other ledger your finance team reads.
* [Connect](/partner-platform/operator-concepts/connect) — the reporting views in context.