Бухгалтерський облік

L1 · Ремісниче

Бухгалтер веде «свій» план рахунків в Excel або в BAS — з відхиленнями від наказу 1591. Аналітика — на рівні великої категорії, без розрізу за центрами відповідальності.

Приклад: На рахунку 92 («Адмінвитрати») разом і оренда, і зарплата CEO, і канцелярія, і юридичні послуги. Аналітики за статтею немає, усе одним мішком.

⚠ Управлінські рішення на таких даних не побудуєш. На перевірці ДПС пояснюєш на словах, бо в обліку цього немає.

L2 · Стандартизоване

Стандартний український план рахунків (наказ 1591) у BAS. Базова аналітика — за статтями витрат і контрагентами. Розширеної (центр відповідальності, проєкт, контракт) немає або є лише частково.

Приклад: Рахунок 23 «Виробництво» з аналітикою «вид продукції». На 3 моделі дронів і 12 типів комплектуючих собівартість видно за моделлю, але не за партією чи контрактом.

⚠ P&L за контрактом недоступне. На оборонному контракті з фіксованою ціною його собівартості фактично не знаєш.

L3 · Інтегроване

Стандартний план рахунків в Oblik-ERP (українська локалізація Odoo). Багатовимірна аналітика через analytic accounts: дерево «Підрозділ → Проєкт → Контракт → Замовлення». Один рахунок 23 розгортається в десятки тисяч аналітичних розрізів. P&L доступне за будь-яким зрізом.

Приклад: Проводка Д23 / К201 на 200k UAH (видача акумуляторів у виробництво) несе аналітики: Підрозділ «Цех 1», Проєкт «Дрон моделі Р-3», Контракт «А-2026-42 МО», MO «M-2026-118», Партія «L-2026-02-156». Один рядок — 5 розрізів. Будь-який зріз — окремий звіт.

L1 · Ремісниче

Першу подію бухгалтер визначає вручну: що раніше — поставка чи оплата? За цим і виписує ПН. Часто із затримкою та помилками в датах, ставках, кодах товарів.

Приклад: Дрони відвантажили 3-го (документ підписано), оплата надійшла 1-го (передоплата 30%). Перша подія — 1-го. Бухгалтер виписує ПН на 3-тє — помилка. На перевірці ДПС — штраф.

⚠ Штрафи 10-50% від суми ПН. Втрата ПК через невчасну реєстрацію. ПДВ-санкції — головна стаття штрафів для малого й середнього бізнесу в УА.

L2 · Стандартизоване

BAS визначає першу подію автоматично на стандартних операціях (продаж + оплата). На нестандартних (передоплата, повернення, бартер) потрібна ручна перевірка. ПН формується автоматично, реєстрація в М.Е.Doc — вручну.

Приклад: BAS формує ПН за продажем автоматично. Але на умові «50% передоплата + 50% після поставки» бухгалтер уточнює, чи правильно проставлено дату. У 80% випадків — так, у 20% — помилка.

⚠ Залишковий ризик помилок, надто на складних операціях. Бухгалтер витрачає на перевірку відчутний час.

L3 · Інтегроване

Oblik-ERP визначає першу подію автоматично за всіма типами операцій із трьома рівнями аналітик (загалом / договір / замовлення). ПН формується автоматично і реєструється в ЄРПН через API М.Е.Doc одразу після події. Помилки відсіюються ще на етапі формування (pre-validation).

Приклад: Контракт з МО на умові «30% передоплата + 70% після приймання». Передоплата 30% надійшла 1-го числа — ПН на цю суму сформувалася і зареєструвалася автоматично 1-го о 14:32. Поставка 15-го — ПН на 70% сформувалася і зареєструвалася 15-го об 11:18. Бухгалтер дивиться на дашборд: усе зелене, робити нічого не треба.

L1 · Ремісниче

Бюджету немає. Витрати за принципом «скільки треба, стільки й витратимо». Планування на ходу. Про витрати CEO дізнається з банківської виписки.

Приклад: У березні CEO дізнається, що зарплати + оренда + сировина = 4.2 млн UAH, а надходження — 3.1 млн. Касовий розрив 1.1 млн закривають терміновим кредитом під 25%.

⚠ Касові розриви, дорогі кредити, кризи cashflow. Стратегічних рішень не ухвалюють — виживають.

L2 · Стандартизоване

Річний бюджет в Excel, складений у січні. Звірка з фактом раз на квартал, у форматі зведення «бюджет проти факту». Реагують уже після того, як витратили.

Приклад: На Q1 2026 бюджет витрат на сировину — 8 млн UAH, факт — 9.4 млн. Перевитрату 1.4 млн помітили 15 квітня — через 15 днів після кінця кварталу. Причини незрозумілі.

⚠ Реактивне управління. Бюджет служить звітною цифрою, а не інструментом.

L3 · Інтегроване

Odoo Budget Module з contracting / forecasting / committed (зарезервовано через PO/PR). Кожен PR / PO звіряється з лімітом бюджету. Перевищив — потрібен approval з обґрунтуванням. Real-time дашборд: бюджет / committed / faktyk.

Приклад: Інженер створює PR на 80k UAH на нестандартне обладнання. Система перевіряє: бюджет статті «Інструменти R&D» = 200k на квартал, committed 150k, available 50k. PR перевищує ліміт — і автоматично йде на approval до CFO + R&D Director з обґрунтуванням, чому понад бюджет. Рішення — за 4 години.

L1 · Ремісниче

3-5 робочих днів вручну. Бухгалтер сидить до 22-ї години над проводками. Звірки — на калькуляторі. Помилки спливають через тиждень, на контрольних звітах.

Приклад: Закриття квітня: 5-15 травня. Бухгалтер працював по 12 годин. Знайшли 23 помилки — неправильні рахунки, дублі, хибна аналітика. Виправляли до 18 травня.

⚠ Бухгалтер вигорає. Звітність ДПС подають із помилками, інколи з пенею за уточнювальні розрахунки.

L2 · Стандартизоване

2 робочих дні у BAS. Стандартні звірки автоматизовано. Помилки спливають на контрольних звітах за 1-2 дні. Бухгалтер працює у звичному режимі.

Приклад: Закриття квітня: 5-6 травня. 2 дні роботи. Помилок 5-8 — переважно технічні, при введенні.

⚠ Усе тримається на людському контролі. Немає бухгалтера — немає закриття.

L3 · Інтегроване

4-8 годин в Odoo з Oblik-ERP. Більшість проводок народжуються з операцій автоматично. Звірки — однією кнопкою. Закриття одразу генерує звітність ДПС. Помилок менше 1, і ті переважно edge-case.

Приклад: Закриття квітня: 1-го травня о 10:00 бухгалтер відкриває Odoo і тисне «Period Close». Система виконує 47 контрольних операцій (звірка банку, каси, контрагентів, аналітики) і формує звіти. О 14:00 все готово. Бухгалтер витратив 4 години, переважно на перевірку.

L1 · Ремісниче

Excel-зведення раз на місяць, бухгалтер готує його для CEO. На це йде 2-3 дні. Запит «а можна детальніше про продажі по місяцях за останній рік» перетворюється на окремий проєкт на тиждень.

Приклад: Раз на місяць CEO отримує 4-сторінковий PDF: P&L, склад залишків, дебіторка, кредиторка. Без розрізу за продуктами, клієнтами, контрактами. На питання «яка маржа за контрактом А-2026-42?» — «зачекайте, я порахую».

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

L2 · Стандартизоване

Стандартні звіти BAS: P&L, баланс, оборотно-сальдова відомість. На запит «детальніше» — щось у BAS, щось в Excel. Звіт забирає кілька годин.

Приклад: CEO питає: «Яка маржа за дроном моделі Р-3?». CFO підіймає BAS, дивиться калькуляцію собівартості, додає в Excel ціни продажу — і за 30 хвилин дає відповідь. Не real-time, але прийнятно.

⚠ Time-to-decision — від годин до днів. У defense-tech, де контракти треба котирувати швидко, це буває неприйнятно.

L3 · Інтегроване

Real-time дашборди в Odoo з multi-dimensional розрізами. CEO бачить P&L за компанією, дивізіоном, продуктом, контрактом, клієнтом — усе в одному інтерфейсі. Drill-down від верхнього рівня до конкретної проводки.

Приклад: CEO заходить о 7:30 ранку в «Маржинальність за виробами» і бачить: модель Р-3 = 22%, v4 = 18%, v5 = 27%. Drill-down на v4: сировина — 64% (план 60%), переробка через QA — 8% (план 5%). Висновок — проблема з постачальником компонента X. На зустрічі о 9:00 питання вже до закупника.