ФСБУ 9/2025 «Доходы» с 2027 года: каких данных о договоре не хватает в CRM и 1С

Что изменится в учёте выручки и почему бухгалтерии одной не справиться

С отчётности за 2027 год вступает в силу ФСБУ 9/2025 «Доходы», который заменит ПБУ 9/99 и ПБУ 2/2008 [1][2]. Возможно досрочное применение стандарта [1]. Стандарт вводит модель признания выручки, близкую к МСФО (IFRS) 15: выручку нужно признавать только при одновременном выполнении пяти условий, включая факт перехода контроля над продукцией к покупателю, а по длительным договорам — определять степень готовности на каждую отчётную дату [3]. Проблема в том, что информация о переходе контроля, этапах, скидках и изменениях цены в большинстве компаний рождается не в бухгалтерии, а в CRM и проектной системе — и сегодня туда, как правило, не «долетает» в нужном виде. Прежде чем настраивать проводки в 1С, стоит понять, какие данные о договоре вообще нужно начать собирать.

Статья будет полезна компаниям с долгосрочными договорами, подписками, комплексными поставками и услугами, а также бухгалтерии и финансовым службам, которым предстоит готовить переход на новый стандарт.

Почему это касается не только бухгалтерии

Обычно новые ФСБУ воспринимаются как задача бухгалтерии: поменять учётную политику, донастроить план счетов, обучить бухгалтеров. С ФСБУ 9/2025 этого недостаточно. Стандарт требует данных, которых в бухгалтерском учёте попросту нет и никогда не было, потому что они возникают на более раннем этапе — при заключении и исполнении договора.

Например, чтобы правильно признать выручку по длительному договору, бухгалтеру нужно знать не только сумму по акту, но и: перешёл ли контроль над результатом к заказчику на отчётную дату, можно ли объединить несколько договоров с одним контрагентом в один для целей учёта, какая скидка гарантированно положена клиенту, и изменялись ли цена или предмет сделки в процессе исполнения [3]. Ни один из этих фактов не появляется автоматически в проводке — их нужно зафиксировать там, где сделка живёт: в CRM у менеджера по продажам, в проектной или производственной системе, в самом договоре и допсоглашениях к нему.

Что меняет ФСБУ 9/2025 простыми словами

ФСБУ 9/2025 утверждён приказом Минфина от 16.05.2025 № 56н, зарегистрирован в Минюсте 08.08.2025 и обязателен к применению начиная с бухгалтерской (финансовой) отчётности за 2027 год; организация вправе начать применять его раньше [1][4]. С 1 января 2027 года утрачивают силу ПБУ 9/99 «Доходы организации» и ПБУ 2/2008 «Учёт договоров строительного подряда» — при этом принципы учёта строительных подрядов не исчезают, а интегрируются в общий порядок нового стандарта [1][5].

Пять условий признания выручки

Стандарт предписывает признавать выручку только тогда, когда одновременно выполняются условия: у компании есть право на получение выручки; к контрагенту перешёл контроль над предметом сделки; оплата получена или будет получена; величина выручки может быть определена; величина расходов по сделке может быть определена [3]. Для некоторых видов выручки (например, от предоставления прав на результаты интеллектуальной деятельности) состав условий немного отличается [3]. Одновременно с признанием выручки в учёте появляется дебиторская задолженность; если получена предоплата, но условия признания ещё не выполнены — это кредиторская задолженность, а не доход [3].

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

Группа договоров как единая сделка

Раньше объединение нескольких договоров в целях признания выручки было прямо предусмотрено только для договоров строительного подряда. Теперь это правило распространено на любые виды деятельности [3]. Два и более договора с одним контрагентом или связанными с ним сторонами можно (при выполнении ряда условий: единая коммерческая цель, взаимозависимость цены, фактически единая обязанность передать продукцию) считать для целей бухучёта единой сделкой [3]. Это значит, что бухгалтеру нужно знать не только каждый договор в отдельности, но и связи между договорами и контрагентами — информацию, которая обычно живёт в CRM в виде карточек компаний, групп контрагентов и связанных сделок.

Признание «по мере готовности»

Для договоров, исполнение которых растянуто дольше одного отчётного периода, стандарт предусматривает признание выручки по мере передачи контроля над продукцией — то есть по мере готовности [3]. Это применимо не только к строительству, а к любым поставкам, работам и услугам. Если договорный период не превышает 12 месяцев, компания может не усложнять учёт и признать выручку одномоментно по факту завершения отгрузки — это право, а не обязанность [3].

Степень готовности определяется одним из двух способов: по доле объёма продукции, контроль над которой уже перешёл к контрагенту, в общем объёме отгрузки; либо по доле фактически понесённых расходов в расчётной величине общих расходов по договору [3]. Выбранный способ должен последовательно применяться к аналогичным сделкам и не может меняться в течение срока исполнения конкретного договора [3].

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

Как теперь оценивается сумма выручки

Стандарт значительно детальнее прежнего ПБУ 9/99 описывает оценку выручки в зависимости от условий сделки: при скидках, отсрочке или рассрочке платежа, неденежных расчётах, изменении объёма или цены в процессе исполнения договора [3]. В частности: если договор предусматривает скидку, на которую контрагент имеет право, выручка признаётся уже с учётом этой скидки; если изменился объём отгрузки или цена — ранее признанная выручка подлежит единовременной корректировке; если же изменился предмет договора — ранее признанная сумма не пересматривается, а оставшаяся часть оценивается по новым условиям [3].

Для практики это означает: недостаточно знать итоговую сумму по договору — нужно понимать историю изменений договора и обоснованность каждой скидки, желательно с привязкой к дате и причине изменения.

Российская специфика: кому и как применять

Стандарт распространяется на все организации, кроме некоммерческих (для них действуют отдельные оговорки) и организаций государственного сектора [3]. Компании, составляющие консолидированную отчётность или отчётность по МСФО, должны руководствоваться непосредственно МСФО (IFRS) 15; организации, чья отчётность подлежит обязательному аудиту, могут выбирать между МСФО (IFRS) 15 и ФСБУ 9/2025 [3]. Разъяснения по стыковке норм ФСБУ 9/2025 с профильными стандартами и МСФО (IFRS) 15 Минфин дал в информационном сообщении от 11.09.2025 № ИС-учет-59 [6][5].

Для организаций, имеющих право на упрощённые способы ведения бухучёта, предусмотрен ряд послаблений: признавать выручку по факту получения оплаты, не дожидаясь перехода контроля; не применять метод «по мере готовности», даже если для него есть основания; не учитывать скидки при определении суммы выручки, признавая их расходом периода; не дисконтировать выручку при длительной отсрочке платежа; переходить на новый порядок перспективно, без пересчёта прошлых периодов [3]. Эти упрощения не обязательны — их применение фиксируется в учётной политике [3].

Здесь важна оговорка, которую нужно сделать честно: ФСБУ 9/2025 — это бухгалтерский стандарт, а не автоматическая смена правил налогового учёта. Какие упрощения применимы конкретной компании и какой порядок перехода выбрать — ретроспективный или упрощённый, — должен определить специалист по учётной политике, с учётом отраслевой специфики и структуры договоров.

Где рвётся цепочка данных: CRM → проект → 1С

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

1. Инвентаризация типов договоров

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

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

2. Данные о переходе контроля и этапах исполнения — что фиксировать и как хранить

CRM и проектная система обычно фиксируют статус сделки («в работе», «оплачено», «закрыто») и, в лучшем случае, этапы воронки продаж. Для ФСБУ 9/2025 этого недостаточно. Нужны данные именно о факте и дате перехода контроля над продукцией к заказчику — а это не всегда совпадает ни с датой оплаты, ни с датой закрытия сделки в CRM.

По длящимся услугам (охрана, консультирование, связь, обслуживание) момент, на который нужно ориентироваться при признании выручки, — это, как правило, окончание согласованного периода оказания услуг или подписания акта, а не факт поступления денег [7]. По договорам с материальным результатом (исследование, заключение, отчёт) ориентир — это принятие результата заказчиком, подтверждённое актом [7]. Значит, в CRM или проектной системе должна быть точная дата фактической передачи результата или подписания акта — а не только дата выставления счёта.

Хранить эти данные стоит не в свободном текстовом поле «комментарий к сделке», а в отдельных структурированных полях карточки договора или этапа: отдельное поле-дата для факта перехода контроля/приёмки; отдельное поле для степени готовности на отчётную дату; связь этого поля с конкретным первичным документом (актом, накладной, УПД), который подтверждает событие. Каждое изменение такого поля должно сохраняться как версия с датой и автором правки, а не перезаписываться — иначе при проверке нельзя будет восстановить, на основании чего и когда была признана выручка.

Для договоров, где применяется метод «по мере готовности», дополнительно нужны: степень готовности на отчётную дату (по объёму или по доле понесённых расходов), фактически понесённые расходы по договору на отчётную дату и плановая (расчётная) величина оставшихся расходов до завершения сделки [3]. Это данные проектной или производственной системы, которые сегодня в 1С обычно попадают только в виде итоговой себестоимости после закрытия этапа, а не в разрезе «на любую отчётную дату».

3. Скидки, изменения цены и связанные соглашения

ФСБУ 9/2025 требует учитывать скидку в сумме выручки только тогда, когда контрагент имеет право на её получение и величина скидки может быть определена [3]. Значит, условия предоставления скидки (объём закупки, срок оплаты, накопительный бонус) должны быть зафиксированы структурированно, а не в переписке или устной договорённости менеджера с клиентом — например, отдельным полем «условие скидки» и «дата, с которой право на скидку подтверждено», привязанным к конкретному договору.

То же касается любых изменений договора в процессе исполнения: если менялась цена или объём — это влияет на уже признанную выручку текущего периода; если менялся только предмет договора — ранее признанная сумма не трогается, а оставшаяся часть выручки оценивается по новым условиям [3]. Для бухгалтера это означает, что ему нужна история изменений договора с датами и причинами, а не только его последняя актуальная версия — то есть хранить нужно не финальный документ, а журнал версий договора с указанием, что именно изменилось в каждой редакции.

Отдельная категория — связанные соглашения и группы договоров. Если у компании есть практика заключать с одним клиентом несколько формально самостоятельных договоров с единой коммерческой целью, взаимозависимой ценой или фактически единой обязанностью передать результат [3], — CRM должна уметь показать эту связь: не просто список сделок клиента, а явную пометку «эти договоры образуют единую сделку для целей учёта выручки» с указанием критерия, по которому это определено.

4. Деньги vs событие, на основании которого признаётся доход

Один из самых частых источников ошибок — смешение движения денег и события признания дохода. По стандарту суммы авансов и предоплат по общему правилу не признаются доходом [3]; доход признаётся только при выполнении всех пяти условий, включая переход контроля [3]. Поэтому системе, которая передаёт данные в 1С, недостаточно передавать факт оплаты — нужно отдельно передавать факт перехода контроля/приёмки результата, и эти два события должны быть различимы в данных, а не слиты в одну дату «сделка закрыта».

Практический приём: в карточке договора или сделки должно быть минимум два независимых поля-даты — «дата оплаты» и «дата перехода контроля/приёмки» — и они не должны автоматически совпадать или подставляться друг из друга.

Что конкретно должно передаваться из CRM и проектной системы в 1С

Обобщая описанное выше, для корректной работы ФСБУ 9/2025 в CRM и проектной системе имеет смысл системно фиксировать и передавать вместе с первичными документами:

• тип договора и признак применяемого метода признания выручки (одномоментно / по мере готовности);
• дату и факт перехода контроля над продукцией (приёмка результата, подписание акта, отгрузка) — отдельно от даты оплаты;
• для длящихся договоров — степень готовности на отчётную дату и способ её определения (по объёму или по доле расходов), а также фактические и плановые расходы по договору;
• условия и суммы предоставленных или гарантированных скидок с привязкой к конкретному договору;
• историю изменений договора: что менялось — цена, объём или предмет, и дата изменения;
• признаки взаимосвязанности договоров с одним контрагентом или связанными сторонами (единая коммерческая цель, зависимость цены, единая по факту обязанность);
• условия оплаты неденежными средствами и отсрочки/рассрочки платежа, если они есть;
• ответственного за каждую единицу данных — то есть кто в компании подтверждает факт перехода контроля или степень готовности, чтобы это можно было проверить при аудите.

Это не техническое задание на интеграцию, а перечень содержательных данных, которые системе обмена нужно научиться передавать; конкретный формат обмена (API, файловый обмен, доработка справочников) — отдельный проектный вопрос, зависящий от используемых CRM и конфигурации 1С [9][10].

Карта недостающих договорных данных

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

Данные, нужные для ФСБУ 9/2025 Где должны рождаться Типичный статус сегодня Тип договора и метод признания выручки CRM / договорной модуль Обычно не выделено отдельным полем Дата и факт перехода контроля / приёмки результата CRM, проектная система, акт Часто подменяется датой оплаты или закрытия сделки Степень готовности на отчётную дату Проектная / производственная система Как правило, отсутствует между отчётными датами Фактические и плановые расходы по договору Проектная система, производственный учёт Есть в виде итоговой себестоимости, не в динамике Условия и факт права на скидку CRM, договор, допсоглашение Часто фиксируется устно или в переписке История изменений цены, объёма, предмета договора CRM / система документооборота Обычно хранится только последняя версия Признаки объединения договоров в группу CRM (карточка контрагента) Как правило, не отслеживается вовсе Условия неденежных расчётов, отсрочки, рассрочки Договор, CRM Фиксируется в договоре, но не выгружается в 1С Ответственный за подтверждение факта (готовность, приёмка) Регламент компании Обычно не назначен формально Эта таблица — не готовое техническое задание, а рабочий чек-лист: для конкретной компании нужно пройти по каждой строке применительно к своим типам договоров и отметить, что уже есть, а что предстоит выстроить.

Как подготовить и проверить новый алгоритм на контрольных данных

Практический план подготовки, не углубляясь в конкретные сроки и стоимость (они зависят от масштаба компании и числа типов договоров):

1. Инвентаризация договоров. Собрать реестр всех действующих типов договоров и выделить те, что подпадают под метод «по мере готовности», содержат условия скидок, потенциально образуют группу договоров.
2. Картирование источников данных. Для каждого типа договора определить, где сегодня физически фиксируется каждый нужный факт: в CRM, в проектной системе, в бумажном акте, в переписке — и выявить, где данных вообще нет. Здесь удобно опираться на карту недостающих данных выше.
3. Определение способов оценки готовности. Для длящихся договоров зафиксировать, каким способом будет определяться степень готовности (по объёму или по расходам), и закрепить это решение так, чтобы оно не менялось в течение исполнения конкретной сделки [3].
4. Формирование тестовых примеров. Взять несколько реальных сложных договоров (с этапами, со скидками, с изменением условий) и вручную прогнать их через новый алгоритм признания выручки, чтобы увидеть, каких данных не хватает на практике.
5. Донастройка обмена данными. По результатам теста определить минимальный набор полей, которые CRM/проектная система должны передавать в 1С вместе с первичными документами, и решить, достаточно ли для этого доработки справочников и регламентного обмена или нужна отдельная интеграция.
6. Контрольный прогон на реальных данных за прошлый период. Прежде чем переходить на новый порядок, стоит пересчитать выручку по нескольким закрытым договорам старым и новым способом и сверить расхождения — это поможет оценить масштаб корректировок при переходе.

Как зафиксировать решения в учётной политике

Стандарт прямо требует раскрывать выбранный способ перехода к применению ФСБУ 9/2025 и его последствия начиная с первой бухгалтерской отчётности, составленной по новому стандарту [3]. Кроме того, в пояснениях к отчётности нужно детализировать способы и допущения, применённые для признания выручки: используется ли метод «по мере готовности», как определяется степень готовности, как оценивается скидка [3]. Это значит, что помимо технических настроек в CRM и 1С компании нужно письменно зафиксировать:

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

Ограничения, ошибки и риски

• Подмена события оплатой. Самая частая ошибка — признавать выручку по факту поступления денег, а не по факту перехода контроля. Это допустимо только при использовании упрощённых способов ведения бухучёта и то при выполнении дополнительных условий [3].
• Отсутствие фиксации степени готовности. Если у компании нет процедуры и данных для определения степени готовности, применять метод «по мере готовности» нельзя — стандарт прямо связывает право на этот метод с наличием такой информации [3].
• Устная договорённость о скидке. Если скидка не зафиксирована в договоре или дополнительном соглашении и её размер нельзя достоверно определить, выручка признаётся без учёта скидки — со всеми последствиями для расхождения плановых и фактических показателей [3].
• Несогласованность договора, акта и внутренних документов. Отдельная практика показывает, что при проверках важно, чтобы формулировки в договоре, техзадании, акте и отчёте были согласованы между собой и прослеживалась цепочка от инициирующего документа до подтверждения результата [8] — это касается не только налоговых, но и бухгалтерских рисков признания дохода.
• Игнорирование связанных договоров. Если менеджеры оформляют с одним клиентом несколько формально самостоятельных договоров, а CRM не хранит эту связь, компания рискует признавать выручку по каждому договору отдельно там, где стандарт требует признания по группе [3].
• Отсутствие готовых типовых решений. Подтверждённых сведений о типовых конфигурациях 1С с готовой поддержкой метода «по мере готовности» именно по ФСБУ 9/2025 в открытых источниках найти не удалось — на момент подготовки статьи это, вероятнее всего, потребует индивидуальной настройки счетов и документов, как это уже происходило при переходе на ПБУ 2/2008 для подрядных организаций.

Когда достаточно донастройки, а когда нужна интеграция или доработка

Если у компании немного типов договоров, а объём сделок небольшой, для перехода на ФСБУ 9/2025 может быть достаточно донастроить внутренние регламенты: обязать менеджеров и руководителей проектов фиксировать нужные факты в существующих полях CRM или в отдельной учётной таблице, без изменения ИТ-архитектуры [11]. Ручной ввод данных при небольшом потоке договоров — рабочий и оправданный вариант, который не требует затрат на интеграцию [11].

Если же договоров много, они разнотипны, есть длящиеся и групповые сделки, а данные уже сегодня теряются при передаче между отделом продаж, проектной командой и бухгалтерией, — обмен данными, скорее всего, придётся выстраивать системно: через доработку полей и процессов CRM, регламентный обмен файлами или API-интеграцию с 1С, в зависимости от используемых систем [9][10][11]. Здесь важно заранее определить, какие данные обязательны для передачи, а какие избыточны, чтобы не перегружать канал обмена и не дублировать информацию [11].

Вывод

ФСБУ 9/2025 меняет не проводки сами по себе, а то, какие факты о договоре нужно фиксировать и когда. Пять условий признания выручки, метод «по мере готовности», правила учёта скидок и групп договоров требуют данных, которые сегодня в большинстве компаний хранятся разрозненно — в головах менеджеров, в переписке, в проектных таблицах, но не в структурированном виде между CRM и 1С. До обязательного перехода в 2027 году имеет смысл провести инвентаризацию договоров по карте недостающих данных, картирование источников информации и тестовый прогон нового алгоритма на реальных сложных договорах — это позволит понять реальный объём доработок задолго до сдачи первой отчётности по новому стандарту.

Источники

[1] garant.ru — Приказ Минфина России от 16.05.2025 № 56н — https://www.garant.ru/products/ipo/prime/doc/412362456/

[2] audit-it.ru — Приказ Минфина России от 16.05.2025 N 56н — https://www.audit-it.ru/law/account/1121777.html

[3] buhexpert8.ru — ФСБУ 9/2025 «Доходы». Раз, два, три, четыре, пять, начинаем применять! — https://buhexpert8.ru/zkn-bu/fsbu-pbu-buhuchet/fsbu-9-2025-dohody-raz-dva-tri-chetyre-pyat-nachinaem-primenyat.html

[4] consultant.ru — Утвержден ФСБУ 9/2025 «Доходы» — https://www.consultant.ru/law/hotdocs/90418.html

[5] astral.ru — Минфин пояснил, как применять ФСБУ 9/2025 «Доходы» — https://astral.ru/aj/elem/minfin-opublikoval-kommentarii-po-pravilam-primeneniya-fsbu/

[6] consultant.ru — ФСБУ 9/2025 «Доходы»: Минфин перечислил основные новшества — https://www.consultant.ru/legalnews/29486/

[7] glavkniga.ru — Длящиеся услуги: когда исполнителю признать доход, а заказчику — расход — https://glavkniga.ru/elver/2013/7/588

[8] glavkniga.ru — Учет маркетинговых расходов — https://glavkniga.ru/elver/2023/9/6469

[9] intervolga.ru — Интеграция 1С с CRM — https://www.intervolga.ru/1c/1c-integratsiya-s-crm/

[10] 42clouds.com — Интеграция 1С и CRM: возможности и преимущества — https://42clouds.com/ru-ru/blog/advices/integracziya-1s-s-populyarnymi-crm-sistemami-vozmozhnosti-i-preimushhestva/

[11] envybox.io — Интеграция CRM и 1С: возможности обновленной системы — https://envybox.io/blog/integracija-crm-s-1s/