Delivering to your funding account

This is the second of the two settlement movements: the real money — the collected funds traveling to your funding account, the actual bank account backing your program. This movement is Mono's job and never blocks the first one — the ledger credit your users see, covered in Crediting the subaccount — it runs behind it, on its own schedule, and reports through its own fields and webhooks.

Automatic or manual

How the delivery runs depends on your program configuration (funds_destination, funds_delivery_mode):

• Automatic — when your funding account is held with Mono's allied bank, Mono sweeps the collected funds to it via a Bre-B transfer, without any action on your side.
• Manual — when your funding account is at an external bank, batches are settled from the dashboard: an operator selects the pending payins and records the transfer that delivered them.

Per-payin tracking

Every payin tracks its own delivery:

• funds_delivery_status — null until the payin is approved_in_provider, then pending_to_deliver → processing → completed.
• funds_destination — funding_account means the money still has to be moved to you, through the batches below; method_receiving_account means it already landed where it belongs, and the delivery completes immediately, with no batch involved.
• settlement_batch_id — the batch that delivered the funds, once one covers this payin.

Settlement batches

Payment rails cap how much a single transfer can carry, so pending payins are grouped: Mono packs payins into batches throughout the day, filling each transfer as close to the rail's per-transfer limit as possible, and flushes whatever remains at the close of the daily accounting cycle. That has three practical consequences:

1. One batch covers many payins — they share a settlement_batch_id, and total_amount is the sum of their funding_amount.
2. A single day can produce several batches.
3. A payin approved late in the cycle may be delivered by the cycle-close flush rather than an intraday batch.

Batch lifecycle

Only created, processing, and completed are notified through webhooks. retryable is a transient send failure the system resends on a later run, and failed is terminal and resolved manually by Mono — both are visible when reading the batch, but neither is notified.

Reading a batch

GET /v1/core/payins/settlement_batches/{id} returns the batch with its covered payins: what each one collected (amount), what it delivers (funding_amount), and the funding_amount_rates behind the conversion when the currencies differ — empty today, since everything is COP. The response is the same shape the payin_settlement_batch_* webhooks deliver. The list endpoint reports payins_count per batch.

Next steps

• Settlement flow — the end-to-end walkthrough with webhooks.
• Crediting the subaccount — the first movement.
• Settlement batches API reference — the full schemas.