Отслеживайте затраты по проектам, клиентам и местам возникновения затрат без плана счетов на 400 счетов

Вы открываете книги, чтобы ответить на простейший вопрос в бизнесе — действительно ли этот проект принёс прибыль? — и обнаруживаете план счетов из 300 строк. Там есть «Командировки», «Командировки — Клиент А», «Командировки, запуск в Сиднее (старое)» и «Прочие расходы 2», которые каким-то образом стали одной из ваших крупнейших статей. Ответ где-то там, погребённый под тремя днями хирургии в электронных таблицах и сноской, в которую никто не верит.

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

Это руководство объясняет единственное правило, которое сохраняет книги пригодными для анализа, как тегирование работает на практике в распространённых бухгалтерских инструментах и как распределять общие затраты по проектам, не теряя нить повествования.

Почему ваш план счетов продолжает разрастаться​

Раздувание списка счетов следует предсказуемому шаблону. Начинается всё невинно: вы получаете крупного клиента и создаёте «Доход от консалтинга — Клиент А», чтобы видеть, сколько он приносит. Затем «Командировки — Клиент А», чтобы сопоставить затраты. Затем второй клиент, грант, выставка, переезд офиса — каждый получает свои счета. Пять лет спустя у вас сотни счетов по три транзакции на каждом, и никто не помнит, чем были «Расходы на мероприятия 2023B».

Следите за этими тревожными признаками того, что дизайн провалился:

• Измерения, спрятанные в названиях счетов. «Командировки, Сидней, Проект Falcon» — это три факта, втиснутых в одну метку. Вы не сможете просуммировать командировки по проектам или Проект Falcon по типам расходов без парсинга строк и молитв. Локация, проект и подразделение — это измерения, им не место в названии счёта.
• Разовые счета для разовых событий. Новый счёт для каждой выставки, каждого гранта, каждого переезда офиса. Кардинальность взрывается, отчёты множатся, а сопоставимость умирает.
• Счёт «Прочее», ставший свалкой. В каждом учёте есть счёт «Прочее». Когда он становится одной из крупнейших статей бизнеса, это уже не категория — это место, где умирает анализ.
• Счета, которые тихо меняют значение. Счёт «Маркетинг», который до прошлого года содержал только рекламу, а потом впитал агентские вознаграждения и мероприятия, даёт красивую кривую тренда, которая ничего не значит. Временные ряды работают только тогда, когда определение остаётся неизменным.

Опытные бухгалтеры стартапов ориентируются примерно на 80–150 счетов для компании ранней стадии. Разница между этим чистым списком и неуправляемым планом на 400 строк, который никто не может закрыть в срок, почти всегда одна и та же: раздутый план кодирует проекты, клиентов и подразделения как счета вместо тегов.

Единственное правило: счета отвечают на «что», теги — на «кто» и «где»​

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

Один счёт «Командировки» с тегом проекта заменяет десятки счетов «Командировки, Проект X», и каждый проект внезапно можно проанализировать по всем типам расходов. Теги — это метаданные, прикреплённые к транзакции, а не ветви дерева счетов. Поскольку список счетов остаётся стабильным, ваши тренды сохраняют смысл год за годом, а теги дают все необходимые сквозные срезы.

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

Выгода проявляется во время отчётности. Вместо ведения отдельного набора счетов для каждого проекта вы запускаете один отчёт о прибылях и убытках с фильтром по тегу и получаете P&L проекта прямо из тех же книг, что дают вашу налоговую декларацию. Никакой параллельной таблицы, никакой сверки между двумя системами, никакой сноски.

Как тегирование выглядит на практике​

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

• QuickBooks Online имеет классы (а на старших тарифах — теги, а также отслеживание клиентов и проектов). Вы назначаете класс, например «Разработка» или «Продукт A», каждой строке транзакции, а затем фильтруете любой отчёт по классу. Отслеживание клиентов и работ идёт на уровень глубже для прибыли и убытков по проекту.
• Xero имеет категории отслеживания — обычно две активные, например регион и подразделение, — плюс отслеживание проектов на старших тарифах для учёта времени и затрат по каждому проекту.
• Plain-text accounting (Beancount, Ledger) использует теги и ссылки, записываемые прямо в строках транзакций, плюс пары ключ-значение метаданных и открытые гибкие структуры счетов. Тег #client-acme или поле метаданных project: falcon путешествует с проводкой и может быть запрошено в любой комбинации, без всякого размножения субсчетов.
• Электронные таблицы и кастомные системы часто реализуют тот же шаблон в виде дополнительных столбцов: один столбец для счёта, один для проекта, один для клиента. Если это то, где вы находитесь сегодня, вы уже понимаете модель — цель в том, чтобы перенести её в свои настоящие книги.

Какой бы инструмент вы ни использовали, дисциплина одна: помечайте тегами последовательно при вводе транзакции, пока контекст свеж. Теги, восстановленные месяцы спустя по памяти, — это догадки, а P&L проекта, построенный на догадках, хуже отсутствия такового, потому что выглядит авторитетно.

Проектирование измерений: их меньше, чем вы думаете​

Самая распространённая ошибка тегирования — создание слишком многих измерений. Начните максимум с двух-трёх, выбранных по вопросам, которые вы действительно задаёте:

1. Проект или договор. Работа, которую вы оцениваете, выполняете и хотите судить, прибыльна она или нет. Агентства помечают клиентские проекты, подрядчики — работы, команды разработки — продуктовые линейки или эпики.
2. Клиент. Часто совпадает с проектом для проектного бизнеса, но различается, когда один клиент приносит повторные заказы, которые вы хотите оценивать как отношения. Клиент, генерирующий три индивидуально прибыльных проекта, всё равно может быть убыточным в целом, если учесть поддержку и переделки.
3. Место возникновения затрат или подразделение. Разработка, продажи, операции — внутренние единицы, расходы которых вы бюджетируете и анализируете. Это измерение отвечает на вопрос «куда уходит жжение?», не трогая список счетов.

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

Внутри каждого измерения держите список тегов коротким и стабильным. Архивируйте завершённые проекты, а не удаляйте их (удаление переписывает историю), и сопротивляйтесь разовым тегам для необычных статей — тег, использованный трижды, — та же болезнь, что разовый счёт, только в новом месте.

Распределение общих затрат без двойного счёта​

Прямые затраты легко пометить тегом: счёт подрядчика по Проекту Falcon получает тег Falcon. Сложная часть — общие затраты: аренда, подписки на ПО, ваша собственная зарплата, — которые обслуживают все проекты сразу. Игнорировать их — значит льстить каждому проекту; сваливать их все на один проект — несправедливо наказывать его.

Выберите один метод распределения для каждого типа затрат и применяйте его последовательно:

• Распределение по времени. Делите общий труд и накладные расходы по часам, отработанным на каждом проекте. Если вы потратили 60 процентов оплачиваемых часов на Falcon в этом месяце, Falcon поглощает 60 процентов общих затрат. Это самый справедливый метод для сервисного бизнеса и тот, который аудиторы считают наиболее защитимым.
• Распределение по выручке. Делите общие затраты пропорционально выручке каждого проекта. Просто и стабильно, но наказывает ваши самые успешные проекты и скрывает отстающие — используйте это для действительно общих затрат, таких как бухгалтерские услуги, а не для затрат, определяемых усилиями.
• Распределение по численности или использованию. Делите лицензии на ПО по пользователям, аренду — по квадратным метрам, затраты на транспорт — по пробегу. Соотносите драйвер с затратой: распределяйте то, что фактически потребляет ресурс.

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

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

Ошибки, которые уничтожают всю систему​

Тегирование проваливается предсказуемыми способами. Берегитесь этих пяти:

1. Непомеченные транзакции. Каждая непомеченная строка невидима для проектной отчётности. Сделайте проектный тег обязательным для расходных, доходных и закупочных транзакций — но не для банковских комиссий или переводов, где он был бы бессмысленным. Просматривайте отчёт «непомеченное» еженедельно и стремитесь свести его к нулю.
2. Разрастание тегов. «Acme», «ACME Corp» и «Acme — new» — это три тега для одного клиента. Заблокируйте список тегов так, чтобы только один человек мог добавлять значения, и объединяйте дубликаты, пока они не окаменели в истории.
3. Тегирование всего. Не каждой транзакции нужны все измерения. Тег, применённый бездумно, становится шумом; тег, применённый там, где это важно, становится инсайтом. Помечайте строки, которые отвечают на реальные вопросы.
4. Ретроактивная переинтерпретация. Изменение значения тега на ходу — поглощение подпроекта родительским, переименование подразделения — портит каждый тренд. Когда структура действительно меняется, сохраняйте старый тег для истории и начинайте новый с чистого листа.
5. Две системы учёта. В тот момент, когда проектные затраты живут частично в книгах, частично в побочной таблице, ни одна из них не заслуживает доверия. Выберите помеченную главную книгу единственным источником истины и откажитесь от теневой системы.

Ничего из этого не требует сложного ПО. Требуется согласие — с самим собой, вашим бухгалтером и всеми, кто касается книг, — что теги являются частью транзакции, а не необязательным украшением.

Чистые теги делают лучше все остальные отчёты​

Как только дисциплина тегирования установлена, выгоды накапливаются за пределами прибыльности проектов. Бюджетирование становится проще, потому что у каждого места возникновения затрат есть своя история для составления бюджета. Подготовка налогов ускоряется, потому что вычитаемые категории остаются чистыми, а не перепутанными с именами клиентов. Заявки на кредит становятся сильнее, потому что вы можете показать кредитору, какие именно части бизнеса генерируют денежный поток. И закрытие месяца становится короче: компактный список счетов с последовательными тегами сверяется за часы, а не недели.

Более глубокая победа — качество решений. Когда вы можете доверять P&L проекта, вы можете оценивать следующий проект на основе доказательств, а не инстинкта, отказаться от клиента, чья нагрузка поддержки съедает маржу, и удвоить усилия на работе, которая действительно окупается. Бизнесы, знающие свои цифры, делают эти шаги рано; бизнесы, гадающие по лабиринту из 300 счетов, делают их поздно, если вообще делают.

Держите проектные книги в порядке с первого дня​

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