Settlement And Reconciliation Operations — Расчёты, сверка и финансовая эксплуатация

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

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

Этот документ фиксирует execution-level слой для settlement, reconciliation, refund/cancellation economics и downstream financial operations платформы vitrip.store.

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

• как quoted commercial promise переходит в settlement-relevant financial reality;
• какие execution-сценарии возникают после booking confirmation, cancellation, amendment и supplier drift;
• как должны работать financial traceability, reconciliation, discrepancy handling и dispute support;
• какие operational owners, queue types, recovery paths и audit requirements обязательны;
• как этот слой должен быть увязан с commercial-model, booking, storage, database-schema и deployment.

Этот документ не является бухгалтерской инструкцией и не описывает локальное налоговое право. Это документ о финансово-операционной модели платформы, которая должна быть промышленно управляемой.

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

• Архитектурная основа платформы vitrip.store
• Главные выводы и проблемные зоны платформы
• Deployment And Operating Model — Развёртывание и эксплуатационная модель
• Commercial Model — Коммерческая модель, цена, settlement и канальные условия
• Offer Pricing Booking Semantics — Семантика предложения, цены и бронирования
• Business Services — Сервисная декомпозиция платформы
• Database Schema — Каноническая модель хранения платформы
• Storage Layer — Модель хранения и жизненный цикл данных
• API Contracts — Surface Contracts и правила внешнего взаимодействия
• Clients Layer — Клиентские поверхности и рабочие модели
• Suppliers Layer — Поставщики, source boundaries и управление внешней реальностью
• Ingestion Layer — Приём, нормализация, маппинг и governance
• Tenancy And Identity — Субъекты платформы, изоляция и модель доступа

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

После фиксации commercial-model, offer-pricing-booking-semantics, database-schema, storage и deployment уже нельзя оставлять settlement как неявный хвост booking-domain.

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

• quoted promise;
• booking-time commercial basis;
• supplier-side payable reality;
• agency/partner/platform financial shares;
• refund and amendment economics;
• reconciliation and discrepancy resolution.

Без отдельного execution-документа эти вещи начнут расползаться между:

• коммерческой моделью;
• booking implementation;
• finance support;
• reporting;
• manual operational actions.

Главный Принцип Settlement And Reconciliation

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

quoted promise, booking commitment и settlement-relevant reality связаны, но не тождественны.

Из этого следуют обязательные выводы:

• quoted price нельзя автоматически считать окончательной settlement reality;
• booking success не означает, что все downstream payable and revenue figures уже окончательно согласованы;
• supplier inputs могут меняться post-booking или выявляться с задержкой;
• refund/cancellation/amendment всегда требуют отдельной финансовой интерпретации;
• reconciliation должна быть first-class operational process, а не поздний reporting job.

Базовые Финансовые Реальности Платформы

На execution-level платформа должна различать как минимум пять уровней финансовой реальности.

1. Quoted Commercial Promise

Это то, что было обещано actor-у в Quote.

Оно важно для:

• customer communication;
• agency workflow;
• partner contract surface;
• booking intent formation;
• dispute context.

2. Booking-Time Commercial Basis

Это денежная база, на которой booking был реально инициирован или подтверждён после revalidation / repricing.

Она нужна для:

• commit traceability;
• explanation of booking-time transition;
• downstream comparison with quote.

3. Supplier Settlement Basis

Это набор supplier-facing payable figures:

• supplier base amount;
• supplier taxes and fees;
• supplier cancellation penalties;
• supplier amendment-related deltas;
• currency and rate basis supplier-side economics.

4. Platform Internal Financial Basis

Это то, что платформа считает своей внутренней финансовой реальностью:

• revenue component;
• service fee;
• margin;
• partner fee or revenue share;
• agency commission or agency margin treatment;
• refund and reversal logic.

5. Reconciled Financial Reality

Это итоговая операционно согласованная реальность после:

• supplier confirmation;
• booking lifecycle completion;
• refund/amendment effects;
• reconciliation checks;
• discrepancy resolution.

Именно она должна становиться базой для final reporting and finance-grade outcomes.

Settlement Is Not A Single Event

Settlement нельзя мыслить как один момент “после бронирования”.

Платформа должна поддерживать как минимум следующие типы settlement-relevant events:

• booking created with financial basis;
• supplier payable recognized;
• agency commission recognized;
• partner revenue share recognized;
• refund recognized;
• cancellation penalty recognized;
• amendment delta recognized;
• reversal or correction posted;
• reconciliation adjustment applied.

Это означает, что settlement-model всегда eventful, staged and operationally reviewable.

Основные Execution-Сценарии

1. Happy Path Booking Settlement

Базовая последовательность:

Quote
  → booking intent
  → booking-time commercial basis confirmed
  → supplier confirmation received
  → settlement-relevant events generated
  → reconciliation checks passed
  → financial reality considered operationally settled

2. Repricing Before Booking

Последовательность:

Quote
  → supplier/commercial drift detected
  → repricing
  → new booking-time basis
  → booking proceeds on updated commercial basis

Здесь критично не потерять:

• старый quote promise;
• причину repricing;
• новый commit basis;
• actor-visible consequence.

3. Booking Confirmed, Financial Divergence Found Later

Последовательность:

Booking confirmed
  → late supplier financial signal arrives
  → discrepancy detected
  → review / reconciliation
  → adjustment or dispute handling

Это одна из самых важных industrial realities платформы.

4. Cancellation / Refund Path

Последовательность:

Booking confirmed
  → cancellation requested or initiated
  → supplier penalty / refund basis determined
  → downstream agency / partner / platform amounts recalculated
  → refund or reversal events posted
  → reconciliation completed

5. Amendment Path

Изменение booking не должно рассматриваться как “перезаписать старую сумму”.

Должны различаться:

• old booking basis;
• new booking basis;
• delta;
• retained obligations;
• new settlement events.

Operational Owners

Для finance-grade эксплуатации платформа должна различать не только домены, но и ownership.

Commercial Domain Owner

Отвечает за:

• price logic;
• quote policy;
• repricing interpretation;
• channel-aware visibility;
• commercial rules.

Booking Operations Owner

Отвечает за:

• booking state transitions;
• unknown external state handling;
• cancellation / amendment execution;
• supplier booking-side investigation.

Finance / Reconciliation Owner

Отвечает за:

• settlement event interpretation;
• payable / receivable checks;
• discrepancy queues;
• refund and reversal verification;
• reconciled status assignment.

Supplier Operations Owner

Отвечает за:

• supplier-side evidence;
• supplier discrepancy investigation;
• supplier financial trace review;
• escalation to supplier support.

Support / Dispute Owner

Отвечает за:

• actor-facing explanation;
• case coordination;
• customer/agency/partner dispute routing;
• trace collection across quote, booking and settlement paths.

Reconciliation Layers

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

1. Quote-To-Booking Reconciliation

Проверяет:

• совпадает ли booking-time basis с quoted promise;
• если нет, было ли это через explicit repricing;
• корректно ли задокументирована разница.

2. Booking-To-Supplier Reconciliation

Проверяет:

• соответствует ли supplier financial basis ожидаемой platform-side basis;
• нет ли missing or duplicated supplier-side signals;
• нет ли pending unknown state.

3. Internal Settlement Reconciliation

Проверяет:

• корректно ли посчитаны platform/agency/partner components;
• нет ли inconsistent fee/commission/revenue-share logic;
• все ли reversal events учтены.

4. Refund / Amendment Reconciliation

Проверяет:

• сходятся ли revised obligations;
• не потеряны ли penalties;
• нет ли mismatch между supplier refund basis и downstream platform treatment.

Discrepancy Classes

Execution-layer должен различать типы расхождений, а не складывать всё в одну queue.

1. Quote Discrepancy

• quote expired but used downstream;
• price changed without proper repricing trace;
• wrong visibility level of monetary breakdown;
• missing quote-to-booking trace.

2. Supplier Financial Discrepancy

• supplier amount mismatch;
• missing taxes or fees;
• unexpected penalty;
• currency mismatch;
• out-of-window supplier update.

3. Platform Internal Discrepancy

• wrong commission recognition;
• incorrect fee composition;
• duplicate settlement event;
• broken reversal handling.

4. Partner / Agency Discrepancy

• contract-visible amount differs from reconciled basis;
• wrong margin exposure;
• wrong revenue share attribution;
• missing explanation of repricing or refund delta.

5. Lifecycle Discrepancy

• booking state and settlement state inconsistent;
• cancellation completed but financial reversal absent;
• amendment posted but new payable basis incomplete.

Reconciliation Queue Model

Платформе нужны не просто “финансовые задачи”, а нормальные operational queues.

Минимальные Queue Types

• quote vs booking mismatch queue;
• supplier payable mismatch queue;
• refund / reversal verification queue;
• amendment delta queue;
• unresolved currency or rounding discrepancy queue;
• partner / agency dispute queue.

Для Каждого Кейса Должно Быть Видно

• primary business object;
• affected actor / tenant / workspace;
• supplier and supplier references;
• quote / booking / settlement traces;
• discrepancy type;
• severity;
• aging;
• current owner;
• next required action.

Required Traceability

Для любого financial-grade case платформа должна позволять пройти цепочку:

offer
  → quote
  → booking intent
  → booking state events
  → supplier financial signal
  → settlement events
  → reconciliation outcome

Без этой цепочки support и finance operations быстро превращаются в ручную археологию.

Data Requirements For Operations

Execution-layer опирается на то, что уже закреплено в database-schema.md и storage.md.

Обязательно Должны Существовать

• quote basis;
• repricing history;
• booking event history;
• settlement-relevant events;
• settlement figure snapshots;
• supplier trace and supplier financial inputs;
• actor / tenant / workspace attribution;
• policy trace;
• refund and amendment financial deltas.

Чего Недостаточно

Недостаточно иметь только:

• текущую booking сумму;
• один commercial_snapshot;
• supplier booking reference;
• отчётный итоговый CSV.

Для industrial operations этого слишком мало.

Currency, Rounding And FX Reconciliation

Одна из самых опасных execution-зон — тихие расхождения из-за валют и округления.

Должно Быть Явно Зафиксировано

• source currency;
• quoted display currency;
• booking payment currency;
• settlement currency, если она отличается;
• exchange-rate reference and timestamp;
• rounding rule and where it was applied.

Discrepancy Handling Должен Отличать

• коммерческую разницу из-за policy;
• supplier change;
• rounding delta;
• FX reference drift;
• ошибку исполнения.

Refund And Cancellation Operations

Refund path не должен быть тонким appendage к booking cancellation.

Execution-Model Обязан Уметь

• отличать refundable and non-refundable components;
• хранить supplier penalty basis;
• рассчитывать downstream agency / partner / platform deltas;
• выпускать reversal events;
• вести queue на unresolved refund discrepancies;
• объяснять actor-facing consequence.

Amendment Operations

Amendment path особенно опасен, потому что создаёт новую реальность поверх старой.

Должно Быть Явно Видно

• original booking basis;
• amended booking basis;
• delta;
• retained obligations;
• new quote or equivalent commercial basis, если нужен;
• reconciliation state after amendment.

Execution Metrics

Для этого слоя нужны отдельные operations metrics.

Core Metrics

• count of unreconciled bookings;
• aging of reconciliation queues;
• quote-to-booking mismatch rate;
• supplier payable mismatch rate;
• refund discrepancy rate;
• amendment delta unresolved rate;
• mean time to reconciliation;
• mean time to refund closure;
• settlement event duplication rate;
• FX/rounding discrepancy frequency.

Alerts And Incident Triggers

Execution-layer должен поднимать не только infra-alerts, но и operational financial alerts.

Примеры Alert Conditions

• surge in quote/booking mismatches;
• sudden rise in supplier financial mismatches;
• settlement event generation lag;
• refund queue aging above threshold;
• amendment cases missing financial delta;
• missing reconciliation closure after booking confirmation window.

Relationship To Surfaces

Этот execution-layer не должен напрямую раскрываться одинаково всем surface-ам.

Internal Operational Surface

Может видеть:

• full financial trace;
• policy trace;
• queue ownership;
• discrepancy classes;
• reconciliation status.

Agency Surface

Может видеть:

• quote vs booking explanation where relevant;
• refund/amendment commercial consequence;
• status of financial follow-up where contractually appropriate.

Partner Surface

Может видеть:

• only contract-approved financial fields;
• partner-visible discrepancy outcomes where required;
• machine-readable finality / pending semantics.

B2C Surface

Обычно не должен видеть internal settlement machinery.

Но он не должен получать ложную finality, если refund/cancellation economics ещё operationally unresolved.

Relationship To Deployment And Operating Model

Этот документ расширяет Deployment And Operating Model — Развёртывание и эксплуатационная модель.

Из него следуют execution requirements:

• отдельные reconciliation-capable operational paths;
• retention-grade financial traces;
• observability around settlement events;
• support for manual queues and operational control;
• rollout caution for any logic affecting quote, booking or settlement semantics.

What This Document Requires Next

После фиксации этого execution-layer следующими сильными документами должны стать:

• operations/observability-and-incident-response.md
• при необходимости operations/release-engineering-and-migrations.md
• затем более прикладные finance workflows, если проекту понадобится deeper business-operational detail.

Текущий Практический Вывод

Платформа vitrip.store должна мыслить settlement and reconciliation не как отчётность “после брони”, а как постоянный execution-layer между:

• quoted commercial promise;
• booking commitment;
• supplier economics;
• platform financial interpretation;
• final reconciled operational truth.

Именно этот слой делает платформу industrial-grade, а не просто удобным поиском и бронированием с красивой коммерческой моделью на бумаге.

Уточнение под Фазы 4–6 (28.04.2026) — связи с payment, post-booking, sla credits, compliance

Документ опубликован 24.04.2026 в Фазе 3 как baseline settlement и reconciliation. После Фаз 4–6 опубликованы специализированные документы, которые используют или расширяют этот baseline. Эта секция фиксирует обязательные связи.

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

reference/payment-domain.md (Фаза 4) определяет каноничные сущности платежей:

• PaymentIntent — намерение платежа, lifecycle до фиксации;
• PaymentTransaction — фактическая транзакция через PSP;
• Refund — возврат средств (отдельная транзакция);
• Chargeback — возврат через банк customer (downstream financial reality);
• Settlement — каноничный расчётный объект между платформой и поставщиком;
• PayoutBatch — партия выплат поставщикам.

Settlement в этом документе — результат payment lifecycle, описанного в payment-domain. Каноничные имена — payment-domain; этот документ описывает операционные процедуры reconciliation поверх них.

Связь с post-booking lifecycle

reference/post-booking-lifecycle.md (Фаза 3) — refund / amendment / cancellation генерируют settlement events. Reconciliation должен учитывать:

• AmendmentRequest → может изменить settlement amount post-booking;
• CancellationCase → triggers refund + settlement reversal;
• SupplierDisruptionCase → может создать compensation events;
• PostBookingDecision → определяет финансовые последствия.

Reconciliation pipeline должен ждать stable post-booking state перед финализацией settlement, не рассчитывать на момент platform_confirmed booking.

Связь со SLA credits как revenue correction

operations/sla-and-on-call-model.md (Фаза 6) определяет service credits при SLA breach:

• 5% / 10% / 25% / 50% от месячной подписки tenant;
• автоматическая выплата через self-service;
• revenue correction в settlement периоде.

Reconciliation должен учитывать service credits как negative revenue adjustment в tenant settlement period:

• credits снижают net revenue от tenant за период;
• credits отражаются в tenant_economic_profile (см. economic-model.md);
• credits — отдельная category в settlement reports.

Связь со 14 состояниями Booking

reference/booking-state-machine.md (Фаза 5) — каноничные 14 состояний. Settlement triggers per state:

Booking state	Settlement action
submitted	hold payment authorization
pending_supplier_confirmation	hold remains
supplier_confirmed	capture payment (PSP)
platform_confirmed	settlement event posted
partially_confirmed	partial settlement, partial refund
unknown_external_state	freeze settlement, manual review required
failed	release authorization (no settlement)
cancelled	refund processing per cancellation policy
amendment_in_progress	settlement adjustment per amendment outcome
completed	final settlement reconciled

unknown_external_state — особо важный case: settlement не должен automatically progress, требуется manual review. Target SLI менее 1% (см. sla-and-on-call-model.md).

Связь с saga для Tour Builder bookings

reference/tour-builder-operational-model.md (Фаза 5) — multi-component tour bookings координируются через saga. Settlement implications:

• Single PaymentIntent для всего тура (предпочтительно) или multi-PaymentIntent (один на компонент);
• Saga compensation при partial booking failure → отдельные refund operations per компонент;
• Per-component settlement — каждый компонент settle с соответствующим поставщиком;
• Drift handling — DriftEvent может изменить settlement amount post-booking.

Reconciliation для tour bookings — сложнее чем для single-component, требует saga-aware logic.

Связь с compliance — EU TOMS VAT

reference/compliance-and-legal.md (Фаза 4) — EU Tour Operators' Margin Scheme:

• Margin VAT — НДС на маржу платформы (revenue minus supplier cost);
• Place of supply rules — VAT в стране customer (B2C) или место supply (B2B);
• Quarterly VAT returns — формальная отчётность;
• Audit trail per booking — для VAT audit обязательно сохранять все settlement details.

Reconciliation pipeline должен separately track:

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

Связь с partner clearing

reference/partner-finance-and-clearing.md (Фаза 3) — partner clearing layer поверх settlement:

• partner balance, credit limit, clearing entries;
• payouts по периодам;
• holds при approaching credit limit;
• netting rules для multi-currency settlements.

Этот документ описывает operational settlement events; partner-finance-and-clearing — бухгалтерскую модель поверх. Не путать.

Связь с tenant isolation для financial data

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

• per-tenant isolation в financial DBs;
• Enterprise tenants с dedicated_infrastructure могут иметь отдельные financial databases;
• audit log каждого access к settlement data (security-architecture.md);
• 7 лет retention (regulated requirement).

Связь с DR — Tier 1 backup

operations/disaster-recovery-and-capacity.md (Фаза 6) — settlement data в Tier 1:

• RTO 60 минут;
• RPO 5 минут;
• continuous WAL streaming + snapshot каждый час;
• ежемесячные restore drills для Tier 1 (включая settlement).

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

Этот документ остаётся операционной процедурой settlement и reconciliation. Расширения и связи:

• Каноничные payment entities → payment-domain.md;
• Post-booking financial implications → post-booking-lifecycle.md;
• SLA credits как revenue correction → sla-and-on-call-model.md;
• Booking state → settlement action mapping → booking-state-machine.md;
• Tour saga settlement → tour-builder-operational-model.md;
• EU TOMS VAT compliance → compliance-and-legal.md;
• Partner clearing layer поверх → partner-finance-and-clearing.md;
• Tenant isolation для financial data → multi-tenant-isolation-strength.md;
• Tier 1 DR обязательства → disaster-recovery-and-capacity.md;
• Security audit для financial access → security-architecture.md.

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