Разходи за внедряване в облак, обяснени: Кои разходи за хостинг настройка се капитализират съгласно ASC 350-40

Компанията ви току-що подписа тригодишен договор за облачен ERP на стойност $60 000 годишно, плюс оферта за внедряване от $90 000 от консултантите на доставчика. Ето въпроса, който вашият главен счетоводител ще зададе, преди да бъде платена първата фактура: тези $90 000 удрят ли изцяло печалбата и загубата за това тримесечие, или остават в баланса и се разпределят като разход по малко всеки месец в продължение на три години? Отговорът променя отчетената ви печалба с десетки хиляди долари през първата година и се ръководи от едно счетоводно правило, за което повечето малки бизнеси никога не са чували.

Това правило е ASC 350-40, изяснено от Актуализацията на счетоводните стандарти 2018-15 на FASB. То определя кои разходи за настройка на облак се капитализират и кои се отчитат като разход. Направете го правилно и финансовите ви отчети съответстват на икономиката на сделката. Направете го грешно и или подценявате печалбата за тази година, или носите фиктивен актив, който вашият одитор ще ви накара да отпишете. Това ръководство преминава през правилото етап по етап, със счетоводните записи в доказателство.

Защо разходите за настройка на облак се нуждаеха от собствено правило​

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

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

ASU 2018-15 го поправи, като изравни двата модела. Разходите за внедряване при хостинг споразумение, което е договор за услуга, вече се оценяват точно както ако бяха разходи за проект за софтуер за вътрешно ползване съгласно ASC 350-40. Някои се капитализират. Уловката е, че кои разходи отговарят на условията зависи изцяло от етапа на проекта, в който попадат — а етапите са по-тесни, отколкото повечето хора очакват.

Първи въпрос: договор за услуга или лиценз за софтуер?​

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

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

1. Имате договорното право да влезете във владение на софтуера по всяко време през периода на хостване без значителна неустойка.
2. Осъществимо е за вас да стартирате софтуера на собствен хардуер или да сключите договор с друга страна да го хоства.

За типичен SaaS абонамент за малък бизнес — QuickBooks Online, NetSuite, HubSpot, облачен ERP — и двете условия се провалят. Не можете да вземете кода вкъщи и не бихте могли да го стартирате сами, дори да го направите. Така че това е договор за услуга, абонаментните такси се отчитат като разход при получаване на услугата, а разходите за внедряване преминават през триетапния тест по-долу.

Обърнете внимание какво правилото не променя: счетоводното отчитане на самия елемент на услугата. Вашите месечни или годишни хостинг такси все още са обикновен оперативен разход. Само еднократните разходи за внедряване и настройка преминават през анализа за капитализиране или разход.

Трите етапа, които решават всичко​

ASC 350-40 разделя всеки софтуерен проект на три етапа. Етапът определя третирането, без изключения.

Етап 1: Предварителен проект — всичко е разход​

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

• Оценяване и избор на доставчици, издаване на RFPs, присъствие на демонстрации
• Определяне на системните изисквания и реинженеринг на бизнес процесите
• Консултанти, наети да ви помогнат да изберете платформа
• Решението за окончателно одобрение — ръководството официално одобрява и финансира проекта

Всеки долар в този етап се отчита като разход в момента на възникването му. $15 000, които сте платили на независим консултант да сравни три ERP системи и да препоръча една? Разход. Вътрешното време, което екипът ви е прекарал в картографиране на изискванията преди подписването? Разход. Нищо не се капитализира, докато ръководството не е одобрило проекта и не е вероятно проектът да бъде завършен и софтуерът да бъде използван по предназначение.

Етап 2: Разработка на приложение — капитализирайте това, което отговаря на условията​

След като проектът бъде одобрен, вие влизате в етапа на разработка на приложение и това е единственият етап, в който се извършва капитализиране. Капитализируемите разходи включват:

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

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

Етап 3: След внедряване и експлоатация — всичко е разход​

След като системата (или модул от нея) влезе в експлоатация, вие отново отчитате всичко като разход:

• Поддръжка, съдействие и дребни поправки на грешки
• Разходи за обучение — винаги се отчитат като разход, независимо кога възникват
• Разходи за преобразуване и миграция на данни — отчитат се като разход в момента на възникването им
• Текуща администрация и реинженеринг на процесите след пускане в експлоатация

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

Защо обучението и преобразуването на данни все още са разход​

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

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

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

На практика това означава, че трябва да разделяте фактурите на доставчика по дейност, а не просто да ги плащате. Едно извлечение за внедряване от $90 000 може да съдържа $50 000 конфигурация (капитализиране), $25 000 миграция на данни (разход) и $15 000 обучение на крайни потребители (разход). Помолете доставчика да разбие времето по дейност, преди проектът да започне — реконструирането на разделянето по време на одита от фактура с обща сума е болезнено и одиторите ще предположат най-лошото за недокументирани суми.

Амортизиране на това, което сте капитализирали​

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

Срокът на хостване включва периода без право на прекратяване плюс всички периоди на подновяване, които разумно сте сигурни, че ще предприемете. Едногодишен договор, който напълно очаквате да подновите два пъти, се амортизира за три години, не за една. Това субективно решение има значение: амортизирането на $50 000 за една година е $4 167 месечен разход, докато разпределянето за три години е $1 389. Документирайте предположението за подновяване, когато го установите.

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

• Разходът за амортизация отива на същия ред в отчета за приходите и разходите като хостинг таксите — обикновено общи и административни или оперативния разходен ред, където живее абонаментът. Не го погребвайте в амортизация или отделен ред за амортизация с другите ви нематериални активи.
• Платените в брой средства за внедряване следват хостинг таксите в отчета за паричните потоци — оперативни дейности, не инвестиционни.

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

Счетоводните записи, от начало до край​

Да речем, че подписвате тригодишен договор за облачен ERP. Внедряването се разбива на $50 000 конфигурационна работа (капитализируема), $25 000 миграция на данни (разход) и $15 000 обучение (разход). Ето пълния жизнен цикъл.

Плащане на фактурите за внедряване:

2026-11-15 * "Cloud ERP vendor" "Implementation - configuration phase"
  Assets:Prepaid-Expenses:Cloud-Implementation  50,000.00 USD
  Expenses:Professional-Fees:Data-Migration      25,000.00 USD
  Expenses:Training:ERP-End-User                 15,000.00 USD
  Assets:Checking:Operating                     -90,000.00 USD

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

Месечна амортизация през 36-месечния срок на хостване ($50 000 / 36 = $1 388,89):

2026-12-31 * "Amortize cloud ERP implementation costs" ""
  Expenses:G-and-A:Software-Subscriptions   1,388.89 USD
  Assets:Prepaid-Expenses:Cloud-Implementation  -1,388.89 USD

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

Пет грешки, които препъват малките бизнеси​

1. Отчитане на всичко като разход от предпазливост. Навикът отпреди 2018 г. остава. Ако отчетете целия $90 000 като разход през първата година, когато $50 000 е трябвало да бъдат в баланса, вие подценявате печалбата за първата година и надценявате следващите. Кредиторите, четящи отчетите ви, виждат по-лоша картина на обслужването на дълга от реалността.

2. Капитализиране на работата по избор на доставчик. Предварителният етап е по-широк, отколкото хората мислят. Стратегическото консултиране, подкрепата за RFP и анализа на изискванията, извършени преди ръководството да е одобрило проекта, се отчитат като разход — дори ако същата консултантска фирма по-късно извърши внедряването. Датата на одобрение е разделителната линия; разходите преди нея никога не отговарят на условията.

3. Капитализиране на миграцията на данни, защото „изглежда като“ внедряване. Това е работа по внедряване на прост език, но не е капитализируем разход съгласно ASC 350-40. Доставчиците на миграция предлагат пакети с фиксирана цена, които замъгляват тази линия. Вземете разбивката по дейност писмено.

4. Амортизиране за грешен срок. Използването на едногодишния първоначален срок, когато разумно сте сигурни, че ще подновите, натоварва разхода в началото и подценява актива. Обратно, разтягането на амортизацията за подновявания, за които не сте ангажирани, подценява текущия разход. Преразгледайте предположението, ако плановете се променят — решението да не подновявате съкращава оставащия живот за в бъдеще.

5. Игнориране на разликата между счетоводство и данъци. За федерални данъчни цели разходите за внедряване в облак обикновено се приспадат като обикновени и необходими бизнес разходи, когато бъдат платени или възникнали — няма данъчен еквивалент на капитализацията по ASC 350-40 за повечето настройки с договори за услуга. Това означава, че вашите книги показват актив и амортизация, докато данъчната ви декларация показва незабавно приспадане. Проследявайте разликата в работните документи за дълготрайни активи или отсрочени данъци, така че да се обърне чисто, вместо да се превърне в постоянна мистериозна позиция за равнение.

Практически контролен списък за следващото ви внедряване в облак​

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

1. Дата на одобрението. Вземете писмено одобрение от ръководството с ангажимент за финансиране и третирайте разходите преди тази дата автоматично като разход от предварителния етап.
2. Изисквайте фактуриране на ниво дейност. Изявлението за работа трябва да разделя конфигурацията и персонализацията, интеграциите, тестването, миграцията на данни и обучението на отделни редове с отделни ставки или фиксирани такси.
3. Настройте акаунта за активи рано. Създайте акаунт за предплатен актив за внедряване за всяко споразумение (не един обединен акаунт), така че графиците за амортизация и прегледите за обезценка да останат чисти, когато управлявате множество системи.
4. Отбележете срока на хостване. Запишете периода без право на прекратяване, очакваните подновявания и обосновката и ги прикачете към графика за амортизация.
5. Планирайте прегледа за обезценка. Поне веднъж годишно — и винаги когато обмисляте смяна на доставчик или извеждане от експлоатация на модул — питайте дали балансовата стойност все още има бъдеща полза.

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