Payouts and reconciliation

A payout is money Qualy sends out: to your own bank account, to a partner or to a supplier. A payment comes in as a charge from the payer; what lands in your bank account is a payout to you. So match your bank statement against payouts, not charges. None of these tools creates, sends or retries a payout.

1. Match deposits into your own bank account

Call payout_list with recipient self and status paid, sorted by paidAt, from the paidAt of the last payout you already recorded (as paidAtFrom, as in the first example; leave it out the first time). Start there rather than from a fixed clock window, which a late or skipped run would leave a gap in. paidAtFrom is inclusive, so the last payout you recorded comes back again: skip what you already matched. Page with hasMore and nextOffset until you have them all.

Each payout to you is one credit on your bank statement. Match it on:

• the amount received: fx.targetAmount in fx.targetCurrency for a payout in another currency, otherwise amount in currency;
• statementDescriptor: the reference sent with the transfer.

Amounts are in major units (e.g. 99.99). Note the latest paidAt you matched: the next reconciliation starts from it.

2. Paid is not arrived

paidAt is when Qualy recorded the payout as paid, not when the bank received it, which depends on the payout and is not guaranteed. It is normally when Qualy sent it, but later when Qualy only confirmed it afterwards (a retry that finds it was already sent), so a deposit can appear before paidAt. A payout can be created and sent days after the payment it comes from (card payments wait for settlement; an agent's share can be re-routed later), so filter with paidAtFrom / paidAtTo, not createdAtFrom / createdAtTo.

3. One payout

payout_get adds the masked bank account, the FX quote, the partnership, why it failed or is paused (failedReason, failureClass, pausedReason) and approval: who approves it and whether you can now (qualy://guides/approvals).

For a paid partner or supplier payout, payout_remittance_advice makes the remittance advice PDF, with a short-lived link. Payouts to your own bank account and unpaid ones have none.

4. Partners

• What was sent to a partner: payout_list with recipient partner and partnership (its id, code or name). Use recipient supplier for suppliers.
• What is still open with each partner: reconciliation_summary, per partnership and currency, over payment splits that are Pending, Due, Overdue or Pending review, belong to a payment and have a due date. total is what you send partners and keep what you keep, and the overdue part is aged from 0-7 to 90+ days. Use it rather than adding up pages of splits. A partner whose payments weren't paid to them directly appears only once something is overdue.
• It has no paid figures and no markup: payment_split_stats has those.

Worked examples

Deposits into your bank account since the last one you recorded

{
  "tool": "payout_list",
  "arguments": {
    "recipient": "self",
    "status": "paid",
    "sort": "paidAt",
    "paidAtFrom": "2026-09-30T23:10:00+10:00"
  }
}

Match each on the amount received and statementDescriptor. The first one back is the last one you recorded.

What was paid to one partner in September

{
  "tool": "payout_list",
  "arguments": {
    "recipient": "partner",
    "partnership": "Sydney English College",
    "status": "paid",
    "paidAtFrom": "2026-09-01T00:00:00+10:00",
    "paidAtTo": "2026-09-30T23:59:59+10:00"
  }
}

count is the total; use hasMore to page.

Why one payout has not gone out

{
  "tool": "payout_get",
  "arguments": {
    "payoutId": "66f1d4c2e4b0a1b2c3d4e5f9"
  }
}

Read status with failedReason or pausedReason, and approval when it is waiting on approvers.

What is still open with a partner

{
  "tool": "reconciliation_summary",
  "arguments": {
    "partnership": "Sydney English College"
  }
}

Up to two rows per currency: one for payments paid to the partner directly, one for the rest. Add them for the partner's total. total is what you send them, keep what you keep.