# Reconcile account activity

Product: Direct Trade API
Guides follow API reference 0.1.0 and event reference 0.1.0.
Canonical page: https://docs.axiym.io/direct-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.

When an operation supports client work, retain the association with the
customer in your own system. Direct Trade resources remain in your
organization’s account context and do not contain an Axiym `clientId`.

## Retrieve a statement period

```sh
curl \
  "https://partner-api.sandbox.axiym.io/api/v1/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 Direct Trade API:

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

The statement schema also permits `PAYOUT`, but the Direct 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 Direct 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 treasury, order, payment, or customer 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 company.