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

# Funding · Overview

> Fund the company pool and dedicated-balance cards, transfer between pool and cards, query balances, and reconcile on three levels: deposit records, transaction records and statements.

## 📄 Guide

The funding side has one principle: fund first, spend second. This page walks "deposit → transfer → balances → reconciliation"; the funding-owner concept is in [Holders and the funding model](../basic-concepts/identity-and-funding).

## Deposits

**① Get the receiving account**: `GET /open-api-corp/fund/v1/deposit-info?subjectType=...&subjectId=...&currency=...` — returns the owner's (COMPANY pool / CARD dedicated balance) receiving VA for that currency: `payeeAccountNumber`, `payeeBankCode` / `payeeBankName`, `payeeAccountName`, `payeeSwiftCode` (required for cross-border wires), bank and recipient addresses, and `remark` (the required transfer reference).

**② The customer wires the funds** to the VA using those details.

**③ Arrival notification**: the webhook `BANK_TRANSFER_INFO` (success / failure distinguished by `status`, carrying `depositId` / `amount` / `currency` / sender details).

## Pool ⇄ card transfers

`POST /open-api-corp/fund/v1/transfer` — internal transfers between the company pool and dedicated-balance cards, **same currency, no FX, closed loop within one company**: COMPANY→CARD funds a card (allocates budget), CARD→COMPANY sweeps balance back.

| Field                                 | Required | Description                                                                                          |
| ------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------- |
| `transferRef`                         | Yes      | ≤64; the transfer idempotency key — a repeat returns `TRANSFER_DUPLICATE`                            |
| `organizationId`                      | Yes      | The closed-loop boundary; both sides must belong to it                                               |
| `from.subjectType` / `from.subjectId` | Yes      | `ORGANIZATION`→`organizationId` / `CARD`→`cardId`                                                    |
| `to.subjectType` / `to.subjectId`     | Yes      | Must differ in type from the `from` side — the two ends are always one `ORGANIZATION` and one `CARD` |
| `amount` + `currency`                 | Yes      | Amount > 0, ≤2 decimals; the currency must match both accounts (`CURRENCY_MISMATCH`)                 |

The response `status` is `SUCCESS` / `PROCESSING` / `FAILED`; **on `PROCESSING` you must poll `GET /fund/v1/transfer-query?transferRef=...` for the final result**. SHARED cards hold no balance and cannot be a transfer endpoint (`CARD_NOT_DEDICATED`); an underfunded sender returns `INSUFFICIENT_FUNDS`.

## Balances

`GET /open-api-corp/fund/v1/balance?subjectType=...&subjectId=...` — per-currency balances for a funding owner, each returning `availableAmount` (the current available balance).

## Reconciliation on three levels

| Level               | Endpoint                                             | Use                                                                                                                                                                                                    |
| ------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Deposit records     | `GET /fund/v1/deposit-records`                       | Paginated VA deposit history (filterable by owner / currency / arrival time), matched against bank advice                                                                                              |
| Transaction records | `POST /statement/v1/transactions`                    | Transactions by time window (independent of billing cycles; **window at most six months**); omit `cardId` for the company view, pass it to narrow to one card (including deposits into that card's VA) |
| Statements          | `POST /statement/v1/statements` + `statement-detail` | Statement-level reconciliation, below                                                                                                                                                                  |

**Key transaction fields**: `transactionCategory` (`PURCHASE` / `REFUND` / `FEE` / `REPAYMENT` / `CASH_ADVANCE` / `DEPOSIT` / `TRANSFER`), `postStatus` (`POSTED` / `UNPOSTED` authorization hold / null for repayment-type rows), the original and posted amount/currency pairs (`originalAmount`/`originalCurrency`, `postAmount`/`postCurrency`), `postTime` (null while on hold) and `merchant` (`merchantName` / `mcc` / `merchantCountryCode`).

**Statement list**: `POST /statement/v1/statements` — by company (`type=SHARED`) or by card (`type=DEDICATED`, `cardId` required) over a time range, cycles in reverse order. Each statement returns `statementId` (null for the open statement), `statementPeriod`, `status` (`OPEN` / `SETTLED`), `statementDate` / `paymentDueDate`, `paymentStatus` (`CURRENT` / `AWAITING_PAYMENT` / `PAID` / `OVERDUE`, computed live) and a per-currency `summary` (purchases / refunds / fees / repayments / cash advances / amount due / overpaymentAmount totals).

**Statement detail**: `POST /statement/v1/statement-detail` — the header + per-currency summary + transaction lines (pagination applies to the lines only). For a **settled** statement pass `statementId`; for the **current open** statement pass `statementId=null` + `status=OPEN`.

<Note>
  **The settled statement is final**: the open statement is a live summary of the current cycle including unsettled authorization holds, so its totals fall back as transactions clear — expected behavior. The billing mechanics and key dates are in [Limits and statements](../basic-concepts/limits-and-billing).
</Note>

## Related webhooks

`BANK_TRANSFER_INFO` (VA deposit arrival) / the balance-change notification / `LOW_BALANCE` (pool low-balance alert; configuration in [Managing companies](./managing-companies)).

## Next steps

* How debt arises and is notified: [Authorization and 3DS](./authorization-and-3ds)
* Open vs settled statement conventions: [Limits and statements](../basic-concepts/limits-and-billing)
* In this group: [Deposits](./deposits) · [Balances and transfers](./balances-and-transfers) · [Statements and transactions](./statements-and-transactions)