Перейти к основному содержимому

Partner Finance And Clearing — Балансы, лимиты, взаиморасчёты и финансовая дисциплина партнёров

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует отдельный домен partner finance and clearing для платформы vitrip.store.

Его задача — определить:

  • как платформа мыслит финансовые отношения с партнёрами и агентствами, которые продают через её surfaces и API;
  • как quoted promise и booking commitment переходят в partner-facing financial obligations;
  • как должны быть устроены балансы, депозиты, кредитные лимиты, удержания, списания, резервирование и взаимозачёт;
  • как clearing-состояние влияет на доступность продаж, booking execution и partner enablement.

Без этого документа commercial-model, settlement-and-reconciliation и partner API остаются важными, но ещё не замыкают полноценную industrial-grade финансовую модель платформы.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

Платформа продаёт не только “технический доступ к данным”, но и право вести поиск, quotation и booking через её ядро.

Это означает, что платформа должна мыслить не только:

  • цену;
  • quote;
  • booking;
  • settlement с поставщиком;

но и:

  • финансовое состояние партнёра внутри платформы;
  • право партнёра порождать новые обязательства;
  • риск неоплаченных или превышающих лимит продаж;
  • правила временного резервирования денежных обязательств;
  • правила взаимозачёта между продажами, возвратами, компенсациями и задолженностью.

Без этого external distribution layer остаётся коммерчески недооформленным.

Главный Принцип Partner Finance And Clearing​

Платформа должна различать:

  1. commercial promise, который видит партнёр;
  2. booking-time financial commitment;
  3. supplier settlement basis;
  4. internal platform revenue and liability view;
  5. partner balance and clearing position.

Эти пять уровней связаны, но не тождественны.

Из этого следует жёсткий вывод:

партнёрский финансовый контур нельзя сводить ни к quote, ни к booking, ни к supplier payable alone.

Основные Финансовые Сущности​

1. Partner Financial Account​

Лицевой счёт партнёра в контуре платформы.

Он нужен для фиксации:

  • текущего доступного баланса;
  • удержанных, но ещё не окончательно списанных обязательств;
  • задолженности;
  • возвратов;
  • корректировок;
  • состояния credit exposure.

2. Clearing Balance​

Агрегированная clearing-позиция партнёра.

Она отражает:

  • что партнёр уже должен платформе;
  • что платформа должна партнёру;
  • какие суммы находятся в reserve / hold;
  • какие суммы ещё спорные или pending reconciliation.

3. Deposit​

Предварительно внесённые средства, из которых партнёр финансирует будущие продажи или покрывает обязательства.

4. Credit Limit​

Разрешённый объём дополнительного риска, который платформа готова брать на себя относительно конкретного партнёра.

Credit limit не равен балансу и не должен смешиваться с commission or markup policy.

5. Hold / Reservation Of Financial Capacity​

Временное резервирование части clearing capacity под Quote, BookingIntent или другой commit-like переход.

6. Clearing Entry​

Нормализованная финансовая запись, отражающая отдельное изменение clearing-состояния:

  • reservation hold;
  • commitment posting;
  • refund posting;
  • adjustment;
  • manual correction;
  • penalty recognition;
  • reversal.

7. Netting Rule​

Правило взаимозачёта между разными потоками:

  • booking sales;
  • refunds;
  • supplier corrections;
  • partner rebates;
  • penalties;
  • manual credits and debits.

Партнёрский Финансовый Контур Не Равен Settlement​

Settlement определяет, что финансово произошло между платформой и поставщиком, а также как platform-internal figures приходят к reconciled reality.

Clearing отвечает на другой вопрос:

может ли конкретный партнёр сейчас продавать дальше, на каких финансовых основаниях и как platform-side obligations учитываются против его финансовой позиции.

Это родственные, но разные домены.

Основные Сценарии Clearing​

1. Pre-Funded Partner​

Партнёр работает из заранее внесённого депозита.

Тогда платформа должна уметь:

  • проверять доступный баланс;
  • временно резервировать capacity;
  • превращать reserve в фактическое списание;
  • возвращать средства при cancellation/refund;
  • блокировать новые commitments при недостатке средств.

2. Credit-Based Partner​

Партнёр работает с credit limit.

Тогда платформа должна уметь:

  • считать utilised credit;
  • удерживать risk exposure по pending and unsettled bookings;
  • запрещать новые продажи при превышении allowed exposure;
  • различать soft and hard blocking.

3. Hybrid Model​

Часть обязательств покрывается депозитом, часть — кредитом или отсрочкой.

4. Netting Model​

Возвраты, корректировки и встречные обязательства уменьшают или увеличивают clearing exposure через formal netting rules, а не через ручные письма и таблицы.

Clearing Gates Для Продаж​

Clearing должен влиять на sales execution не в reporting-слое, а до возникновения uncontrolled риска.

Платформа должна уметь отвечать на вопросы:

  • можно ли дать этому партнёру право создать новый Quote;
  • можно ли партнёру перейти из quote в booking;
  • можно ли публиковать агенту или downstream platform offers с данным settlement exposure;
  • нужно ли ввести degraded mode, hold или manual review.

Связь С Quote И Booking​

Quote​

Quote ещё не обязан создавать окончательное финансовое списание, но может:

  • требовать hold of commercial capacity;
  • требовать reserve of partner exposure;
  • участвовать в лимитной проверке;
  • порождать временное financial intent.

Booking​

Booking уже должен уметь:

  • фиксировать clearing-impacting commitment;
  • создавать обязательную financial trace;
  • переходить в post-booking adjustment flows;
  • быть привязанным к partner financial account.

Канально-Зависимая Финансовая Политика​

Платформа не должна считать, что у всех каналов одинаковая финансовая механика.

Нужно различать как минимум:

  • internal sales;
  • agency working channel;
  • partner API channel;
  • white-label / embedded distribution;
  • high-risk / low-trust integration channel.

Для каждого из них могут различаться:

  • pre-funding requirements;
  • credit rules;
  • hold policy;
  • reserve duration;
  • allowed debt;
  • settlement timing;
  • dispute handling strictness.

Financial Risk Controls​

Промышленная платформа обязана иметь не только accounting trace, но и контур риск-контроля.

Минимально должны существовать:

  • insufficient balance checks;
  • credit overflow checks;
  • excessive pending exposure checks;
  • stale quote vs insufficient coverage checks;
  • partner-specific anomaly escalation;
  • forced manual review for risky commitments.

Balance Release при unknown_external_state​

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором отмечено: «не до конца прописано, блокируется ли баланс партнера навсегда при unknown_external_state».

Раздел фиксирует каноничное правило unknown_state_balance_release: средства, зарезервированные на партнёрском балансе под бронирование, не могут блокироваться навсегда из-за молчания или некорректного поведения поставщика.

Settlement Split — разделение ответственности при refund​

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором отмечено: «Финансовая модель Refund при отмене одного элемента из пакета (Package Travel Directive) прописана сложно. Нужно чётко разделить: что возвращает поставщик и что обязана вернуть платформа (insolvency protection)».

Раздел фиксирует каноничную модель разделения ответственности при refund — кто из участников цепочки (supplier, платформа, партнёр, end-customer) что возвращает, в каком порядке, и как обрабатывается разрыв между ожидаемым refund'ом от supplier'а и реальным.

Принцип​

В каноничной merchant-of-record цепочке платформа → supplier, partner → платформа, end-customer → partner каждый refund-событие касается четырёх отдельных финансовых потоков, которые могут не совпадать по сумме и времени:

  1. Supplier portion — сколько supplier возвращает платформе (определяется контрактом supplier'а с платформой и его собственными политиками).
  2. Platform portion — сколько платформа гарантирует возвращать партнёру (определяется нашими SLA и Package Travel Directive обязательствами, независимо от supplier portion).
  3. Partner portion — сколько партнёр возвращает end-customer'у (определяется его собственным customer agreement, обычно совпадает с platform portion плюс/минус его commission policy).
  4. Customer portion — что в итоге получает end-customer (определяется partner portion).

Разница между expected supplier portion и actual supplier portion — это loss accounting платформы. Она покрывается через insolvency reserve fund.

Каноничный поток refund при отмене​

Партнёр инициирует refund (или event автоматической отмены через cancel-by-supplier)
    ↓
PlatformRefundIntent создаётся с явным split:
    expected_supplier_portion: amount, currency
    platform_obligation: amount, currency (что платформа обязана вернуть партнёру)
    partner_to_customer: amount, currency (что партнёр обязан вернуть клиенту)
    insolvency_protection_applies: bool
    ↓
Параллельно запускаются два независимых процесса:

  Поток A — Платформа → Партнёр:
    1. Списание с partner_balance reverse (или credit на partner_balance в зависимости от модели clearing'а)
    2. Платформа делает payout партнёру в размере platform_obligation
    3. Платформа начинает supplier_refund_recovery process
  
  Поток B — Партнёр → End-customer:
    1. Партнёр делает refund end-customer'у через свой payment processor в размере partner_to_customer
    2. Платформа отслеживает factual refund execution (через webhook от partner-side payment processor если интеграция есть)
    ↓
Поток C (асинхронный) — Платформа → Supplier recovery:
    1. Платформа request'ит refund от supplier'а в размере expected_supplier_portion
    2. Supplier processes per his rules (может быть delayed: 30-90 дней, может быть partial)
    3. При получении actual_supplier_portion — сравнение с expected
    4. При расхождении — clearing_correction_event с loss accounting

Каноничные расчёты split'а​

Случай 1: Supplier-side cancellation (free cancellation window)​

Supplier даёт full refund по своим правилам.

  • expected_supplier_portion = full amount
  • platform_obligation = full amount (минус platform fee если применимо)
  • partner_to_customer = full amount минус partner commission
  • insolvency_protection_applies = false (всё в норме)

Loss risk: низкий — supplier gives full refund, потоки совпадают.

Случай 2: Late cancellation с supplier penalty​

Supplier удерживает часть amount как cancellation fee (per его правил).

  • expected_supplier_portion = full_amount − supplier_cancellation_fee
  • platform_obligation = ?

Здесь начинается ключевое решение: что платит платформа партнёру?

Каноничный подход — трансляция supplier penalty наверх:

  • platform_obligation = full_amount − supplier_cancellation_fee − platform_fee
  • partner_to_customer = что_получил_партнёр − partner_commission_loss

Партнёр and end-customer получают меньше чем они заплатили — это норма для late cancellation.

Loss risk: низкий, но требует ясной коммуникации end-customer'у о cancellation fee.

Случай 3: Supplier insolvency или undelivered service​

Supplier не доставляет услугу (банкротство, отказ, no-show на стороне supplier'а).

  • expected_supplier_portion = full amount (мы вправе ожидать full refund)
  • actual_supplier_portion = 0 (supplier не возвращает или не существует)
  • platform_obligation = full amount (Package Travel Directive insolvency protection)
  • partner_to_customer = full amount минус partner commission (partner возвращает customer'у per consumer protection)

Loss accounting: разница = full amount − recoverable_from_insurance. Это покрывается через insolvency reserve fund платформы.

Insolvency reserve fund формируется из:

  • процент от каждого booked transaction (например, 0.5% — конфигурируемо);
  • partner-tier premium (Enterprise tier платит higher percentage in exchange for higher protection);
  • комерческое страхование (B2B insurance contract платформы с реinsurer'ом).

Случай 4: Partial cancellation в multi-segment туре​

Один segment отменяется, остальные остаются.

  • Каждый supplier даёт refund по своим правилам, независимо.
  • platform_obligation = sum of platform_obligations per segment.
  • Tour-level cancellation policy может отличаться от sum of segment-level (например, tour-level cancellation fee применяется поверх segment refunds).

Bundle integrity check: при cancellation одного segment'а проверяется, остаётся ли тур экономически и логистически жизнеспособным (см. reference/tour-builder-operational-model.md, раздел Каскадный drift и auto-replace). Если нет — тур может предлагаться к full cancellation.

Случай 5: Currency mismatch​

Booking в одной валюте, supplier refund в другой, partner billed в третьей.

  • Каноничное правило: refund к end-customer в валюте, в которой он платил (защита от currency volatility risk на стороне customer'а).
  • Currency conversion delta между supplier и customer = cost of platform (loss accounting), потому что customer не должен страдать от FX volatility.
  • При значительной (>5%) FX delta — partner может получить partial cost-sharing (определяется partner-tier policy).

Caнoничные events для audit​

Каждый refund event порождает structured events:

  • platform_refund_intent_created — initiation, фиксация expected splits.
  • platform_payout_to_partner_executed — Поток A завершён.
  • partner_refund_to_customer_confirmed — Поток B завершён (если есть webhook от partner-side processor).
  • supplier_refund_received — actual supplier portion received.
  • clearing_correction_applied — при расхождении expected vs actual.
  • insolvency_protection_invoked — при использовании reserve fund для покрытия gap'а.

Все эти events — первоклассные финансовые события, навсегда сохраняемые в audit trail.

Loss Accounting​

loss_accounting_entry создаётся при каждой ситуации, где actual_supplier_portion < expected_supplier_portion после full recovery attempts:

  • loss_amount = expected − actual (в нормализованной currency)
  • loss_category:
    • supplier_insolvency
    • supplier_underpayment (вернул меньше чем должен по контракту)
    • supplier_unrecoverable (исчерпали все recovery attempts)
    • currency_volatility (FX changes during recovery period)
    • partial_supplier_refund_acceptable (consciously decided to accept partial as закрытие случая)
  • recovery_attempts[]: log of all recovery attempts with timestamps, methods.

Aggregate loss accounting feeds into:

  • monthly platform P&L;
  • insolvency reserve fund replenishment calculations;
  • supplier risk model для future contracts;
  • ML-feature input для supplier reliability scoring.

Insurance Product как opt-in расширение​

Для случаев где партнёр хочет дополнительной защиты (например, vacation rentals где insolvency risk выше), платформа предлагает opt-in расширенную страховку:

  • Партнёр платит дополнительный insurance fee (% от booking value).
  • В обмен — повышенный platform_obligation guarantee (например, 100% refund в течение 7 дней независимо от supplier'а).
  • Loss затрат покрывается через third-party insurance contract или augmented internal reserve.

Этот product не входит в Stage 1 (для первой стадии достаточно базовой insolvency protection через reserve fund), но архитектурно зафиксирован для post-Stage-1 monetization.

Метрики Settlement Split​

  • expected_vs_actual_supplier_portion_delta — средняя разница между ожидаемым и фактическим refund от supplier'а.
  • recovery_time_avg — среднее время от refund_intent до supplier_refund_received.
  • loss_amount_per_booking_avg — средний loss на бронирование (важная метрика для unit economics).
  • insolvency_invocation_rate — частота использования reserve fund.
  • platform_obligation_compliance_rate — % случаев где платформа выполнила platform_obligation в SLA-window (target ≥ 99.5%).

Регуляторное обеспечение​

  • EU Package Travel Directive (2015/2302) — обязывает обеспечить insolvency protection для package travel; наш reserve fund обеспечивает compliance.
  • Consumer Rights Directive (2011/83/EU) — определяет refund rights в EU; platform_obligation должен соответствовать минимальным стандартам.
  • Local consumer protection laws для каждой юрисдикции (UA, KZ, etc.) — проверяются перед commercial activity.

См. также reference/compliance-and-legal.md для деталей regulatory обязательств.

Обоснование (тезисы)​

Тезис 1. Платформа гарантирует platform_obligation независимо от supplier_portion.

Альтернативы: (а) платформа возвращает партнёру только то что получила от supplier'а; (б) платформа гарантирует full refund независимо от supplier'а (insolvency protection).

Trade-off: вариант (а) делает партнёра и customer'а заложниками supplier'ов и нарушает Package Travel Directive; вариант (б) — каноничный для верхнеуровневых платформ, требует insolvency reserve, но обеспечивает trust.

Тезис 2. Loss accounting явно отделён от operational refund flow.

Альтернативы: (а) считать loss как просто «недополученный refund» без отдельной категоризации; (б) explicit loss_accounting_entries с категориями.

Trade-off: вариант (а) скрывает unit economics проблемы; вариант (б) — каноничный для финансовой прозрачности и improvement-driven decisions.

Тезис 3. End-customer защищён независимо от внутренней цепочки.

Альтернативы: (а) end-customer receives proportionally к тому что вернул supplier; (б) end-customer receives full refund per consumer protection регуляции.

Trade-off: вариант (а) нарушает регуляции и разрушает trust; вариант (б) — обязательное каноничное правило.

Тезис 4. Insurance product как opt-in для повышенной защиты.

Альтернативы: (а) baseline insolvency protection одинаково для всех; (б) baseline + opt-in extended.

Trade-off: вариант (а) ограничивает revenue diversification; вариант (б) — каноничный, позволяет партнёрам выбирать risk tolerance и платить за это.

Принцип​

Партнёр не должен быть заложником ненадёжности поставщика. Если бронирование переходит в unknown_external_state (см. reference/booking-state-machine.md, раздел Обработка unknown_external_state), резерв партнёрского баланса:

  • временно удерживается на период восстановительного цикла (до 32 часов);
  • автоматически освобождается по hard-deadline восстановительного цикла, независимо от итогового исхода (failed / manual_intervention);
  • корректируется обратно через clearing_correction_event, если в финальном исходе выясняется что обязательство всё-таки возникло.

Это защищает партнёра от ситуации «у меня замёрзло 50 тыс. EUR на балансе из-за того что один поставщик сломался».

Каноничные временные окна освобождения резерва​

Сценарий бронированияУдержание резерваФинальное освобождение
unknown_external_state в search-флоудо 15 минутавтоматически по hard timeout
unknown_external_state в booking-флоу до confirmedдо 4 часовавтоматически по hard timeout
unknown_external_state post-confirmed (cancel/amendment)до 32 часов (восстановительный цикл)автоматически по завершении цикла
Переход в manual_intervention без явного исходарезерв освобождается сразу при переходе в manual_interventionbalance correction только если оператор подтверждает обязательство

Все hard-timeout значения должны совпадать с timeout values, зафиксированными в booking-state-machine.md. При расхождении — приоритет state machine как source of truth таймаутов; партнёрский баланс следует за её решениями.

Каноничные события для аудита​

Каждое освобождение/коррекция резерва порождает события в шине:

  • partner_balance_reserved — при создании бронирования.
  • partner_balance_released_unknown_state_timeout — при автоматическом освобождении по hard timeout. Содержит booking_id, original_reservation_amount, restoration_attempts_count, final_state (на момент освобождения).
  • partner_balance_correction_applied — при последующей коррекции, когда выясняется итоговое обязательство. Содержит booking_id, correction_direction (debit/credit), amount, reason_code (supplier_finally_confirmed, customer_completed_use, etc.), audit_trail_ref.

Эти события — первоклассные финансовые события (см. reference/initial-event-taxonomy.md), они навсегда сохраняются в audit-журнале партнёрского контура с продолжительным сроком хранения.

Связь с Insolvency Protection (Package Travel Directive)​

Если бронирование переходит в failed после освобождения партнёрского резерва, но end-customer уже совершил платёж в expectation услуги — обязательство возврата end-customer'у не зависит от того, в каком состоянии партнёрский баланс. Платформа покрывает разрыв через:

  • собственный insolvency reserve fund (резервный фонд платформы, формируется как процент от revenue);
  • последующую коррекцию через clearing_correction_event если supplier всё-таки вернёт деньги post-factum;
  • разница между ожидаемым возвратом от supplier'а и реальным — это loss accounting платформы, см. раздел Settlement Split ниже.

Это соответствует требованиям EU Package Travel Directive о insolvency protection: end-customer защищён независимо от внутренних финансовых отношений между платформой, партнёром и supplier'ом.

Метрики для мониторинга​

  • unknown_state_release_count — количество автоматических освобождений резерва за период.
  • unknown_state_release_amount — суммарный объём освобождённых средств.
  • correction_after_release_rate — доля случаев, когда освобождённый резерв был скорректирован обратно (показатель качества timeout policy: высокая ставка означает что timeout слишком короткий).
  • partner_balance_avg_reservation_duration — среднее время удержания резерва (показатель надёжности supplier-сети).

При correction_after_release_rate > 5% — review timeout policy (возможно нужно расширить окна) и supplier quality (несколько supplier'ов медленные).

Что НЕ делает Balance Release​

Чтобы избежать неправильных интерпретаций:

  • Balance release не отменяет обязательство партнёра перед платформой по самому бронированию. Если бронирование позже окажется confirmed — обязательство возникает обратно через clearing_correction_event.
  • Balance release не означает автоматическую отмену бронирования. State machine продолжает работать своим циклом восстановления, balance release — это independent финансовый процесс.
  • Balance release не возвращает деньги конечному клиенту автоматически. Это отдельный процесс, управляемый через payment domain (см. reference/payment-domain.md).

Обоснование (тезисы)​

Тезис 1. Партнёрский баланс не может быть заложником поставщика.

Альтернативы: (а) держать резерв до итогового исхода (потенциально навсегда); (б) освобождать резерв по hard timeout с возможной коррекцией; (в) не резервировать баланс до confirmed.

Trade-off: вариант (а) — описанный ревьюером риск «зависших денег»; вариант (в) допускает партнёрский overdraft в момент confirmed; вариант (б) — каноничный баланс защиты партнёра и финансовой корректности.

Тезис 2. Каждое освобождение и коррекция фиксируются в шине событий.

Альтернативы: (а) обновлять баланс прямой записью без событий; (б) полная событийная трассировка каждого изменения.

Trade-off: вариант (а) убивает аудиторскую способность; вариант (б) — каноничный, основа для регуляторного аудита и ML-мониторинга качества supplier-сети.

Тезис 3. End-customer protection не зависит от состояния партнёрского баланса.

Альтернативы: (а) возврат end-customer'у только если есть resources на партнёрском балансе; (б) платформа всегда возвращает end-customer'у через insolvency fund независимо от партнёрского состояния.

Trade-off: вариант (а) нарушает Package Travel Directive и разрушает доверие к платформе; вариант (б) — обязательное регуляторное требование и каноничная модель верхнеуровневой платформы.

Surface Consequences​

Partner API​

Должен получать честные сигналы:

  • quota or balance exhaustion;
  • payment or clearing hold;
  • temporary trading restriction;
  • risk-review requirement;
  • degraded ability to confirm booking.

Agency Surface​

Должна понимать:

  • почему booking blocked;
  • является ли проблема ценовой, supplier-side или financial;
  • может ли оператор вручную override scenario.

Internal Operations​

Должны видеть:

  • partner exposure;
  • blocked sales reasons;
  • aging holds;
  • debt and over-limit positions;
  • disputes and manual corrections.

Persistent And Operational Requirements​

Этот домен требует отдельного storage and persistence discipline:

  • ledger-like clearing entries;
  • account snapshots;
  • hold lifecycle;
  • utilisation history;
  • limit changes;
  • manual financial decisions;
  • audit trail on unblock and override actions.

Что Должно Быть Сделано Дальше​

После фиксации этого документа нужно будет:

  • синхронизировать commercial-model, settlement-and-reconciliation, api-contracts, database-schema, storage;
  • определить, какие clearing states доступны external surfaces;
  • уточнить partner onboarding rules в tenant enablement контуре;
  • оформить implementation-ready financial trace model.

Уточнение под Фазы 4–6 (28.04.2026) — связь с payment, settlement, SLA credits, isolation​

Документ опубликован 24.04.2026 (Фаза 3). После Фаз 4–6 partner finance интегрирован с canонических payment, SLA, isolation; эта секция фиксирует связи.

Связь с платёжным доменом​

reference/payment-domain.md (Фаза 4) — каноничные сущности PaymentTransaction, Refund, Chargeback, Settlement, PayoutBatch. Этот документ — clearing layer поверх payment-domain:

  • Partner Financial Account агрегирует множество PaymentTransaction и Settlement events;
  • Clearing Balance — derived view от payment-domain финансовых событий;
  • PayoutBatch — операционная сущность, выпуск выплат партнёрам.

При конфликте между этим документом и payment-domain — payment-domain авторитетен для transaction lifecycle; partner-finance — для clearing aggregation.

Связь с операциями settlement и reconciliation​

operations/settlement-and-reconciliation.md (Фаза 3 + Фаза 10 уточнение) — операционные процедуры settlement; этот документ — бизнес-модель clearing. Не путать.

Связь с booking state machine​

reference/booking-state-machine.md (Фаза 5) — clearing triggers per state:

  • platform_confirmed → settlement entry, partner balance update;
  • partially_confirmed → partial clearing;
  • unknown_external_state → freeze clearing, manual review;
  • cancelled → reverse clearing entry, refund propagation.

Связь с SLA service credits​

operations/sla-and-on-call-model.md (Фаза 6) — service credits (5%/10%/25%/50% от месячной подписки) — negative entries в partner clearing balance. Каноничный flow:

  • SLA breach detected → service credit calculated;
  • credit applied к partner balance в next clearing cycle;
  • audit log per credit (см. security-architecture);
  • credit visible через partner-facing dashboard.

Связь с tier-моделью​

reference/api-as-product.md (Фаза 4) — tier определяет:

  • credit limits и deposit requirements;
  • payout frequency (weekly для Enterprise, monthly для Starter);
  • netting rules для multi-currency partners.

Связь с уровнями тенантной изоляции​

reference/multi-tenant-isolation-strength.md (Фаза 5) — clearing data — Tier 1 critical:

  • per-tenant isolation в financial DBs;
  • Enterprise tenants с dedicated_infrastructure могут иметь отдельные financial schemas;
  • 7 лет retention (regulated).

Связь с EU TOMS VAT​

reference/compliance-and-legal.md (Фаза 4) — clearing должен tracking margin per booking для VAT calculation:

  • gross revenue per partner;
  • supplier cost per booking;
  • margin = gross − cost (база для EU TOMS VAT);
  • VAT collected and remitted per period.

Связь с DR — Tier 1​

operations/disaster-recovery-and-capacity.md — financial data Tier 1: RTO 60м, RPO 5м, 7 лет retention.

Связь с economic model​

reference/economic-model.md (Фаза 4) — partner finance feeds revenue stream classes:

  • partner_api_subscription (подписка);
  • partner_api_usage (фактическое потребление);
  • agency_commission (если applicable);
  • tour_builder_paid_access (отдельный stream).

Каноничный итог уточнения

Partner finance остаётся clearing layer над transaction layer payment-domain. Реализация:

Уточнение выполнено через no-destruction.