Settlement cycles and cut-off

1) Conceptual base

Settlement - settlement between the PSP/Acquirer and the merchant (operator), in which money for successfully captured transactions is transferred to the merchant account.
Cut-off - a daily "slice" of operations that fall into a specific billing cycle (usually a fixed time in the provider's time zone).
T + N - typical notation for the delay in posting funds: T - cut-off date, N - the number of working days before the actual enrollment.

• Cards (Visa/Mastercard): often T + 2/T + 3 banking days, cut-off 23:00 UTC (approximately).
• A2A/Open Banking: T + 0 to T + 1.
• SEPA Credit Transfer: T+1/T+2 (Instant — T+0).
• ACH (US): T+2/T+3; Same Day ACH — T+0/T+1.
• RTP (US): T + 0, but cut-off on reports is possible.
• Crypto: actually T + 0 over the network, but the PSP can apply its own funding windows (T + 0/1).

2) How the cut-off works and what gets into it

1. The provider fixes the collection window (for example, 00: 00-23: 00 UTC).
2. All settled/captured transactions in this window fall into a batch.
3. Returns, chargebacks, corrections are aggregated to the package to calculate gross and net funding.
4. Upon the cut-off, a settlement file is generated and the T + N timer starts before enrollment.

Important: authorization without capture is not included in the package. Canceled conclusions - also not.

3) Settlement types: gross vs net, reserves and commissions

Gross settlement - gross capture amount is transferred (minus a separate commission charge).
Net settlement - the provider holds fees, chargebacks, refunds, rolling reserve and lists net amount.
Rolling reserve - withholding% of turnover for N days (for example, 10% for 180 days) to cover risk.
Negative carry-over - if the "net" goes into minus per day, the deficit is transferred and paid off in the next cycles.

Recommendation: store decryption of both planes - operational gross (by transactions) and funding net (by provider files).

4) Timezones, Local Output and DST

Cut-off is determined by the timezone of the provider, which may differ from yours.
Consider DST (daylight saving time) - slices can shift by ± 1 hour relative to local time.
Holidays/weekends in the jurisdiction of the receiving bank affect N in T + N (for example, T + 2 banking days becomes T + 4 around holidays).
Practice: normalize all technical times in UTC, simultaneously store 'provider _ tz _ cutoff _ at' and 'local _ tz _ posted _ at'.

5) Settlement calendar (funding calendar) and SLA

• cut-off time and tz for each method/PSP,
• standard T + N and exceptions (holidays),
• expected amounts (forecasts),
• SLA receipt: for example, "no later than 12:00 Europe/Kyiv on day T + 2."

Any SLA deviations → alert and ticket to Ops/Finance.

6) Relationship with Net Deposits and outputs

ND (net contributions) is counted on settled transactions (see related article).
Conclusions (withdrawals) do not participate in funding from PSP on deposits, but affect the merchant's cash desk.
Liquidity planning: inflow by settlement minus outflow by payments/taxes/operating expenses.

7) Reconciliation and provider artifacts

• 'batch _ id/ settlement_id', cut-off date in tz provider,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• decryption by methods/merchant accounts ('MID', 'descriptor', 'MCC'),
• transaction references ('provider _ tx _ id', 'rrn', 'arn' - if cards),
• file (s): CSV/XML/JSON + human readable statement (PDF/HTML).

1. From transactions to files (everything we thought was in the file?)

2. From files to transactions (everything in the file is in our storefront? do the statuses match?)

8) Specifics of payment rails (in general terms)

Maps: frequent presentation delay scenarios; late 'chargeback' are possible (up to 120-540 days for the case); interchange & scheme fees appear in files, are not deducted in ND.
SEPA/ACH: Batches depend on bank windows; Cancellations/returns have their own codes Same Day options are separate cut-offs.
Open Banking/A2A: T + 0/1, but files can go post-factum; the need for strict RPP/Unique ID for matches.
RTP/Instant: money comes quickly, but the report file is on schedule.
Crypto: onchain settlement instant, but provider makes' payout windows'; store 'fx _ at _ settle'.

9) Accounting (FI/Accounting)

9. 1. Accrual vs cache method

For management reporting, accrual is often used: we recognize revenue/movement at the time of'settled _ at'.
For treasury/DDS - cache method: we recognize the fact of receipt 'funded _ at'.

9. 2. Typical wiring (simplified)

• JT: Cash in settlement with PSP (AR: PSP)
• KT: Player Commitment (Purse/Player Balance)

• Dt: Bank (cashier's office)
• Kt: Cash in settlements with PSP
• JT: Expenses (PSP fees), JT: Provisions (if changed)

You store a sheaf 'transaction_id → batch_id → funding_id' for trace.

10) Risk management and alerts

Missed file: No settlement file before X: YY - P1.
Funding delay: T + N expired, no money - P1.
Delta thresholds: variance 'our _ gross' vs' file _ gross'> 0. 5% - P2; 'fees' out of range - P2.
Negative carry-over: A series of negative net packs - an investigation.
Holiday impact: automatic forecast taking into account the calendar; if the fact is <80% of the forecast - ticket.

11) Data model (simplified)

finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12) Examples of SQL templates

12. 1. Cut-off recording

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12. 2. Transaction-to-file reconciliation

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_cr
FROM finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12. 3. Revenue Forecast (cash-flow T + N)

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13) Processes and SLOs

SLO 1: import settlement files - T + 0, until 08:00 Europe/Kyiv.
SLO 2: initial reconciliation - until 09:00, variances> 0. 5%.
SLO 3: Cash-flow forecast update - until 10 a.m.
SLO 4: closing of the day - all funding matches are led to DWH.

14) Edge-cases and how to handle them

Late presentation: the transaction got into the next batch - keep the "fact of the source" ('presented _ in _ batch _ id').
Partial capture: multiple capture per authorization - aggregate correctly in batch.
Multi-MID: one provider, different MIDs by geo/brand - do not mix in one batch.
Reprocessing: when a file is jammed - versioning 'batch _ revision' and full revalidation.
FX races: courses - on 'settled _ at'; funding in a different currency - start 'fx _ at _ funding' and delta.

15) Dashboards and KPIs

Funding ETA: expected date/time of receipt vs actual.
Hit-rate SLA: percentage of files arriving on time.
Delta gross/net by provider, method, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: forecast vs actual by week with holidays.

16) Best practices (short)

1. Normalize the time to UTC, but keep the cut-off provider_tz.
2. Separate operational gross and funding net; do not confuse ND and funding.
3. Implement a funding calendar with pre-entered bank holidays.
4. Automate import and reconciliation of settlement files + alerts to SLAs/deltas.
5. Implement batch _ revision and deterministic reprocess.
6. Type single source of truth: 'transaction ↔ batch ↔ funding' links.
7. Save ARN/RRN and card acquiring fields - critical for disputes.
8. Forecast cash-flow taking into account weekends/holidays, reserves and commissions.

17) Implementation checklists

Data and diagrams

• Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.
• Timezone fields are UTC + provider_tz.
• Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

Import and validation

• CSV/XML/JSON parsers + file hashes.
• Validation of amounts/currencies/dates; match по `provider_tx_id/ARN`.
• Handlers "late presentation," "partial capture," "reversal."

Operations and Alerts

• SLA monitor cut-off, missed files, funding delays.
• Delta-threshold alerts (gross, fees, net).
• Holiday impact and negative carry-over report.

18) FAQ

Q: Why did T + 2 become T + 4?
A: There were weekends/holidays at the correspondent bank or at the receiving bank; см. funding calendar.

Q: There is less in the net file than our net calculation. What to watch?
A: Check the fees, reserve_delta, late refund/chargeback, and correctness of courses.

Q: How do you account for crypt?
A: By fiat equivalent to 'settled _ at'; funding can come to USDT/fiat - keep a separate 'fx _ at _ funding'.

Q: Is it possible to have one common cut-off for all providers?
A: No, each PSP has its tz/hour. Make an aggregating display over their slices.

Summary

• accurately verify providers,
• forecast liquidity and cover payments,
• comply with SLAs and reduce operational risks,
• speak the same language as finance and compliance.

By implementing a single funding calendar, a rigorous data model, and automated reconciliation, you make cash flow predictable and manageable.