Si no se toma esta medida inicial, podría resultar difícil separar correctamente los costos entre los que deben capitalizarse y los que deben contabilizarse como gastos. This could lead to errors in the application of GAAP as well as errors in the amount of net income or loss entities report., Este artículo está diseñado para ayudar a los lectores a responder a esta pregunta: ¿qué costos de software deben capitalizarse y qué costos deben gastarse cuando una entidad construye software de uso externo utilizando un entorno de desarrollo ágil?
la tendencia hacia el desarrollo ágil
el método de desarrollo de software conocido como ágil se ha vuelto popular en la industria del software en los últimos años., Debido a que el enfoque ágil (consulte el gráfico «enfoque ágil») se percibe ampliamente como más rápido y más receptivo a los requisitos que cambian rápidamente, muchas empresas lo utilizan ahora como una alternativa preferida al enfoque tradicional de desarrollo en cascada.
el enfoque convencional de desarrollo en cascada implica organizar un proyecto en una serie de fases tradicionales, tales como Concepción, iniciación, análisis, diseño, construcción, pruebas, producción e implementación, y mantenimiento., Estas fases están marcadas por actividades, que la Guía utiliza como marco para llegar a una conclusión sobre cuándo se logra la viabilidad tecnológica y se pueden capitalizar los costos del proyecto de desarrollo de software.
bajo un modelo ágil, por otro lado, un proyecto se organiza en módulos separados, y el trabajo de desarrollo y prueba de estos módulos se realiza en sprints cortos., Identificar cuándo ocurren las actividades tradicionales del enfoque de cascada requiere un análisis y un juicio significativos en el desarrollo ágil, lo que puede dificultar la aplicación de la guía GAAP para capitalizar los gastos.
en última instancia, los modelos agile y waterfall pueden producir un proyecto exitoso; sin embargo, determinar el punto en el proceso de desarrollo de software para comenzar y terminar capitalizando los costos puede ser más difícil con el modelo agile.,
2 conjuntos de reglas de capitalización de software
como punto de partida para capitalizar adecuadamente los costos de desarrollo de software, es importante determinar la orientación adecuada. Según los PCGA de los Estados Unidos, pueden aplicarse dos conjuntos potenciales de reglas principales al determinar si los costos de desarrollo de software deben capitalizarse o gastarse.
Un conjunto de reglas (FASB Accounting Standards Codification (ASC) Topic 985, Software) está diseñado para los costos de software que la entidad tiene la intención de vender o arrendar., Estas reglas, comúnmente conocidas como reglas de capitalización de software para software de uso externo, son el enfoque principal de este artículo. El otro conjunto de reglas (ASC tema 350, Intangibles — fondo de comercio y otros) rige el software que la entidad no tiene la intención de vender o arrendar. Estas reglas comúnmente se conocen como reglas de capitalización de software para software de uso interno.
es importante tener en cuenta que el umbral de capitalización es menor para el software de uso interno., Bajo las reglas de software de uso interno, los costos de desarrollo generalmente se pueden capitalizar después del final de la etapa preliminar del proyecto. El umbral para los costos de desarrollo de software para la venta externa o la concesión de licencias — el enfoque de este artículo — es más estricto, lo que significa que se requiere más análisis para determinar qué costos de desarrollo deben capitalizarse.
donde los PCGA y la metodología ágil no se alinean
en el tema 985, la cuestión crítica para determinar si los costos de desarrollo de software de uso externo deben capitalizarse gira en torno al término «viabilidad tecnológica.,»Cualquier costo de desarrollo de software que se incurra antes del punto en el que el proyecto ha demostrado la viabilidad tecnológica debe ser contabilizado como gasto a medida que se incurre.
una vez que se ha establecido la viabilidad tecnológica, la mayoría (pero no todos) los costos de desarrollo pueden capitalizarse. Por último, una vez que se ha completado el desarrollo y el software está disponible para su lanzamiento a los clientes, la capitalización ya no es apropiada porque los costos restantes se consideran mantenimiento y soporte continuos. Estos gastos siempre deben contabilizarse como gastos a medida que se efectúan.,
La definición de «viabilidad tecnológica» es, por lo tanto, el factor crítico para determinar cuándo una empresa debe comenzar a capitalizar sus costos de desarrollo. El tema 985 dice :» la viabilidad tecnológica de un producto de software informático se establece cuando la entidad ha completado todas las actividades de planificación, diseño, codificación y pruebas que son necesarias para establecer que el producto puede ser producido para cumplir con sus especificaciones de diseño, incluidas las funciones, características y requisitos de rendimiento técnico.,»También es importante tener en cuenta que los costos de desarrollo de software están sujetos a estas reglas, independientemente de si los costos se generaron internamente (como el tiempo de los empleados) o externamente (como las tarifas de los proveedores).
en proyectos de desarrollo de software convencionales con fases consecutivas bien definidas, la viabilidad tecnológica generalmente se demuestra a través de un diseño de programa detallado o, cuando no existe un diseño de programa detallado, un modelo de trabajo que está listo para las pruebas del cliente. Estos son hitos familiares para proyectos que utilizan el enfoque de cascada.,
en un entorno de proyecto ágil, sin embargo, las funciones y características individuales se desarrollan por separado en una serie de sprints. Cada sprint o módulo se concibe, planifica, financia, desarrolla y prueba individualmente para ser incorporado al proyecto general cuando esté listo.
en tal entorno, los diseños integrales de programas o los modelos de trabajo a menudo son imprácticos o irrelevantes., Las empresas que utilizan un enfoque ágil para desarrollar software podrían llegar a la conclusión inapropiada de que la viabilidad tecnológica no se ha cumplido significativamente antes de que la mejora del software esté disponible para los clientes, lo que resulta en que los costos se contabilizan como gastos en lugar de capitalizarse. Si se acumulan costos significativos entre el momento en que se alcanzó realmente la viabilidad tecnológica y el momento en que el software está disponible para los clientes, la contabilidad resultante podría ser inconsistente con los PCGA.,
aplicar los GAAP en un entorno ágil
aunque las directrices actuales de los GAAP para el software de uso externo no están adaptadas al entorno ágil, eso no significa que los costos de desarrollo ágil no puedan capitalizarse en absoluto. Después de todo, hay diferentes niveles de agilidad. Si bien un proyecto ágil puro puede comenzar con solo una idea y relativamente poco trabajo de diseño, algunos proyectos ágiles tienen diseños de programas detallados con guiones gráficos en profundidad, estudios de aceptación del mercado y otros documentos de trabajo de diseño reunidos antes de que comience el desarrollo real., Esos documentos podrían utilizarse para ayudar a evaluar la viabilidad tecnológica.
el punto crítico a recordar es que para evaluar los costos que deben capitalizarse, es necesario que haya suficiente planificación del proyecto para demostrar que se han cumplido los criterios para un «diseño detallado del programa». El riesgo es que los equipos del proyecto no hagan suficiente planificación inicial o no conserven la documentación adecuada para demostrar que han alcanzado este umbral., Demostrar la viabilidad tecnológica es probable que requiera que el equipo del proyecto haga más planificación y compile más documentación de lo que es típico en la mayoría de los proyectos ágiles.
otras consideraciones importantes a la hora de determinar la viabilidad tecnológica se refieren a las características de desarrollo de alto riesgo. Por ejemplo, ¿es el proyecto una plataforma de software completamente nueva, o es una mejora o recreación de algo que se ha hecho antes? ¿Está la compañía desarrollando software desde cero, o está juntando varios componentes de software que ya existen?, Las características de desarrollo de alto riesgo pueden requerir un análisis adicional del momento en que se alcanza la viabilidad tecnológica y, en algunos casos, la contabilización de los costos previamente capitalizados.
Las mejoras de productos que no se consideran actividades de mantenimiento a veces pueden cumplir con el umbral de viabilidad tecnológica más fácilmente porque los desarrolladores están agregando funciones a un producto ya exitoso. Los factores decisivos en tales casos incluyen el tipo de software, el nivel de modificación requerido y el nivel de trabajo de diseño que se completó antes del inicio del desarrollo.,
incluso cuando se establece la viabilidad tecnológica, no todos los costos de desarrollo ágil se pueden capitalizar. En la mayoría de los casos, solo algunos de los costos en cada sprint se pueden capitalizar. Los costos que no deben capitalizarse incluyen el análisis inicial, la adquisición de conocimientos, la planificación inicial del proyecto, la creación de prototipos y el trabajo de diseño comparable que se debe realizar para lograr una comprensión de las características y la viabilidad deseadas del producto.
pero grandes porciones de los costos incurridos para desarrollar y probar tales características a menudo deben capitalizarse si se logra la viabilidad tecnológica., Estos costos incluyen la codificación real, las pruebas y los costos de mano de obra asociados.
tenga en cuenta, sin embargo, que cualquier costo relacionado con el mantenimiento o la corrección de errores que se incurra durante el sprint puede necesitar ser contabilizado en lugar de capitalizarse, ya que muchas actividades durante el sprint pueden no ser codificación y pruebas, pero pueden ser actividades como solución de problemas y descubrimiento. Además, la capitalización termina una vez que el proyecto está completo y el software está listo para su uso.,
distinguir entre los costos que se pueden capitalizar y los que no se pueden capitalizar puede complicar un poco los pasos de contabilidad, informes y documentación del proyecto dentro de cada sprint. Pero el trabajo administrativo adicional no tiene por qué ser oneroso. En la mayoría de los casos, las diversas tareas y entregables dentro de cada sprint se pueden segmentar en categorías amplias, de modo que todos los costos asociados con esa tarea se pueden contabilizar como gastos o capitalizar.,
preparación y comunicación: los pasos críticos
decidir qué costos de desarrollo de software de uso externo se pueden capitalizar en un entorno de proyecto ágil implica una cierta cantidad de juicio. En muchos casos, los hechos y circunstancias específicos que rodean el tipo de software que se está desarrollando impulsarán el tratamiento de los costos. Una planificación cuidadosa puede ayudar en el análisis de qué costos capitalizar frente a los gastos.,
por esta razón, generalmente es aconsejable discutir el tratamiento contable con el equipo de gestión del proyecto y los expertos en la materia antes de comenzar cualquier proyecto de desarrollo grande. También es importante comprender desde el comienzo de un proyecto el nivel de apoyo y documentación que se necesitará para poder tomar las decisiones apropiadas con respecto a la capitalización de los costos. Además, se requiere una comprensión clara del nivel de documentación que será necesario mantener para que los auditores evalúen y confirmen las decisiones sobre capitalización y gastos.,
por ejemplo, el equipo del proyecto debe documentar minuciosamente el papel de cada persona en el proyecto para que la contabilidad pueda distinguir entre aquellos individuos cuyo tiempo y actividades podrían potencialmente estar sujetos a capitalización y aquellos cuyas actividades nunca caerían en esta categoría. También es importante mantener controles internos adicionales, como revisiones mensuales de las actividades, montos capitalizados y gastados, y plantillas de comunicación que los gerentes de proyecto pueden llenar para verificar que el tiempo de los empleados está codificado correctamente.,
aunque se ha producido alguna discusión en la industria sobre la actualización de los estándares relevantes para hacerlos más aplicables al marco ágil, tales actualizaciones generalmente implican varios años de planificación, discusión, propuestas y comentarios de la industria. Eso significa que, en el futuro previsible, las empresas que utilizan un modelo ágil para desarrollar software para venta externa o licencias tendrán que continuar coordinando estrechamente con sus equipos de contabilidad para aplicar las directrices GAAP existentes y capitalizar los costos de desarrollo de manera adecuada.
Deja una respuesta