SaaS-контракт из Кыргызстана: 9 ключевых пунктов

Почему SaaS-контракт из Кыргызстана требует особого подхода?

Кыргызстанская IT-компания, продающая облачный сервис зарубежному заказчику, находится на пересечении нескольких правовых систем одновременно. С одной стороны — право КР, регулирующее деятельность поставщика и его налоговые обязательства. С другой — право страны заказчика, требования GDPR, американские санкционные режимы, европейские стандарты обработки данных. Без явных договорённостей о применимом праве и юрисдикции суды разных стран могут прийти к противоположным выводам об исполнении одного и того же контракта.

Кыргызский рынок облачных услуг вырос на фоне двух факторов: волны релокации IT-специалистов из России и Беларуси после 2022 года и расширения режима ПВТ, который с 2024 года стал бессрочным. Сегодня в ПВТ зарегистрировано более 500 резидентов, совокупная выручка которых в 2024 году превысила 11,4 млрд сомов. Значительная часть этой выручки — контракты на предоставление программного обеспечения как услуги. При этом типичный SaaS-контракт, написанный «по шаблону из интернета», не учитывает ни режим нулевого НДС для ПВТ-резидентов, ни требования Закона «Об информации персонального характера», ни особенности исполнительного производства в КР.

Девять пунктов, рассмотренных в этом материале, — не академический перечень, а практическая карта рисков. Каждый пункт соответствует реальной точке разногласий, которая становится предметом споров между поставщиком и заказчиком. По сложившейся практике межрайонных судов по экономическим делам, значительная часть споров о выплате за SaaS-услуги связана именно с отсутствием чётких договорных условий о приёмке результата, SLA и порядке прекращения доступа.

Разбор ведётся в логике «контекст → риск → формулировка». Для каждого пункта указаны типичная ошибка и рекомендуемое решение с учётом режима налогообложения поставщика — ПВТ, единый налог или общий режим.

Пункт 1. Предмет договора: как описать SaaS без передачи прав на ПО?

Ключевое юридическое различие SaaS от лицензионного договора — отсутствие передачи прав на программное обеспечение. Поставщик предоставляет доступ к функциональности через сеть, но не передаёт исходный код, объектный код или право воспроизведения. Если контракт написан как «лицензионный», налоговые органы могут переквалифицировать выплаты как роялти с последствиями для удержания налога у источника.

Правильная формулировка предмета: «Исполнитель обязуется обеспечить Заказчику дистанционный доступ к функциональным возможностям программной платформы [название] через сеть Интернет на условиях, определённых настоящим договором и Соглашением об уровне обслуживания (Приложение 1)». Слова «лицензия», «право использования», «передача прав» в предмете недопустимы, если не предполагается реальная передача прав по Закону «Об авторском праве и смежных правах».

Для резидента ПВТ корректная квалификация предмета критична: только при правильном отражении выручки как дохода от предоставления IT-услуг, а не роялти, компания сохраняет право на нулевую ставку налога на прибыль и 5% подоходного налога. Выручка от роялти формально не исключена из режима ПВТ, однако при проверке квалификация контракта влияет на признание дохода «профильным» для целей режима. Для компаний на едином налоге (2% безналичные) квалификация предмета влияет на ставку: электронные услуги облагаются по 2%, тогда как иные виды — по другим ставкам.

В контракте с иностранным заказчиком рекомендуется прямо указать: «Настоящий договор не является лицензионным соглашением и не влечёт передачи исключительных или неисключительных прав на программное обеспечение». Это снимает риск переквалификации как в юрисдикции КР, так и в юрисдикции заказчика, где налогообложение роялти может отличаться от налогообложения платежей за услуги.

ПВТ-резидентство даёт экономию налоговой нагрузки около 80% против общего режима — но только при корректной квалификации доходов как доходов от IT-деятельности.

Пункт 2. Применимое право и юрисдикция: право КР или нейтральная юрисдикция?

Выбор применимого права — не формальность. От него зависит, какие нормы будут регулировать споры о качестве услуги, ограничении ответственности и защите данных. Для кыргызской IT-компании существует три реалистичных варианта: право КР, право страны заказчика, нейтральная юрисдикция (Великобритания, Швейцария, ОАЭ).

Право КР — оптимальный выбор при работе с заказчиками из СНГ, при арбитражных оговорках с МТС при ТПП КР, а также при получении платежей через кыргызские банки. Гражданский кодекс КР содержит достаточно развитую базу для регулирования договоров возмездного оказания услуг, на которые опирается SaaS-контракт. При этом суды КР — в частности, межрайонные суды по экономическим делам — рассматривают споры между юрлицами в установленные сроки, а обеспечительные меры принимаются в течение 1 рабочего дня.

Для заказчиков из ЕС практически всегда требуется дополнительная «прослойка» в контракте, учитывающая GDPR. Даже при выборе права КР в части обработки персональных данных субъектов ЕС контракт должен содержать Стандартные договорные оговорки (SCC) либо ссылку на иной механизм передачи данных по смыслу Регламента (ЕС) 2016/679. Кыргызстан не является «адекватной юрисдикцией» по решению Европейской комиссии, поэтому каждый контракт с ЕС-заказчиком требует явного механизма передачи данных.

Для арбитражных оговорок рекомендуется указывать МТС при ТПП КР — арбитражный институт с 367 арбитрами из 30 стран. Кыргызстан является участником Нью-Йоркской конвенции 1958 года, что обеспечивает исполнение арбитражных решений в 172 странах. Альтернатива — ICC или SIAC для контрактов с крупными международными заказчиками, которые настаивают на нейтральном институте.

Типичная ошибка — отсутствие арбитражной оговорки вообще: «Споры разрешаются в суде по месту нахождения поставщика». Для иностранного заказчика такая формулировка означает необходимость участвовать в процессе в МСЭД Бишкека, что практически исключает реальное исполнение решения. Результат — переговорная слабость поставщика при возникновении спора.

Пункт 3. SLA и порядок приёмки: как зафиксировать факт оказания услуги?

В SaaS-контракте нет «акта выполненных работ» в традиционном смысле — услуга оказывается непрерывно в течение расчётного периода. Но именно отсутствие чёткого SLA и порядка приёмки становится причиной отказа заказчика от оплаты под предлогом «услуга оказана ненадлежащим образом». Суды, как правило, занимают позицию, что бремя доказывания факта надлежащего оказания услуги лежит на поставщике.

Соглашение об уровне обслуживания (SLA) должно содержать: целевой показатель доступности (uptime) в процентах, формулу расчёта downtime, исключения из SLA (плановые работы, форс-мажор, действия заказчика), механизм Service Credit при нарушении SLA и порядок подачи заявок на кредит. Стандарт для B2B SaaS — 99,5–99,9% uptime в месяц; для инфраструктурно-критичных сервисов — 99,95%.

Порядок приёмки в SaaS-контракте реализуется через «молчаливую приёмку»: если в течение [N] рабочих дней после окончания расчётного периода заказчик не направил мотивированного возражения, услуга считается принятой и подлежит оплате. Механизм «молчаливой приёмки» признаётся действующим законодательством КР как форма конклюдентного акцепта при наличии явной договорной нормы.

Для подтверждения факта оказания услуги поставщик должен автоматически формировать лог-отчёт за период: время работы, число API-запросов, метрики производительности. Этот отчёт является доказательством в случае спора. Рекомендуется хранить логи не менее 3 лет — срок исковой давности по общему правилу Гражданского кодекса КР.

Отдельно фиксируется порядок уведомления о плановых работах (maintenance window): минимальный срок уведомления, формат, исключение плановых работ из расчёта downtime. Без этого положения любое плановое обслуживание системы может быть квалифицировано заказчиком как нарушение SLA.

Пункт 4. Цена, валюта и налогообложение: как учесть режим ПВТ?

Раздел о цене в SaaS-контракте должен содержать три элемента: сумму в валюте контракта, налоговый статус платежа и порядок выставления счёта. Для резидента ПВТ это означает явное указание: «Услуги оказываются в рамках деятельности Исполнителя как резидента Парка высоких технологий КР. НДС не облагается (0%). Ставка налога на прибыль: 0%. Подоходный налог с выплат физическим лицам — сотрудникам Исполнителя: 5%».

Формулировка о НДС критична при работе с российскими заказчиками. По действующему соглашению об избежании двойного налогообложения между РФ и КР (СОИДН), дивиденды облагаются у источника по ставке 10%, проценты — 10%, роялти — 10%. Для платежей за услуги (не роялти) удержание налога у источника в РФ, как правило, не применяется — но только при корректной квалификации предмета контракта (см. Пункт 1). Правило 183 дней определяет, в какой стране компания платит налог на прибыль как налоговый резидент.

Валютная оговорка имеет особое значение для кыргызских SaaS-компаний: сом исторически волатилен относительно доллара и евро. Контракт, номинированный в сомах с российским заказчиком, создаёт валютный риск для поставщика. Практическое решение — номинировать контракт в USD или EUR с оплатой в сомах по курсу НБКР на дату платежа. Либо — жёсткая фиксация курса с условием пересмотра при отклонении более чем на X%.

Порядок выставления счёта: для резидентов ПВТ ЭСФ не требуется при оказании услуг нерезидентам (освобождение от НДС). Для компаний на общем режиме с НДС-регистрацией ЭСФ выписывается в течение 5 рабочих дней. В контракте рекомендуется указать: «Счёт выставляется в последний рабочий день расчётного периода. Оплата — в течение [N] банковских дней с даты выставления счёта».

Для компаний на едином налоге (2% безналичные для IT) важно, чтобы контракт отражал безналичный характер расчётов — это буквально влияет на налоговую ставку: 4% за наличные против 2% за безналичные. Смешение наличных и безналичных расчётов без разделения в учёте — типичная ошибка, обнаруживаемая при камеральной проверке ГНС.

Пункт 5. Данные заказчика: как разграничить роли Data Controller и Data Processor?

Обработка данных — один из наиболее юридически нагруженных разделов SaaS-контракта, особенно при работе с европейскими заказчиками. Разграничение ролей Controller (оператор) и Processor (обработчик) определяет, кто несёт первичную ответственность за соответствие требованиям защиты данных перед регулятором.

По общему правилу GDPR: заказчик — Controller (определяет цели и средства обработки), поставщик SaaS — Processor (обрабатывает данные по инструкции контроллера). Это означает, что поставщик обязан: обрабатывать данные только по задокументированным инструкциям заказчика, обеспечивать конфиденциальность персонала, принимавшего участие в обработке, реализовывать технические и организационные меры безопасности, уведомлять заказчика об инцидентах безопасности в течение 72 часов, содействовать проведению аудитов по запросу заказчика.

В кыргызском праве аналогичное регулирование содержится в Законе «Об информации персонального характера»: оператор персональных данных обязан обеспечить конфиденциальность и защиту от несанкционированного доступа. Для SaaS-поставщика из КР, обрабатывающего данные резидентов КР, требования кыргызского закона применяются в полном объёме. Агентство по защите персональных данных (DPA) вправе проводить проверки операторов.

В контракте рекомендуется включить: Data Processing Agreement (DPA) как отдельное приложение; перечень подпроцессоров (субподрядчиков, которым передаются данные — облачные провайдеры, аналитические сервисы); территорию обработки данных; перечень технических мер защиты (шифрование, разграничение доступа, резервирование); процедуру уничтожения данных при расторжении контракта.

Типичная ошибка — отсутствие DPA вообще или его включение в виде нечитаемого приложения на 50 страниц, которое никто не подписывает. Европейский регулятор при проверке запрашивает именно этот документ как доказательство соблюдения принципа подотчётности (accountability). Для кыргызских поставщиков, работающих с ЕС-заказчиками без DPA, штрафной риск несёт заказчик, но коммерческий риск — потеря контракта — несёт поставщик.

Пункт 6. Ограничение ответственности: как установить liability cap?

Ограничение ответственности — критический пункт для любого SaaS-провайдера. Облачный сервис с тысячами пользователей при серьёзном инциденте (утечка данных, длительный downtime) теоретически может нанести заказчикам убытки, многократно превышающие годовую выручку поставщика. Без чёткого liability cap один иск способен уничтожить компанию.

Гражданский кодекс КР допускает договорное ограничение ответственности за нарушение обязательства. Исключение — умышленное нарушение: ответственность за умысел нельзя ограничить договором. Для B2B SaaS стандартный liability cap — 3–12 месячных платежей заказчика за период, предшествующий инциденту. Конкретная сумма зависит от переговорной позиции сторон и уровня сервиса.

Структура раздела об ответственности включает три уровня: (1) взаимное исключение ответственности за косвенные убытки (lost profits, loss of data, consequential damages) — это «жёсткий пол» контракта; (2) liability cap на прямые убытки — обычно 3–12 месячных платежей; (3) перечень исключений из cap (утечка данных по вине поставщика, нарушение конфиденциальности, умысел) — для этих случаев cap может быть выше или отсутствовать.

Для резидентов ПВТ, работающих с крупными корпоративными заказчиками, нередко возникает давление на отмену liability cap или его существенное увеличение. В таких случаях поставщику рекомендуется либо застраховать профессиональную ответственность (E&O insurance), либо скорректировать цену контракта с учётом принимаемого риска. Работа без cap при значительных оборотах — прямой путь к экзистенциальному риску для компании.

Отдельно прописывается ответственность за нарушение SLA: формула Service Credit (кредит на будущие периоды) является заранее оцениваемым убытком и не суммируется с liability cap — это типичная ошибка в переговорах. Суды, как правило, признают Service Credit надлежащей компенсацией за нарушение SLA, если договор прямо указывает, что кредит является исключительным средством защиты при нарушении уровня доступности.

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

В SaaS-контракте необходимо чётко урегулировать, кому принадлежат данные, загруженные заказчиком в платформу, и что с ними происходит при расторжении договора. Без этих положений возникает правовая неопределённость: поставщик может технически получить доступ к данным конкурентов, клиентским базам или коммерческой тайне заказчика.

Базовое правило, которое должно быть закреплено в контракте: «Все данные, загруженные Заказчиком в платформу, являются собственностью Заказчика. Исполнитель не приобретает прав на эти данные и использует их исключительно в целях оказания услуг по настоящему договору». Это предложение снимает большинство вопросов о праве собственности на данные.

Право на агрегированные и анонимизированные данные — отдельный вопрос. Многие SaaS-провайдеры используют агрегированные данные использования для улучшения продукта, обучения моделей, отраслевых бенчмарков. Это допустимо, но должно быть явно разрешено контрактом: «Исполнитель вправе обрабатывать анонимизированные агрегированные данные об использовании платформы для улучшения функциональности и аналитики при условии, что такие данные не позволяют идентифицировать Заказчика или его пользователей».

Порядок возврата и удаления данных при расторжении — критически важное условие. Стандарт рынка: заказчик получает экспорт всех данных в машиночитаемом формате в течение 30 дней после расторжения; поставщик безвозвратно удаляет данные в течение следующих 30 дней с предоставлением сертификата об удалении. Для заказчиков, подпадающих под GDPR, срок удаления — обязательное требование, отсутствие которого блокирует подписание контракта.

Дополнительно фиксируется: запрет поставщика раскрывать данные заказчика третьим лицам без согласия, за исключением случаев, предусмотренных законодательством КР; порядок ответа на запросы госорганов (поставщик уведомляет заказчика, если это не запрещено законом); режим конфиденциальности в отношении коммерческих данных заказчика.

Пункт 8. Расторжение контракта: что происходит с доступом и платежами?

Порядок расторжения SaaS-контракта — один из наиболее конфликтных разделов. Типичный сценарий: заказчик прекращает оплату, ссылаясь на недовольство качеством; поставщик отключает доступ; заказчик требует возврата предоплаты и компенсации убытков от простоя. Без чётких договорных норм каждая из сторон имеет основания для иска.

Контракт должен разграничивать три вида прекращения: (1) расторжение по соглашению сторон — порядок и последствия определяются дополнительным соглашением; (2) расторжение по инициативе поставщика при нарушении заказчиком — неоплата, нарушение условий использования, противоправная деятельность через платформу; (3) расторжение по инициативе заказчика — уведомительный порядок, компенсация при досрочном расторжении срочного контракта.

При расторжении по вине заказчика (неоплата) стандартная последовательность: предупреждение с установлением срока для оплаты (7–14 дней) → ограничение доступа (read-only) → полное отключение → расторжение с взысканием задолженности. Немедленное отключение без уведомления при первой задержке оплаты — избыточная мера, которая на практике создаёт большие правовые риски для поставщика, чем для заказчика.

Для срочных контрактов (ежегодная подписка) при досрочном расторжении по инициативе заказчика без вины поставщика рекомендуется предусмотреть плату за досрочное прекращение — early termination fee. Как правило, это остаток подписки за неиспользованный период. Гражданский кодекс КР позволяет предусматривать такую плату как условие договора при отсутствии монополистических злоупотреблений.

Важно зафиксировать в контракте: «При расторжении настоящего договора по любому основанию доступ Заказчика к платформе прекращается в дату расторжения. Данные Заказчика хранятся в течение 30 дней для целей экспорта, после чего безвозвратно удаляются. Предоплаченные периоды, не использованные на дату расторжения, возврату не подлежат, за исключением случаев расторжения по вине Исполнителя».

Пункт 9. Обновления и изменение условий: как не потерять заказчика при апдейте?

SaaS-продукты постоянно эволюционируют: меняется функциональность, тарифные планы, политика использования данных. В отсутствие чёткого механизма изменения условий каждое обновление потенциально создаёт новый договор или нарушает действующий. По сложившейся практике коммерческих судов изменение существенных условий договора в одностороннем порядке без уведомления заказчика — основание для признания изменений недействительными.

Существенные условия SaaS-контракта, изменение которых требует явного согласия заказчика или уведомительного периода: цена и тарифный план, объём предоставляемых функций (feature set), SLA, политика обработки данных, юрисдикция и применимое право. Несущественные изменения (интерфейс, порядок работы функций, добавление новых возможностей без удаления существующих) могут вноситься в одностороннем порядке.

Механизм изменения условий должен быть прописан явно: «Исполнитель вправе изменить условия настоящего договора, уведомив Заказчика за [30/60/90] дней до вступления изменений в силу. Уведомление направляется по электронной почте. Если Заказчик продолжает использование сервиса после даты вступления изменений в силу, это означает принятие новых условий. Если Заказчик не принимает изменения, он вправе расторгнуть договор без уплаты штрафа за досрочное прекращение».

Отдельно регулируется изменение цен. Для годовых подписок принято замораживать цену на период подписки и объявлять об изменении не менее чем за 60 дней до автопролонгации. Для месячных — уведомление за 30 дней. Финнадзор в 2025 году массово проверял VASP-лицензиатов в том числе на предмет прозрачности условий тарификации — принцип применим и к небанковским финансовым сервисам. Travel Rule обязателен для всех VASP в Кыргызстане; если SaaS включает функции передачи виртуальных активов, изменение политики Travel Rule требует уведомления Финнадзора, а не только заказчиков.

Рекомендуется вести публичный changelog — журнал изменений продукта — и ссылаться на него в контракте. Это одновременно маркетинговый инструмент и доказательство в случае спора о том, когда именно было введено изменение, повлёкшее убытки заказчика.

Налоговый режим поставщика: как он влияет на структуру всего контракта?

Девять пунктов выше — универсальный каркас. Но конкретное наполнение каждого пункта существенно зависит от налогового режима поставщика. Три основных сценария для кыргызской IT-компании — ПВТ, единый налог, общий режим — создают разные требования к контрактной документации.

Резидент ПВТ: нулевая ставка НДС, нулевой налог на прибыль, 5% подоходный налог. В контракте: явное указание на статус резидента ПВТ, освобождение от НДС. Платёжные условия: безналичные (влияет на расчёт взноса в Дирекцию ПВТ — 1% от выручки). Для иностранных заказчиков — стандартный инвойс без НДС с пометкой о статусе ПВТ. Реестр резидентов ПВТ публичен, заказчик вправе проверить статус.

Единый налог (2% безналичные для IT-услуг): в контракте фиксируется безналичный характер расчётов. Любое смешение с наличными — автоматически 4%. Ограничения по обороту отсутствуют (в отличие от Казахстана и Армении), что делает этот режим привлекательным для масштабирующихся SaaS-компаний. Сравнение: в Армении при обороте свыше ~$300 тыс. оборотный налог 5% для IT заменяется общим режимом; в КР этого порога нет.

Общий режим (10% НП + 12% НДС при обороте свыше порога): контракт должен содержать НДС-оговорку. При экспорте услуг нерезидентам НДС КР, как правило, не начисляется (ставка 0% для экспорта услуг) — но это требует правильного документального оформления для вычета входного НДС. ЭСФ обязательны для подтверждения вычетов по НП: вычеты принимаются только при наличии ЭСФ, срок выписки — 5 рабочих дней. Отсутствие ЭСФ от поставщика — основание для снятия вычета при камеральной проверке ГНС.

Для облачных сервисов, включающих функции работы с виртуальными активами (стейблкоины, токены, криптовалюта), требуется отдельный анализ необходимости VASP-лицензии Финнадзора. Уставный капитал: 40 млн сомов для обменника, 100 млн сомов для криптобиржи. Срок получения лицензии — ориентировочно 1–3 месяца на практике. AML/KYC-политика: обязательна, Travel Rule применяется.

Практические рекомендации: минимальный набор документов для SaaS-поставщика из КР

Девять пунктов выше формируют требования к контентному наполнению контракта. На практике полный комплект документации SaaS-поставщика из КР включает несколько взаимосвязанных документов, каждый из которых решает свою задачу.

Основной договор (Master Services Agreement, MSA или Договор оказания услуг): регулирует общие условия — предмет, стороны, срок, применимое право, арбитражную оговорку, ограничение ответственности, конфиденциальность, расторжение. Объём: 8–15 страниц. Язык: русский для заказчиков из СНГ, английский для EU/US, двуязычный для смешанных случаев (с оговоркой о приоритете одной версии при противоречии).

Соглашение об уровне обслуживания (SLA): Приложение к MSA. Содержит метрики доступности, механизм Service Credit, исключения, порядок сообщения об инцидентах. Обновляется при изменении инфраструктуры без изменения MSA.

Соглашение об обработке данных (DPA): обязательно при работе с заказчиками из ЕС; рекомендуется для всех контрактов при обработке персональных данных пользователей. Включает SCС для передачи данных из ЕС в КР.

Политика допустимого использования (Acceptable Use Policy, AUP): публичный документ, ограничивающий использование платформы для незаконной деятельности. Защищает поставщика от ответственности за действия заказчика через платформу.

Для компаний, планирующих масштабирование и привлечение инвестиций, полный комплект контрактной документации — обязательное условие due diligence инвестора. По сложившейся практике венчурных инвесторов в регионе, отсутствие стандартизированной клиентской документации снижает оценку компании и затягивает сделку. Подробнее о структурировании ПВТ-резидентства и контрактных схемах — в обзоре IT-права и виртуальных активов в Кыргызстане и в материале об облачных сервисах из КР: налогообложение и контракты.

Сопутствующие вопросы налогообложения IT-доходов рассматриваются в материале «Единый налог для IT в КР: 4% нал, 2% безнал». Анализ трудовых отношений при удалённой работе — в разборе «Удалённая работа из Кыргызстана на российского работодателя: налоги». Полный каталог материалов по IT-праву доступен в разделе аналитики БЕКЕМ. Услуги по структурированию контрактов — на странице IT-право и виртуальные активы.