Уяви: ти фриланс-розробник. Узяв проєкт на 60 000 ₴, відсидів за ним увесь березень, здав. Клієнт перерахував гроші аж у травні.
Питання просте: в якому місяці ти заробив ці 60 000 ₴?
На перший погляд — у травні, коли гроші впали на картку. Але є й інша логіка. Працював же ти в березні. Праця — там, гроші — лише її наслідок. Якщо завтра клієнт збанкрутує і не заплатить, ти ж не «не заробив». Ти просто не отримав платіж за зароблене.
Це два різні погляди на питання «коли я заробив». Бухгалтерія обидва формалізувала і назвала методами визнання.
Метод нарахування (Accrual basis)
Дохід визнаємо тоді, коли він виник економічно — товар відвантажений, послуга надана, акт підписаний. Витрату — коли ресурс спожитий: зарплата нарахована, оренда «з’їдена» за місяць, амортизація нарахована.
Грошовий потік тут ні до чого. Заплатили чи ні — це окреме питання й окремий звіт.
Чому цей метод чесніший:
- Показує реальну економіку періоду, а не випадковий момент платежу.
- Зіставляє доходи з витратами, які їх породили (matching principle). Якщо в березні був продаж, то й матеріали, витрачені на нього, треба віднести на березень.
- Не дозволяє «грати» з прибутком, відкладаючи чи прискорюючи платежі. Касовим це робиться легко: хочеш зменшити прибуток місяця — затримай платежі або стимулюй передоплати.
Чому він складніший:
- Доводиться вести облік дебіторки і кредиторки (хто кому винен), а не просто «грошей у касі».
- Треба нараховувати амортизацію, резерви, нараховану зарплату — все, що не гроші.
- Звіт про рух грошей будуєш окремо, бо P&L грошей не показує.
В Україні метод нарахування — стандарт для всіх підприємств на загальній системі. П(С)БО і МСФЗ обидва його вимагають. ТОВ, ПП, АТ — усі на нарахуванні.
Касовий метод (Cash basis)
Дохід визнаємо тільки коли гроші прийшли. Витрату — коли гроші пішли.
Простіше не буває. Гроші увійшли — дохід. Гроші вийшли — витрата. Усе.
Хто його використовує в Україні:
- ФОП на спрощеній системі (2-3 групи) — за виручкою, тобто фактично за касовим методом.
- Деякі категорії платників ПДВ — застосовують касовий метод тільки для ПДВ (про це нижче).
- Малі підприємства на спрощеному бухгалтерському обліку (рідко).
А тепер чому касовий метод гірший економічно.
Уяви компанію за рік:
- Січень-листопад: продали товарів на 5 млн, витратили 4 млн на матеріали.
- Грудень: відправили велику партію, рахунок 2 млн, клієнт обіцяв заплатити в січні.
За нарахуванням: дохід року = 5 + 2 = 7 млн, витрати = 4 млн, прибуток 3 млн. Економічно справедливо.
За касовим методом: дохід = 5 млн (бо за грудневу партію гроші ще не прийшли), витрати = 4 млн, прибуток 1 млн. Економічно неточно — компанія за рік фактично заробила більше, але звіт «недобачив».
Тож касовий метод лишається там, де простота важливіша за точність: малий бізнес з невеликими оборотами і швидким кешем.
Класичний приклад різниці
ТОВ «УкрПром-Тех» у березні:
- Виконали роботу для клієнта А на 300 000 ₴, акт підписаний 15.03. Гроші прийдуть у квітні.
- Отримали аванс від клієнта Б на 200 000 ₴ 20.03. Роботу для нього виконають у травні.
- Нарахували зарплату 100 000 ₴ за березень, виплатили 5.04.
- Заплатили оренду 50 000 ₴ за лютий (затримали платіж).
Метод нарахування:
- Дохід березня: 300 000 ₴ (тільки робота для А, бо завершена).
- Витрати березня: 100 000 ₴ (зарплата за березень).
- Прибуток: 200 000 ₴.
Аванс від Б — не дохід (поки робота не зроблена, це зобов’язання, на рахунку 681). Оренда за лютий — теж не березнева витрата, її врахували в лютому.
Касовий метод:
- Дохід: 200 000 ₴ (тільки гроші від Б).
- Витрати: 50 000 ₴ (тільки оренда).
- Прибуток: 150 000 ₴.
Зарплата нарахована, але ще не виплачена — отже не витрата. Дохід від А не визнаний, бо гроші не прийшли.
Різниця — 50 000 ₴ прибутку за один місяць. Це не помилка, а різні способи рахувати. За одним методом та сама компанія показує велику маржу, за іншим — посередню.
ПДВ — особлива історія
Тепер до головного. В Україні ПДВ має власну логіку — правило першої події. Розкладемо.
ПДВ-зобов’язання виникає за першою з двох подій:
- Відвантаження товару чи надання послуги.
- Отримання передоплати.
Тобто це гібрид нарахування і касового. Зазвичай ПДВ нараховується раніше, ніж дохід у звичайному обліку. Чому так?
Бо держава хоче податок раніше. Якби ПДВ нараховувався тільки на момент відвантаження, то на передоплатах податок «зависав» би: гроші вже є, податку нема, відвантаження може бути ще через кілька місяців. Тож ПКУ каже коротко: гроші прийшли — нараховуй ПЗ; товар пішов — нараховуй ПЗ; що було першим, те й рахується.
Винятки:
- Касовий метод ПДВ для деяких категорій — комунальні підприємства, ЖЕКи, деякі будівельні, аграрії. Вони можуть обрати ПДВ за касовим методом, тобто нараховувати ПЗ тільки коли отримали оплату. Це закріплено в ст. 187.10 ПКУ.
- Експорт: ПЗ виникає за датою оформлення митної декларації (особлива логіка).
Перша подія — це не загальний бухгалтерський метод, це метод ПДВ. Решта обліку все одно йде за нарахуванням. Тому бухгалтер веде паралельно два «годинники»: один для бухгалтерського P&L, другий для ПДВ-декларації.
Чому це важливо для defense-tech
Defense-контракти часто мають таку структуру:
- Аванс 30-50% при підписанні (не завжди, але часто).
- Постачання за етапами з актами.
- Остаточний розрахунок через 30-90 днів після останнього акту.
За методом нарахування дохід визнаємо на дату акту, а не в момент авансу. Аванс — це зобов’язання: гроші отримали, ще не відробили.
Проте ПДВ-зобов’язання за авансом виникає одразу (перша подія). Тому на 643 «Податкові зобов’язання за авансами» з’являється проводка, навіть якщо у звичайному обліку доходу ще нема.
Звідси характерний defense-парадокс:
- Бухгалтер каже: «У нас за місяць ще не було доходу за цим контрактом — акт не підписаний».
- Фінансовий звіт показує: «За цей місяць нараховано ПЗ на 200 000 ₴, треба сплатити до 30-го».
Жодної суперечності. Просто два «годинники» — бухгалтерський (за актами) і ПДВ (за першою подією) — тікають у різному темпі.
Що з цього важливо для розробника Odoo
В Odoo за умовчанням усе на методі нарахування. account.move створюється на дату документа (інвойсу, акту), а не на дату платежу.
Проте для ПДВ потрібна окрема логіка. Кастомізація l10n_ua додає дві дати: дату документа (для бухгалтерського обліку) і дату ПН (для податкового), яка фіксується за першою подією.
Технічно це реалізовано через:
account.move.date— дата операції для бухгалтерського обліку.l10n_ua_tax_invoice_date— дата ПН (першої події).l10n_ua_pn_state— статус реєстрації ПН в ЄРПН.
Без цієї кастомізації стандартний Odoo не дасть правильну ПДВ-звітність за українським законодавством. Тож кожен defense-проєкт впровадження стартує з установки і налаштування l10n_ua — без цього далі рухатись нікуди.
Підсумок
Дві системи координат, які варто тримати в голові:
- Метод нарахування — економічна реальність періоду. Дохід там, де подія.
- Касовий метод — рух грошей. Простіше, але менш точно.
- ПДВ (перша подія) — гібрид, оптимізований під державу, щоб податок надходив швидше.
Для українського загального бізнесу — нарахування. Для ФОПа — касовий. Для ПДВ — окремі правила.