Особенности бюджетного планирования. 26. 5

Особенности бюджетного планирования в одном американском стартапе.
Содержание - http://proza.ru/2026/08/21/1876
---

Глава 26 с половиной

в которой я пишу про НДС

В процессе формирования регламента составления Бюджетных Отчётов люди иногда сталкиваются с техническими мелочами. В теории они выглядят пустяками. На практике одна такая мелочь может засорить весь план-факт. Один из таких случаев - учёт косвенных налогов.

Название главы не вполне точно. В Канаде стартап мог иметь дело с GST - федеральным налогом на товары и услуги - или с HST, его объединённой федерально-провинциальной формой. В Австралии тоже действует GST. В странах Евросоюза это VAT, или налог на добавленную стоимость. В США компания чаще сталкивается с налогами с продаж, которые различаются по штатам и муниципалитетам.

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

При возмещаемом НДС или GST часть платежа похожа на деньги, покинувшие компанию только временно. Поставщику их нужно заплатить сейчас, поэтому банк видит всю сумму. Но при налоговом расчёте компания может вычесть эту часть из налога, собранного с продаж, или заявить её к возврату. Для банка это деньги. Для проекта - не обязательно окончательный расход. Для налогового учёта - часть будущего расчёта с государством.

При планировании бюджета менеджер указывает сумму, которая, по его мнению, покинет счёт компании. Он знает, что нужно провести тестирование продукта, но ещё не знает, произойдёт ли оно в родной североамериканщине или во враждебной Австралии. От места, статуса поставщика и вида услуги будет зависеть налоговая судьба платежа. Менеджер обычно этого не знает. Он знает другое: для теста нужно примерно 120 долларов.

Требовать, чтобы он заранее разложил эти 120 долларов на стоимость услуги и налог, - хороший способ заменить бюджет массовым экзаменом по косвенному налогообложению. Экзамен будет провален. Менеджеры будут следовать простому указанию: сколько денег и когда должно уйти, а сколько прийти. Остальное они поручат финансовому директору, пусть он сам рушит мозг за этот НДС.

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

Проблема возникает позже, когда счёт уже оплачен. Предположим, компания запланировала выплату 120 долларов и фактически заплатила 125. На банковском счёте всё очевидно: денег ушло на 5 долларов больше. Но бухгалтерская система делит платёж на две части. При условной ставке 20 процентов платёж 125 распадается на 104,17 стоимости и 20,83 налога.

Если сравнить плановую выплату 120, включающую налог, с фактической стоимостью 104,17 без возмещаемого налога, отчёт покажет мнимую экономию 15,83. Цифры посчитаны правильно, а ответ ложен. План содержит налог, факт не содержит. Отчёт сравнил две разные вещи только потому, что обе выражены в долларах.

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

Плановые 120 долларов при той же условной ставке состоят из 100 долларов чистой стоимости и 20 долларов налога. Теперь можно сделать три сопоставимых сравнения.

Денежный план: 120.
Денежный факт: 125.
Отклонение: 5 долларов перерасхода.

Чистая стоимость по плану: 100.
Чистая стоимость по факту: 104,17.
Отклонение: 4,17 доллара перерасхода.

Налог по плану: 20.
Налог по факту: 20,83.
Разница: 0,83.

Первое сравнение нужно для кассового плана. Второе - для оценки стоимости проекта. Третье - для налогового расчёта и прогноза срока, в котором налог будет зачтён, возвращён или уплачен. Разницы 4,17 и 0,83 вместе объясняют весь денежный перерасход в 5 долларов, но отвечают за разные его части.

У одной операции появляются три правдивых числа. Проблема начинается не из-за их множества, а когда отчёт забывает сообщить, на какой вопрос отвечает каждое. Руководитель видит 125 и спрашивает: «Сколько денег ушло?» Руководитель проекта видит 104,17 и спрашивает: «Сколько стоила работа?» Бухгалтер видит 20,83 и спрашивает: «Что случится с этой частью при расчёте с бюджетом?» Ни один из них не ошибается. Они смотрят на одно событие из разных частей компании.

Тут нужна оговорка. Входной налог - НДС, GST или HST, начисленный поставщиком при покупке, - не всегда можно вернуть или зачесть. Право на зачёт зависит от статуса компании, назначения покупки, документов, вида деятельности и местных правил. Если налог не возмещается, он может стать частью стоимости. В системе налога с продаж может вообще не быть того же механизма зачёта, как в НДС. Поэтому компании нужно не единое правило «везде убрать 20 процентов», а набор правил по юрисдикциям и типам операций.

В трансграничной операции даже вопрос «кто начислит налог» не всегда имеет очевидный ответ. Его может начислить поставщик. При reverse charge - механизме обратного начисления - налоговое обязательство переходит к покупателю: он сам отражает налог в своём учёте, а не платит его поставщику в составе счёта. Место налогообложения может зависеть от того, где находятся товар, покупатель или место оказания услуги. Поэтому указание страны в бюджетной записи - не декорация. Оно помогает системе понять, какое правило применить.

Вернёмся к одному счёту на 125 долларов. Если вся эта сумма уже стоит в проектном кассовом плане, добавлять туда ещё 20,83 как отдельный «резерв по НДС» нельзя. Один и тот же налог дважды снизит остаток. Отдельно нужно планировать не вторую оплату того же счёта, а будущий расчёт с налоговым органом: платёж, возврат или зачёт. Он может произойти в другом месяце и должен иметь собственную дату.

Значит ли это, что менеджеру всё-таки придётся выучить налоговый кодекс Австралии? Нет. Он может вносить ту сумму, которую ожидает увидеть в банке. Но рядом с ней должны стоять несколько полей: страна или территория, вид покупки, включён ли налог в сумму и насколько уверен в этом автор плана. Если место пока неизвестно, так и надо записать. Неизвестность лучше выделить в отдельное поле, чем прятать внутри завышенной суммы.

После этого компьютер может выполнить те самые суперсложные операции сложения и вычитания. Он покажет ожидаемую валовую выплату в кассовом плане, чистую стоимость в план-факте проекта и налоговую часть в расчёте с бюджетом. После оплаты плановая запись и факт должны быть связаны с банковской операцией и налоговой проводкой. Тогда один платёж не превратится в три несвязанные истории.

Менеджеру не нужно знать всю налоговую логику. Он может заполнить одну понятную строку, а система покажет её в трёх связанных видах: как движение денег, как стоимость проекта и как расчёт с государством. Удобство ввода при этом не портит отчёты, потому что сложность убрали из поля зрения человека, а не из самой модели.