Счетоводно третиране на разходите за внедряване на софтуер под наем

Счетоводно третиране на разходите за внедряване на софтуер под наем

(Коментар на Тълкувателно решение на КРМСФО от м. април 2021 г.)

Георги Николов, д-р по икономика, д.е.с., регистриран одитор

Актуално към 01.11.2021 г.

ХИЛЯДИ е-статии ВЕДНАГА след като се абонираш (тук) за е-сп. "Данъци ТИТА" за 2022 г.

1. Особености на модела “софтуер като услуга“

В последните няколко години използването на дадено софтуерно приложение на абонаментен принцип (т.нар. използване на „софтуер под наем“, „софтуер като услуга“ или SaaS – „Software as a Service“) добива все по-голяма популярност и по всичко личи, че ще се превърне в трайна тенденция и утвърден стандарт за доставка на бизнес приложения.

Най-общо това е софтуер, който не се инсталира локално при потребителите и не се притежава от тях, а:

се хоства централно в защитен център за данни (най-често намиращ се в „облачно пространство“) и

се достъпва от потребителите при необходимост посредством уеб браузър.

У нас това иновативно решение все по-често се възприема при бизнес приложенията – счетоводни програми, софтуер за управление на складовото стопанство, електронни магазини, системи за фактуриране, ЕРП системи, системи за управление на отношенията с клиенти (CRM), системи за управление на човешките ресурси (HRM), системи за управление на съдържанието (CM), софтуерни приложения за управление на проекти и т.н.

Същевременно на този принцип вече работят и редица приложения, предназначени за крайни потребители – компютърни програми за текстова обработка, за електронни таблици, за създаване на музика, за обработка на снимки, за създаване на интернет блогове и много други.

Този иновативен модел за използване на дадено софтуерно приложение поражда интересни счетоводни проблеми.

Първият принципен въпрос засяга подходящото счетоводно третиране на заплащания от предприятията абонамент за правото на достъп до съответното софтуерно приложение.

По този въпрос е публикувано Тълкувателно решение на КРМСФО през м. март 2019 г. В сърцевината на това решение стоят следните изводи:

споразумение, по силата на което клиентът получава правото на достъп до приложния софтуер на доставчика, представлява договор за извършване на услуга и в общия случай не води до признаване на нематериален актив;

клиентът черпи изгодата от получената услуга през срока на договора;

ако клиентът предплати за своя абонамент, направеното авансовото плащане първоначално се отчита като актив (предплатени разходи / разходи за бъдещи периоди). Активът се признава на части за разход през периода на получаване на услугата [1].

В обобщение, заплащаният абонамент за „софтуер под наем“ най-често счетоводно трябва да се признава в печалбата или загубата като текущ разход на систематична база за срока на споразумението.

Разбира се, не всички споразумения за използване на софтуер под наем се подчиняват на този модел на отчитане, но към настоящия момент изключенията засягат значителни по-рядко срещани у нас споразумения.

В този смисъл третирането на абонаментите плащания като текущ разход може да се изведе като общо правило.

Същото обаче не може да се каже за другите видове плащания, които клиентът-ползвател прави за внедряване на софтуера.

При споразуменията за използване на софтуер под наем клиентът най-често поема за своя сметка всички разходи за внедряване на приложния софтуер на доставчика.

Подходящото счетоводно третиране на тези разходи, които често са съществени по размер, налага извършването на доста по- задълбочен анализ.

На първо място обаче трябва да се прецизира терминологията за състава на разходите по внедряване на софтуер.

За счетоводни цели е важно да се разграничат дейностите по конфигуриране на софтуера от дейностите по неговото персонализиране.

Опит за такова разграничение е представен в таблицата по-долу:

Конфигурирането на софтуер:	Персонализирането на софтуер:
включва дейностите по настройка на различни „флагове“ или „превключватели“ в системата;	налага извършването на определени промени в съществуващата функционалност на софтуера;
настройват се системни параметри, които са предварително заложени като опции в стандартната функционалност на софтуера	често включва добавяне на допълнителни програмни възможности според конкретните изисквания на клиента
не изисква допълнително програмиране	изисква допълнително програмиране
представлява настройка на софтуера, а не негова доработка	представлява доработка на софтуера, а не негова настройка.

От очертаните различия в характера на дейностите се създава първоначалното впечатление, че:

направените разходи за персонализиране на софтуера се признават като актив, а

тези за неговото конфигуриране – не.

В най-общ план това разсъждение е правилно, но би могло да послужи единствено като отправна в по-нататъшния цялостен анализ.

Освен от характера на разходите, правилното счетоводно третиране зависи също така от:

правата на интелектуална собственост върху получения резултат; и от

лицето, което реално извършва дейностите по внедряване (дали това е клиентът, доставчикът на софтуера или независима трета страна.

2. Общ преглед на счетоводния подход съгласно Тълкувателното решение на КРМСФО от м. април 2021 г.

Правилното определяне на подходящото счетоводно третиране на разходите за внедряване на „софтуер под наем“ изисква анализ на поредица от фактори. Те най-лесно могат да бъдат осмислени чрез визуализиране им под формата на „дърво на решенията“.

Опит за такава систематизация е направен в представената по-долу фигура:

Всички стъпки от процеса по вземане на решения ще бъдат последователно разгледани в изложението.

Преди това обаче се изследва един основен въпрос, който възниква във всички възможни сценарии, а именно: могат ли разходите за внедряване на „софтуер под наем“ да формират нематериален актив?

3. Признават ли се разходите по внедряване за нематериален актив?

Съгласно предходното Тълкувателно решение на КРМСФО по същата тема (от м. март 2019 г.), правото на достъп до софтуера на доставчика в общия случай не представлява актив за клиента-ползвател, а трябва да се третира като получена услуга. Това обаче не означава непременно, че нематериален актив не може да възникне от направените разходи за внедряване на използвания на абонаментен принцип софтуер.

Счетоводната дефиниция за нематериален актив се състои от три взаимосвързани елемента:

разграничимост,
контрол над ресурса и
бъдещи икономически ползи.

Действията по конфигуриране на софтуера не водят до създаване на нематериален актив, тъй като постигнатият чрез тях резултат не може да бъде разграничен от правото на достъп до използвания на абонаментен принцип софтуер.

Чрез дейностите по персонализиране обаче се променя стандартната функционалност на софтуера. От там несъмнено се повишава икономическата му полезност за ползвателя. Създава се нов софтуерен код, който лесно може отделен от кода на стандартната версия на приложението. Следователно два от елементите в дефиницията за нематериален актив (разграничимост и бъдещи икономически ползи) се явяват покрити.

Допълнително остава да се изследва единствено признакът за контрол над ресурса. Тук вече са възможни различни конфигурации в зависимост от конкретните договорки между страните.

Ключовият въпрос е дали клиентът може да ограничи достъпа на трети лица до подобрената функционалност на софтуера.

Отговорът на този въпрос най-често зависи от постигнатото споразумение за правата на интелектуална собственост върху направената софтуерна модификация.

Ако клиентът-ползвател може да ограничи достъпа на други лица до персонализираната версия на софтуера, признакът за контрол е налице.

В този случай разходите за персонализиране на софтуера отговарят на дефиницията за нематериален актив.

В останалите случаи не възниква нематериален актив за ползвателя.

Пример 1:

Предприятие преминава към уеб-базирана система за фактуриране, която ще използва на абонаментен принцип.

Освен месечната такса за използване на системата предприятието възлага на доставчика да извърши следните допълнителни услуги:

(а) настройка на изгледа на фактурите спрямо използвания от клиента до момента от образец;

(б) миграция на основните данни на клиентите от старата към новата система за фактуриране;

(в) настройка на езика на издаване на фактурите спрямо адреса на клиента (старата система на предприятието не е разполагала с такава функционалност);

(г) обучения на персонала за работа със системата;

(д) изграждане на двупосочен интерфейс между персонално разработения складов софтуер на клиента и ползваната на абонаментен принцип система за фактуриране.

Първите три услуги са част от обикновените потребителски настройки на софтуера. Участието на доставчика обаче е задължително в процеса по разработване на интерфейса, тъй като се налагат промени в софтуерния код на системата за фактуриране (той от своя страна е интелектуална собственост на доставчика).

Анализ:

Услугите в т. (а), (б) и (в) са част от процеса по конфигуриране на софтуера.

За предприятието не възниква допълнителна икономическа изгода от услуги в т. (а) и в т. (б), тъй те не надграждат функционалността на използваната до момента система. Следователно тези разходи не формират нематериален актив.

Услугата в т. (в) принципно води до допълнителна изгода. Тази допълнителна полза обаче се дължи на цялостната функционалност на новата система за фактуриране. Освен това опцията е налична в стандартната функционалност на новия софтуер. Не е налице нематериален актив поради липсата на разграничимост.

Обучението в т. (г) не допринася по никакъв начин за привеждане на системата в работно състояние. Успоредно с това в МСС 38 съществува изрична забрана за признаване на разходите за обучение като част от цената на придобиване на нематериален актив (пар. 29).

Услугата по разработване на интерфейса в т. (д) може да се определи като услуга по персонализиране на софтуера. Интерфейсът е разграничим от основния софтуер и несъмнено води до бъдещи икономически ползи.

В конкретния случай не е необходимо задълбочено да се изследва контролът върху интерфейса. Причината е, че дори да има правната възможност, доставчикът едва ли би могъл да предлага интерфейса на други свои клиенти поради твърде специфичния му характер[2].

Следователно направените разходи за изграждане на интерфейс между използваните от клиента системи отговарят на дефиницията за нематериален актив.

Пример 2:

Предприятие използва на абонаментен принцип софтуер за провеждане на онлайн обучения. В стандартната версия на софтуера е включена възможност за проверка на знанията на участниците в обучението чрез тестове.

Същевременно не е предвидена възможност за ограничаване на времето за попълване на тестовете.

Предприятието настоява за въвеждане на определен времеви лимит за отговор на всеки от въпросите в тестовете.

Разработчикът се съгласява срещу допълнително възнаграждение да разработи модифицирана версия на софтуера в изпълнение на конкретните изисквания на клиента.

Съгласно общите условия за ползване на софтуера всяка софтуерна модификация задължително се помества в уеб-базирана библиотека и е достъпна от всеки от потребителите на софтуера.

Анализ:

Направените разходи в примера са за персонализиране, а не за конфигуриране на софтуера.

Чрез допълнително програмиране се създава нова функционалност на приложението, която е различна от стандартната.

Разходите водят до бъдещи икономически ползи, а модифицираната версия на софтуера е разграничима от стандартната.

Същевременно обаче предприятието не може да ограничи достъпа на други лица до подобрената за негова сметка функционалност на софтуера (модификацията е свободно достъпна за всички останали потребители).

Признакът за контрол не е изпълнен и не е налице нематериален актив.

4. Изпълнени ли са критериите за признаване на нематериален актив?

Съгласно изискванията на МСС 38 (пар. 21) даден нематериален актив се признава единствено когато:

а) е вероятно, че предприятието ще получи очакваните бъдещи икономически ползи от актива;

б) стойността на актива може да бъде определена надеждно.

При външно придобити нематериални активи тези критерии се явяват автоматично изпълнени (МСС 38, пар. 25 и пар. 26) и не е необходим допълнителен анализ.

С други думи, ако:

услугите по внедряване на софтуера са извършени от доставчика или от независима външна фирма, и

се достигне до заключението, че полученият резултат отговаряна дефиницията за нематериален актив,

такъв автоматично се признава

Ако обаче дейностите са осъществени със собствени ресурси (персонал) на клиента, попадаме в хипотезата на вътрешно създаден нематериален актив.

Тогава, за да изпълни критериите за признаване на нематериален актив, предприятието допълнително трябва да се опита да разграничи фазите:

на научноизследователска и

на развойна дейност

в процеса по персонализиране на софтуера.

Направените разходи:

във фазата на научноизследователската дейност задължително се признават като текущи в момента на възникването им, а тези

във фазата на развойната дейност могат да формират нематериален актив при положение, че са изпълнени допълнителните условия за техническа осъществимост и ресурсна обезпеченост на проекта (пар. 57).

Вярно е, че границата между двете фази в процеса по разработване на софтуер е много тънка, но това не освобождава предприятията от задължението им да направят такава преценка.

Пример 3:

Специализирано одиторско предприятие използва система (по модела „софтуер като услуга“) за автоматизирано разпращане на потвърдителни писма на контрагентите на своите клиенти за одит.

Тъй като предприятието губи много ресурси в последващото ръчно проследяване на разликите от получените потвърдителни писма, ръководството възлага на свои вътрешни софтуерни инженери да разработят и да внедрят в системата параметризиран модел на писмо за потвърждение, който да направи възможно автоматичното съпоставяне на данните от получените потвърдителни писма с данните от счетоводството на клиента.

Софтуерните специалисти извършват следните дейности:

(а) за един тестови клиент изследват различните възможности за параметризиране на писмото, като постепенно пресяват неработещите варианти;

(б) след серия от тестове установяват, че има няколко добре работещи решения;

(в) работещите възможности се тестват в по-широка популация и се установяват техните предимства и недостатъци;

(г) след изрично потвърждение на предпочитания от ръководството вариант се започва същинското му програмиране в тестова среда;

(д) изчистват се всички възникнали грешки и се преминава към продуктивна фаза.

Анализ:

Макар с известна степен на условност може да заключи, че:

дейностите в стъпки (а), (б) и (в) имат характер на научно-изследователска дейност и направените за тях разходи трябва да се признаят за текущи;

дейностите в стъпки (г) и (д) по-скоро представляват развойна дейност и направените за тях разходи могат да се капитализират като вътрешно-създаден нематериален актив.

Изложеното дотук може да се обобщи чрез следните междинни изводи:

Разходите за конфигуриране на „софтуер под наем“ не отговарят на дефиницията за нематериален актив;

Разходите за персонализиране на „софтуер под наем“ биха могли да отговарят на дефиницията за нематериален актив. Решаващ в преценката най-често се явява признакът за контрол.

Разходите за персонализиране на „софтуер под наем“ се признават като нематериален актив от ползвателя, когато са извършени:

- от доставчика на софтуера или от трета независима страна, или

- от клиента и едновременно с това са изпълнени допълнителните критерии за признаване на вътрешно създаден нематериален актив.

Разходите за конфигуриране на софтуера, както и тези разходи за персонализирането му, които не отговарят на дефиницията или на условията за признаване на нематериален актив, се признават за текущи.

5. Момент на признаване на разходите, които не формират нематериален актив

Поначало разходите за даден нематериален обект, които не формират част от стойността на нематериален актив, за счетоводни цели се отчитат като текущи. (МСС 38, пар. 68). За признаването на тези разходи в МСС 38 се съдържат три допълнителни и взаимно допълващи се пояснения:

Когато направените разходи са за външни услуги, разходите се признават в момента на получаване на съответната услуга (пар. 69).

Услугите се считат за получени в момента на тяхното извършване от доставчика в съответствие с условията на договора (пар. 69А).

Не се изключва възможността предприятието да признае направено авансово плащане към доставчика като актив, когато плащането е извършено преди услугите да са получени (пар. 70).

Моментът на признаване на разходите за внедряване на софтуер под наем, от които не възниква нематериален актив, на пръв поглед изглежда съвсем ясен – те би следвало да се признаят в момента на извършване на услугата по внедряване на софтуера.

Според разбирането на КРМСФО този извод е правилен, но само в случаите, когато разходите са извършени от:

от клиента-ползвател или

от независимо трето лице (което не е подизпълнител на доставчика на софтуера).

За най-често срещания в практиката случай, при който дейностите по внедряване се възлагат на доставчика на софтуера, е необходим допълнителен анализ.

Очакването на КРМСФО е анализът да протече в следната логическа последователност:

Клиентът трябва да се опита да се постави на мястото на доставчика и да анализира сключеното между тях споразумение от негова гледна точка;

Клиентът мислено трябва да приложи изискванията на МСФО 15 Приходи от договори с клиенти, за да определи дали услугите по внедряване на софтуера са отделни от услугата по предоставяне на достъп до него.

Услугите по внедряване са отделни по смисъла на МСФО 15, когато

- естеството им позволява да бъдат отделени по принцип (пар. 27, б. „а) и

- услугите са разграничими в контекста на конкретния договор (пар. 27, б.“б“)

Услугите не са разграничими в контекста на договора, когато:

- доставчикът предоставя съществена услуга по обединяването на услугите по внедряване с услугата по достъп до софтуера (пар. 29, б. „а“);

- услугите по внедряване съществено изменят услугата за предоставяне на достъп (пар. 29, б. „б“);

- услугите по внедряване и по предоставяне на достъп са силно взаимозависими или силно взаимосвързани (пар. 29, б. „в“).

От гледна точка на доставчика на софтуера:

- ако услугите не са отделни по смисъла на МСФО 15, те се комбинират в една обща услуга, приходът от която се признава на линейна база за срока на договора;

- ако услугите са отделни по смисъла на МСФО 15, приходът от услугата по внедряване се признава в момента на извършването ѝ, а приходът от услугата за предоставяне достъп до софтуера – на текуща база за срока на договора.

Клиентът трябва да приложи огледален модел на отчитане при признаването на разходите. С други думи:

- ако получените услуги не са отделни, те се комбинират в една обща услуга, разходът за която се признава на линейна база за срока на договора.

- ако услугите са отделни, разходът за услугата по внедряване се признава в момента на извършването ѝ, а разходът за услугата за получаване на достъп до софтуера – на текуща база за срока на договора.

Тази интерпретация на приложимата отчетна рамка на пръв поглед изглежда странна, но същевременно не е лишена смисъл.

Като формално основание за възприетото тълкуване се използва препратката към момента на извършване на услугата от доставчика в МСС 38 (пар. 69А).

Може дълго да се спори на семантична основа дали извършването на услугата от доставчика трябва непременно да се отъждествява с момента на признаване на счетоводен приход от него.

Малко вероятно е действително такъв да е бил първоначално заложеният в това правило смисъл[3].

По-важното в случая обаче е, че тази логика може да доведе до по-смислен и по-достоверен финансов резултат за клиента.

Този извод може най-добре да се илюстрира с конкретен пример.

Пример 4:

Предприятие възнамерява да наеме софтуер за автоматизирано попълване на пътни книжки според данните от GPS устройствата на служебните автомобили.

Договорът за ползване на софтуера ще бъде сключен за пет години.

Едно от основните изисквания на предприятието е чрез данните от софтуера да може лесно да се разграничава личното от служебно ползване на автомобилите.

Предприятието получава две оферти:

Оферта от доставчик, чийто софтуер А разполага с желаната от предприятието допълнителна функционалност. Месечната абонаментна такса за използването на софтуера възлиза на 500 лв.
Оферта от доставчик, чийто софтуер Б не разполага с тази функционалност. Доставчикът обаче е склонен срещу еднократно допълнително възнаграждение в размер на 6 хил. лв. да доработи софтуера, така че той да отговори на всички изисквания на клиента. Единственото условие на доставчика за тази допълнителна разработка е той да има правото да предлага модифицираната версия на софтуера на други свои клиенти. Месечната абонаментна такса за използването на софтуер Б възлиза на 400 лв.

Анализ:

Прави впечатление, че двете оферти предлагат еднаква функционалност при идентична (в номинално изражение) обща сума на разходите за срока на договора.

Същевременно преди публикуването на решението на КРМСФО можеше да се достигне до различно счетоводно третиране на двата договора:

при сключване на договор с доставчик А предприятието-ползвател щеше месечно да признава текущ разход в размер на 500 лв.;

при сключване на договор с доставчик Б предприятието-ползвател вероятно щеше да признае:

- цялата платена сума за мофицириране на софтуера (6 хил. лв.) още в момента на завършване на разработката (модифицирането не отговаря на дефиницията за нематериален актив поради липсата на контрол); и

- текущ месечен разход от 400 лв. за правото на ползване на софтуера.

Крайният финансов резултат за целия срок на договора и в двата случая би бил еднакъв, но щеше да има разминаване в момента на признаване на разходите.

След публикуването на Решението на КРМСФО е много по-вероятно двете хипотези да бъдат счетоводно отчетени по един и същ начин.

Съгласно изискванията на МСФО 15, дори да приемем, че услугата по доработка на софтуер Б може да бъде отделна по своето естество от услугата по предоставяне на достъп до софтуера (т.е. условието на от пар. 27, б. „а“ да е изпълнено), тя категорично не представлява отделно обещание в контекста на договора (т.е. условието на пар. 27, б. „б“ категорично не е изпълнено)

Причината е, че (съобразявайки се с трите допълнителните изисквания на пар. 29):

достъпът до модифицираната версия на софтуера представлява една обща услуга или по-скоро пакет от услуги, формиращи общ краен продукт (условието в пар. 29, б. „а“ е изпълнено);

доработката на софтуера съществено изменя стандартната му функционалност (условието в пар. 29, б. „б“ е изпълнено);

клиентът не би сключил договор с доставчика за ползване на стандартната версия на софтуера без желаната от него модификация (условието в пар. 29, б. „в“ е изпълнено).

В обобщение, на база на извършения анализ може да обосновано да се заключи, че действителната цел на доставчика на софтуер Б е:

не да продаде две отделни услуги (достъп до стандартен софтуер и услуга по персонализиране),

а един общ продукт (услуга за достъп до интегриран софтуер с допълнителна функционалност).

Следователно при договор Б клиентът признава общото дължимо възнаграждение по договора (30 000 лв. = 6000 лв. + 60 месеца х 400 лв.) на линейна база за целия му срок (60 месеца).

Получава се месечен разход за услугата за достъп до модифицирания софтуер в размер на 500 лв.

Счетоводното третиране в двете хипотези е обобщено в таблицата по-долу:

	Софтуер А		Софтуер Б
В момента на сключване на договора	-		Д-т с/ка Разходи за бъдещи периоди К-т с/ка Парични средства	6000 6000
В края на всеки месец	Д-т с/ка Разходи за външни услуги К-т с/ка Доставчици	500 500	Д-т с/ка Разходи за външни услуги К-т с/ка Доставчици К-т с/ка Разходи за бъдещи периоди	500 400 100

Накрая трябва да се обърне внимание, че е много малко вероятно моделът на отчитане чрез обединяване на получените услугите да се приложи към услугите по конфигурирането на софтуера. Причината е, че този вид услуги по всяка вероятност няма да отговарят на изискванията на МСФО 15 за комбинирането им.

Пример 5:

Предприятие решава да премине към използването на уеб-базиран софтуер за управление на складовото стопанство.

Софтуерът е напълно функционален, без да е необходима каквото и да е допълнителна настройка.

Въпреки това предприятието желае софтуерът да се настрои в рамките на съществуващата му функционалност, така че по-точно да отговаря на индивидуалните му потребности.

Конфигурирането не е сложно и може да бъде извършено от различни доставчици, но е възложено на доставчика срещу допълнително възнаграждение.

Анализ:

Разходите за конфигуриране на софтуера не отговарят на дефиницията за нематериален актив и трябва да се признаят за текущи.

По отношение на момента на признаването им предприятието-ползвател трябва да приложи изискванията на МСФО 15 за комбиниране на услугите от гледна точка на доставчика.

Предприятието оценява критериите в МСФО 15, за да определи дали двете услуги (достъп до софтуера и конфигурация) са отделни.

Изследват се двата кумулативни критерия в пар. 27 от МСФО 15:

Отделни ли са услугите по своето естество (пар. 27, б. „а“)?

Неконфигурираният софтуер е напълно функционален и не се нуждае от специална конфигурация, а услугите по конфигурирането му могат свободно да се извършат от други доставчици. Следователно двете услуги са отделни по естеството си.

Разграничими ли са услугите в контекста на договора (пар. 27, б. „б“)?

Предприятието взема под внимание допълнителните факторите в пар. 29 от МСФО 15, за да определи дали двете услуги са разграничими в контекста на договора (т.е. дали представляват входящи ресурси за общ краен продукт):

(а) Доставчикът не предоставя услуга по значително обединяване на услугите. Доставчикът е поел два отделни ангажимента - да предостави достъп до софтуер и след това да го конфигурира. Той ще е в състояние да изпълни своето обещание за предоставяне на достъп до софтуера независимо и отделно от обещанието си за последващата му конфигурация.

(б) Конфигурирането на софтуера не изменя съществено функционалността на софтуера.

(в) Въпреки че клиентът не може да се възползва от услугите по конфигуриране преди да е получил достъп до самия софтуера, двете услуги не си влияят съществено, т.е. не са силно взаимозависими или силно взаимосвързани.

Всеки от факторите, без да е самостоятелно решаващ, допринася за заключението, че достъпът до софтуера и услугите по конфигурирането му са отделно разграничими.

Следователно предприятието трябва да признае разходите за конфигуриране на софтуера в момента на извършването им, а не да ги разсрочва за срока на договора.

[1] За обстоен коментар на това Тълкувателно решение, както и за анализ на другите възможности за счетоводно отчитане на този вид споразумения (третиране като лизингов договор или като нематериален актив) виж публикувания на сайта на списанието видеоматериал от 22.04.2021 г.

[2] По друг начин би стоял въпросът, ако клиентът използваше стандартен и широко разпространен складов софтуер. Тогава доставчикът би могъл да предлага допълнително разработения интерфейс и на други свои клиенти. В този случай решаваща роля щяха да имат правата на интелектуална собственост върху интерфейса.

[3] До друг извод се достига чрез изследване на генезиса на въпросната норма. Всъщност идеята на това правило е била да се противодейства на неправомерното разсрочване във времето на разходите за промоция и реклама. Прилагането на това правило в случая обаче ще има точно обратния ефект, позволявайки по-честото разсрочване на разходите. Освен това никъде в документите за обсъждане на това изменение не се реферира към момента на признаване на приход от доставчика.

ХИЛЯДИ е-статии ВЕДНАГА след като се абонираш (тук) за е-сп. "Данъци ТИТА" за 2022 г.