Перейти до вмісту

Бухгалтер в ІТ · частина 1: агент ШІ порахував усе до копійки. І помилився в головному

Це перша частина серії «Бухгалтер в ІТ» (IT accountant): що насправді відбувається в обліку ІТ-компаній і стартапів, коли у справу вступає ШІ. Беру лише те, з чим зіткнулася сама.

Нещодавно я виконувала тестове завдання на роль бухгалтерки в ІТ-компанії. Звичайна, здавалося б, річ: банківська виписка, надходження від клієнтів, комісія платформи. Агент ШІ розніс усе за хвилини, цифри зійшлися до копійки.

І саме тут у мене спрацювала професійна деформація аудитора: коли звіт виходить надто гарним, хочеться подивитися, що за ним стоїть.

Що бачить агент

Деталі завдання я не розкриваю, тому далі цифри умовні, а логіка — та сама. Компанія продає річну підписку на свій застосунок. У грудні запустила акцію, і клієнти купили річних підписок на 1 200 тис. Платформа-посередник утримала 15% комісії, тобто 180 тис.

Агент бачить виписку і робить те, що бачить: надходження — у дохід, комісію — у витрати. У звіті за грудень виручка 1 200, витрати 180, різкий злет. Якщо попросити, він ще й побудує прогноз на рік уперед із тим самим темпом зростання.

Арифметика бездоганна. Висновок хибний.

Що бачить фахівець

Перше питання не до цифр, а до бізнес-моделі: що саме компанія продала? Не разову послугу, а доступ на дванадцять місяців. Отже, за МСФЗ 15 зобов’язання виконується протягом року, і дохід визнається так само — рівними частинами.

  • Дохід грудня: одна дванадцята, тобто 100 тис.
  • Решта, 1 100 тис.: зобов’язання за договорами з клієнтами. Це гроші, які компанія ще має відпрацювати.
  • Комісія посередника: стосується тих самих дванадцяти місяців, тож логічно розподілити її разом із доходом — 15 тис. щомісяця.

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

Чесна примітка про комісію

Тут я мушу бути точною, бо це саме те місце, де колеги з DipIFR одразу піднімуть руку.

Комісію за залучення клієнта МСФЗ 15 дозволяє капіталізувати як актив і амортизувати протягом строку договору. Але є практичне спрощення: якщо цей строк не перевищує року, витрати можна одразу визнати в періоді, коли вони виникли. Річна підписка якраз у межах року.

Тобто списати комісію в грудень формально можна. Але це вибір облікової політики, який хтось має зробити свідомо, записати й застосовувати послідовно. Агент цього вибору не робив. Він просто не знав, що вибір існує.

І ще дві речі, які в цьому кейсі треба перевірити до будь-яких проводок:

  • Хто принципал. Якщо платформа лише посередник, дохід показують у повній сумі, а комісію окремо. Якщо компанія фактично продає через платформу як агент — картина інша. Від цього залежить, валова виручка чи чиста.
  • Повернення. Якщо клієнт може відмовитися від підписки й отримати гроші назад, частина надходжень — це не дохід навіть у майбутньому, а потенційне повернення.

Як це виглядає в обліку

Для українського обліку (за НП(С)БО, спрощено, без ПДВ і податкових наслідків — їх треба розбирати окремо під конкретну компанію) логіка така:

  1. Отримано оплату за річні підписки: Дт 311 — Кт 681 (або 69, залежно від облікової політики) — 1 200.
  2. Визнано дохід грудня: Дт 681 — Кт 703 — 100.
  3. Нараховано комісію посередника: Дт 39 — Кт 631 (632, якщо платформа іноземна) — 180.
  4. Списано частку комісії за грудень: Дт 93 — Кт 39 — 15.

Далі щомісяця ті самі 100 і 15, поки підписка не закінчиться.

Американська версія: US GAAP

ІТ-компанії з американськими інвесторами часто звітують за US GAAP, тож той самий кейс варто прогнати й через нього.

Дохід. ASC 606 побудований на тій самій моделі з п’яти кроків, що й МСФЗ 15. Результат не змінюється: у грудні визнається 100, решта — це deferred revenue, зобов’язання за договором.

Комісія. ASC 340-40 так само вимагає капіталізувати додаткові витрати на укладення договору і так само дозволяє одразу списати їх, якщо строк амортизації не перевищує року. І тут пастка, про яку агент точно не здогадається.

Строк амортизації — це не строк договору, а період, протягом якого комісія приносить вигоду, з урахуванням очікуваних продовжень. Якщо за продовження підписки посереднику не платять нової комісії (або платять значно меншу), вигода від першої комісії тягнеться на весь очікуваний «вік» клієнта. Для підписок це часто кілька років. Тоді річне спрощення недоступне навіть для річного договору. В МСФЗ 15 логіка така сама.

Тобто щоб правильно обліковувати одну грудневу комісію, треба знати умови договору з платформою на роки вперед і статистику продовжень. У виписці цього немає.

Що зміниться з 2028 року

Є ще одна деталь, яка стосується саме ІТ-стартапу, і вона свіжа. У вересні 2025 року FASB випустив ASU 2025-06 — оновлення правил обліку витрат на програмне забезпечення для внутрішнього використання (ASC 350-40).

Чому це про наш застосунок: якщо клієнти лише отримують доступ до сервісу через інтернет і не забирають програму собі, витрати на його розробку в US GAAP обліковуються саме за ASC 350-40. Тобто це питання про те, скільки коштів на розробку компанія може показати як актив, а скільки — як витрати періоду.

Що змінюється:

  • Стадій більше немає. Старий поділ на попередню стадію, розробку й після впровадження погано пасував до agile, де все відбувається одночасно. Тепер правило не залежить від методології розробки.
  • Новий поріг. Капіталізація починається, коли керівництво затвердило проєкт і взяло на себе зобов’язання його фінансувати, а завершення ймовірне і програма виконуватиме задуману функцію.
  • Стоп-фактор — суттєва невизначеність розробки. Капіталізувати не можна, поки в продукті є нові, неперевірені функції, невизначеність яких ще не знята кодуванням і тестуванням, або поки суттєві вимоги до продукту не визначені чи постійно переписуються. Для стартапу, який шукає свій продукт, це майже автопортрет.
  • Витрати на розробку вебсайту тепер теж у ASC 350-40.

Коли: обов’язково для річних періодів, що починаються після 15 грудня 2027 року, тобто для компаній із календарним роком — з 1 січня 2028-го. Дострокове застосування дозволене, а перехід можна робити перспективно, модифікованим способом або ретроспективно.

І ось тут знову вибір, якого агент не зробить сам. Застосувати новий стандарт у 2026 чи дочекатися 2028-го, який спосіб переходу обрати — це рішення фінансового директора. Воно змінює і баланс, і EBITDA, і ту саму «швидкість спалювання грошей», яку дивиться інвестор. А якщо група звітує ще й за МСФЗ, де розробка досі оцінюється за критеріями МСФЗ (IAS) 38, з’являється різниця між двома звітами, яку треба пояснити й узгодити.

Агент, якому не сказали, яку редакцію стандарту і з якої дати застосовує компанія, порахує за тією, яку «пам’ятає». І знову зробить це бездоганно.

Чому це не про «поганий ШІ»

Агент не помилився. Він порахував рівно те, що було в даних. Проблема в тому, чого в даних не було: умов договору, бізнес-моделі, стандарту, облікової політики, юрисдикції.

Можливості ШІ зростають так швидко, що технічних бар’єрів для бухгалтера майже не лишилося. Розпізнавання виписки вже вбудоване в облікові програми, і вчити сьогодні «фокуси» з налаштування автоматичної обробки — це витрачати час на те, що й так працює.

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

Що я тепер додаю в інструкцію агенту

  • Тип договорів і їхній строк: разова послуга, підписка, ліцензія.
  • Стандарт, його редакцію й облікову політику: МСФЗ, US GAAP чи НП(С)БО, які спрощення компанія обрала, чи застосовує нові правила достроково.
  • Роль кожного посередника: принципал чи агент.
  • Правило: будь-яке надходження більше за звичайний місячний обсяг — не проводити, а показати людині з питанням «що це за гроші?».

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

Первинка

  • IFRS Foundation, МСФЗ 15 «Виручка за договорами з клієнтами» — визнання доходу протягом періоду, принципал чи агент, витрати на укладення договору й практичне спрощення для строку до року.
  • Мінфін України, НП(С)БО 15 «Дохід» та План рахунків бухгалтерського обліку.
  • FASB, ASC 606 і ASC 340-40 — визнання доходу й витрати на укладення договору в US GAAP.
  • FASB, ASU 2025-06 «Targeted Improvements to the Accounting for Internal-Use Software», вересень 2025 — зміни до ASC 350-40, дати набрання чинності й способи переходу.
  • Deloitte, Roadmap: SEC Comment Letter Considerations, розділ про технологічні компанії — питання регулятора щодо строку амортизації комісій з урахуванням продовжень.
  • RSM US, FASB modernizes accounting for internal-use software costs — огляд ASU 2025-06.
  • Власна практика: тестове завдання на роль бухгалтерки ІТ-компанії, 2026. Цифри в дописі умовні.

Далі в серії: інші випадки з моєї практики в ІТ-компаніях і стартапах — розбираю їх так само, від виписки до логіки за нею.

А у вашій практиці траплялися звіти, де машина порахувала правильно, але відобразила неправильно? Розкажіть у коментарях — розберемо разом.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *