Flujo de Decisión de Ingresos NIIF 15: Sector Tecnológico: Ecuador | ciferi

Introducción

El reconocimiento de ingresos bajo la NIIF 15 presenta retos específicos para las empresas de tecnología ecuatorianas, particularmente en la identificación de obligaciones de desempeño separadas, la determinación de si los ingresos se reconocen en un punto en el tiempo o a lo largo del tiempo, y la estimación de la consideración variable en contratos de software, servicios de consultoría y soluciones integradas.
Este flujo de decisión está diseñado para guiar auditorías de ingresos NIIF 15 en el sector tecnológico ecuatoriano. Incluye orientación específica sobre cómo aplicar el modelo de cinco pasos de la NIIF 15 a los tipos de contratos comunes en compañías de software, consultoría tecnológica y provisión de servicios en la nube.
La Superintendencia de Compañías, Valores y Seguros (SCVS) requiere que todas las sociedades anónimas ecuatorianas apliquen la NIIF de forma íntegra, incluyendo la NIIF 15 para los contratos con clientes. Los requisitos de esta norma no admiten simplificaciones ni excepciones basadas en el tamaño de la entidad o la complejidad relativa de sus operaciones.
---

Patrones de Ingresos en el Sector Tecnológico Ecuatoriano

Las compañías de tecnología ecuatorianas generan ingresos a través de múltiples modelos:
Licencias de software: Venta de derechos de uso perpetuo o temporal sobre código, con o sin derecho de acceso a actualizaciones.
Servicios de consultoría: Asesoría técnica, diseño de sistemas, aplicación de soluciones. Estos servicios suelen reconocerse a lo largo del tiempo.
Software como Servicio (SaaS): Acceso a plataformas hospedadas en la nube, con facturación mensual, trimestral o anual. El reconocimiento es a lo largo del tiempo.
Mantenimiento y soporte: Incluidos en contratos de software o vendidos por separado. Representan obligaciones separadas cuando son distinguibles.
aplicación técnica: Instalación, configuración, migración de datos, capacitación. Pueden constituir obligaciones separadas o formar parte de una obligación única de "suministrar un sistema funcional".
Contratos integrados: Combinaciones de licencia + aplicación + soporte + capacitación. Estos contratos requieren análisis cuidadoso para identificar cuántas obligaciones de desempeño existen.
---

Paso 1: Identificar el Contrato con el Cliente (NIIF 15.9–21)

Criterios de Existencia del Contrato

Antes de evaluar el reconocimiento de ingresos, confirma que existe un contrato que cumple los cinco criterios de la NIIF 15.9:

1. Aprobación y Compromiso de las Partes (NIIF 15.9(a))

Pregunta: ¿Han aprobado ambas partes el contrato y se han comprometido a cumplir sus obligaciones respectivas?
Las compañías de tecnología ecuatorianas a menudo cierran acuerdos mediante correo electrónico, órdenes de compra, o confirmaciones verbales seguidas de facturación. Para evidenciar la aprobación y el compromiso:
Documentación: Nota de auditoría: "Se verificó la orden de compra del cliente [nombre/referencia] con fecha [fecha], firmada por [autoridad]. Contrato aprobado explícitamente."

2. Identificación de Derechos Contractuales (NIIF 15.9(b))

Pregunta: ¿Pueden identificarse claramente los derechos de cada parte respecto de los bienes o servicios a transferirse?
En contratos de tecnología:
Documentación: Nota de auditoría: "Derechos identificados: [Descripción de lo que la entidad entregará]. Cliente tiene derecho a [Descripción de lo que el cliente recibirá]. Plazo: [Duración]. Acceso/Soporte: [Términos específicos]."

3. Términos de Pago (NIIF 15.9(c))

Pregunta: ¿Están identificados claramente el monto, plazo y forma de la consideración?
Ejemplos de términos de pago comunes en tecnología ecuatoriana:
Documentación: Nota de auditoría: "Consideración identificada: [Monto en USD], pagadero [condiciones], términos de crédito [días], pagos por hito: [detalles]. Variabilidad: [descripción y método de estimación]."

4. Sustancia Comercial (NIIF 15.9(d))

Pregunta: ¿Cambiará el contrato el riesgo, timing o monto de los flujos de caja futuros de la entidad de forma considerable?
Para la mayoría de las transacciones de tecnología, la sustancia comercial es evidente:
El riesgo comercial puede incluir: riesgo de que el cliente no pague, riesgo de que la entidad deba proporcionar soporte técnico inesperado, riesgo de que los cambios en la tecnología requieran inversión adicional.
Situación que falla la sustancia comercial: Una compañía de software A intercambia 100 licencias de su software de contabilidad con la compañía B a cambio de 100 licencias del software de recursos humanos de B. Ambos productos tienen funcionalidades similares y valores de mercado similares. Existe sustancia comercial solo si el cambio en el timing o el riesgo de flujo de caja es significativo. Típicamente, el flujo de caja no cambia materialmente (ambas compañías venden típicamente a terceros, así que la permuta acelera o retrasa el reconocimiento de manera simétrica). En este caso, evalúa cuidadosamente si la sustancia comercial existe.
Documentación: Nota de auditoría: "Sustancia comercial confirmada. El contrato genera flujo de caja que [describe el cambio respecto de la posición sin contrato]."

5. Probabilidad de Cobro (NIIF 15.9(e))

Pregunta: ¿Es probable (más probable que no) que la entidad cobre la consideración a la que tiene derecho?
En Ecuador, la evaluación de la probabilidad de cobro requiere considerar:
Si la entidad ofrece un descuento de precio (por ejemplo, $10,000 USD en lugar de $12,000 USD para que el cliente pague dentro de 15 días), la evaluación de cobro se basa en la consideración esperada reducida ($10,000 USD), no en el precio de lista.
Documentación: Nota de auditoría: "Evaluación de cobro: Cliente es [descripción de solvencia]. Historial de pago: [días de morosidad promedio]. Garantías: [descripción]. Conclusión: Probable cobrar USD [monto esperado]."
---

Combinación de Contratos (NIIF 15.17)

Si la entidad tiene múltiples contratos con el mismo cliente o con una cliente relacionado, evalúa si deben combinarse en un único contrato para efectos del análisis NIIF 15.
Ejemplo: Tecnológica Quito S.A. propone a la Municipalidad de Cuenca:
Estos tres contratos fueron negociados conjuntamente, con un descuento global combinado, y forman una solución integrada para la Municipalidad. Deben combinarse en un único contrato NIIF 15 para la evaluación de obligaciones de desempeño.
Los criterios para la combinación (NIIF 15.17):
Si se responde "sí" a cualquiera de estos, combina los contratos.
---

Modificaciones de Contrato (NIIF 15.18–21)

Las modificaciones son cambios acordados a los derechos o las obligaciones prometidas. En tecnología, son comunes:
Tratamiento contable de la modificación:
Si la modificación añade bienes o servicios distinguibles con un precio que refleja el precio de venta independiente ajustado por las circunstancias del contrato, contabiliza la modificación como un nuevo contrato separado, prospectivamente.
Ejemplo: Un cliente de SaaS de Soluciones Tecnológicas Guayaquil Cía. Ltda. solicita añadir un módulo de reportes avanzados durante el año 2. El precio es $8,000 USD, que es aproximadamente el precio de venta independiente de ese módulo cuando se vende solo. La modificación es prospectiva: la obligación original de SaaS continúa bajo los términos originales, y la nueva obligación de módulo de reportes se contabiliza como un contrato separado iniciado en la fecha de la modificación.
Si la modificación añade servicios que no son distinguibles (por ejemplo, cambios técnicos menores que no son una obligación separada del resto de la aplicación), o si el precio no refleja el precio de venta independiente, entonces contabiliza la modificación como un cambio prospectivo a la obligación existente (cumulative catch-up adjustment).
Documentación: Nota de auditoría: "Modificación del [fecha]: [Descripción]. Bienes/servicios adicionales distinguibles: [Sí/No]. Precio reflejando SSP: [Sí/No]. Tratamiento: [Prospectivo como nuevo contrato / Cumulative catch-up a la obligación existente]."
---

• Ubicar la orden de compra firmada o correo de aceptación del cliente
• Si el cliente es una institución pública (por ejemplo, una agencia del Estado ecuatoriano), verificar que el contrato haya sido autorizado por el funcionario competente y que el cliente haya girado fondos o iniciado pagos
• Documentar si existe una práctica comercial establecida (por ejemplo, la entidad vende regularmente bajo los mismos términos) que evidencie aprobación tácita
• Especificar exactamente qué módulos de software, qué versiones, qué nivel de acceso se proporcionará
• Detallar el alcance de los servicios de consultoría (número de horas, temas cubiertos, entregables específicos)
• Describir la duración del acceso a la plataforma SaaS y cualquier limitación de uso (por ejemplo, número de usuarios concurrentes)
• Indicar si hay derecho a actualizaciones, y bajo qué condiciones
• Pago único al cierre: $15,000 USD por la licencia de software perpetua
• Cuota mensual: $500 USD mensuales por SaaS, facturados el primer día de cada mes
• Hito: 30% a la firma, 40% a la mitad de la aplicación, 30% a la aceptación
• Variable: Tarifa base de $10,000 USD más comisión del 5% si el sistema procesa más de 10,000 transacciones mensuales
• Un contrato SaaS de $500 mensuales por 12 meses proporciona flujo de caja recurrente predecible
• Un contrato de consultoría de $50,000 para diseñar un sistema proporciona ingresos puntuales que de otro modo la entidad no recibiría
• Un contrato de licencia perpetua de $100,000 proporciona un flujo de caja importante
• Clientes corporativos ecuatorianos: Revisar estados financieros publicados (si es una S.A.), historial de pago previo, referencias bancarias
• Instituciones públicas ecuatorianas: Verificar que hay presupuesto asignado y fondos disponibles. Aunque las entidades estatales rara vez incumplen (están respaldadas por la tesorería estatal), los pagos pueden retrasarse 60-120 días. Aun así, la probabilidad de cobro es alta
• Clientes extranjeros: Si el cliente está fuera del Ecuador, considerar riesgo país, situación financiera reportada, y si hay garantías (aval bancario, carta de crédito, depósito en garantía)
• Contrato 1: Licencia de software de presupuesto participativo por $80,000 USD
• Contrato 2: aplicación e integración con sistemas existentes por $60,000 USD
• Contrato 3: Soporte y mantenimiento por 3 años a $5,000 USD anuales
• ¿Fueron negociados como un paquete con un objetivo comercial único?
• ¿La consideración en un contrato depende del precio o del desempeño del otro?
• ¿Los bienes o servicios prometidos forman una única obligación de desempeño?
• Ampliación de alcance: El cliente solicita módulos adicionales o usuarios adicionales
• Cambio de especificación: El cliente requiere cambios técnicos a los entregables
• Extensión de período: SaaS de 12 meses se extiende a 24 meses
• Pausa o cancelación: El cliente detiene el proyecto temporalmente o cancela algunos servicios

Paso 2: Identificar Obligaciones de Desempeño (NIIF 15.22–30)

Una obligación de desempeño es una promesa de transferir un bien o servicio distinguible al cliente. Cada obligación distinguible dentro del contrato debe identificarse por separado.

Test de Distintividad (NIIF 15.27–29)

Un bien o servicio es distinguible si cumple dos condiciones:

Condición 1: Capaz de Ser Distinguible (NIIF 15.28)

El cliente puede beneficiarse del bien o servicio por sí solo o junto con recursos disponibles fácilmente.
Para bienes o servicios de tecnología:
Licencia de software: El cliente puede usar la licencia de forma independiente (aunque algunos complementos como actualizaciones pueden estar vinculados). La licencia es capaz de ser distinguible.
aplicación técnica: ¿Puede el cliente beneficiarse de la aplicación sin la licencia? Generalmente, no. la aplicación es un servicio que le permite usar el software, pero por sí sola la aplicación no tiene valor para el cliente. Sin embargo, si otros vendedores de software pueden usar los servicios de aplicación de la misma entidad, entonces la aplicación es capaz de ser distinguible.
Capacitación: ¿El cliente puede obtener capacitación en el software de otro proveedor o de terceros de manera económicamente similar? Si sí, la capacitación es capaz de ser distinguible. Si la capacitación es específica al software de la entidad y no está disponible de terceros, evalúa si el cliente puede beneficiarse del conocimiento adquirido de forma independiente.
SaaS + Soporte: El acceso al SaaS (servicio de computación en la nube) es capaz de ser distinguible. El soporte técnico también puede ser, si el cliente puede obtenirlo de terceros o si la entidad lo vende por separado.
Indicador práctico: ¿Vende la entidad este bien o servicio regularmente de forma separada? Si sí, es capaz de ser distinguible.
---

Condición 2: Separadamente Identificable Dentro del Contrato (NIIF 15.29)

El bien o servicio es separadamente identificable si la entidad no proporciona un servicio importante de integración que combine este bien o servicio con otros, el bien o servicio no modifica de forma notable otros bienes o servicios, y el bien o servicio no es interdependiente o interrelacionado con otros.
Señales de que un bien o servicio NO es separadamente identificable:
Ejemplo: Sistema de gestión de inventario integrado para minorista ecuatoriano: El software se personaliza, la aplicación incluye limpieza y migración de datos históricos, y la capacitación es integral para que el minorista pueda operar de inmediato. Aunque la entidad podría vender la licencia de forma separada, aquí la incorporación es tan significativa que el cliente percibe una única solución. Una obligación de desempeño.
Indicador práctico de separabilidad: ¿El cliente normalmente pagaría diferentes precios por estos elementos si se vendieran por separado, reflejando beneficios independientes? Si sí, probablemente sean separadamente identificables.
---

Cómo Identificar Obligaciones Comunes en Tecnología Ecuatoriana

Escenario 1: Licencia + aplicación + Soporte

Contrato: Constructora Tecnológica Quito S.A. vende un sistema de presupuestación a Constructor Andino Cía. Ltda.
Análisis:
---

Escenario 2: SaaS + Integración + Soporte

Contrato: Software as a Service (SaaS) de análisis de clientes de Plataforma Digital Guayaquil S.A. a Comercial Importadora Cía. Ltda.
Análisis:
En este escenario, asumir que la incorporación es técnicamente simple y separadamente identificable: el cliente puede optar por no integrar, o integrar más tarde con terceros. Obligación separada.
---

Regla de Series (NIIF 15.22(b))

Si una entidad promete una serie de bienes o servicios sustancialmente idénticos con el mismo patrón de transferencia, pueden contabilizarse como una única obligación de desempeño.
Ejemplo: Contabilidad SaaS mensual. La entidad proporciona acceso a un servicio contable basado en la nube a un cliente durante 24 meses. Cada mes, el cliente recibe acceso idéntico a la plataforma.
El reconocimiento de ingresos es a lo largo del tiempo, medido por lo general por la entidad de paso de tiempo (o "lineal"): $2,000 USD mensuales x 24 meses = $48,000 USD reconocidos linealmente.
---

• Integración significativa: La entidad diseña e implementa una solución integrada donde el software, la aplicación, los datos y el soporte forman un único producto final. El cliente no puede usar cada componente sin los otros. En este caso, todos estos elementos forman una única obligación de desempeño.
• Modificación significativa: Un componente de forma notable modifica el funcionamiento de otro. Por ejemplo, un módulo de inteligencia artificial que cambia radicalmente cómo funciona el software base.
• Interdependencia alta: Los componentes dependen unos de otros de tal manera que el rendimiento de cada uno se ve de forma notable afectado por los otros. Por ejemplo, una plataforma de análisis de datos que depende de un modelo específico de ingesta de datos; si cambia una, debe cambiar la otra.
• Licencia perpetua de software: Entidad retiene derecho de propiedad, cliente obtiene derecho de uso limitado. Precio independiente: $50,000 USD
• aplicación (60 horas de consultoría técnica): Instalación, personalización, integración con contabilidad existente. Precio independiente: $30,000 USD (tasa horaria $500 USD x 60)
• Capacitación (20 horas): Usuarios finales de Constructor Andino aprenden a usar el sistema. Precio independiente: $5,000 USD (tasa $250 USD x 20)
• Soporte técnico, 2 años: Respuesta en 4 horas para problemas críticos, 24 horas para otros. Precio independiente: $8,000 USD anuales
• Precio total del contrato: $100,000 USD (descuento global aplicado)
• Licencia: Capaz de ser distinguible (venta separada común). Separadamente identificable (cliente puede usar con soporte técnico de terceros o soporte interno). Obligación separada.
• aplicación: Capaz de ser distinguible (otros consultores pueden hacer implementaciones similares). Separadamente identificable (el cliente puede pagar aplicación a una consultora diferente en principio, aunque aquí está integrada). Sin embargo, evalúa si la aplicación modifica de forma notable la licencia. Si la instala y la configura sin cambios al código, es separada. Si modifica el código base de forma notable, puede ser parte de la obligación de licencia única. Típicamente, la aplicación es separadamente identificable como obligación separada.
• Capacitación: Capaz de ser distinguible (otros pueden capacitar). Separadamente identificable (no modifica el software ni la aplicación). Obligación separada.
• Soporte técnico: Capaz de ser distinguible (vendido por separado habitualmente). Separadamente identificable (proporciona un servicio pero no modifica el software o la aplicación). Obligación separada.
• Conclusión: Cuatro obligaciones de desempeño: (1) Licencia, (2) aplicación, (3) Capacitación, (4) Soporte técnico 2 años.
• SaaS (acceso a plataforma en la nube): $2,000 USD mensuales, facturados anualmente por anticipado ($24,000 USD anuales)
• Integración con sistemas ERP existentes: 40 horas de trabajo, sin costo adicional (incluido)
• Soporte técnico 24/7: Incluido en el precio de SaaS
• Precio total: $24,000 USD anuales por 3 años (contrato de 3 años)
• SaaS: Capaz de ser distinguible (ofrecido habitualmente en el mercado por la entidad y competidores). Separadamente identificable (cliente puede usar el SaaS con integración técnica simple o sin integración personalizada; existen integradores de terceros disponibles). Obligación separada.
• Integración: ¿Es la incorporación capaz de ser distinguible? El cliente puede obtenerse incorporación de terceros. ¿Es separadamente identificable? Aquí el análisis es más cuidadoso. Si la incorporación es simple (mapeo de datos, configuración de API), es separadamente identificable. Si la incorporación requiere personalización del ERP o del SaaS de forma que ambos se modifican de forma notable mutuamente, entonces la incorporación puede no ser separadamente identificable de la obligación de SaaS (formarían una única solución integrada).
• Soporte técnico: ¿Capaz de ser distinguible? Sí, soporte puede comprarse por separado (aunque típicamente incluido en SaaS). ¿Separadamente identificable? Depende de si el soporte está ligado al SaaS o es un servicio independiente. Habitualmente, en SaaS, el soporte es parte inseparable de la obligación de acceso: el cliente paga por acceso + soporte como una única solución. Aquí, el soporte probablemente sea parte de la obligación de SaaS, no una obligación separada.
• Conclusión: Dos obligaciones de desempeño: (1) SaaS (incluyendo soporte incluido), (2) Integración técnica (si se considera separadamente).
• ¿Sustancialmente idénticos? Sí, cada mes proporciona el mismo acceso.
• ¿Mismo patrón de transferencia? Sí, cada mes el cliente recibe y consume beneficios de forma idéntica.
• Resultado: Única obligación de desempeño (SaaS de 24 meses), no 24 obligaciones separadas.

Paso 3: Determinar el Precio de la Transacción (NIIF 15.47–72)

El precio de la transacción es el monto de consideración que la entidad espera tener derecho a cambio de transferir bienes o servicios.

Consideración Variable (NIIF 15.50–58)

Muchos contratos de tecnología incluyen consideración variable:
Cuando existe consideración variable, estimar el monto incluido en el precio de la transacción usando uno de dos métodos:

Método 1: Valor Esperado

El promedio probabilidad-ponderado de todos los resultados posibles.
Ejemplo: Cliente de Plataforma Digital Guayaquil S.A. puede procesar entre 50,000 y 200,000 transacciones mensuales. Histórico:
Precio base: $0.10 USD por transacción. Si excede 100,000 transacciones mensuales, rebate de $0.02 USD por transacción sobre todas las transacciones por encima de 100,000.
Cálculo del valor esperado:
Valor esperado:
(20% × $6,500) + (50% × $10,000) + (30% × $14,800)
= $1,300 + $5,000 + $4,440
= $10,740 USD mensuales
Este es el monto de consideración variable incluido en el precio de la transacción.

Método 2: Monto Más Probable

El resultado más probable único en escenarios de dos opciones discretas.
Ejemplo: Cliente contratos de aplicación: la entidad entrega un sistema que costará $50,000 USD o $75,000 USD dependiendo de descubrimientos técnicos durante el análisis inicial. No hay valores intermedios.
El método de monto más probable usa el resultado más probable: $75,000 USD (60% de probabilidad).
Nota: El método de valor esperado daría: (40% × $50,000) + (60% × $75,000) = $67,500 USD.
Cuál método usar: Usa el que mejor predice la consideración esperada. En escenarios con muchas variables posibles e incertidumbre amplia, el valor esperado es típicamente mejor. En escenarios binarios o de dos resultados, el monto más probable es típicamente mejor.
---

Restricción de Consideración Variable (NIIF 15.56–58)

No incluyas toda la consideración variable estimada en el precio de la transacción. Debes restringir (reducir) la cantidad incluida si existe una incertidumbre significativa sobre el monto que será cobrado.
Ejemplo: Contrato de software de Ingeniera de Datos Cuenca S.A. con cliente minorista:
Sin embargo, existe incertidumbre significativa porque:
Estimación mediante valor esperado: El monto más probable es $80,000 USD (cliente normalmente ve 80% de sus proyecciones). Pero hay dispersión amplia de resultados posibles ($0 a $150,000 USD).
Restricción: Incluir en el precio de la transacción el monto que es probable que no sea reversado cuando se resuelva la incertidumbre.
Evaluación: Aplicar un "constraint" conservador. incluir solo $40,000 USD de la comisión estimada de $100,000 USD. Incluir la consideración variable adicional solo cuando se resuelva la incertidumbre.
Documentación: Nota de auditoría: "Consideración variable identificada: [Descripción]. Método de estimación: [Valor esperado / Monto más probable]. Monto estimado: [Monto]. Restricción aplicada: [Monto restringido]. Justificación: [Explicación del grado de incertidumbre y por qué se redujo]."
---

Financiamiento Significativo (NIIF 15.60–65)

Si el contrato incluye un período significativo entre cuando el cliente paga y cuando la entidad transfiere los bienes o servicios (o viceversa), y este período proporciona un componente de financiamiento significativo, debe ajustarse el precio de la transacción.
Ejemplo de financiamiento del cliente: Consultoría Integral Quito S.A. vende un contrato de aplicación de software por $120,000 USD en enero, pero el cliente no pagará hasta diciembre (11 meses después). Tasa de interés de mercado de 8% anual.
Valuación presente del pago:
$120,000 USD ÷ (1 + 8% × 11/12) = $120,000 ÷ 1.0733 = $111,797 USD
El precio de la transacción se registra como $111,797 USD (ingresos por servicios). La diferencia de $8,203 USD se registra como ingresos por intereses a lo largo del período de crédito, o se acumula proporcionalmente.
Ejemplo de financiamiento de la entidad (cliente pagando por adelantado): SaaS de Procesamiento de Datos Guayaquil Cía. Ltda. cobra $30,000 USD en enero por servicios que se proporcionarán durante todo el año (enero-diciembre). El cliente pre-paga.
Precio de la transacción: $30,000 USD. Sin ajuste por componente de financiamiento generalmente, ya que el período es normal para SaaS. Sin embargo, si el cliente pagara 5 años por adelantado, evaluaría si existe un componente de financiamiento significativo.
Criterio: ¿El diferimiento entre pago y desempeño es sustancialmente mayor que lo comercialmente normal para este tipo de transacción? Si sí, ajusta por financiamiento.
En tecnología ecuatoriana, es común:
Documentación: Nota de auditoría: "Componente de financiamiento evaluado. Período entre pago y desempeño: [Período]. Tasa de mercado: [Tasa]. Monto del ajuste: [Monto]. Conclusión: [Significativo / No significativo]."
---

Consideración No Monetaria (NIIF 15.66–68)

Si el cliente paga con algo que no es dinero (por ejemplo, servicios del cliente, activos del cliente), mide la consideración al valor razonable del bien o servicio recibido.
En tecnología ecuatoriana, esto es raro, pero puede ocurrir:
Ejemplo: Empresa A (software de contabilidad) intercambia licencias con Empresa B (software de nómina) para que cada una pueda vender el software del otro como add-on. Valor de mercado de cada licencia: $40,000 USD (basado en precios normales de venta).
Consideración: $40,000 USD (valor razonable del software recibido).
---

Consideración Pagadera al Cliente (NIIF 15.69–72)

A veces, una entidad paga al cliente como parte del acuerdo (por ejemplo, comisiones de afiliado, descuentos, incentivos de volumen pagados en efectivo).
Ejemplo: Plataforma de E-Commerce Ambato S.A. paga a Comercial Minorista Cía. Ltda. $5,000 USD para que integre su plataforma en el sitio de la minorista. Esto se trata como una reducción del precio de la transacción, no como un gasto de marketing.
---

• Rebates volumétricos: Si el cliente procesa más de 100,000 transacciones al mes, se reduce el precio por transacción
• Bonificaciones por desempeño: Si el sistema alcanza ciertos uptime (disponibilidad) del 99.9%, se paga una bonificación anual
• Comisiones: La entidad retiene un porcentaje de las ventas procesadas a través del sistema
• Penalidades: Si el sistema no cumple con SLA (Service Level Agreement), se reembolsa parte de la factura
• 20% de probabilidad de 50,000–80,000 transacciones (promedio 65,000)
• 50% de probabilidad de 80,000–120,000 transacciones (promedio 100,000)
• 30% de probabilidad de 120,000–200,000 transacciones (promedio 160,000)
• Escenario 1 (65,000 transacciones): 65,000 × $0.10 = $6,500 USD. Sin rebate (por debajo de 100,000).
• Escenario 2 (100,000 transacciones): 100,000 × $0.10 = $10,000 USD. Sin rebate.
• Escenario 3 (160,000 transacciones): (100,000 × $0.10) + (60,000 × $0.08) = $10,000 + $4,800 = $14,800 USD.
• 40% de probabilidad de $50,000 USD
• 60% de probabilidad de $75,000 USD
• Precio base: $100,000 USD
• Comisión variable: 2% de las ventas procesadas. Cliente proyecta $5 millones USD en ventas anuales, por lo que la comisión estimada es $100,000 USD.
• Las proyecciones de ventas del cliente pueden no materializarse
• El cliente puede cambiar canales de ventas y reducir la dependencia de este sistema
• Cambios macroeconómicos o de mercado pueden afectar ventas
• Pagos a hito (% a la firma, % a entregas parciales) con financiamiento mínimo
• SaaS pagado mensualmente o anualmente por adelantado (sin componente de financiamiento significativo)
• Implementaciones con período de pago más largo (90-180 días): evalúa si esto es significativo

Paso 4: Asignar el Precio de la Transacción a Obligaciones de Desempeño (NIIF 15.73–86)

Después de determinar el precio total de la transacción, asígnalo a cada obligación de desempeño identificada en el Paso 2.
Método: Asigna el precio proporcionalmente basado en los precios de venta independientes (SSP, Standalone Selling Price) de cada obligación.

Determinación del Precio de Venta Independiente (NIIF 15.76–77)

El SSP es el precio al que la entidad normalmente vendería un bien o servicio al cliente por sí solo.
Jerarquía de evidencia para determinar SSP:

Nivel 1: Precio Observado

¿Vende la entidad este bien o servicio con regularidad de forma separada? Si es así, usa el precio de venta observado.
Ejemplo: Licencia de software. la entidad vende regularmente la licencia a otros clientes por $50,000 USD. Este es el SSP.

Nivel 2: Precio Ajustado

Si la entidad no vende la obligación de forma separada al cliente, pero sí vende a otros clientes, usa ese precio ajustado para las circunstancias del cliente actual.
Ejemplo: aplicación técnica. la entidad no incluye aplicación al vender solo licencia a otros clientes, pero cobra $500 USD/hora por aplicación (o $30,000 USD para 60 horas). Para este cliente, el SSP de la aplicación es 60 horas × $500 USD/hora = $30,000 USD.

Nivel 3: Método Estimado

Si la entidad no vende la obligación por separado ni a otros clientes, estima el SSP usando:
Ejemplo de método estimado (Costo incrementado): Soporte técnico personalizado. la entidad no vende este servicio por separado (típicamente solo lo vende incluido en contratos). Costo estimado para 2 años:
---

Ejemplo de Asignación: Contrato Integrado de Tecnología

Contrato: Constructora Tecnológica Quito S.A. y Constructor Andino Cía. Ltda.: Sistema integrado de presupuestación
Obligaciones de desempeño identificadas:
Precios de venta independientes:
Total de SSPs: $143,500 USD
Precio de transacción (incluyendo descuento global): $100,000 USD
Asignación proporcional:
Total asignado: $100,000 USD (verifica que el total coincida con el precio de la transacción)
Documentación: Nota de auditoría: "SSPs determinados [para cada obligación: fuente, monto]. Total SSP: $143,500 USD. Asignación de precio proporcional a cada obligación [tabla de asignación]. Asignación verificada contra precio de transacción total."
---

• Costo incrementado apropiado: Costo directo de la obligación + un margen de ganancia razonable para la entidad
• Precios de competidores: ¿Cuánto cobraría un competidor por esta obligación en el mercado ecuatoriano?
• Análisis residual: (Raramente permitido) Si hay una obligación dominante con SSP observable, y solo una obligación no observable, calcula el SSP de la no observable como residuo.
• Salarios: 0.5 FTE × $40,000 USD/año × 2 años = $40,000 USD
• Infraestructura (servidor, teléfono, software): $5,000 USD
• Costo total: $45,000 USD
• Margen de ganancia (30%): $45,000 × 30% = $13,500 USD
• SSP estimado: $58,500 USD
• Licencia perpetua de software
• aplicación técnica (60 horas)
• Capacitación (20 horas)
• Soporte técnico (2 años)
• Licencia: Vendida regularmente a $50,000 USD (Nivel 1: Precio observado)
• aplicación: Consultores cobran $500 USD/hora = 60 × $500 = $30,000 USD (Nivel 1: Precio observado)
• Capacitación: $250 USD/hora = 20 × $250 = $5,000 USD (Nivel 1: Precio observado)
• Soporte: Estimado en $58,500 USD (Nivel 3: Costo incrementado)
• Licencia: ($50,000 ÷ $143,500) × $100,000 = $34,834 USD
• aplicación: ($30,000 ÷ $143,500) × $100,000 = $20,900 USD
• Capacitación: ($5,000 ÷ $143,500) × $100,000 = $3,484 USD
• Soporte: ($58,500 ÷ $143,500) × $100,000 = $40,782 USD

Paso 5: Reconocer Ingresos cuando (o mientras) se Cumplen Obligaciones de Desempeño (NIIF 15.31–45)

El paso final es determinar cuándo reconocer ingresos para cada obligación. Los ingresos se reconocen cuando la entidad transfiere el control de un bien o servicio distinguible al cliente.

Transferencia de Control: Control en un Punto en el Tiempo vs. A Lo Largo del Tiempo

Para cada obligación, determina si el control se transfiere:
---

A Lo Largo del Tiempo (NIIF 15.35)

El control se transfiere a lo largo del tiempo si se cumple uno de estos tres criterios:
##### Criterio 1: El Cliente Simultáneamente Recibe y Consume Beneficios (NIIF 15.35(a))
El cliente recibe los beneficios del desempeño de la entidad conforme ocurre (y no puede obtener esos beneficios de otro lugar).
Ejemplos en tecnología:
---
##### Criterio 2: El Desempeño de la Entidad Crea un Activo que el Cliente Controla (NIIF 15.35(b))
El trabajo de la entidad modifica un activo (por ejemplo, un edificio, un software personalizado, datos) de tal manera que el cliente controla el activo conforme se modifica.
Ejemplos en tecnología:
---
##### Criterio 3: La Entidad No Tiene Uso Alternativo para el Activo y Tiene Derecho Exigible al Pago (NIIF 15.35(c))
El activo creado para el cliente es tan específico (personalizado) que la entidad no puede venderlo a otro cliente, Y el cliente está en una posición donde debe pagar aunque no acepte los bienes finales.
Ejemplo: Desarrollo de software a medida para un banco ecuatoriano, completamente personalizado a sus procesos únicos de auditoría interna. El software no puede venderse a otro cliente sin cambios sustanciales. El cliente está contractualmente obligado a pagar aunque rechace entrega. Control a lo largo del tiempo.
---

En un Punto en el Tiempo (NIIF 15.38)

Si ninguno de los tres criterios de "a lo largo del tiempo" se cumple, entonces el control se transfiere en un punto en el tiempo específico, típicamente cuando:
Ejemplos en tecnología:
---

Métodos para Medir el Progreso (NIIF 15.40–42)

Si el control se transfiere a lo largo del tiempo, la entidad reconoce ingresos midiendo el progreso en la satisfacción de la obligación.
Hay dos enfoques:

Enfoque de Entrada (Input Method)

Mide el progreso en términos de recursos invertidos por la entidad:
Fórmula: Ingresos reconocidos = (Entrada incurrida hasta la fecha ÷ Entrada total estimada) × Precio de transacción asignado
Ejemplo: aplicación de software de 60 horas, precio asignado de $20,900 USD.
Ventaja: Refleja el ritmo actual de trabajo. Si la aplicación se acelera, los ingresos también.
Desventaja: Requiere estimaciones fiables de horas/costo totales.
---

Enfoque de Salida (Output Method)

Mide el progreso en términos de valor entregado al cliente:
Fórmula: Ingresos reconocidos = (Salida entregada hasta la fecha ÷ Salida total esperada) × Precio de transacción asignado
Ejemplo: aplicación con 5 hitos contractuales:
Precio asignado: $20,900 USD
Ventaja: Alineado con hitos contractuales, más fácil de comunicar al cliente.
Desventaja: Puede no reflejar el progreso real si los hitos están distribuidos de manera desigual en el trabajo.
---

Ejemplo de Reconocimiento de Ingresos: Contrato de aplicación y Soporte

Obligación: aplicación técnica (60 horas): Precio asignado: $20,900 USD
Control: Transfiere a lo largo del tiempo (Criterio 2: Cliente controla el sistema parcialmente modificado conforme se integra)
Método de medición: Enfoque de entrada (% de horas incurridas)
Cronograma realizado:
| Período | Horas realizadas

• En un punto en el tiempo: Un único momento específico (por ejemplo, la entrega)
• A lo largo del tiempo: Gradualmente durante un período (por ejemplo, mientras se proporciona un servicio)
• SaaS mensual: Cada mes, el cliente recibe acceso a la plataforma y acceso simultáneamente (y consume los beneficios usándola). Control se transfiere a lo largo del tiempo.
• Soporte técnico: Cada mes, el cliente recibe y consume el beneficio del soporte técnico disponible.
• aplicación con personalización incrementada: La entidad integra y personaliza un sistema de ERP para un cliente. Conforme avanzan las fases de aplicación (análisis → diseño → desarrollo → pruebas), el cliente controla el sistema parcialmente modificado después de cada fase. Si hay hitos de aceptación donde el cliente verifica y acepta cada fase, el control se transfiere a lo largo del tiempo.
• Migración de datos: Transferir datos de un sistema legado a uno nuevo. A medida que se migran y validan datos, el cliente controla los datos migrados hasta ese punto. Control a lo largo del tiempo.
• La entidad transfiere la posesión física del bien
• El cliente obtiene derecho legal sobre el bien
• La entidad transfiere riesgo y recompensas de la propiedad
• El cliente acepta el bien (si hay requisito de aceptación contractual)
• Venta de licencia perpetua sin aplicación: Control se transfiere cuando se entrega la licencia (típicamente descargable o a través de clave de activación en línea). Un punto en el tiempo.
• Venta de software en caja (rara en 2024 pero aún ocurre): Control se transfiere cuando se entrega la caja y el cliente puede usar el software.
• Costo incurrido como porcentaje de costo total estimado
• Horas trabajadas como porcentaje de horas estimadas
• Unidades producidas como porcentaje de unidades totales a producir
• Mes 1: 15 horas trabajadas = 15÷60 = 25% completado. Ingresos: 25% × $20,900 = $5,225 USD
• Mes 2: 20 horas trabajadas (35 total) = 35÷60 = 58.33% completado. Ingresos: 58.33% × $20,900 = $12,213 USD menos $5,225 ya reconocidos = $6,988 USD en el mes 2
• Mes 3: 25 horas trabajadas (60 total) = 100% completado. Ingresos: 100% × $20,900 menos cantidades ya reconocidas = $1,675 USD en el mes 3
• Unidades transferidas al cliente (si hay entregas incrementales)
• Milestones alcanzados (análisis completado, diseño aprobado, etc.)
• Evaluaciones de desempeño acordadas
• Análisis inicial: 15% de los ingresos
• Diseño aprobado: 25% de los ingresos
• Desarrollo completado: 35% de los ingresos
• Pruebas pasadas: 15% de los ingresos
• Aceptación final: 10% de los ingresos
• Cuando se completa análisis (Hito 1): 15% × $20,900 = $3,135 USD reconocidos
• Cuando se aprueba diseño (Hito 2): 25% × $20,900 = $5,225 USD reconocidos
• Y así sucesivamente