Diagrama de Flujo de Ingresos: Sector Tecnológico | ciferi

Navegue por el modelo de cinco pasos de la NIIF 15 con orientación específica para el sector tecnológico español

La NIIF 15 Ingresos de Actividades Ordinarias presenta un dificultad particular para las entidades del sector tecnológico. El software como servicio (SaaS), las licencias de software, los servicios de aplicación integrados, y los acuerdos de mantenimiento generan estructuras de ingresos que no siempre encajan de forma clara en el modelo de cinco pasos.
Este diagrama de flujo interactivo le guía a través de la identificación de obligaciones de desempeño, la determinación del precio de transacción, y la asignación de consideración en los acuerdos tecnológicos más complejos que audita.
---

¿Por qué los ingresos tecnológicos requieren atención especial?

Las entidades de tecnología en España operan bajo la NIIF 15 sin excepciones. Sin embargo, los riesgos de reconocimiento de ingresos en este sector son persistentes en la actividad inspectora de la ICAC y en los hallazgos internacionales de calidad de auditoría.
Patrones recurrentes en auditoría:
Los auditores frecuentemente no desafían con rigor la identificación de obligaciones de desempeño distintivas en acuerdos que combinan licencias de software, servicios de aplicación y contratos de mantenimiento. Cuando una entidad promete múltiples elementos (software + instalación + soporte técnico), la pregunta crítica es: ¿son cada uno de estos elementos distintivos, o forman una obligación de desempeño única?
Del mismo modo, la asignación del precio de transacción a cada obligación depende de precios de venta independientes. En el sector tecnológico, estos precios raramente se establecen en transacciones independientes. La entidad debe estimar el precio de venta independiente (PVI) usando métodos apropiados (enfoque de costo incrementado, enfoque de mercado ajustado, u otro método de asignación).
Por último, el reconocimiento a lo largo del tiempo versus en un momento puntual requiere evaluar si el cliente recibe y consume simultáneamente los beneficios (criterio de NIIF 15.35(a)) o si la entidad crea un activo que el cliente controla (criterio de NIIF 15.35(b)). En acuerdos SaaS, esto casi siempre es reconocimiento a lo largo del tiempo. Pero en acuerdos de aplicación con un resultado claramente identificable, puede ser en un momento puntual.
---

Usando este diagrama de flujo

Paso 1: Identificar el contrato: Valide que existe un contrato con un cliente, que las cinco condiciones de NIIF 15.9 se cumplen, y que no existen modificaciones de contrato no contabilizadas.
Paso 2: Identificar obligaciones de desempeño: Para cada elemento prometido (software, aplicación, mantenimiento, soporte), determine si es distintivo. Aquí es donde ocurren la mayoría de los errores en auditoría.
Paso 3: Determinar el precio de transacción: Calcule la consideración esperada, incluida cualquier consideración variable, componentes de financiación significativos, y consideración no monetaria.
Paso 4: Asignar el precio de transacción: Distribuya la consideración total entre cada obligación de desempeño usando los precios de venta independientes estimados.
Paso 5: Reconocer ingresos: Determine si cada obligación se satisface en un momento puntual o a lo largo del tiempo, y aplique el método de medida de progreso correcto.
---

Paso 1: Identificación del contrato (NIIF 15.9–21)

Valide que existe un contrato con un cliente evaluando cinco criterios. Considere también si los contratos deben combinarse y si ha habido modificaciones.

¿Han aprobado las partes el contrato y se han comprometido a cumplir con sus obligaciones respectivas?

Referencia: NIIF 15.9(a)
La aprobación puede ser escrita, oral, o implícita por práctica comercial habitual. El compromiso significa que las partes tienen intención de hacer cumplir sus derechos respectivos.
Para un acuerdo de software SaaS típico, la aprobación es generalmente una orden de compra del cliente firmada, una propuesta aceptada del vendedor, o una secuencia de correos electrónicos confirmando los términos. No todos los acuerdos requieren un documento legal formal; una serie de comunicaciones que demuestren acuerdo sobre términos principal es suficiente.
Documentación de auditoría: Obtenga evidencia de que ambas partes aprobaron el contrato. Esto puede incluir la orden de compra, el contrato firmado, o evidencia de ejecución de los servicios sin objeción formal sobre los términos.

¿Puede la entidad identificar los derechos de cada parte respecto a los bienes o servicios a transferir?

Referencia: NIIF 15.9(b)
El contrato debe establecer derechos exigibles para cada parte. En acuerdos de tecnología, esto significa identificar claramente:
Incluso si algunos términos son implícitos (por ejemplo, "mantenimiento estándar" sin definición), los derechos deben ser identificables usando la práctica comercial habitual de la entidad.
Documentación de auditoría: Revise el contrato y la propuesta para confirmar que especifican claramente cada derecho. Si los términos son implícitos, obtenga documentación que respalde los términos estándar de la entidad (lista de precios, política de servicios estándar, etc.).

¿Puede la entidad identificar los términos de pago de los bienes o servicios a transferir?

Referencia: NIIF 15.9(c)
Los términos de pago incluyen la cantidad, el momento y la forma de consideración. Los términos no necesitan ser explícitamente establecidos si pueden determinarse a partir de prácticas comerciales habituales o los términos del contrato.
En acuerdos de SaaS, los términos de pago típicos son:
Si los términos incluyen consideración variable (por ejemplo, "soporte al usuario de €500 + €50 por usuario adicional si se exceden 100 usuarios"), estos deben estar especificados suficientemente para ser estimables.
Documentación de auditoría: Extraiga de la factura y el contrato los términos de pago. Si hay consideración variable, obtenga documentación que respalde cómo se estima (por ejemplo, uso histórico del cliente, capacidad esperada durante el período de contrato).

¿Tiene el contrato sustancia comercial (es decir, se espera que cambie el riesgo, momento o cantidad de flujos de efectivo futuros de la entidad como resultado del contrato)?

Referencia: NIIF 15.9(d)
Un contrato tiene sustancia comercial cuando se espera que cambie los flujos de efectivo futuros de la entidad. Esta condición evita que las entidades reconozcan ingresos en intercambios recíprocos de bienes o servicios de naturaleza y valor similar (por ejemplo, transacciones de trueque).
En acuerdos de tecnología, la sustancia comercial es casi siempre clara. El cliente paga efectivo (o promete pagar) a cambio de acceso a software y servicios. Hay un cambio claro en los flujos de efectivo de la entidad.
La única excepción sería un intercambio totalmente gratuito o un trueque donde la entidad proporciona software sin costo a cambio de datos o acceso comercial de valor equivalente. Incluso en estos casos, si hay valor comercial anticipado, podría haber sustancia.
Documentación de auditoría: Documente brevemente cómo el contrato afecta los flujos de efectivo de la entidad (entrada de efectivo esperada de X euros en período Y).

¿Es probable que la entidad cobre la consideración a la cual tiene derecho a cambio de los bienes o servicios que transferirá al cliente?

Referencia: NIIF 15.9(e)
Evalúe la capacidad e intención del cliente de pagar. Considere:
"Probable" bajo NIIF significa más probable que no. Si la entidad ofrece una concesión de precio (descuento por pagador anticipado, rebaja por volumen), evalúe la cobrabilidad sobre el importe esperado después de la concesión, no el precio contractual establecido (NIIF 15.9.A1).
Documentación de auditoría: Para clientes nuevos o con calificación crediticia cuestionable, obtenga un análisis de crédito (referencias de bancos, estados financieros, informes de crédito). Para clientes existentes, revise el historial de pago de períodos anteriores.
---

• ¿Qué versión del software se proporciona (número de versión, módulos, funcionalidades específicas)?
• ¿Cuál es el período de la licencia (plazo fijo, anual, perpetuo)?
• ¿Qué derechos de uso tiene el cliente (usuario único, múltiples usuarios, número de puntos de acceso)?
• ¿Qué incluye el mantenimiento (actualizaciones, parches de seguridad, soporte técnico)?
• ¿Cuál es la obligación de aplicación (horas de servicio, responsabilidades del cliente, entregables específicos)?
• Cuota anual pagada por adelantado
• Cuota mensual pagada al inicio de cada mes
• Cuota de aplicación pagada por hitos (inicio, al 50% completado, al completarse)
• Cuota de soporte técnico pagada anualmente
• Consideración variable basada en el número de usuarios activos o volumen de transacciones
• Historial crediticio del cliente
• Posición financiera actual del cliente
• Garantías o avales proporcionados
• Experiencia pasada de la entidad con clientes similares

Paso 2: Identificación de obligaciones de desempeño (NIIF 15.22–30)

Para cada bien o servicio prometido, evalúe si representa una obligación de desempeño separada probando su carácter distintivo. Evalúe también la cláusula de serie.

¿Es el bien o servicio capaz de ser distintivo (es decir, ¿puede el cliente beneficiarse de él por sí solo o junto con otros recursos fácilmente disponibles)?

Referencia: NIIF 15.27(a), 15.28
Un bien o servicio es capaz de ser distintivo si el cliente puede usarlo, consumirlo, venderlo u obtener beneficios económicos de otra forma de él, ya sea por sí solo o junto con recursos fácilmente disponibles de la entidad o terceros.
En acuerdos de tecnología:
Un indicador útil: ¿vende la entidad el elemento de forma regular por separado a otros clientes? Si es sí, es probablemente distintivo. Si nunca lo ha vendido por separado, es menos probable que sea distintivo.
Documentación de auditoría: Para cada elemento de la propuesta, documente si la entidad vende ese elemento de forma separada. Si no, obtenga evidencia de que el cliente podría beneficiarse del elemento usando recursos fácilmente disponibles (por ejemplo, software estándar que muchos proveedores ofrecen, o servicios disponibles en el mercado).

¿Es la promesa de transferir el bien o servicio separadamente identificable dentro del contexto del contrato (es decir, distinto dentro del contrato)?

Referencia: NIIF 15.27(b), 15.29
Esto es más difícil. Un bien o servicio que es capaz de ser distintivo puede no ser separadamente identificable si está en detalle integrado en otros elementos del contrato.
Indicadores de que una promesa NO es separadamente identificable (NIIF 15.29):
Ejemplos en tecnología:
Documentación de auditoría: Para cada elemento, documente:
Si la respuesta a la primera es sí y a las otras dos es no, el elemento es probablemente separadamente identificable.

¿Son los bienes o servicios en la serie sustancialmente los mismos?

Referencia: NIIF 15.22(b)(i)
La cláusula de serie se aplica cuando la entidad promete transferir una serie de bienes o servicios distintos que son sustancialmente los mismos, con el mismo patrón de transferencia.
Ejemplos en tecnología:
Documentación de auditoría: Documente si cada elemento en la serie es del mismo carácter (mismo software, mismo servicio, misma funcionalidad).

¿Tienen los bienes o servicios en la serie el mismo patrón de transferencia?

Referencia: NIIF 15.22(b)(ii)
El mismo patrón de transferencia significa que cada bien o servicio en la serie cumpliría con el mismo criterio de reconocimiento a lo largo del tiempo (NIIF 15.35) y se usaría el mismo método para medir el progreso.
En acuerdos de SaaS:
Si ambos criterios (sustancialmente los mismos + mismo patrón de transferencia) se cumplen, la serie se contabiliza como una obligación de desempeño única. Por ejemplo, 36 cuotas mensuales de SaaS por 36 euros cada una se contabilizan como una obligación única de 1.296 euros por ingresos a lo largo del tiempo durante 36 meses usando medida de progreso lineal.
Documentación de auditoría: Para cada elemento en la serie, documente el criterio de reconocimiento a lo largo del tiempo aplicable (NIIF 15.35(a), (b), o (c)) y el método de medida de progreso (tiempo, salida de unidades de trabajo, etc.). Si todos los elementos en la serie cumplen con el mismo criterio y método, pueden ser tratados como una obligación única.
---

• Licencia de software por sí sola: Generalmente distintiva si el cliente puede operar el software de forma independiente.
• aplicación de software por sí sola: Generalmente distintiva si produce un resultado identificable (base de datos configurada, sistema integrado, datos migrados).
• Mantenimiento y soporte por sí solos: Generalmente distintos si la entidad los vende por separado a otros clientes.
• Datos o servicios de datos por sí solos: Distintivos si el cliente puede usarlos con sistemas u herramientas disponibles.
• significativa: La entidad proporciona un servicio significativo de del bien o servicio con otros elementos en una salida combinada.
• Modificación o personalización significativa: El bien o servicio modifica o personaliza de forma notable otro bien o servicio prometido.
• Interdependencia: El bien o servicio es interdependiente o interrelacionado con otros elementos, significando que cada uno es afectado de forma notable por los otros.
• Software + instalación fuertemente integrada = una obligación: Si la aplicación del software requiere modificación extensa del código fuente, personalización completa, con múltiples sistemas heredados del cliente, y la entidad debe mantener la solución personalizada en funcionamiento, la instalación puede no ser separadamente identificable de la licencia. Forman una única solución integrada.
• Software + datos de migración personalizada = una obligación: Si el cliente no puede usar el software sin datos migrados del sistema anterior, y la migración requiere cambio personalizada significativa de datos, estas pueden formar una obligación única.
• Software estándar + instalación estándar = dos obligaciones: Si la entidad vende la licencia de software a otros clientes tal cual, y ofrece un servicio de instalación estándar (configuración de usuario, carga de datos estándar, entrenamiento básico) que otros clientes también reciben, la instalación es probablemente separadamente identificable.
• ¿Ofrece la entidad este elemento separadamente a otros clientes con requisitos similares?
• ¿Modificaría de forma notable este elemento otros elementos del contrato?
• ¿Podría el cliente usar este elemento sin los otros elementos, o depende completamente de los otros?
• Cuotas mensuales de SaaS: Cada mes, el cliente recibe acceso al mismo software durante 30 días. Son sustancialmente los mismos.
• Entradas de datos mensuales: La entidad procesa datos del cliente cada mes de forma idéntica. Son sustancialmente las mismas.
• Actualizaciones de licencia: La entidad proporciona actualizaciones de software cada trimestre durante tres años. Si las actualizaciones son del mismo carácter y complejidad, pueden ser sustancialmente las mismas.
• Cada mes de acceso al software se transfiere a lo largo del tiempo (el cliente simultáneamente recibe y consume beneficios, satisfaciendo el criterio de NIIF 15.35(a)).
• El progreso se mide por el tiempo transcurrido (una entrada linealmente a lo largo del período).

Paso 3: Determinación del precio de transacción (NIIF 15.47–72)

Determine el importe de consideración que la entidad espera tener derecho a recibir, considerando consideración variable, componentes de financiación significativos, consideración no monetaria, y consideración pagable al cliente.

¿Incluye el contrato algún tipo de consideración variable (por ejemplo, descuentos, reembolsos, penalizaciones, bonificaciones de desempeño, concesiones de precio, pagos de incentivo, o importes contingentes)?

Referencia: NIIF 15.50–51
La consideración variable puede surgir de:
También considere si la consideración puede variar a causa de prácticas comerciales habituales de la entidad. Por ejemplo, si la entidad regularmente ofrece concesiones de precio incluso cuando no son contractualmente requeridas (NIIF 15.52), esto es consideración variable.
Documentación de auditoría: Revise el contrato e identifique todos los términos que podrían resultar en variantemente de la cantidad establecida a ser pagada. Documente la naturaleza de la variabilidad (qué evento causa el cambio).

¿Cuál método de estimación predice mejor el importe de consideración al que la entidad tendrá derecho?

Referencia: NIIF 15.53
Dos métodos están disponibles:
Método del valor esperado: Suma de todas las salidas posibles ponderadas por su probabilidad de ocurrencia. Más predictivo cuando hay muchos posibles resultados.
Ejemplo: El acuerdo incluye una comisión de "2% de las ventas anuales del cliente por encima de 1 millón de euros." Basado en datos históricos, el cliente ha generado entre 1,2 y 1,8 millones de euros en años similares, con distribución dispersa de probabilidades. El valor esperado es aproximadamente 1,5 millones × 2% = €30.000.
Método del importe más probable: El único resultado más probable. Más predictivo cuando hay pocas salidas discretas.
Ejemplo: El contrato ofrece descuentos por pago anticipado: 2% de descuento si se paga dentro de 10 días, sin descuento después. El cliente casi siempre paga dentro de 10 días (basado en historial de 10 años sin excepción). El importe más probable es que se aplique el descuento del 2%.
Seleccione el método que su entidad juzgue que predice mejor la consideración real.
Documentación de auditoría: Documente qué método se eligió y por qué se espera que prediga mejor el resultado. Para el valor esperado, proporcione los rangos de posibles resultados y las probabilidades. Para el importe más probable, explique por qué ese resultado es el más probable.

¿Debe incluirse consideración variable en el precio de transacción, o debe estar restringida bajo NIIF 15.56–58?

Referencia: NIIF 15.56–58 (restricción de consideración variable)
Incluso después de estimar la consideración variable, el importe puede estar restringido. Debe incluirse consideración variable en el precio de transacción solo en la medida en que sea probable que no se produzca una reversión significativa de ingresos acumulados cuando la incertidumbre se resuelva.
En otras palabras, si hay riesgo importante de que el cliente no cumpla los requisitos para la consideración variable, o la consideración variable sea cobrada y luego deba ser reembolsada, restrinja la cantidad incluida.
Ejemplo de restricción: Un acuerdo de software incluye una bonificación de €50.000 si el sistema logra un tiempo de respuesta de menos de 100 milisegundos durante todo el año de contrato. El cliente es un banco grande con sistemas complejos e profunda. Históricamente, tal objetivo de desempeño se ha logrado en aproximadamente el 60% de los casos con clientes similares. Aunque el importe esperado es €30.000 (50.000 × 60%), la restricción requiere que incluyas solo el importe donde es probable que no se revierte. Esto podría ser €0 (si "probable" se interpreta como >80%) o una cantidad menor (si se interpreta como el 60% + un búfer de prudencia para reversión esperada).
Documentación de auditoría: Para cada elemento de consideración variable, evalúe:
Documente el importe que se considera probable que no será invertido, basado en su evaluación de riesgo de reversión.

¿Incluye el contrato un componente de financiación significativo (por ejemplo, plazo extendido sin interés, pago por anticipado, o tercer año de soporte deferred)?

Referencia: NIIF 15.61–65
Si el contrato efectivamente proporciona financiación (porque el momento de pago deferido significa que el cliente recibe una opción de crédito sin costo), debe ajustarse el precio de transacción por el componente de financiación. Esto se aplica si el componente de financiación es significativo.
Ejemplos en tecnología:
El ajuste solo es necesario si el componente de financiación es significativo (tipicamente una diferencia de más del 5–10% del precio total).
Documentación de auditoría: Calcule la tasa de interés implícita del contrato. Si la diferencia entre el precio de contado esperado y el precio total es significativa, incluya el ajuste de financiación. Documente la tasa de interés implícita aplicada y el cronograma de reconocimiento de interés.

¿Incluye el contrato consideración no monetaria (por ejemplo, acciones, propiedad intelectual, productos intercambiados, o derechos futuros)?

Referencia: NIIF 15.66–67
Si el cliente promete consideración no monetaria, mida el precio de transacción al precio de mercado justo de lo que el cliente promete pagar.
Ejemplos en tecnología:
Documentación de auditoría: Para consideración no monetaria, documente el método usado para estimar el valor de mercado justo (comparables en el mercado, modelos de valoración, tasaciones, etc.).

¿Incluye el contrato consideración pagable al cliente (en lugar de cobrable del cliente)?

Referencia: NIIF 15.68–72
En algunos casos raros, el vendedor paga al cliente para que acepte el contrato (por ejemplo, una compañía de software promete pagar a un cliente grande un subsidio de €100.000 para asegurar que adopte la plataforma). Esto reduce el precio de transacción (potencialmente a cero o incluso a una cifra negativa si se está bajo las obligaciones mixtas).
Ejemplo: El contrato es por acceso a software por €500.000 anuales, pero el vendedor promete un subsidio de aplicación de €150.000. El precio de transacción es €500.000 − €150.000 = €350.000.
Documentación de auditoría: Documente cualquier subsidio, apoyo, o pagos realizados por la entidad al cliente para asegurar la aceptación del contrato. Reduzca el precio de transacción por estos importes.
---

• Descuentos volumen (por ejemplo, reducción de precio si el cliente excede 100 usuarios)
• Reembolsos o créditos (por ejemplo, descuento si el cliente firma un contrato de tres años)
• Penalizaciones de desempeño (por ejemplo, rebaja si el tiempo de respuesta excede los límites del acuerdo de nivel de servicio)
• Bonificaciones de desempeño o incentivos (por ejemplo, comisiones si el software genera ventas del cliente superiores a un umbral)
• Derechos de devolución (por ejemplo, período de reembolso de 30 días)
• ¿Cuál es la probabilidad de que el cliente cumpla con las condiciones?
• ¿Cuál es el historial de cumplimiento del cliente en contratos similares?
• ¿Cuál es el riesgo de reversión (si el cliente no cumple o el desempeño se deteriora)?
• Pago en tres años sin interés: El contrato es por €300.000 pagable en tres cuotas anuales de €100.000. Si la entidad usualmente vende el software por €290.000 al contado, la diferencia de €10.000 es implícitamente interés no cobrado. Debe ajustarse el precio de transacción a €290.000 con los €10.000 de interés reconocidos en los próximos tres años.
• Soporte deferred pagado por adelantado: El cliente paga €50.000 por licencia de software + soporte de tres años, pero el soporte está diferido (comienza en el año 2). Si la tasa de interés separada de estos elementos indica que el soporte de tres años debería valer €40.000 si se proporciona ahora, pero el cliente ha pagado €50.000 (como pago por adelantado por no recibir soporte durante el año 1), el ajuste de financiación es inmaterial y podría ignorarse.
• Acuerdo de participación en ingresos: En lugar de pagos mensuales fijos, el cliente promete al vendedor el 5% de los ingresos que genera usando el software. El precio de transacción es el valor de mercado justo de los ingresos esperados (estimado según NIIF 15.47–72 usando consideración variable y restricción).
• Intercambio de licencias: Dos empresas de software intercambian el acceso a licencias del otro. Cada una mide su ingresos al precio de mercado justo de la licencia que proporciona (o la que recibe, si esta es más observable).

Paso 4: Asignación del precio de transacción (NIIF 15.73–86)

Distribuya la consideración total entre cada obligación de desempeño usando los precios de venta independientes estimados.

¿Cuál es el precio de venta independiente de cada obligación de desempeño?

Referencia: NIIF 15.73–81
Asigne el precio de transacción a cada obligación de desempeño en proporción a sus precios de venta independientes (PVI). El PVI es el precio al que la entidad vende (o vendería) la obligación de desempeño al cliente por sí solo en circunstancias similares.
Jerarquía de métodos para estimar PVI:
Ejemplo: La entidad vende licencias de software estándar por €100 por usuario anual. Un cliente en el contrato actual recibe 50 usuarios, así que el PVI para la licencia es 50 × €100 = €5.000.
Ejemplo: La entidad realiza aplicación de software. El costo estimado para este cliente es €20.000 (mano de obra de consultores + hardware de servidor). La entidad típicamente logra un margen del 40% en aplicación. El PVI estimado es €20.000 × (1 + 0,40) = €28.000.
Ejemplo: Un proveedor de datos de terceros vende datos de referencia de mercado similares por €15.000. La entidad ajusta este precio en un 10% hacia abajo porque su fuente de datos es menos actualizada, resultando en PVI de €13.500.
Documentación de auditoría: Para cada obligación, documente:

Asigne el precio de transacción total usando la proporción de PVIs

Una vez estimados todos los PVIs, asigne el precio de transacción total proporcionalmente.
Fórmula:
Precio asignado a la obligación A = (PVI de A ÷ PVI total de todas las obligaciones) × Precio de transacción total
Ejemplo:
Contrato de €100.000 por:
La asignación es proporcional:
Si el cliente negocia un descuento de €10.000, el precio de transacción es €90.000. La asignación se recomputa:
Documentación de auditoría: Prepare una tabla que muestre todos los PVIs estimados, el total, el precio de transacción, y la asignación resultante para cada obligación. Reconcilie que la asignación suma al precio total de transacción.
---

• Precio de venta observable: Si la entidad vende la obligación de desempeño de forma separada a otros clientes, use ese precio (ajustado por volumen del cliente, geografía, momento, u otras circunstancias).
• Costo incrementado: Si no hay precio de venta observable, estime el PVI como el costo de la obligación más un margen apropiado (generalmente el margen que la entidad logra en contratos comparables).
• Mercado ajustado: Si la entidad no vende la obligación de forma separada, pero otros vendedores sí, use sus precios como referencia, ajustados por las diferencias en el producto/servicio de la entidad.
• Si existe un precio de venta observable, proporcione la evidencia (facturas a otros clientes, lista de precios publicada, contrato separado con cliente diferente).
• Si se usa el método de costo incrementado, documente el costo y el margen.
• Si se usa mercado ajustado, documente los precios de referencia y el ajuste de razonabilidad.
• Licencia de software (observable): PVI = €40.000
• aplicación (costo incrementado): PVI = €35.000
• Soporte anual (costo incrementado): PVI = €25.000
• Total PVI: €100.000
• Licencia: (€40.000 ÷ €100.000) × €100.000 = €40.000
• aplicación: (€35.000 ÷ €100.000) × €100.000 = €35.000
• Soporte: (€25.000 ÷ €100.000) × €100.000 = €25.000
• Licencia: (€40.000 ÷ €100.000) × €90.000 = €36.000
• aplicación: (€35.000 ÷ €100.000) × €90.000 = €31.500
• Soporte: (€25.000 ÷ €100.000) × €90.000 = €22.500

Paso 5: Reconocimiento de ingresos (NIIF 15.31–42)

Determine si cada obligación se satisface en un momento puntual o a lo largo del tiempo, y aplique el método de medida de progreso correcto.

¿Se satisface la obligación de desempeño a lo largo del tiempo o en un momento puntual?

Referencia: NIIF 15.31–38
Una obligación se satisface a lo largo del tiempo si cumple alguno de estos tres criterios (NIIF 15.35):
Criterio 1: Cliente simultáneamente recibe y consume beneficios
El cliente recibe y consume los beneficios del desempeño de la entidad a medida que ocurre. Esto es típico de servicios continuos donde el cliente se beneficia durante el período de prestación.
Ejemplos en tecnología:
Criterio 2: Activo creado o mejorado que el cliente controla
La entidad crea un activo (tangible o intangible) que el cliente controla mientras la entidad lo construye o mejora. Esto es típico de servicios de construcción,, o desarrollo personalizado.
Ejemplos en tecnología:
Control significa el cliente puede dirigir el uso del activo y obtener beneficios de él. En desarrollo de software, si el código es propiedad del cliente (como especificar su propiedad intelectual), entonces el cliente controla el activo.
Criterio 3: Sin uso alternativo + derecho exigible al pago
La entidad no tiene uso alternativo para el activo creado (porque está tan personalizado que solo el cliente puede usarlo), Y la entidad tiene un derecho legal exigible al pago por el desempeño completado hasta la fecha.
Ejemplo: La entidad desarrolla un módulo de software único para un cliente que integra sistemas heredados específicos del cliente. El módulo no tiene valor para otros clientes (sin uso alternativo). El contrato especifica que si el cliente cancela el trabajo, la entidad retiene el derecho al pago por el trabajo completado a la fecha (derecho exigible al pago). Se cumple el criterio 3.
Una obligación que cumple al menos uno de estos criterios se satisface a lo largo del tiempo. Si ninguno se cumple, se satisface en un momento puntual.
Documentación de auditoría: Para cada obligación, explícitamente resuelva cuál de los tres criterios se aplica (o si ninguno, concluyendo satisfacción en un momento puntual). Documente la razón (citas el contrato, prácticas de la industria, etc.).

Para obligaciones satisfechas a lo largo del tiempo, ¿cuál es el método de medida de progreso?

Referencia: NIIF 15.39–41
El progreso se mide de forma que la entidad reconoce ingresos a medida que satisface la obligación. Dos métodos están disponibles:
Método de salida: Mida el progreso basado en el valor de los bienes o servicios transferidos hasta la fecha. Esto se mide observando las salidas directamente (por ejemplo, unidades completadas, hitos alcanzados, tiempo transcurrido).
Ejemplos:
Método de entrada: Mida el progreso basado en los esfuerzos o insumos incurridos por la entidad para satisfacer la obligación (por ejemplo, horas de mano de obra, costos incurridos, recursos utilizados).
Ejemplos:
Selección del método: Use el método que mejor representa el desempeño de la obligación.
Para servicios continuos (SaaS, soporte técnico), el método de salida es típicamente más simple: el tiempo transcurrido es la salida observable.
Para proyectos de aplicación con duración variable, el método de entrada (horas incurridas o costos incurridos) es típicamente más observable y fiable.
Documentación de auditoría: Documente el método elegido y la medida de progreso. Para cada período de informe (mes, trimestre), calcule el porcentaje de progreso y el ingreso resultante.
Ejemplo de cálculo:
Contrato: aplicación de software €100.000, satisfecho a lo largo del tiempo, medido por horas de consultoría incurridas.
---

• Acceso a SaaS mensual: El cliente usa el software todos los días de cada mes. Se beneficia (y se consume el beneficio) continuamente durante los 30 días.
• Soporte técnico: El cliente puede tener acceso a soporte técnico durante todo el período del contrato. Se beneficia continuamente.
• Procesamiento de datos mensual: La entidad procesa datos para el cliente cada mes. El cliente recibe los datos procesados al final de cada mes.
• Desarrollo de software personalizado: La entidad crea un sistema de software nuevo, integrado, para el cliente. El cliente controla el sistema a medida que se desarrolla (el código escrito para el cliente es controlado por el cliente, no por la entidad).
• Migración de datos: La entidad migra la base de datos del cliente desde un sistema heredado. El cliente controla los datos a medida que se transforman y cargan.
• aplicación con personalización significativa: La entidad configura un ERP para el cliente con cambios personalizados. El cliente controla la aplicación personalizada a medida que se construye.
• SaaS mensual: El tiempo transcurrido es la salida medible. En cada mes, el 1/12 de la obligación anual se satisface. Si el contrato es por 12 meses de acceso, cada mes de acceso es 1/12 del total.
• Procesamiento de datos en hitos: La obligación es procesar 12 archivos de datos mensuales. Cada archivo completado es una salida. Si se completan 3 archivos, 3/12 = 25% de la obligación se ha completado.
• aplicación por etapas: El cliente firma cuando se han completado cinco hitos específicos (diseño, construcción, configuración, pruebas, despliegue). Se completan 2 hitos, 2/5 = 40% de progreso.
• aplicación personalizada: La entidad estima que la aplicación requerirá 500 horas de consultoría. Hasta la fecha, 150 horas se han incurrido. Progreso = 150/500 = 30%.
• Desarrollo de software: El presupuesto total de desarrollo es 100.000 euros. Se han incurrido 25.000 euros en costos. Progreso = 25.000/100.000 = 25%.
• Presupuesto total: 500 horas
• Año 1 (11 meses): 250 horas incurridas
• Progreso: 250/500 = 50%
• Ingresos año 1: €100.000 × 50% = €50.000
• Año 2 (enero–marzo): 200 horas incurridas, 450 total incurridas
• Progreso acumulado: 450/500 = 90%
• Ingresos acumulados hasta marzo: €100.000 × 90% = €90.000
• Ingresos año 2 hasta marzo: €90.000 − €50.000 = €40.000

Patrones de auditoría comunes en tecnología

Error 1: No desafiar la identificación de obligaciones de desempeño

Síntoma: El auditor acepta la conclusión de la dirección de que una licencia de software + aplicación = una obligación, sin evaluar independientemente si la aplicación es separadamente identificable.
Por qué importa: Si la aplicación es separadamente identificable, debería asignarse una porción de la consideración y reconocerse cuando se completa (momento puntual) o a medida que avanza (a lo largo del tiempo), no cuando se transfiere la licencia.
Enfoque de auditoría correcto:

Error 2: Aceptar precios de venta independientes no verificados

Síntoma: La dirección estima PVIs basado en "lista de precios interna" o "margen típico", pero no proporciona evidencia.
Por qué importa: La asignación del precio de transacción depende de PVIs fiables. PVIs sobrestimados pueden resultar en ingresos excesivos sobre un elemento; PVIs subestimados pueden resultar en ingresos insuficientes.
Enfoque de auditoría correcto:

Error 3: No restringir consideración variable cuando es apropiado

Síntoma: La dirección incluye la cantidad total estimada de consideración variable sin evaluar si es probable que no se revierta.
Por qué importa: Puede resultar en reconocimiento excesivo de ingresos si el cliente posteriormente no cumple las condiciones para la consideración variable.
Enfoque de auditoría correcto:

Error 4: No evaluar si el reconocimiento a lo largo del tiempo versus en un momento puntual es apropiado

Síntoma: La dirección reconoce todos los ingresos cuando se transfiere la licencia (momento puntual) sin evaluar si la obligación se satisface a lo largo del tiempo (por ejemplo, para SaaS).
Por qué importa: SaaS es típicamente satisfecho a lo largo del tiempo (el cliente simultáneamente recibe y consume beneficios). Reconocer todos los ingresos al principio es incorrecto bajo NIIF 15.35.
Enfoque de auditoría correcto:

Error 5: No calcular progreso de forma fiable para obligaciones a lo largo del tiempo

Síntoma: La dirección estima progreso vagamente (por ejemplo, "completado al 50%" sin cálculo específico de horas incurridas o etapas alcanzadas).
Por qué importa: Puede resultar en ingresos reconocidos en el período incorrecto.
Enfoque de auditoría correcto:
---

• Obtenga el contrato y la propuesta de técnicamente especificando qué se proporciona.
• Entreviste a la dirección sobre si la entidad vende aplicación por separado a otros clientes.
• Indague si el cliente podría beneficiarse de la licencia de software estándar incluso si la dirección no proporciona aplicación personalizada (por ejemplo, ¿podría un cliente interno de TI del cliente configurar el software?).
• Documente independientemente si la aplicación es separadamente identificable.
• Para precios observables, obtenga evidencia directa de precios a otros clientes (facturas, contratos separados).
• Para precios de costo incrementado, recalcule el costo estimado de forma independiente y valide el margen usado.
• Para mercado ajustado, valide los precios de referencia de terceros usados.
• Compare los PVIs estimados con los precios históricos a otros clientes para detectar cambios inesperados o incoherencias.
• Para cada elemento de consideración variable, evalúe la probabilidad de que el cliente la obtenga.
• Obtenga datos históricos sobre la frecuencia con que clientes similares han cumplido condiciones similares.
• Evalúe el riesgo de reversión (si el cliente reclama posteriormente que no se cumplieron los términos).
• Documente el razonamiento para la cantidad incluida versus restringida.
• Para acuerdos de SaaS, software como servicio, o servicios de suscripción, presuma que se satisfacen a lo largo del tiempo a menos que haya razón específica para una transferencia puntual (por ejemplo, una licencia de perpetuidad, sin actualización, sin soporte).
• Para aplicación, evalúe si el cliente controla el activo siendo construido (criterio 2 de NIIF 15.35). Si es así, se satisface a lo largo del tiempo.
• Para software de licencia perpetua estándar sin servicios relacionados, será tipicamente un momento puntual.
• Para método de salida (tiempo transcurrido), valide el período del contrato y calcule linearmente (mes transcurrido ÷ meses totales).
• Para método de entrada (horas incurridas, costos incurridos), obtenga hojas de tiempo, nóminas, o registros de gastos que respalden las horas/costos incurridos.
• Compare la estimación de progreso con la realización histórica en proyectos similares.

Consideraciones específicas del sector tecnológico en España

Entidades típicas en auditoría de tecnología

Los auditores españoles auditando entidades de tecnología encuentran típicamente:

Riesgos de auditoría recurrentes

---

• Empresas de SaaS : Software de gestión empresarial, herramientas de análisis de datos, plataformas de comercio electrónico, software de cumplimiento regulatorio
• Empresas de consultoría tecnológica: aplicación de ERP, incorporación de sistemas, migración de datos, servicios de cloud computing
• Desarrollo de software a medida: Construcción de soluciones personalizadas para clientes específicos
• Proveedores de datos o infraestructura: Centros de datos, almacenamiento en la nube, servicios de API
• Acuerdos agrupados: Un cliente grande (por ejemplo, un banco) contrata software + aplicación + soporte técnico + hosting de cloud en un único contrato por importe significativo. Fácil no desagregar las obligaciones correctamente.
• Consideración variable desenfrenada: El cliente promete comisiones o cuotas basadas en el desempeño del software. Difícil de estimar con fiabilidad.
• aplicación sin fin definido: La entidad proporciona "aplicación" de forma abierta (sin hitos definidos). Difícil de saber cuándo se satisface la obligación.
• Soporte técnico indefinido: El cliente recibe acceso al soporte técnico "ilimitado". Difícil medir el progreso.
• Transiciones de contrato anterior: Un cliente estaba en un contrato anterior bajo IAS 18 (la norma anterior). Ahora está bajo NIIF 15. La entidad debe contabilizar correctamente si hay cambios en la obligación pendiente o si es una nueva obligación.

Herramientas y plantillas

Este diagrama de flujo interactivo incluye:
Exporte su resultado completado como un documento de trabajo en PDF o Word para inclusión en su archivo de auditoría.
---

• Nodos de decisión: Responda sí/no o seleccione de opciones múltiples en cada pregunta de NIIF 15.
• Orientación contextual: Explanaciones de cada criterio con ejemplos específicos de tecnología.
• Cuadros de rationale: Campos de texto para documentar su razonamiento (para incluir en papeles de trabajo).
• Cálculos de asignación: Tablas integradas para calcular asignaciones de precio de transacción.
• Verificaciones de auditoría: Listas de evidencia a obtener en cada paso.

Regulación española en contexto

La NIIF 15 fue adoptada en la Unión Europea en 2015 y es obligatoria en España para todas