Тема учета компьютерных игр почти всегда вызывает путаницу, потому что под словом «игра» на практике скрываются совершенно разные хозяйственные ситуации. В одном случае организация просто перепродает коробочные версии, ключи или цифровые экземпляры. В другом случае компания сама разрабатывает игру и затем зарабатывает на лицензиях, подписке, внутриигровых покупках или издательских договорах. В третьем случае студия делает игру по заказу конкретного клиента, а значит, по сути оказывает услуги разработки.
Именно из-за этого в обсуждениях на профильных форумах обычно спорят не о том, на каком счете вести игры вообще, а о том, какую экономическую сущность имеет конкретная операция. Рассмотрим подробнее, как правильно подойти к задаче, чтобы не смешивать товарный учет, учет нематериальных активов и учет затрат на разработку.
Разберем по шагам основную логику. Сначала определим, что именно делает организация:
Только после этого имеет смысл выбирать счета, документы и объекты в 1С. Если начать наоборот — например, сразу пытаться посадить «игру» на 41, 04 или 08.05 без анализа сути операции, — почти наверняка получится ошибочная схема.
Начнем с самого простого сценария. Если организация покупает готовые экземпляры игр, цифровые ключи, коробочные поставки или иные единицы для дальнейшей перепродажи, то по своей учетной логике это ближе всего к обычному товару. В такой ситуации нам важно не техническое название продукта, а факт того, что компания не создает игру сама, а получает готовый объект и реализует его покупателю.
На профильных форумах именно этот вариант часто советуют как базовый для внутреннего оперативного учета: купили за одну сумму, продали за другую, получили понятную валовую прибыль по каждой позиции. Такой подход особенно удобен, когда нужно контролировать остатки, закупочные цены, наценку, оборачиваемость и продажи по площадкам.
В 1С при таком варианте удобно использовать стандартный товарный контур:
Номенклатура;ХарактеристикиНоменклатуры для платформы, региона, издания, языка или типа поставки;СериямНоменклатуры;Поступление (акты, накладные, УПД) или товарным документом в вашей конфигурации;Реализация (акты, накладные, УПД) или аналогичным документом продажи;Если вы работаете в 1С:Бухгалтерии, то логика обычно строится вокруг счета 41 для товаров и счета 90 для продажи. Если вы используете 1С:УНФ, 1С:УТ или ERP, то основной акцент смещается в сторону управленческого и складского учета: номенклатура, склады, партии, цены, продажи, аналитика по каналам реализации.
Посмотрим на пример. Допустим, компания закупает цифровые ключи игры для ПК у дистрибьютора и продает их через интернет-магазин. В такой модели нам удобно учитывать каждый ключ как товарную единицу либо как партию товара. Тогда мы видим:
Здесь важный практический момент: не путайте товарный учет с правовой квалификацией операции. В реальных обсуждениях по 1С часто спорят, что является объектом реализации — экземпляр программы как товар или право использования программы по лицензионной модели. Для бухгалтера и пользователя 1С это означает следующее: смотрите не на название «компьютерная игра», а на комплект документов и договор. Если поставка оформлена как обычная перепродажа экземпляров, товарная схема в 1С обычно наиболее понятна. Если же речь идет именно о передаче прав по лицензионному или сублицензионному договору, схема учета может стать другой.
Разберем, как не ошибиться на практике.
Используйте товарный учет, если одновременно выполняются следующие признаки:
При этом для аналитики в 1С полезно заранее продумать структуру карточки товара. Например, можно завести отдельные реквизиты или характеристики:
Это не только делает каталог удобнее, но и позволяет строить полезные отчеты без доработок: по платформам, по издателям, по цифровым и физическим поставкам, по маржинальности каждой группы. Рассмотрим подробнее: если в одной карточке смешать все версии одной игры, потом будет трудно понять, что именно продается лучше — ПК-ключи или консольные коробки. Поэтому лучше изначально разносить позиции на отдельные номенклатурные единицы или характеристики.
Если учет ведется в 1С с интеграцией с сайтом, маркетплейсом или онлайн-кассой, товарная модель особенно удобна. Стандартные механизмы 1С проще связывать именно с Номенклатура, чем с объектами права или капитальными вложениями.
Теперь разберем другую ситуацию. Компания сама разрабатывает игру, владеет правами на нее и рассчитывает получать экономические выгоды в течение длительного срока: продавать лицензии, получать роялти, монетизировать игру через площадки, внутриигровые покупки, подписку, рекламу или издательские соглашения. В этом случае игра уже не выглядит как обычный товар. Она становится результатом интеллектуальной деятельности, и тогда нужно анализировать учет как нематериального актива.
С 2024 года для бухгалтерского учета ключевую роль играет ФСБУ 14/2022. На практике это означает, что права на программу для ЭВМ, в том числе на игру, могут учитываться как НМА, если выполняются критерии признания актива. Иными словами, нам недостаточно просто сказать «мы делаем игру». Нужно проверить, есть ли у организации:
Если эти признаки выполняются, логика обычно такая: сначала собираем затраты на создание игры, а после готовности к использованию принимаем объект к учету как НМА.
В 1С для этого обычно задействуются такие счета и объекты:
08.05 — капитальные вложения в НМА, если мы накапливаем затраты на создание;04 — нематериальные активы, когда игра уже принята к учету как готовый объект;05 — амортизация НМА, если по учетной политике она начисляется;НематериальныеАктивы или аналогичный справочник объекта права в типовой конфигурации;Принятие к учету НМА — документ, которым оформляется ввод объекта в эксплуатацию;Закрытие месяца — механизм, который выполняет регламентные операции, в том числе начисление амортизации или списание расходов по правилам конфигурации.Разберем по шагам, как выстроить учет в 1С, если игра создается собственными силами.
08.05 до момента, когда игра станет готова к использованию по назначению.Принятие к учету НМА и переведите сумму на счет 04.Выясним причину, почему здесь нельзя сразу все списывать в расходы периода. Пока игра находится в разработке и еще не готова приносить выгоду, затраты формируют стоимость создаваемого актива. Если же сразу отправить их на 20, 26 или 44, мы потеряем связь между вложениями и созданным результатом. Для студии разработки это особенно критично: несколько месяцев или лет расходов пройдут через отчетность как текущие затраты, а сам созданный объект нигде не будет отражен.
Посмотрим на типичную ошибку. Студия делает собственную игру два года, ежемесячно платит команде, заказывает музыку, сценарии и тестирование, но всю зарплату и подрядчиков списывает на общехозяйственные расходы. Формально расходы отражены, но экономическая картина искажена: баланс не показывает созданный актив, а отчет о финансовых результатах перегружен затратами периода. Если игра действительно принадлежит студии и будет приносить выгоду дальше, такая схема обычно выглядит слабой.
При этом важно понимать и обратное: не всякая игра автоматически становится НМА. Если проект закрыт, не завершен, не доведен до состояния готовности, не дает контроля над будущими выгодами или невозможно надежно выделить затраты, то признание НМА может быть преждевременным. Поэтому сначала анализируем документы, права, стадию готовности и учетную политику, а уже затем принимаем объект на 04.
Теперь разберем тонкий, но очень важный нюанс. В обсуждениях по этой теме часто смешивают игру как актив компании и игру как результат производства для продажи. А это не одно и то же.
Если организация разрабатывает программный продукт именно для дальнейшей реализации как результата своей деятельности, то в профессиональных разъяснениях часто подчеркивается: программы для продажи не всегда относятся к НМА. Иными словами, если компания по сути производит программный продукт как коммерческий выпуск, нужно отдельно анализировать, не ближе ли эта ситуация к готовой продукции, незавершенному производству или выполнению работ.
Рассмотрим подробнее два подварианта.
Первый подвариант: компания делает игру по договору для конкретного заказчика. Тогда по смыслу хозяйственной операции она оказывает услуги разработки или выполняет работы. В этом случае основным объектом учета становится не НМА компании, а затраты по заказу и последующая выручка по договору.
Здесь логика учета обычно такая:
В 1С для этого чаще используются производственные или затратные счета, а также аналитики по заказам, проектам, номенклатурным группам и статьям затрат. В зависимости от конфигурации это могут быть:
20 — основное производство;23 — вспомогательные производства, если это предусмотрено схемой учета;25 и 26 — косвенные и общехозяйственные расходы;90.01 и 90.02 — выручка и себестоимость;НоменклатурныеГруппы — для раздельного учета направлений деятельности;СтатьиЗатрат — для настройки правил включения расходов в себестоимость;Заказы, Проекты или аналогичные объекты — если конфигурация поддерживает проектный контур.Второй подвариант: студия делает игру для массовой продажи как свой коммерческий продукт. Здесь нужно особенно внимательно зафиксировать учетную модель в учетной политике и внутренних регламентах. Если игра создается как результат производства для дальнейшей реализации, часть специалистов рассматривает такую ситуацию не как классический НМА для собственного использования, а как продукт, близкий к готовой продукции. На практике выбор модели зависит от того, что именно компания продает: экземпляры, доступ, услуги, лицензии, исключительные права или смешанную модель монетизации.
Поэтому в спорных случаях разумно не пытаться найти «универсальный счет для игр», а описать конкретный бизнес-процесс:
Именно после этого становится понятно, нужно ли накапливать затраты на 08.05, вести производство через 20 либо использовать товарный контур.
Самая сложная часть темы начинается там, где в вопросе звучит формулировка вроде: «игры постоянно дорабатываются, добавляются новые уровни, исправляются ошибки». Это типичная ситуация для современных проектов. И здесь нельзя все последующие расходы автоматически учитывать одинаково.
Проанализируем ситуацию. После выпуска игры возможны как минимум три типа расходов:
И вот тут действует практическое правило: не всякая доработка увеличивает стоимость актива. Если расходы связаны только с поддержанием игры в рабочем состоянии, устранением дефектов и текущим сопровождением, их чаще рассматривают как расходы периода. А если доработка создает новый самостоятельный функционал и увеличивает экономические выгоды, появляется аргумент в пользу капитализации таких затрат.
Разберем по шагам.
Когда безопаснее списывать расходы периода:
Когда можно рассматривать капитализацию затрат:
В 1С такую логику удобно организовать через раздельные статьи затрат. Например, можно завести:
Такой подход помогает не спорить задним числом, почему одни суммы ушли в расходы, а другие попали в стоимость актива. Все решается заранее настройкой аналитики и правилами классификации затрат.
Посмотрим на практический пример.
Студия выпустила игру и через полгода делает:
В этой ситуации логично рассматривать первые два блока как текущие расходы периода, а третий — как самостоятельный объект затрат, который может повлиять на стоимость нематериального актива или учитываться как отдельный результат в зависимости от учетной модели компании. Главное — не сваливать все в одну общую статью «доработка игры».
Даже если теоретическая модель выбрана правильно, на практике все часто ломается из-за слабой аналитики. Когда студия ведет несколько игр одновременно, а еще параллельно выпускает патчи, DLC, мобильную версию и порт на консоли, без проектного разреза учет становится непрозрачным. Тогда невозможно ответить на самые важные вопросы:
Поэтому в 1С стоит заранее построить аналитическую модель. В зависимости от конфигурации используйте:
Подразделения — если есть отдельные команды по проектам;СтатьиЗатрат — для разделения разработки, тестирования, дизайна, музыки, локализации, поддержки;НоменклатурныеГруппы — для учета выручки и себестоимости по направлениям;Проекты или аналоги — если они доступны в конфигурации;Договоры и Контрагенты — для подрядчиков, издателей и заказчиков;СпособыОтраженияЗарплаты — чтобы зарплата команды попадала в нужный проектный контур;РегламентныеЗадания и Закрытие месяца — для корректного распределения и списания затрат.Рассмотрим полезный принцип настройки: одна игра — один проектный центр аналитики. Не обязательно называть его именно проектом. Это может быть номенклатурная группа, отдельная статья, заказ на производство, направление деятельности или комбинация нескольких аналитик. Но по итогам месяца вы должны получить ответ: «Вот все затраты по игре А, вот по игре Б, вот по мобильному порту, вот по DLC».
Если не сделать этого с самого начала, потом приходится вручную восстанавливать данные по зарплате, подрядчикам и услугам. А это уже не решение, а дорогостоящий разбор последствий.
Теперь соберем практическую часть именно в терминах типовой 1С:Бухгалтерии 8. Пользователю обычно нужно не только понять теорию, но и увидеть, какими документами оформлять операции.
Если игры учитываются как товар:
Поступление (акты, накладные, УПД) — для закупки;Реализация (акты, накладные, УПД) — для продажи;Списание с расчетного счета и Поступление на расчетный счет — для оплаты;Если игра создается как НМА собственными силами:
Принятие к учету НМА — для ввода готовой игры в состав НМА;Закрытие месяца — для начисления амортизации и регламентных операций.Если игра разрабатывается по заказу клиента как работа или услуга:
Если конфигурация поддерживает расширенный учет прав на программные продукты, можно использовать специальные объекты и карточки прав. В новых версиях методических материалов 1С также активно фигурируют объекты учета прав и счет 76.18 для операций, связанных с правами на результаты интеллектуальной деятельности. Но важно понимать: этот счет чаще всплывает в вопросах приобретения лицензий на использование ПО, а не обязательно в учете собственной разработки игры для продажи. Поэтому не переносите механически одну методику на другую ситуацию.
Выясним причину частой ошибки. Пользователь находит статью о том, как учитывать приобретенную лицензию на стороннюю программу в 1С, видит там 76.18 и пытается по той же схеме вести собственную игру, которую компания сама разрабатывает и монетизирует. Это неверно, потому что экономическая природа операций разная: в одном случае компания покупает право у другого лица, в другом — создает собственный объект.
Это, пожалуй, главный вывод по теме. Формулировка «как вести учет компьютерных игр» звучит просто, но на самом деле в ней скрыто несколько разных вопросов:
Поэтому правильный ответ обычно начинается не со счета, а с диагностики бизнес-модели. Рассмотрим удобный алгоритм принятия решения.
Если кратко свести все варианты к одной таблице решений в текстовом виде, получится такая логика:
Посмотрим на наиболее типичный сценарий из подобных вопросов. Организация занимается компьютерными играми, игры постоянно обновляются, добавляются новые уровни, исправляются ошибки, проект живет долго и приносит доход. В такой ситуации обычно недостаточно простого ответа «ведем на счете 41» или «ставим на 04». Правильнее сделать так:
Если же компания просто покупает и перепродает игровые ключи, не нужно усложнять схему НМА. В такой модели лучше использовать обычный товарный контур и не превращать торговую задачу в учет интеллектуальных прав без необходимости.
То есть универсальное решение звучит так: ведите учет не по названию объекта «компьютерная игра», а по экономической сути операции. Это самый надежный способ избежать путаницы и в бухгалтерии, и в настройке 1С.
Информация носит справочный характер.