ციკლის სეტლენტი და cut-off

1) კონცეპტუალური ბაზა

Settlement (settlement) არის გაანგარიშება PSP/Acquirer- სა და murchant (ოპერატორს) შორის, რომელშიც წარმატებით დატყვევებული გარიგებების თანხა გადარიცხულია მერჩანტის ანგარიშზე.
Cut-off არის ოპერაციების ყოველდღიური „გაჭრა“, რომელიც შედის კონკრეტულ გამოთვლილ ციკლში (ჩვეულებრივ ფიქსირებული დრო პროვაიდერის დროში).
T + N - სახსრების განაწილების შეფერხების ტიპიური ნოტაცია: T - cut-off თარიღი, N - სამუშაო დღეების რაოდენობა ფაქტობრივი ჩარიცხვამდე.

• ბარათები (Visa/Mastercard): ხშირად T + 2/T + 3 ბანკინგის დღეები, cut-off 23:00 UTC (დაახლოებით).
• A2A/Open Banking: T + 0 - დან 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, მაგრამ შესაძლებელია ანგარიშები.
• კრიპტო: სინამდვილეში T + 0 ქსელში, მაგრამ PSP- ს შეუძლია გამოიყენოს საკუთარი funding ფანჯრები (T + 0/1).

2) როგორ მუშაობს cut-off და რა შედის მასში

1. პროვაიდერი აფიქსირებს კოლექციის ფანჯარას (მაგალითად, 00: 00-23: 00 UTC).
2. ამ ფანჯარაში ყველა settled/captured გარიგება შედის პაკეტში (batch).
3. ვალუტა, ჩარჟბეკი, კორექტირება გაერთიანებულია პაკეტში, რათა გამოითვალოს gross და net funding.
4. Cut-off- ის დაწყებისთანავე იქმნება settlement ფაილი და იწყება T + N ტაიმერი ჩარიცხვამდე.

მნიშვნელოვანია: საავტორო უფლებები არ შედის პაკეტში. გაუქმებული დასკვნები ასევე არ არის.

3) გაანგარიშების ტიპები: gross vs net, რეზერვები და საკომისიო

Gross settlement - მთლიანი თანხა გადარიცხულია (კომისიების მინუს ცალკეული ჩამოწერა).
Net settlement - პროვაიდერი ფლობს fees, chargebacks, refunds, rolling reserve და ჩამოთვლის net amount.
Rolling reserve - ბრუნვის% შენარჩუნება N დღის განმავლობაში (მაგალითად, 10% 180 დღის განმავლობაში) რისკის დასაფარად.
Negative carry-over - თუ „ნეტო“ დღეში მინუსში გადადის, დეფიციტი გადადის და იშლება შემდეგი ციკლებით.

რეკომენდაცია: შეინახოთ ორივე თვითმფრინავის გაშიფვრა - ოპერატიული გროსი (გარიგების თვალსაზრისით) და funding net (პროვაიდერის ფაილების მიხედვით).

4) ტაიმსონები, ადგილობრივი შაბათ-კვირა და DST

Cut-off განისაზღვრება პროვაიდერის დროით, რომელიც შეიძლება განსხვავდებოდეს თქვენგან.
გაითვალისწინეთ DST (ზაფხულში გადასვლა) - ნაჭრები შეიძლება გადავიდეს ± 1 საათით, ვიდრე ადგილობრივი დრო.
მიმღები ბანკის იურისდიქციაში არდადეგები/შაბათ-კვირას გავლენას ახდენს N T + N- ში (მაგალითად, T + 2 ბანკინგის დღეები გადაიქცევა T + 4 არდადეგების გარშემო).
პრაქტიკა: ნორმალიზება ყველა ტექნიკურ დროს UTC- ში, პარალელურად შეინახეთ 'provider _ tz _ cutoff _ at' და 'local _ tz _ posted _ at'.

5) Settlement კალენდარი (funding calendar) და SLA

• cut-off დრო და tz თითოეული მეთოდისთვის/PSP,
• სტანდარტული T + N და გამონაკლისები (არდადეგები),
• მოსალოდნელი თანხები (პროგნოზები),
• SLA მიღება: მაგალითად, „არაუგვიანეს 12:00 Europe/Kyiv დღეში T + 2“.

SLA- ს ნებისმიერი გადახრა არის ალერტი და პიკეტი Ops/Finance- ში.

6) ურთიერთობა Net Deposits- თან და დასკვნებთან

ND (სუფთა დანართები) განიხილება settled გარიგებებით (იხ. დაკავშირებული სტატია).
დასკვნები (withdrawals) არ მონაწილეობს PSP- ის დეპოზიტებზე, მაგრამ გავლენას ახდენს მერჩანტის სალაროზე.
ლიკვიდობის დაგეგმვა: inflow მარტოხელა მინუს outflow გადახდების/გადასახადების/ოპერაციული ხარჯების შესახებ.

7) Conconciliation (reconciliation) და პროვაიდერების არტეფაქტები

• 'batch _ id/settlement _ id', cut-off თარიღი tz პროვაიდერში,
• суммы по типам: `captured_deposits`, `refunds`, `chargeback_debits`, `chargeback_credits`, `fees`, `reserve_delta`, `net_funding`,
• გაშიფვრა მეთოდების/MID ანგარიშების მიხედვით ('MID', 'descriptor', 'MCC'),
• გარიგების რეფერენდუმები ('provider _ tx _ id', 'rrn', 'arn' - თუ ბარათები),
• ფაილი (s): CSV/XML/JSON + ადამიანური საკუთრება (PDF/HTML).

1. გარიგებიდან ფაილებამდე (ყველაფერი, რაც ვფიქრობდით, ფაილში ჩავარდა?)

2. ფაილებიდან გარიგებამდე (ფაილში ყველაფერი ჩვენს ფანჯარაშია? სტატუსები ემთხვევა?)

8) სპეციფიკა გადახდის რელსებზე (ზოგადად)

ბარათები: ხშირი წინასწარი სცენარი; შესაძლებელია გვიანდელი 'chargeback' (საქმესთან დაკავშირებით 120-540 დღემდე); Interachine & scheme fees ჩანს ფაილებში, ND- ში ისინი არ გამოდიან.
SEPA/ACH: ბატები დამოკიდებულია საბანკო ფანჯრებზე; გაუქმებას/დაბრუნებას აქვს საკუთარი კოდები; Same Day პარამეტრები - ინდივიდუალური cut-off.
Open Banking/A2A: T + 0/1, მაგრამ ფაილებს შეუძლიათ მიიღონ post-factum; მკაცრი RPP/Unique ID- ის საჭიროება მატჩებისთვის.
RTP/Instant: ფული სწრაფად მოდის, მაგრამ საანგარიშო ფაილი დაგეგმილია.
Crypto: Onchein setlent მყისიერი, მაგრამ პროვაიდერი აკეთებს 'payout windows'; შეინახეთ 'fx _ at _ settle'.

9) აღრიცხვა, გაყვანილობა და ანგარიში (FI/ანგარიში)

9. 1. Acrual vs ქეშის მეთოდი

მენეჯმენტის ანგარიშგებისთვის ხშირად გამოიყენება აკრული: ჩვენ ვაღიარებთ შემოსავალს/მოძრაობას „settled _ at“ მომენტში.
ხაზინისთვის/DDS - ქეშის მეთოდი: ჩვენ ვაღიარებთ 'funded _ at' მიღებას.

9. 2. ტიპიური გაყვანილობა (გამარტივებული)

• დტ: ფულადი სახსრები PSP- ით (AR: PSP)
• Kt: მოთამაშის წინაშე ვალდებულებები (მოთამაშის საფულე/ბალანსი)

• დტ: ბანკი (მერჩანტის სალარო)
• კტ: ფულადი სახსრები PSP- ით
• დტ: ხარჯები (PSP fees), DT/Kt: რეზერვები (თუ შეიცვალა)

შეინახეთ ბმული 'transaction _ id _ batch _ id _ funding _ id' კვალიფიკაციისთვის.

10) რისკის მენეჯმენტი და ალერტები

Missed file: არ არსებობს settlement ფაილი X: YY - P1.
Funding delay: T + N ამოიწურა, ფული არ არის - P1.
Delta thresholds: შეუსაბამობა 'our _ gross' vs 'file _ gross'> 0. 5% - P2; 'fees' დიაპაზონის გარეთ - P2.
Negative carry-over: უარყოფითი წმინდა პაკეტების სერია - გამოძიება.
Holiday impact: ავტომატური პროგნოზი კალენდრის გათვალისწინებით; თუ პროგნოზის <80% ფაქტი არის ტიკეტი.

11) მონაცემთა მოდელი (გამარტივებული)

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) SQL შაბლონების მაგალითები

12. 1. ჭრის რეგისტრაცია cut-off- ზე

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. შერწყმა „გარიგებიდან ფაილამდე“

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. შემოსავლის პროგნოზი (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) პროცესები და SLO

SLO 1: settlement ფაილების იმპორტი - T + 0, 08:00 საათამდე ევროპა/კიევი.
SLO 2: პირველადი კრიკეტი - 09:00 საათამდე, ალერტები განსხვავებებში> 0. 5%.
SLO 3: cash-flow პროგნოზის განახლება - 10:00 საათამდე.
SLO 4: დღის დახურვა - ყველა funding მატჩი ტარდება DWH- ში.

14) Edge-cases და როგორ უნდა დამუშავდეს ისინი

გვიან შეთავაზება: გარიგება მოხვდა შემდეგ batch- ში - შეინახეთ „წყაროს ფაქტი“ ('presented _ in _ batch _ id').
Partial capture: რამდენიმე capture თითო ავტორიზაციისთვის - სწორად აერთიანეთ batch.
Multi-MID: ერთი პროვაიდერი, გეო/ბრენდების სხვადასხვა MIDs - არ აურიოთ ერთ ნაწილში.
Reprocessing: ფაილის ჯართის დროს - „batch _ revision“ ვერსიის ვერსია და სრული ბუმბული.
FX ნახტომი: კურსები - 'settled _ at'; funding სხვა ვალუტაში - მიიღეთ 'fx _ at _ funding' და დელტა.

15) დაშბორდი და KPI

Funding ETA: მოსალოდნელი თარიღი/დრო vs ფაქტი.
Hit-rate SLA: დროულად ჩამოსული ფაილების წილი.
Delta gross/net პროვაიდერების მიხედვით, მეთოდები, MIDs.
Fees % of volume, Reserve balance, Negative carry-over streak.
Holiday impact: პროგნოზი vs არის არდადეგების კვირების ფაქტი.

16) საუკეთესო პრემიები (მოკლედ)

1. დროის ნორმალიზება UTC- ში, მაგრამ შეინახეთ provider _ tz cut-off.
2. გაზიარეთ ოპერატიული გროსი და funding net; ნუ დაიბნევით ND და funding.
3. შემოიღეთ funding calendar ადრე ბანკების არდადეგებით.
4. ავტომატიზაცია მოახდინეთ settlement ფაილების იმპორტი და შერწყმა SLA/delta- ზე.
5. გააცნობიერეთ პარტიების ვერსიები ('batch _ revision') და დეტერმინისტული reprocess.
6. შეიყვანეთ truth სინგლის წყარო: კავშირი 'ტრანსფორმაცია' batch 'funding'.
7. შეინარჩუნეთ ARN/RRN და ბარათების შეძენის ველები - კრიტიკულია დავებისთვის.
8. პროგნოზირებთ cash flow შაბათ-კვირის/არდადეგების, რეზერვებისა და საკომისიოს გათვალისწინებით.

17) განხორციელების ჩეკის ფურცლები

მონაცემები და სქემები

• Таблицы `payment_transactions`, `settlement_batches`, `funding_receipts`, `recon_links`.
• ტაიმსონის ველები: UTC + provider _ tz.
• Поля FX: `fx_rate_at_settle`, `fx_at_funding`.

იმპორტი და ვალიდაცია

• პარსერები CSV/XML/JSON + ფაილების ჰეში.
• თანხების/ვალუტის/თარიღების შესაბამისობა; match по `provider_tx_id/ARN`.
• Hendlers „late presentment“, „partial capture“, „reversal“.

ოპერაციები და ალერტები

• SLA მონიტორი cut-off, მისასალმებელი ფილმები, ფუნდამენტური სესხები.
• დელტა ბარიერი ალერტები (gross, fees, net).
• ანგარიში holiday impact და negative carry-over.

18) FAQ

Q: რატომ გადაიქცა T + 2 T + 4?
A: იყო შაბათ/არდადეგები შესაბამის ბანკში ან მიმღებ ბანკში; см. funding calendar.

Q: Net ფაილი ნაკლებია ვიდრე ჩვენი net გაანგარიშება. რა უნდა უყუროთ?
A: შეამოწმეთ fees, reserve _ delta, გვიან refund/chargeback და კურსების სისწორე.

Q: როგორ გავითვალისწინოთ კრიპტი?
A: ფიატის ექვივალენტი 'settled _ at'; funding შეიძლება მოვიდეს USDT/fiat- ში - შეინახეთ ცალკე 'fx _ at _ funding ".

Q: შესაძლებელია თუ არა ერთი საერთო cut-off ყველა პროვაიდერისთვის?
A: არა, თითოეულ PSP- ს აქვს საკუთარი tz/საათი. გააკეთეთ საკონტროლო ფანჯარა მათ ნაჭრებზე.

რეზიუმე

• ზუსტად შეამოწმეთ პროვაიდერები
• ლიკვიდობის პროგნოზირება და გადახდების დაფარვა,
• SLA- ს დაცვა და ოპერაციული რისკების შემცირება,
• იგივე ენაზე საუბარი ფინანსებთან და შესაბამისობასთან.

ერთი ფულადი კალენდარის დანერგვა, მონაცემთა მკაცრი მოდელი და ავტომატური შერიგება, თქვენ გახდებით ფულადი სახსრების ნაკადი პროგნოზირებადი და კონტროლირებადი.