Nordlet

← Документація / Посібники

Визнання доходу (МСФЗ (IFRS) 15 / ASC 606)

Відкладений дохід (deferred revenue), рівномірні графіки (ratable), графіки за етапами (milestone) та відсотком виконання (percent-complete), зобов'язання щодо повернення коштів, підписки.

Відкладення доходу за позиціями та планове визнання: зобов'язання за контрактами, методи за часом виконання (over-time), розподіл ціни операції, забезпечення під повернення коштів, підписки та модифікації контрактів. Стандартний сценарій залишається незмінним: звичайний рядок рахунка-фактури все ще визнає дохід у повному обсязі на дату виставлення (в момент часу), що відповідає стандартам ASC 606 / МСФЗ (IFRS) 15 для єдиного виконання обов'язку до задоволення під час поставки. Усе, що наведено нижче, застосовується за вибором для кожного окремого рядка рахунка-фактури.

Програмне забезпечення здатки виконувати вимоги стандартів 606/15; звітуюча компанія є тією стороною, яка відповідає (або не відповідає) цим вимогам. Вибір правильного методу для кожного обов'язку до задоволення, оцінка цін самостійного продажу та ставок повернення, а також визначення того, чи є решта товарів або послуг відокремлюваними при модифікації, залишаються на розсуд бухгалтерії підприємства-подавача звітності.

Рахунки

Три рахунки Плану рахунків забезпечують підтримку цих рухів, налаштовані як ключі правил проведень (їх можна перевизначити для кожної компанії через ledger/posting-rules/update): revenue.deferredIncome → 4910 "Ateinančių laikotarpių pajamos" (зобов'язання за контрактом), revenue.refundLiability → 4450 "Grąžinimo įsipareigojimai pirkėjams", revenue.contractAsset → 2910 "Sukauptos pajamos". Існуючі компанії отримують ці рахунки шляхом повторного застосування шаблона Плану рахунків (ledger/accounts/apply-template).

Обов'язки до задоволення в рядках рахунків-фактур

Рядки в sales/invoices/create|update приймають параметр recognition: { method, startDate, endDate, milestones }, де method може набувати одного з таких значень:

Метод Поведінка під час виставлення Визнання
point_in_time (за замовчуванням) Кредит (CR) на повну суму доходу на дату виставлення, без змін
ratable (startDate..endDate) Кредит (CR) на відкладений дохід щомісячний графік із зважуванням за днями протягом періоду надання послуг
milestone (milestones[], відсотки в сумі становлять 100) Кредит (CR) на відкладений дохід один транш на етап, визнається при настанні події
percent_complete Кредит (CR) на відкладений дохід на основі кумулятивних звітів про виконання

Дебіторська заборгованість та ПДВ залишаються незмінними: виставлення створює дебет (DR) 2410 на валову суму, кредит (CR) 4492 на ПДВ і розподіляє чисту суму між доходом (рядки з визнанням у момент часу) та рахунком 4910 (відкладені рядки). Графіки зберігаються у базовій валюті компанії за валютним курсом на дату виставлення - sales/recognition-schedules/list (sales:read) показує кожен транш зі статусом pending | recognized | cancelled.

Розподіл ціни операції. Якщо є більше одного рядка, параметр standaloneSellingPrice у кожному рядку розподіляє чисту суму рахунка-фактури між зобов'язаннями пропорційно (МСФЗ (IFRS) 15 §76–80); саме розподілена сума, а не зазначена ціна в рядку, визначає співвідношення доходу та відкладених сум, а також графіки. ПДВ залишається прив'язаним до рядків рахунка-фактури в задекларованому вигляді.

Рушій визнання доходу

Процес визнання створює проведення дебет (DR) 4910 / кредит (CR) доходу (рахунок послуги/продукту та центр витрат з оригінального рядка) у вигляді єдиного журналу на один запуск, який записується в sales/recognition/runs/list.

  • POST /v1/sales/recognition/compute (sales:read) { asOfDate? } - попередній перегляд (dry-run) очікуваних рівномірних траншів.
  • POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } - проведення очікуваних рівномірних траншів або конкретних траншів, зазначених через scheduleIds (для будь-якого методу).
  • POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } - для рядків із визнанням за відсотком виконання: звітування про кумулятивний прогрес; новозароблена дельта проводиться негайно, регресії відхиляються.
  • POST /v1/sales/recognition/summary (sales:read) - визнано на дату, залишок, кількість очікуваних траншів і дата наступного платежу за кожним рядком, а також загальні підсумки по компанії.

Три події запускають визнання без необхідності опитування (polling): блокування періоду (ledger/periods/lock) спочатку визнає все, що підлягає визнащенню до кінця періоду, з проведенням на дату закінчення періоду; виставлення акта приймання-передачі (sales/acts/issue) визнає пов'язані з ним очікувані транші за етапами з рахунка-фактури на дату акта; а таймер настання строку за графіком активується на наступну дату рівномірного платежу та виконує проводки для компанії у момент настання цієї дати (заблокований період повторить спробу пізніше). Етапи навмисно прив'язані до подій - параметр expectedDate для етапу є плановою інформацією і сам по собі ніколи не запускає визнання доходу.

Змінне відшкодування - зобов'язання щодо повернення коштів

Параметр refundEstimatePercent у рядку кредитує відповідну частку (розподіленої) чистої суми на рахунок 4450 замість доходу чи відкладеного доходу на момент виставлення - очікувані повернення виключаються з ціни операції (МСФЗ (IFRS) 15 §55). Стан для кожного рахунка-фактури зберігається в sales/refund-liability/list (оціночне, погашене, фактично зареєстровані повернення за врегулюванням, залишок).

Фактичні дані: кредитове авізо до рахунка-фактури дебетує рахунок 4450 в межах залишку зобов'язання до того, як зачіпати дохід. sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } переглядає оцінку і проводить дельту проти доходу в будь-якому напрямку (з обмеженням знизу на рівні погашеної суми). Повернення коштів за врегулюванням від постачальника платіжних послуг (PSP), зіставлені з рахунком-фактурою, записуються на зобов'язання та генерують вебхук refund_liability.actual - вони не проводяться безпосередньо проти рахунка 4450, оскільки зменшення доходу та вихідного ПДВ вимагає наявності кредитового авізо як документа з ПДВ.

Підписки - угоди та рахунки-фактури

Надайте угоді параметр billingPeriod (monthly | quarterly | annual), і виклик agreements/generate-invoice (agreements:write) створить проєкт рахунка-фактури за наступний неабонований період: рядки з позицій угоди (або значення value як один рядок на період), кожен із рівномірним визнанням протягом періоду надання послуг. Виклик agreements/billing/run { asOfDate? } опрацьовує всі активні угоди, генерує рахунки за всі періоди, строк яких настав, і закриває угоди, термін дії яких повністю завершився після закінчення дати дії. Кінцеві короткі періоди пропорційно розподіляються за днями; autoRenew продовжує строк дії на власний період і продовжує виставляти рахунки. Згенеровані рахунки містять agreementId (з можливістю фільтрації в sales/invoices/list).

Модифікації контрактів

POST /v1/sales/recognition/modify (sales:write) { invoiceLineId, approach, date?, newEndDate?, newMilestones? }:

  • prospective - скасувати очікуваний графік і перерозподілити невизнаний залишок за новими умовами починаючи з дати модифікації (решта товарів/послуг є відокремлюваними: МСФЗ (IFRS) 15 §20(a), §21(a)). Для рівномірних рядків використовується newEndDate; для рядків за етапами - newMilestones (відсотки від залишкової суми).
  • cumulative_catch_up (лише для рівномірних рядків) - перерахувати дохід так, ніби нові умови застосовувалися з самого початку, і провести різницю негайно в будь-якому напрямку (єдиний частково задоволений обов'язок: §21(b)); решта суми перерозподіляється.

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

Ліміти та обмеження

  • Графіки та проведення визнання базуються на сумах у базовій валюті (EUR), зафіксованих за валютним курсом на дату виставлення; відкладені залишки не переоцінюються за валютним курсом після виставлення.
  • Рахунок контрактного активу (2910) надається в Плані рахунків та як ключ проводки, але автоматичний рух неабонованого доходу на нього поки не налаштований - визнання до виставлення рахунка наразі виконується ручним проведенням журналу.
  • Розподіл вимагає наявності ціни самостійного продажу для всіх рядків рахунка-фактури або для жодного; залишковий метод (§79(c)) не реалізовано.
  • Зобов'язання щодо повернення коштів відстежуються без урахування ПДВ на рівні рахунка-фактури; відповідний актив щодо право на повернення товарів (§B25) не моделюється.
  • Кумулятивний перерахунок (cumulative catch-up) застосовується до рівномірних рядків; перепланування етапу є лише перспективним; рядки з відсотком виконання коригуються через звіти про прогрес, а не через modify.
  • Суттєві компоненти фінансування (§60–65), негрошова компенсація та компенсація, що підлягає сплаті клієнту, виходять за рамки цієї сфери.
  • Автоматичні запуски очікуваних графіків проводяться в день їх спрацьовування; проведення корегувань заднім числом у заблоковані періоди відхиляються - розблокуйте період або використовуйте відкриту дату проведення.