# Reconcile account activity

Product: Client Trade API
Guides follow API reference 0.3.0 and event reference 0.2.0.
Canonical page: https://docs.axiym.io/trade-api/integration-guide/reconcile-activity

Use Axiym account statements as the ledger view of balance changes. Use
deposits, conversions, and withdrawals as the business view of the operations
that caused those changes.

Retrieve the statement and every related resource through the same client's
`/clients/{clientId}` path. Retain `clientId` in your own ledger so records
from different clients cannot be mixed.

## Retrieve a statement period

```sh
curl \
  "https://partner-api.sandbox.axiym.io/api/v1/clients/$CLIENT_ID/accounts/$ACCOUNT_ID/statement?from=2026-07-01&to=2026-07-31&first=100" \
  --header "Authorization: Bearer $AXIYM_ACCESS_TOKEN"
```

`from` and `to` are inclusive UTC calendar dates. If you omit them, the
statement covers the Axiym account's full history.

The statement is self-checking:

```text
openingBalance + totalCredited - totalDebited = closingBalance
```

Each entry has a positive `amount`; `type` determines whether it is a `CREDIT`
or `DEBIT`. When `balanceBefore` is present, consecutive entries should also
reconcile through `balanceBefore` and `balanceAfter`.

## Follow every page

When `pageInfo.hasNextPage` is true, send the returned `endCursor` as the next
request's `after` value. Keep the original Axiym account, date range, and filters
unchanged while paging.

Do not parse or construct cursors yourself.

## Join entries to API resources

When a statement entry is linked to a resource, it contains:

* `relatedResourceType`: `DEPOSIT`, `CONVERSION`, `WITHDRAWAL`, or `PAYOUT`; and
* `relatedResourceId`: the corresponding resource identifier.

For `DEPOSIT`, `CONVERSION`, and `WITHDRAWAL`, use those fields to retrieve the
authoritative resource through the Client Trade API:

| Entry type   | Retrieve                                             |
| ------------ | ---------------------------------------------------- |
| `DEPOSIT`    | `GET /clients/{clientId}/deposits/{depositId}`       |
| `CONVERSION` | `GET /clients/{clientId}/conversions/{conversionId}` |
| `WITHDRAWAL` | `GET /clients/{clientId}/withdrawals/{withdrawalId}` |

The statement schema also permits `PAYOUT`, but the Client Trade API does not
expose a payout retrieval endpoint. If encountered, retain the linked identifier
for reconciliation and confirm the appropriate resource access with Axiym.

An entry without related-resource fields can be a direct ledger adjustment.
Do not invent a Client Trade API resource for it.

## Reconcile conversions across two Axiym accounts

A completed conversion affects both Axiym accounts in the pair:

1. retrieve the `sellAccount` statement and find the conversion debit;
2. retrieve the `buyAccount` statement and find the conversion credit;
3. join both entries to the same `conversionId`; and
4. compare the resource's `sellAmount`, `buyAmount`, rate, and fee with your
   internal record.

## Use each identifier for its intended purpose

| Identifier          | Purpose                                                         |
| ------------------- | --------------------------------------------------------------- |
| Resource ID         | Retrieve the Axiym deposit, conversion, or withdrawal.          |
| `externalReference` | Correlate a conversion or withdrawal with your business record. |
| `X-Request-Id`      | Trace one HTTP attempt and investigate it with Axiym.           |
| `Idempotency-Key`   | Determine whether a state-changing request is new or a retry.   |

Store these separately. Reusing one value for every purpose makes incident
investigation and safe retry behavior harder.

## Reconciliation in sandbox

Sandbox operations create sandbox statement entries and should satisfy the
same balance equation as production activity. Bank deposits and withdrawals
may have simulated external processing and synthetic payment references, so
there is no corresponding real bank statement to compare. A completed wallet
operation can include a test-network transaction hash that can be checked on
the relevant test-network explorer.

Before production, supplement sandbox reconciliation tests with the real bank,
provider, and operational records used by your partnership.