Пример вымышленный. Компания, люди и суммы придуманы для иллюстрации, совпадения случайны.
Владелец компании пришёл с вопросом: почему расходы на разработку не уменьшают налог на прибыль, хотя деньги потрачены реальные. Оказалось, зарплаты программистов попали в стоимость нематериального актива, а не в текущие расходы. Разбираем, как нашли причину и что исправили.
С чем пришёл владелец
Компания разрабатывает программное обеспечение на заказ. Владелец заметил, что по итогам года налог на прибыль вышел заметно больше, чем он ожидал по своей же таблице доходов и расходов. Бухгалтер объяснила это тем, что часть затрат «сидит в активе» и списывается постепенно.
Владелец не бухгалтер, поэтому формулировка его не убедила. Он попросил разобраться: почему живые деньги, ушедшие на зарплаты команде, не уменьшают налог сразу. Отдельно его смущало, что часть сотрудников делала доработки для клиентов, а часть — внутренний продукт, и в учёте всё это выглядело одинаково.
Ещё один повод для беспокойства — предстоящая проверка. Владелец хотел заранее понять, есть ли в учёте ошибка, и если да, то исправить её самому, а не ждать вопросов.
Как нашли причину
Начали с учётной политики. В ней было записано, что затраты на создание программного обеспечения признаются нематериальным активом. Формулировка широкая, без разграничения: относится она к продукту, который компания будет использовать сама, или к работам по договорам с заказчиками.
Дальше посмотрели, как это правило применяется на практике. Сверили договоры с заказчиками, акты сдачи-приёмки, технические задания и табели сотрудников. Картина стала понятной: значительная часть работ выполнялась по конкретным договорам, результат передавался клиенту и оплачивался им. Такие затраты — это расходы по обычной деятельности, а не создание актива для себя.
Отдельно проверили, что именно попало в стоимость актива. В неё включили зарплату всей команды за период, включая разработчиков, занятых на клиентских проектах, а также часть административных расходов. Сверили начисления по расчётным ведомостям с распределением по проектам — совпадения не было.
Последний шаг — сверка налоговых регистров с бухгалтерскими. В регистрах сумма расходов по разработке оказалась меньше, чем в бухучёте, ровно на величину, «осевшую» в активе. Это подтвердило, что дело не в арифметике, а в классификации затрат.
Что исправили по шагам
Сначала переписали учётную политику. В ней разделили два случая: создание программного продукта для собственных нужд и работы по договорам с заказчиками. Для второго случая прямо указали, что затраты признаются расходами по мере выполнения работ, а не формируют актив.
Затем восстановили картину по каждому проекту. По табелям и техническим заданиям определили, сколько времени сотрудники тратили на клиентские работы, а сколько — на внутренний продукт. Это позволило разделить зарплаты и начисления между двумя направлениями.
После этого пересчитали стоимость актива. Из неё убрали всё, что относилось к клиентским договорам, и оставили только затраты на собственный продукт. Суммы получились существенные: речь шла о нескольких миллионах рублей, ошибочно осевших в активе.
Далее оформили исправления в учёте. Сделали корректирующие проводки, обновили регистры и подготовили уточнённую отчётность за прошлый период. Параллельно проверили, не потянула ли ошибка за собой другие расчёты, и убедились, что смежные показатели не пострадали.
В конце зафиксировали порядок на будущее. Ввели правило: перед тем как отнести затраты на разработку в актив, бухгалтер сверяет основание — собственный продукт или договор с заказчиком. Без этой сверки проводка не делается.
Что изменилось для бизнеса
Расходы на клиентские разработки вернулись в текущие, и налоговая база уменьшилась на их величину. У компании появилась переплата, которую можно зачесть или вернуть в установленном порядке. Точные суммы зависят от периода и решения налогового органа, поэтому обещать конкретный результат заранее нельзя.
Владелец получил понятную картину: теперь он видит, какая часть затрат уменьшает налог сразу, а какая растянута во времени. Это помогло планировать платежи и не удивляться расхождениям между своей таблицей и отчётностью.
Отдельный эффект — снижение риска при проверке. Ошибка была найдена и исправлена самостоятельно, документы приведены в порядок, у каждой суммы есть основание. Спорить с инспектором о классификации затрат, когда всё разложено по полочкам, заметно проще.
Наконец, изменился сам подход к учёту разработки. Раньше затраты собирали «в общий котёл», теперь их делят по направлениям с самого начала. Это занимает немного больше времени, но избавляет от пересчётов задним числом.
Чему научиться другим
Первое: широкая формулировка в учётной политике — частая причина ошибок. Если правило не различает собственный продукт и работы для клиентов, бухгалтер будет применять его как получится. Проверьте свои формулировки и убедитесь, что они описывают реальные ситуации.
Второе: зарплата команды редко бывает однородной. Люди переключаются между проектами, и относить всю зарплату в одну категорию нельзя. Нужны табели, задания и понятное распределение времени — иначе разделить затраты будет нечем.
Третье: сверка бухгалтерских и налоговых регистров — простой способ заметить проблему. Расхождение на ровном месте почти всегда означает ошибку в классификации, а не в арифметике.
Четвёртое: исправлять ошибку лучше самому. Это не отменяет вопросов проверяющих, но даёт вам инициативу и понятную историю: что было не так, почему и что сделано.
Частые вопросы
Чем опасна ошибка с капитализацией зарплат?
Затраты, которые должны были уменьшить налог сразу, «зависают» в активе и списываются годами. Компания платит налог больше, чем должна, а при проверке к этому добавляются вопросы о классификации расходов.
Как понять, что у нас та же проблема?
Посмотрите учётную политику: различает ли она разработку для себя и работы по договорам с заказчиками. Затем сверьте налоговые регистры с бухучётом — расхождение по затратам на разработку будет заметно.
Можно ли исправить ошибку за прошлые периоды?
Да, для этого делают корректирующие проводки и готовят уточнённую отчётность. Порядок зависит от периода и существенности ошибки, поэтому лучше сначала восстановить документы по проектам.
Нужно ли менять учётную политику после исправления?
Да, иначе ошибка повторится в следующем периоде. В политике стоит прямо описать, какие затраты формируют актив, а какие признаются расходами текущего периода.
Услуга по теме: Комплексное ведение учёта на ОСНО, УСН «доходы», УСН «доходы минус расходы».