Settlement & payouts

Multiple providers, multiple rails, multiple settlement cycles — collapsed into one payout per currency and one report your finance team can reconcile without knowing what a provider is. This page covers the funding schedule, the payout and report objects, reserves, and what the fee column is actually made of.

How settlement works

Without orchestration, five providers means five settlement files in five formats on five schedules. Finscale sits in the middle and absorbs that:

1. Providers settle to Finscale

   Each provider settles captured funds into safeguarded accounts on its own cycle. Finscale ingests every provider's settlement file and matches each line to a payment.

2. Finscale nets your balance

   Per currency: gross captures − fees − refunds = net. Every component is itemized — no opaque "adjustments". (Disputes debit your balance when they open and are itemized on the dispute object, not as report lines.)

3. You get one payout per currency

   On your payout schedule, Finscale pays the net amount to your bank account. One incoming transfer per currency, regardless of how many providers processed the underlying volume.

4. Report + webhook

   Each payout links a settlement report itemizing every line. You're notified via the settlement.report.ready webhook; track the payout itself via GET /v1/payouts and its status/arrival_date.

Funding schedule

Three dates matter for any captured payment, and each is a field you can read:

The default end-to-end schedule is T+2: funds captured on Monday are paid out Wednesday. Notes:

• Payouts run on business days (TARGET2 calendar for EUR; local banking calendars elsewhere).
• Slower rails don't delay the payout — a direct-debit payment enters a payout only once it has actually settled, so a given day's payout mixes capture dates but never contains unsettled money.
• Daily is the default cadence; weekly and monthly schedules are configurable per currency in the dashboard.
• Currency conversion, if you've opted to consolidate payouts into one currency, happens at this step and is itemized on the report.
• Lines captured after the 04:00 UTC cutoff roll into the next settlement day.

What varies is the capture-to-settlement leg — it's a property of each method's rail, not of Finscale:

The Payout object

{
  "id": "po_6Fn1mS8vQ2Xc",
  "object": "payout",
  "amount": 1914190,
  "currency": "EUR",
  "status": "paid",
  "destination": { "type": "iban", "last4": "3401", "country": "DE" },
  "arrival_date": "2026-07-18",
  "settlement_report": "stl_2026_07_16_eu01",
  "created_at": "2026-07-18T06:00:12Z",
  "livemode": false
}

amount is the net, in minor units — €19,141.90 here, exactly the linked report's totals.net. Statuses: pending → in_transit → paid | failed (a failed payout — closed bank account, rejected transfer — is retried after you fix the bank details; the funds never leave your balance). List with GET /v1/payouts and track status and arrival_date — and subscribe to settlement.report.ready for the moment the linked report is downloadable.

The settlement report

Every payout references a settlement report — stl_2026_07_16_eu01 covers the EUR activity settled on 2026-07-16 for prov_eu_acq_01. Reports are generated per provider per settlement day, plus a consolidated all-provider report ("provider": null); every one has the same shape, columns, and totals identity gross + refunds + fees = net. A report starts in status: generating and flips to ready when its CSV exists — that's the moment settlement.report.ready fires.

Fetch it as JSON via the API, or as the transaction-level CSV with Accept: text/csv (also downloadable from the dashboard). The CSV columns:

payment_id,reference,method,provider,gross,fee,net,currency,settled_at
pay_8Q2mX4nT1cVb,ord_9f21_0716,ideal,prov_eu_acq_01,4900,-64,4836,EUR,2026-07-16T04:00:00Z
pay_3Xw9cR5pLm,ord_9f22_0716,card,prov_eu_acq_01,12900,-206,12694,EUR,2026-07-16T04:00:00Z
pay_8Q2mX4nT1cVb,ord_9f21_0716,ideal,prov_eu_acq_01,-1500,-25,-1525,EUR,2026-07-16T04:00:00Z
# … 409 more rows. sum(net) = totals.net = payout amount = 1914190

Reserves & rolling reserve

Settled money can still move backwards: a refund lands weeks after capture, a dispute months after. A reserve is settled money held back to cover that tail, so a burst of reversals doesn't land on funds that already left. Whether your account carries one — and on what terms — is decided during onboarding & KYB, based on your business model, delivery windows, and dispute history, and is revisited as history accrues.

How reserves interact with the objects on this page:

• Reserved funds are settled but not available. They never appear in available on GET /v1/balance — the balance you can pay out is always genuinely payable.
• Releases rejoin available when their holding window lapses, and leave with the next scheduled payout — no separate transfer.
• Holds and scheduled releases are itemized in the dashboard, per day, so finance can project the release calendar. The reserve share, window, and any fixed amount are defined in your merchant agreement — terms live there, not in these docs.

Fee concepts: what's inside the fee column

The fee on a settlement line isn't one charge — it's layers, each collected by a different party. Understanding them explains why fees differ between a domestic debit card and a foreign commercial credit card, even at the same amount. Concepts only: actual rates are commercial terms and live in your merchant agreement, not in these docs.

Two more concepts worth knowing:

• Blended vs pass-through pricing. Under blended pricing the layers are combined into one uniform fee per transaction — predictable, but the mix is invisible. Under pass-through (interchange-plus) pricing, interchange and scheme fees are passed at cost and the margin is stated separately — each settlement line's fee then varies with the card behind it. Which model applies to your account is part of your merchant agreement.
• Not every method has interchange. The interchange/scheme structure is a card-network construct. Bank redirects, real-time payments, and direct debit ride bank rails with their own — typically simpler — cost structures. That difference is one reason routing and method choice matter.

Unified reconciliation

The property that makes multi-provider finance workable: every line carries the payment_id and your reference, no matter which provider processed it. The example order was routed to prov_eu_acq_01; had failover pushed it to prov_eu_acq_02, the line would be byte-identical except for the provider column.

Reconciliation is therefore one join, not five:

• Order-level: match reference against your orders table. ord_9f21_0716 reconciles to €49.00 gross, €0.64 fee, €15.00 refunded — regardless of routing.
• Payout-level: the bank transfer of €19,141.90 equals sum(net) of report stl_2026_07_16_eu01. One number to tie to your bank statement.
• Provider-level (optional): group by provider when finance wants the mix — it's a column, not a separate file format.

The step-by-step daily routine — batch proofs, the id chain, and exception handling — has its own page: Reconciliation. Why the numbers can't drift in the first place: Ledger.