> ## 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. # Record balance operations > Money that moves on an account without a trade — a payout, a credit, a correction — written to the ledger first and keyed so it can never happen twice. A balance operation is money moving on a firm-issued account for a reason that is not a trade. Trading P\&L never comes through here: fills settle on their own path, and this route exists for everything else your business does to an account. Everything here runs with your partner key against `/api/partner/` routes. [Create a balance operation](/api-reference/firm-accounts/create-a-balance-operation) names the account, the direction, a positive amount, and your own `referenceId`. ```bash theme={null} curl -X POST "$TRDRS_API_BASE_URL/api/partner/balance-op" \ -H "Authorization: Bearer $TRDRS_PARTNER_KEY" \ -H "Content-Type: application/json" \ -d '{ "accountNumber": "EVAL-7C21A9", "op": "debit", "amount": 800, "referenceId": "payout-2026-08-31-a", "comment": "August profit-share payout" }' ``` The move lands on the account immediately and the trader's dashboard repaints live. The response is small on purpose: `recorded`, the `op`, and the `amount`. The operation is written to the balance ledger *first*, keyed on your `referenceId`. A duplicate reference answers `409` and moves nothing — so a retried pipeline can never pay out twice, and a `409` on a payout retry is the correct, boring outcome rather than an incident. The reference is at most 80 characters. Key it on the thing your business actually means: the payout run and the account, not a timestamp that changes on retry. [List issued accounts](/api-reference/firm-accounts/list-issued-accounts) shows the effect. The `balance` field is the live figure — the starting balance plus realized trading P\&L plus every balance operation you have recorded — while `startingBalance` does not move. ```bash theme={null} curl "$TRDRS_API_BASE_URL/api/partner/accounts" \ -H "Authorization: Bearer $TRDRS_PARTNER_KEY" ``` Every recorded operation fires a `balance.recorded` event to your registered endpoints, with the account number, the op, the amount, and your `referenceId` in the payload — which is also the natural key for a handler that must tolerate a retried delivery. ```json theme={null} { "type": "balance.recorded", "createdAt": "2026-08-24T19:12:44Z", "data": { "accountNumber": "EVAL-7C21A9", "op": "debit", "amount": 800, "referenceId": "payout-2026-08-31-a" } } ``` ## The three ops `amount` is always positive. The `op` carries the direction — there are no negative amounts to get the sign wrong on. | `op` | Direction | The usual reason | | ------------ | ----------- | -------------------------------------------------- | | `credit` | adds | A promotional credit, a bonus, a top-up. | | `debit` | subtracts | A payout to the trader, a fee your firm is taking. | | `adjustment` | as recorded | A correction to something that landed wrong. | `amount` is in account currency and at most 10000000. A missing field, a non-positive amount, or an unknown `op` is a `400`. ## When a firm records one * **A payout.** The trader earned a profit share and you are moving it off the platform account. A `debit`, keyed on the payout run. * **A promotional credit.** A bonus balance, a goodwill top-up after an outage, a reward. A `credit`. * **A correction.** Something landed wrong and the books need to agree. An `adjustment`, with the `comment` carrying why. What it is *not* for: returning an evaluation to its starting state. That is [reset](/api-reference/firm-accounts/reset-an-issued-account), which also clears positions and working orders and stamps `resetAt` on the account. Reaching for a balance operation to fake a reset leaves the trader's open risk in place. ## What lands in the audit trail The ledger row is permanent and auditable on both sides — your records and ours describe the same event, because both were written from the same call. Each row carries your `referenceId` and, when you sent one, the `comment` (at most 300 characters). Write something a colleague will understand in six months; it is the only free text on the row. Two other things write to the same ledger, so a firm's account history reads as one sequence: a `provision` row when the account is [issued](/guides/issue-accounts), and a row for every [reset](/api-reference/firm-accounts/reset-an-issued-account). ## The refusals | Status | When | | ------ | --------------------------------------------------------------------------------------------------------------------------------------- | | `400` | A missing field, a non-positive amount, or an unknown `op`. | | `401` | The bearer is not a partner-scoped key for an active partner firm. | | `404` | No firm-issued account with that number — which also covers "not your account" — or issuing accounts is not enabled on this deployment. | | `409` | Duplicate `referenceId`. This operation was already recorded, and nothing moved. | ## Where to go deeper * [Issue evaluation accounts](/guides/issue-accounts) — where `startingBalance` and reset come from. * [Receive events](/guides/receive-events) — wiring `balance.recorded` into your back office. * [Read your usage](/guides/read-your-usage) — the other number your finance team reconciles. * [Prop firms](/guides/prop-firms-overview) — the whole firm surface in one page.