Відстежуйте витрати за проєктами, клієнтами та центрами витрат без плану рахунків на 400 рахунків

Ви відкриваєте свою бухгалтерію, щоб відповісти на найпростіше питання в бізнесі — чи цей проєкт насправді приніс прибуток? — і бачите план рахунків на 300 рядків. Там є «Відрядження», «Відрядження — Клієнт А», «Відрядження: запуск у Сіднеї (старе)» і якісь «Різні витрати 2», які чомусь стали однією з ваших найбільших статей. Відповідь десь там, похована під трьома днями хірургії в електронних таблицях і виноскою, у яку ніхто не вірить.

Дані не брудні. Вони погано спроєктовані. Щоразу, коли вам був потрібен новий зріз бізнесу — проєкт, клієнт, локація — ви створювали для нього новий рахунок, і список рахунків розростався в лабіринт. Є кращий дизайн, і він простіший за те, що у вас зараз: тримайте план рахунків лаконічним, а проєкти, клієнтів і центри витрат відстежуйте тегами на кожній транзакції.

Цей посібник пояснює одне правило, яке зберігає аналізованість книг, як тегування працює на практиці в поширених бухгалтерських інструментах і як розподіляти спільні витрати на проєкти, не втрачаючи суті.

Чому ваш план рахунків постійно розростається​

Роздування списку рахунків відбувається за передбачуваною схемою. Починається все невинно: ви отримуєте великого клієнта і створюєте «Дохід від консалтингу — Клієнт А», щоб бачити, скільки він приносить. Потім «Відрядження — Клієнт А», щоб зіставити витрати. Потім другий клієнт, грант, виставка, переїзд офісу — кожен отримує власні рахунки. Через п'ять років у вас сотні рахунків із трьома транзакціями кожен, і ніхто не пам'ятає, чим були «Витрати на заходи 2023B».

Стежте за цими тривожними ознаками того, що дизайн зазнав невдачі:

• Виміри, заховані в назвах рахунків. «Відрядження, Сідней, Проєкт Falcon» — це три факти, втиснуті в одну назву. Ви не можете підсумувати відрядження за проєктами або Проєкт Falcon за типами витрат без розбору рядків і молитви. Локація, проєкт і відділ — це виміри, їм не місце в назві рахунку.
• Одноразові рахунки для одноразових подій. Новий рахунок для кожної виставки, кожного гранту, кожного переїзду офісу. Кардинальність вибухає, звіти розростаються, а порівнюваність помирає.
• Рахунок «Різне», що став звалищем. У кожній книзі є рахунок «Різне». Коли він стає однією з найбільших статей у бізнесі, це вже не категорія — це місце, куди вирушає вмирати аналіз.
• Рахунки, що тихо змінюють значення. Рахунок під назвою «Маркетинг», який містив лише рекламу до минулого року, а потім увібрав агентські гонорари та заходи, дає гарну лінію тренду, яка нічого не означає. Часові ряди працюють лише тоді, коли визначення залишається незмінним.

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

Одне правило: рахунки відповідають на «що», теги — на «хто» і «де»​

Це єдине правило виправляє більшість шкоди: рахунок відповідає на питання, який тип грошей рухався — оренда, зарплати, продаж продуктів. Усе інше — яка філія, яка продуктова лінія, який проєкт, який клієнт — належить до окремих тегів на кожному рядку транзакції.

Один рахунок «Відрядження» з тегом проєкту замінює десятки рахунків «Відрядження, Проєкт X», і кожен проєкт раптом можна аналізувати за кожним типом витрат. Теги — це метадані, прикріплені до транзакції, а не гілки дерева рахунків. Оскільки список рахунків залишається стабільним, ваші лінії трендів зберігають значення рік за роком, а теги дають усі потрібні наскрізні зрізи.

У підручниках з бухгалтерського обліку ця ідея має формальну назву: центри відповідальності. Центр витрат — це одиниця звітності — відділ, філія, проєкт — керівник якої відповідає за віднесені до неї витрати. Бухгалтерський відділ, бригада з обслуговування і клієнтський проєкт можуть бути центрами витрат. Тегування — це просто спосіб, у який малий бізнес реалізує цю ідею без корпоративної ERP: тег на кожному рядку вказує, до якого центру відповідальності належить витрата.

Вигода проявляється під час звітності. Замість підтримки окремого набору рахунків для кожного проєкту ви запускаєте один звіт про прибутки та збитки, відфільтрований за тегом, і отримуєте P&L проєкту прямо з тих самих книг, що дають вашу податкову декларацію. Жодної паралельної електронної таблиці, жодного звіряння між двома системами, жодної виноски.

Як тегування виглядає на практиці​

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

• QuickBooks Online має класи (а на вищих тарифах — теги, а також відстеження клієнтів і проєктів). Ви призначаєте клас, наприклад «Інженерія» або «Продукт A», кожному рядку транзакції, а потім фільтруєте будь-який звіт за класом. Відстеження клієнтів і робіт іде на рівень глибше для прибутку та збитків на рівні проєкту.
• Xero має категорії відстеження — зазвичай дві активні, наприклад регіон і відділ — а також відстеження проєктів на вищих тарифах для обліку часу й витрат за кожним проєктом.
• Облік у простому тексті (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 — нове» — це три теги для одного клієнта. Заблокуйте список тегів так, щоб лише одна людина могла додавати значення, і об'єднуйте дублікати, перш ніж вони скам'яніють в історії.
3. Тегування всього. Не кожна транзакція потребує кожного виміру. Тег, застосований бездумно, стає шумом; тег, застосований там, де це важливо, стає інсайтом. Тегуйте рядки, які відповідають на справжні питання.
4. Ретроактивне переосмислення. Зміна значення тега на півдорозі — поглинання підпроєкту батьківським, перейменування відділу — псує кожен тренд. Коли структура справді змінюється, зберігайте старий тег для історії й починайте новий чисто.
5. Дві системи обліку. Щойно витрати проєкту живуть частково в книгах, а частково в бічній електронній таблиці, жодна з них не заслуговує довіри. Оберіть тегований регістр як єдине джерело істини й відмовтеся від тіньової системи.

Жодна з них не вимагає складного програмного забезпечення. Вони вимагають згоди — із собою, своїм бухгалтером і будь-ким іншим, хто торкається книг — що теги є частиною транзакції, а не необов'язковою прикрасою.

Чисті теги роблять кращими всі інші звіти​

Коли дисципліна тегування налагоджена, вигоди накопичуються поза межами прибутковості проєктів. Бюджетування стає легшим, бо кожен центр витрат має власну історію для складання бюджету. Підготовка податків стає швидшою, бо категорії відрахувань залишаються чистими, а не заплутаними з назвами клієнтів. Заявки на кредит стають сильнішими, бо ви можете показати кредитору, які саме частини бізнесу генерують гроші. А закриття місяця стає коротшим: лаконічний список рахунків із послідовними тегами звіряється за години, а не тижні.

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

Тримайте бухгалтерію проєктів організованою з першого дня​

Коли ви берете більше клієнтів і проєктів, збереження витрат кожного з них видимими без заплутування плану рахунків — це те, що відрізняє книги, які ви можете аналізувати, від книг, які ви лише здаєте в архів. Облік у простому тексті природно підходить цій моделі: теги, посилання та метадані живуть прямо на рядках транзакцій, під контролем версій і запитувані в будь-якій комбінації. Beancount.io пропонує облік у простому тексті, який дає вам повну прозорість і контроль над вашими фінансовими даними — без чорних скриньок, без прив'язки до постачальника. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на облік у простому тексті.