Diagrama de Flujo NIIF 15: Tecnología (Costa Rica) | ciferi

Navegue el modelo de cinco pasos de reconocimiento de ingresos bajo la NIIF 15 adoptada en Costa Rica, con orientación alineada a las expectativas regulatorias y las prácticas de la industria tecnológica costarricense.

---

Adopción de la NIIF 15 en Costa Rica

Costa Rica ha adoptado las Normas Internacionales de Información Financiera (NIIF) como el marco contable obligatorio para las entidades de interés público (PIE) y las entidades cotizadas en bolsa. La NIIF 15 Ingresos de Actividades Ordinarias entró en vigor para los períodos anuales que comenzaron el 1 de enero de 2018. El Colegio de Contadores Públicos de Costa Rica (CCPA) es la autoridad profesional responsable de guiar la aplicación de la NIIF 15 en el país. Para las entidades pequeñas y medianas que no califican como PIE, el CCPA permite opcionalmente el uso de la NIIF para Pymes, que simplifica ciertos aspectos del reconocimiento de ingresos pero sigue el mismo modelo de control de cinco pasos.
La Superintendencia General de Valores (SUGEVAL), bajo la supervisión del Consejo Nacional de Supervisión del Sistema Financiero (CONASSIF), ejerce autoridad regulatoria sobre las entidades cotizadas. Aunque SUGEVAL no publica hallazgos temáticos formales como hace la FRC (Junta de Supervisión Financiera) del Reino Unido, la práctica de auditoría costarricense se alinea estrechamente con los estándares internacionales y los hallazgos de inspección de auditoría emitidos por reguladores internacionales (como IFAC).
---

Contexto de la industria tecnológica en Costa Rica

Costa Rica ha posicionado la tecnología de la información como un pilar estratégico de su economía. La industria de software, servicios de desarrollo de aplicaciones, soluciones en la nube, y empresas de tecnología médica representan un segmento creciente del sector empresarial. Empresas como Soluciones Digitales Centroamericanas S.A. (fabricante ficticio de software) y Plataforma de Datos Caribeños S.R.L. (proveedor ficticio de servicios en la nube) enfrentan dificultades específicos de reconocimiento de ingresos bajo la NIIF 15.
Las características comunes de los contratos tecnológicos en Costa Rica incluyen:
---

• Acuerdos de Software-as-a-Service (SaaS): servicios de acceso a aplicaciones basadas en la nube con facturas recurrentes mensuales o anuales
• Bundled offerings: combinaciones de licencias de software, servicios de aplicación, y soporte técnico en un único paquete contractual
• Consideración variable: cargos por uso basados en consumo, bonificaciones por hito, y penalizaciones por incumplimiento de niveles de servicio (SLA)
• Deferred revenue: deferimiento de ingresos anticipados (por ejemplo, suscripciones pagadas por adelantado por un período de 12 meses)

Expectativas regulatorias de SUGEVAL y el CCPA

Aunque SUGEVAL no ha publicado una revisión temática formal dedicada a la NIIF 15, los auditores que trabajan con entidades cotizadas costarricense deben aplicar los estándares internacionales de auditoría (NIA) sin modificación. Los hallazgos de inspección internacionales, particularmente los de la FRC (Reino Unido) y la AFM (Holanda), son una fuente confiable de tendencias de calidad de auditoría en la aplicación de la NIIF 15. Estos organismos reguladores internacionales han identificado consistentemente que:
Para el contexto costarricense, estas hallazgos internacionales se aplican directamente: un auditor que trabaja con una entidad de tecnología cotizada en SUGEVAL debe estar alerta a estos riesgos comunes.
---

• Los auditores con frecuencia no desafían adecuadamente la identificación de obligaciones de desempeño distintas en arreglos complejos o agrupados
• La evaluación de la consideración variable (en particular, la estimación de restricciones) es a menudo insuficiente
• La testing de métodos de progreso para ingresos reconocidos a lo largo del tiempo es a menudo superficial
• La contabilización de modificaciones de contrato se pasa por alto, particularmente en relaciones de largo plazo

El modelo de cinco pasos de la NIIF 15: Descripción general

La NIIF 15 establece un modelo de cinco pasos para reconocer ingresos de actividades ordinarias:
En la industria tecnológica costarricense, el dificultad más grande es típicamente el Paso 2 (identificación de obligaciones distintas en bundled arrangements) y el Paso 3 (estimación de consideración variable para servicios basados en consumo).
---

• Identificar el contrato (NIIF 15.9–21): verificar que el contrato cumple cinco criterios para ser reconocido
• Identificar obligaciones de desempeño (NIIF 15.22–30): determinar qué bienes o servicios son distintos
• Determinar el precio de transacción (NIIF 15.47–72): cuantificar la consideración esperada, incluida la consideración variable
• Asignar el precio de transacción (NIIF 15.73–86): distribuir el precio entre las obligaciones de desempeño distintas
• Reconocer ingresos (NIIF 15.31–45): reconocer ingresos cuando (o a medida que) se transfiere el control del bien o servicio al cliente

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

Un contrato con un cliente existe cuando se cumplen cinco criterios obligatorios:

Criterio A: Aprobación y compromiso de las partes

Las partes han aprobado el contrato y se han comprometido a ejecutar sus obligaciones respectivas.
En la práctica tecnológica costarricense, la aprobación puede ser:
Orientación para auditores: Si una entidad tecnológica costarricense afirma que un "acuerdo marco" genera un contrato, verifique que el cliente ha dado instrucciones específicas para servicios bajo ese marco. Un acuerdo marco sin órdenes de compra generales específicas puede no constituir un contrato hasta que se emita la orden.

Criterio B: Identificación de derechos de cada parte

El auditor puede identificar los derechos de ambas partes respecto a los bienes o servicios a transferir.
Para contratos SaaS típicos:
Orientación para auditores: Si un contrato contiene cláusulas de "uso justo" (fair use clauses) que limitan el consumo sin especificar un límite cuantitativo, documente cómo se determinó el alcance del derecho del cliente y si esa limitación afecta al reconocimiento de ingresos.

Criterio C: Identificación de términos de pago

Los términos de pago incluyen el monto, el timing, y la forma de consideración.
Para entidades tecnológicas costarricense:
Orientación para auditores: Verificar que los términos de crédito estén completamente identificados. Si el contrato es silencioso respecto a la fecha de pago, determine los términos según la práctica comercial habitual de la entidad (por ejemplo, pago neto 30 días es el estándar para SaaS en Costa Rica).

Criterio D: Sustancia comercial

El contrato tiene sustancia comercial: cambia el riesgo, timing, o importe de los flujos de efectivo futuros de la entidad.
Casi todos los contratos comerciales con clientes independientes tienen sustancia comercial. Las transacciones barterización (intercambio de servicios de valor similar sin efectivo) o transacciones intragrupales pueden carecer de sustancia comercial.
Orientación para auditores: Si una entidad tecnológica costarricense intercambia licencias de software con otra entidad por servicios de valor similar, cuestione si la transacción tiene sustancia comercial.

Criterio E: Probabilidad de cobro

Es probable que la entidad cobre la consideración a la que tiene derecho. "Probable" bajo NIIF 15 significa "más probable que no".
Para entidades tecnológicas costarricense, evalúe:
Si la entidad ofrece un descuento de precio porque anticipa que el cliente no pagará el monto completo, la evaluación de probabilidad se realiza sobre el monto neto (después del descuento), no sobre el precio establecido.
Orientación para auditores: En la industria tecnológica costarricense, donde las suscripciones SaaS se renuevan automáticamente, verifique las tasas de renovación. Una tasa de renovación del 85% al 90% es típica; si cae por debajo del 70%, investigue si el cliente tiene dificultades de pago o si ha reducido su consumo.

Combinación de contratos (NIIF 15.17)

Si se han negociado múltiples contratos como un paquete con un objetivo comercial único, combínelos para fines de contabilización.
Indicadores de combinación en contratos tecnológicos:
Orientación para auditores: Si ve que un cliente ha firmado dos contratos con la misma fecha de ejecución y términos interconectados, considere si deben ser contabilizados como una obligación de desempeño única.

Modificaciones de contrato (NIIF 15.18–21)

Cuando un cliente solicita cambios en el contrato (por ejemplo, agregar usuarios adicionales, extender el período de vigencia, cambiar el ámbito de servicios), evalúe cómo contabilizar la modificación.
Tres resultados posibles:
1) Prospectivo (nuevo contrato separado): si los bienes/servicios agregados son distintos Y el aumento de precio refleja los precios de venta independientes de esos bienes/servicios, contabilice como si el contrato original hubiera terminado y se haya creado uno nuevo.
Ejemplo: Empresa de tecnología costarricense Gestión de Datos Centroamericana S.A. tiene un contrato existente por ₡2.000.000 anuales por un módulo de reportería. El cliente solicita agregar un módulo de análisis predictivo distinto. El precio para el módulo nuevo es de ₡800.000 anuales (y es comparable a lo que cuesta venderlo por separado). Contabilice el módulo nuevo como una obligación de desempeño separada en un "nuevo contrato".
2) Cumulative catch-up (mismo contrato, ajuste al ingresos ya reconocido): si los bienes/servicios restantes (después de la modificación) no son distintos de lo que ya se ha transferido, aplique un ajuste retroactivo al ingreso ya reconocido.
Ejemplo: El mismo cliente solicita extender su suscripción de reportería en 6 meses adicionales con el mismo precio unitario. Dado que la extensión no es distinta de la suscripción original (ambas son acceso a reportería), contabilice la extensión prospectivamente como parte de una obligación de desempeño única que continúa.
3) Combinación (modificación dentro del contrato original): si los bienes/servicios agregados son distintos pero la modificación es integral a la relación original (por ejemplo, una ampliación de funcionalidad menor), combínelos.
---

• Un acuerdo firmado (forma más común)
• Una orden de compra aceptada por el proveedor
• Un patrón establecido de negociación (por ejemplo, renovaciones anuales automáticas de suscripciones SaaS)
• Comunicación oral (menos común en transacciones formales, pero posible en relaciones de largo plazo)
• El cliente tiene derecho a: acceso a la plataforma durante el período de suscripción, actualizaciones de software, soporte técnico dentro del horario de negocio
• El proveedor tiene derecho a: el pago (en dinero) al final del período de facturación
• Pago fijo mensual: cliente paga una tarifa plana de ₡500.000 mensuales por acceso ilimitado al software
• Pago variable basado en consumo: cliente paga ₡0,15 por transacción procesada, facturado mensualmente
• Pago con hito: cliente paga en tres cuotas: 40% a la firma del contrato, 40% a la aplicación completada, 20% a 30 días después de la aceptación en vivo
• Historial de crédito del cliente: ¿ha pagado facturas anteriores a tiempo?
• Condición financiera: ¿tiene el cliente capacidad aparente de pagar? (analizar estados financieros públicos si la entidad es cotizada)
• Garantías colaterales: ¿ha colocado el cliente un depósito de seguridad?
• Prácticas de descuento de precio: ¿ha ofrecido la entidad un descuento de precio porque sospecha la cobrabilidad?
• El precio de una licencia de software depende de si el cliente también compra un servicio de aplicación (pricing interdependiente)
• Una suscripción SaaS se negoció junto con un contrato de soporte técnico garantizado (objetivo comercial vinculado)
• El cliente acepta una suscripción de 3 años pero recibe un descuento de volumen solo si también compra un módulo complementario

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 distinto al cliente. Cada obligación de desempeño distinta se contabiliza por separado.

Criterio de distinción (NIIF 15.27)

Un bien o servicio es distinto si cumple ambas condiciones:

(a) Capacidad de ser distinto

El cliente puede beneficiarse del bien/servicio por sí solo o junto con otros recursos fácilmente disponibles.
Análisis para contratos tecnológicos:
| Bien/Servicio | ¿Distinto? | Justificación |
|---|---|---|
| Licencia de software | Sí | El cliente puede usar el software por sí solo sin soporte adicional. La entidad lo vende regularmente de forma independiente. |
| Servicio de aplicación | Sí | El cliente puede contratar a un tercero diferente para la aplicación si lo desea. Es un servicio separado de la licencia. |
| Servicio de soporte técnico | Sí | El cliente puede obtener soporte de terceros (por ejemplo, un partner certificado) independientemente de la licencia. |
| Datos de configuración personalizados | Quizás no | Si los datos están tan personalizados que solo funcionan con el software específico de la entidad y no están disponibles en el mercado, puede que no sean distintos. El cliente no puede beneficiarse de los datos sin el software. |
| Actualizaciones de software (incluidas en la suscripción) | Sí | Las actualizaciones se proporcionan regularmente y el cliente podría, en teoría, esperar a actualizaciones futuras en lugar de suscribirse ahora. |
Orientación para auditores: Verifique qué componentes vende la entidad por separado. Si el software se vende tanto en un paquete "software + aplicación + soporte" como como "solo software", entonces cada elemento es distinto en el paquete. Si la entidad nunca vende solo la aplicación (siempre viene con software), cuestione si la aplicación es distinta.

(b) Separabilidad dentro del contexto del contrato

La promesa es identificable de forma separada de otras promesas en el contrato: es decir, el bien/servicio no está integrado de manera central con otro bien/servicio de la entidad.
Indicadores de NON-distinctness (la promesa no es separable):
Análisis para contratos tecnológicos comunes:
Caso 1: Licencia SaaS + aplicación + Soporte
Resultado: Tres obligaciones de desempeño distintas.
Caso 2: Desarrollo de Software Personalizado + Mantenimiento de Largo Plazo
Resultado: Probablemente dos obligaciones distintas, pero verifique si el software puede ser mantenido por terceros.
Caso 3: Servicio de Procesamiento de Datos + Análisis de Negocio Mensual
Resultado: Depende de la naturaleza de la incorporación. Generalmente distintos, pero documente el razonamiento.

Disposición de series (NIIF 15.22(b))

Si una entidad promete transferir una serie de bienes o servicios distintos que son sustancialmente los mismos y tienen el mismo patrón de transferencia, puede contabilizar la serie como una obligación de desempeño única.
Ejemplo de serie: Un cliente contrata un servicio de mantenimiento mensual de software durante 12 meses. Cada mes se proporciona la actualización de la base de datos, reparación de bugs, y ajustes de configuración. Todos estos servicios mensuales son sustancialmente los mismos (actualizaciones de rutina) y siguen el mismo patrón de transferencia (al final de cada mes, cuando se han completado los servicios).
¿Resultado? La serie de 12 servicios mensuales puede contabilizarse como una obligación de desempeño única (el contrato de mantenimiento de 12 meses), no como 12 obligaciones separadas.
Orientación para auditores: La disposición de series simplifica la contabilización cuando una entidad proporciona servicios recurrentes sustancialmente idénticos. Verifique que el cliente recibe el mismo nivel de servicio cada mes. Si un mes hay una actualización importante de funcionalidad (no solo bug fixes), entonces ese mes puede no ser "sustancialmente el mismo" y podría requerir una obligación separada.
---

• Integración significativa: la entidad proporciona un servicio de integración que combina múltiples bienes/servicios en un resultado conjunto. Por ejemplo, un proveedor de software que diseña una solución personalizada que integra su software con sistemas de terceros de tal manera que los componentes son inseparables.
• Modificación significativa: un bien/servicio modifica sustancialmente otro. Por ejemplo, trabajo de aplicación que personaliza el software para que tenga características específicas que no existen en la versión estándar.
• Interdependencia alta: cada bien/servicio depende de forma notable de los otros. Por ejemplo, en un contrato de desarrollo de software personalizado, el análisis de requisitos, el diseño, la codificación y las pruebas son interdependientes; no se pueden proporcionar de forma separada de forma considerable.
• ¿La licencia SaaS es distinta de la aplicación? Sí, porque la entidad vende acceso de SaaS a muchos clientes sin aplicación.
• ¿la aplicación es distinta del soporte? Sí, porque el soporte es ofrecido regularmente sin una aplicación inicial.
• ¿Son todas tres obligaciones distintas? Normalmente sí, a menos que la aplicación esté tan customizada que el software no pueda funcionar sin ella (lo cual sería inusual).
• ¿El desarrollo inicial es distinto del mantenimiento? Esta es una pregunta más compleja. Si el cliente contrata el mantenimiento con una entidad diferente, ¿el software funciona? Probablemente sí, así que es distinto. Pero si la entidad diseñó el software de tal manera que solo ella puede mantenerlo (por ejemplo, documentación limitada, código propietario ofuscado), entonces el mantenimiento podría no ser separable.
• El análisis depende de si el cliente puede sustituir el servicio de mantenimiento con otra entidad sin una pérdida significativa de valor.
• ¿El procesamiento de datos es distinto del análisis de negocio? Si el cliente podría obtener el análisis de un tercero analizando los datos ya procesados, entonces sí, son distintos. Si el análisis es tan integrado con los datos que no se puede entender sin una relación continua con la entidad, entonces quizás no sean distintos.

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

El precio de transacción es la cantidad de consideración a la que la entidad espera tener derecho a cambio de la transferencia de bienes o servicios prometidos.

Consideración fija

Cuando un cliente se compromete a pagar un monto fijo (por ejemplo, ₡500.000 por una suscripción anual), el precio de transacción es simple: ₡500.000.

Consideración variable

Cuando el monto que la entidad recibirá depende de eventos futuros o acciones del cliente, el precio incluye consideración variable.
Fuentes comunes de consideración variable en tecnología:
| Fuente | Ejemplo | Cómo estimarlo |
|---|---|---|
| Descuentos de volumen | Cliente obtiene 10% de descuento si compra 1.000+ licencias | Usar el método del valor esperado o el monto más probable |
| Reembolsos | Cliente puede devolver el software dentro de 30 días por reembolso completo | Estimar el porcentaje probable de devoluciones |
| Bonificaciones de rendimiento | Si el software logra 99,5% de uptime, cliente paga un bonus de ₡50.000 | Evaluar si 99,5% uptime es probable |
| Penalidades por SLA incumplido | Si uptime cae por debajo del 95%, cliente recibe crédito de ₡10.000 | Evaluar si es probable que se incumpla el SLA |
| Cargos por consumo | Cliente paga ₡0,15 por cada transacción procesada, facturado mensualmente | Estimar el volumen probable de transacciones |
| Incentivos de renovación | Si cliente renueva antes de que venza su contrato actual, recibe 15% de descuento | Evaluar probabilidad de renovación temprana |

Estimación de consideración variable: Método del valor esperado vs. monto más probable (NIIF 15.53)

La entidad debe usar el método que mejor predice el monto de consideración al que tendrá derecho.
Método del valor esperado (probabilidad ponderada):
Ejemplo: Empresa Soluciones de Nube Tica S.A. vende una suscripción con descuento de volumen. El cliente pagará:
Valor esperado = (₡1.000.000 × 0,30) + (₡850.000 × 0,70) = ₡300.000 + ₡595.000 = ₡895.000
Método del monto más probable:
Ejemplo alternativo: Si la entidad analiza los datos históricos del cliente y determina que es casi seguro (90%+) que comprará 1.000+ licencias, entonces el monto más probable es ₡850.000.
Orientación para auditores:

Restricción de consideración variable (NIIF 15.56–58)

Incluso después de estimar la consideración variable, la entidad debe aplicar una restricción: solo reconocer la consideración variable si es probable que no haya una reversión significativa posterior.
"probable" significa sustancialmente más probable que no, pero es un estándar más alto que "probable". La NIIF 15 proporciona orientación en NIIF 15.57–58.

Factores a considerar para evaluar la restricción (NIIF 15.57):

Restricción de consideración variable: ejemplos en tecnología

Ejemplo 1: Bonus de rendimiento probable
Entidad: Plataforma de Datos Caribeños S.R.L.
Contrato: SaaS con garantía de 99,5% de uptime. Si se cumple, cliente paga bonus de ₡50.000.
Ejemplo 2: Reembolso con reversión probable
Entidad: Aplicaciones Médicas del Caribe S.A. (proveedor ficticio de software médico)
Contrato: Suscripción a aplicación de gestión de clínicas con período de prueba de 60 días con reembolso íntegro si el cliente no está satisfecho.

Consideración no monetaria (NIIF 15.66)

Si el cliente promete bienes o servicios en lugar de efectivo, mida la consideración al valor justo de los bienes/servicios recibidos o, si no es determinable, el precio de venta independiente del bien/servicio de la entidad.
Ejemplo en tecnología: Un cliente pequeño costarricense ofrece pagar una licencia de software con servicios de diseño gráfico personalizados en lugar de efectivo. Si el diseño tiene un valor de mercado de ₡300.000, reconozca ₡300.000 como consideración.

Componente de financiamiento significativo (NIIF 15.60–65)

Si el tiempo entre la transferencia del bien/servicio y el pago es significativo, ajuste el precio de transacción para reflejar el valor temporal del dinero.

¿Cuándo aplica?

La NIIF 15 requiere este ajuste solo si hay un "componente de financiamiento significativo" implícito en el contrato. Esto es más probable cuando:

¿Cómo se ajusta?

Descontar la consideración futura al valor presente usando la tasa de interés de descuento implícita en el contrato (o una tasa equivalente si no es explícita).
Ejemplo: Un cliente paga una suscripción de ₡1.000.000 al principio del año por servicios a prestar durante todo el año. El componente de financiamiento implícito es aproximadamente 6 meses de "préstamo" de fondos a la entidad. Si la tasa de interés de mercado es el 6% anual, ajuste:
El resto (₡30.000) se reconoce como ingreso por intereses a lo largo del año.
Orientación para auditores: En la industria SaaS costarricense, donde los clientes típicamente pagan mensuales o al inicio de cada período de facturación, el componente de financiamiento generalmente es inmaterial (pocos meses de diferencia). Las excepciones incluyen:
---

• Suma todos los posibles resultados, multiplicados por su probabilidad
• Mejor cuando hay muchos resultados posibles (por ejemplo, descuentos de volumen con múltiples umbrales)
• Fórmula simple: (Resultado A × Probabilidad A) + (Resultado B × Probabilidad B) + ...
• ₡1.000.000 si compra 500-999 licencias (estima probabilidad: 30%)
• ₡850.000 si compra 1.000+ licencias (estima probabilidad: 70%)
• Toma el resultado más probable de una serie de posibles resultados (no un promedio, sino el específico más probable)
• Mejor cuando hay pocos resultados posibles discretos, o cuando una opción domina claramente en probabilidad
• Más simple pero requiere identificar qué es "más probable"
• Verifique que la entidad ha documentado cómo eligió entre estos dos métodos. Si la elección no es clara, cuestione.
• Para servicios basados en consumo (como cargos por transacción), el método del valor esperado es generalmente más apropiado, porque hay muchos posibles volúmenes de transacciones.
• Si los datos históricos muestran patrones claros (por ejemplo, el cliente siempre compra entre 1.000 y 1.200 licencias cada año), el monto más probable puede ser más apropiado.
• Amplitud del rango de resultados posibles: Si el rango de posibles reembolsos es amplio (por ejemplo, entre ₡0 y ₡500.000), hay mayor incertidumbre, así que menos consideración variable satisface el criterio de "probable".
• Experiencia histórica: Si la entidad ha ofrecido descuentos similares en el pasado y sabe que el 95% de los clientes cumplen la condición, entonces es probable. Si solo ha visto el 40% cumplir condiciones similares, entonces NO es probable.
• Cambio comercial esperado: Si se anticipa un cambio notable en el volumen de transacciones (por ejemplo, la economía entra en recesión), la experiencia pasada puede no ser fiable.
• Grado de subjetividad en la estimación de la condición: Algunas condiciones son objetivas (uptime medible), otras son subjetivas (satisfacción del cliente). Las subjetivas tienen mayor riesgo de reversión.
• Experiencia histórica: en los últimos 24 meses, la plataforma ha logrado 99,5%+ de uptime el 98% de los meses.
• Análisis: es probable que el bonus sea ganado.
• Conclusión: reconocer todo el bonus de ₡50.000 en la estimación del precio de transacción.
• Experiencia histórica: 45% de clientes solicitan reembolso dentro de los 60 días.
• Análisis: no es probable que la entidad retenga el ingreso completo.
• Conclusión: estimar el precio de transacción como ₡X × (1 - 45%) = ₡X × 55%, solo reconocer como ingresos la porción que es probable de retener.
• El cliente paga con un atraso importante después de la transferencia del control (por ejemplo, pago a los 12 meses después de la aplicación completada)
• El cliente paga por adelantado antes de la transferencia del control (por ejemplo, suscripción pagada a principios de año por servicios que se prestarán durante todo el año)
• La diferencia entre el precio en efectivo y el precio pagado es grande (más del ~10-15% es generalmente considerado significativo)
• Consideración nominal pagada al inicio del año: ₡1.000.000
• Ingreso de financiamiento implícito (6% × 6 meses): ≈ ₡30.000
• Precio de transacción (consideración por bienes/servicios): ₡1.000.000 - ₡30.000 = ₡970.000
• Suscripciones anuales pagadas al principio del año (ingreso diferido)
• Contratos de aplicación con pagos en múltiples hitos (financiamiento de largo plazo)

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

Después de determinar el precio de transacción total, asigne ese monto a cada obligación de desempeño distinta. El método es: asignar según los precios de venta independientes (PVI) de cada bien/servicio.

Precios de venta independientes (NIIF 15.76–80)

El PVI es el precio al que la entidad vendería un bien o servicio al cliente de forma independiente (es decir, por separado, sin el paquete).

Métodos para determinar PVI (NIIF 15.79–80):

| Método | Descripción | Cuándo usar |
|---|---|---|
| Precio observable | La entidad vende regularmente el bien/servicio de forma separada a clientes similares | Primera opción si está disponible |
| Precio evaluado | La entidad ajusta los precios observables por diferencias en circunstancias (por ejemplo, descuentos por volumen, geografía) | Cuando se venden de forma separada, pero no a clientes exactamente similares |
| Método de resalte (residual) | Asigne toda la consideración variable a una obligación y derive el PVI de la otra restando | Último recurso cuando el PVI no se puede estimar de otra forma |

Ejemplo de asignación de PVI en contratos tecnológicos

Contrato: Cliente compra "Licencia de Software + aplicación + 12 Meses de Soporte" por ₡3.000.000.
Determinación de PVI:
Total de PVI: ₡1.500.000 + ₡700.000 + ₡120.000 = ₡2.320.000
Asignación:
Tratamiento contable:

Método de resalte: cuándo es el último recurso

El método de resalte (residual) es cuando:
Este método se usa cuando no se puede estimar el PVI de una o más obligaciones porque:
Ejemplo: Contrato de desarrollo de software personalizado. La entidad desarrolla software único para un cliente. El precio es ₡5.000.000 por "Análisis de Requisitos + Diseño + Codificación + Pruebas".
Como este software es único, la entidad no tiene comparables para el precio de venta independiente de "Codificación" o "Diseño". Podría:
Orientación para auditores: El método de resalte introduce subjetividad. Si la entidad lo usa, verifique que:
---

• Licencia (vendida regularmente sola a clientes similares): ₡1.500.000
• aplicación (la entidad cobra típicamente ₡700.000 por aplicación de este tamaño): ₡700.000
• Soporte (la entidad cobra ₡10.000/mes × 12 meses en contratos separados): ₡120.000
• A licencia: ₡3.000.000 × (₡1.500.000 / ₡2.320.000) = ₡1.936.207
• A aplicación: ₡3.000.000 × (₡700.000 / ₡2.320.000) = ₡905.172
• A soporte: ₡3.000.000 × (₡120.000 / ₡2.320.000) = ₡155.172
• Total: ₡3.000.000 ✓
• Licencia (obligación de desempeño a punto en el tiempo): reconocer ₡1.936.207 cuando la licencia esté lista para usar (normalmente inmediatamente)
• aplicación (obligación de desempeño a punto en el tiempo): reconocer ₡905.172 cuando la aplicación esté completada
• Soporte (obligación de desempeño a lo largo del tiempo): reconocer ₡155.172 a lo largo de los 12 meses (₡12.931/mes)
• La entidad asigna el precio de transacción a todas las obligaciones excepto una
• La cantidad restante se asigna a la última obligación
• La entidad rara vez vende ese bien/servicio de forma separada
• El PVI varía de forma notable según el cliente
• El bien/servicio es personalizado
• Usar la experiencia histórica para estimar el PVI de "Análisis de Requisitos" (observable, la entidad lo vende con frecuencia): ₡500.000
• Estimar el PVI de "Pruebas" (también observable, la entidad cobra por pruebas): ₡800.000
• Residual: ₡5.000.000 - ₡500.000 - ₡800.000 = ₡3.700.000 asignado a "Diseño + Codificación" como una sola obligación
• La estimación de los PVI usados como base es bien soportada (datos históricos, precios de mercado)
• La obligación residual es identificable y tiene contenido económico real
• No se usa para asignar toda la incertidumbre a una obligación

Paso 5: Reconocer Ingresos (NIIF 15.31–45)

La entidad reconoce ingresos cuando (o a medida que) transfiere el control del bien o servicio prometido al cliente. El control es el factor determinante.

¿Cuándo se transfiere el control? Punto en el tiempo vs. a lo largo del tiempo (NIIF 15.35)

La entidad reconoce ingresos en un punto en el tiempo O a lo largo del tiempo, según cuál aplique.

Ingresos reconocidos a lo largo del tiempo (NIIF 15.35)

Reconocer ingresos a lo largo del tiempo si se cumple al menos uno de estos criterios:
Criterio 1: El cliente recibe y consume simultáneamente los beneficios mientras la entidad ejecuta.
Ejemplo: Servicios de limpieza mensuales. El cliente recibe el beneficio (locales limpios) en el mismo momento que la entidad limpia. Reconocer ingresos mensualmente.
Criterio 2: El desempeño de la entidad crea un activo que el cliente controla a medida que se crea.
Ejemplo: Construcción de un edificio según especificaciones del cliente. El edificio se construye sobre la propiedad del cliente y según sus especificaciones. Aunque no está completado, el cliente controla el activo en proceso. Reconocer ingresos a medida que avanza la construcción.
Criterio 3: La entidad tiene sin alternativa de uso para el activo creado Y tiene un derecho exigible al pago por el desempeño completado hasta la fecha.
Ejemplo: Desarrollo de software personalizado donde el código fuente debe ser entregado al cliente y la entidad no puede usarlo para otros clientes. El cliente ha autorizado la entidad a comenzar el trabajo y ha acordado pagar por cualquier trabajo completado incluso si el cliente cancela. Reconocer ingresos a medida que el software se desarrolla.

Cómo medir el progreso para ingresos a lo largo del tiempo (NIIF 15.39–40)

Si la entidad reconoce ingresos a lo largo del tiempo, debe medir el progreso hacia la satisfacción completa de la obligación de desempeño.
Dos métodos:
| Método de entrada | Método de salida |
|---|---|
| Mide el trabajo input realizado por la entidad | Mide el valor output entregado al cliente |
| Insumos: horas de trabajo, costos incurridos, recursos consumidos | Outputs: unidades producidas, hitos completados, progreso físico |
| Usa el indicador observable de input (horas * tasa de costo) | Usa el indicador observable del resultado (% del trabajo completado) |
| Mejor cuando los inputs son fiables y correlacionan con el progreso | Mejor cuando los outputs son cuantificables y objetivos |
Ejemplo de método de entrada: Empresa Desarrollo de Sistemas Tico S.A. contrata desarrollo de aplicación Web. El presupuesto es ₡3.000.000 en costos totales. Después de 2 meses, la entidad ha incurrido en ₡1.200.000 en costos.
Ejemplo de método de salida: Mismo contrato, pero dividido en 5 hitos (Análisis, Diseño, Codificación, Pruebas, aplicación). Después de 2 meses, la entidad ha completado Análisis (20% del trabajo) y parte de Diseño (estimado 10% del total).
Orientación para auditores:

Ingresos reconocidos en un punto en el tiempo (NIIF 15.38)

Si la obligación de desempeño no cumple los criterios de "a lo largo del tiempo", reconocer ingresos en el punto en el tiempo en que se transfiere el control al cliente.
Indicadores de transferencia de control (NIIF 15.38):
En tecnología costarricense: la mayoría de los casos son puntos en el tiempo:
| Bien/Servicio | Punto de transferencia | Justificación |
|---|---|---|
| Licencia de software (entrega de clave de activación) | Cuando se proporciona la principal y el cliente puede acceder | Cliente tiene control inmediato |
| Acceso a SaaS | Cuando el cliente puede acceder por primera vez a la plataforma | Control es inmediato |
| Servicio de aplicación | Cuando la aplicación está completada y aceptada | Criterio 1 NIIF 15.35 no se cumple (cliente no recibe/consume durante la aplicación) |
| Descarga de software | Cuando se completa la descarga y el cliente puede instalar | Cliente tiene acceso inmediato |
| Datos enviados a cliente | Cuando se entregan los datos y cliente puede acceder | Cliente tiene control |

Reembols​os y derechos de devolución (NIIF 15.B2–B5)

Si el cliente tiene derecho a devolver el bien/servicio para un reembolso u otro crédito, la entidad debe estimar el número probable de devoluciones y ajustar el ingreso reconocido.
Ejemplo: Suscripción de software con período de prueba de 30 días y reembolso completo si el cliente cancela.
---

• Progreso = ₡1.200.000 / ₡3.000.000 = 40%
• Ingresos a reconocer = Precio de transacción × 40% = ₡2.000.000 × 40% = ₡800.000
• Progreso = 30%
• Ingresos a reconocer = ₡2.000.000 × 30% = ₡600.000
• Verifique que el método de medición de progreso es consistente con los métodos usados en proyectos similares (principio de consistencia).
• Para contratos de costos más, asegúrese de que los costos incurridos incluyen solo costos directos del contrato, no costos generales asignados arbitrariamente (NIIF 15.40 límite de margen no debe ser negativo).
• Reclasifique cualquier método que combine tanto método de entrada como de salida de forma ad hoc sin justificación.
• La entidad tiene el derecho presente al pago por el activo (cliente es obligado a pagar)
• La entidad ha transferido la custodia física del activo (cliente lo tiene)
• El cliente asume riesgos y beneficios de la propiedad (pérdida, obsolescencia, cambios de valor)
• El cliente ha aceptado legalmente el activo
• El cliente tiene una obligación contractual de pago vinculada al activo específico
• Precio: ₡1.000.000 mensual
• Experiencia histórica: 20% de nuevos clientes solicitan devoluciones dentro de 30 días
• Ingresos a reconocer en el Mes 1: ₡1.000.000 × (1 - 20%) = ₡800.000
• Pasivo de devoluciones: ₡200.000 (estimado probable de devoluciones)

Consideraciones específicas para entidades tecnológicas costarricense

SaaS y servicios en la nube

Contrato típico: Cliente paga suscripción mensual de ₡50.000 por acceso a plataforma de gestión de datos en la nube.
Análisis NIIF 15:

Bundled offerings (software + aplicación + soporte)

Contrato típico: Cliente compra "Suite Completa de Software ERP" por ₡10.000.000 incluyendo licencia de software, aplicación personalizada de 3 meses, y 12 meses de soporte.
Análisis NIIF 15:

• Identificar el contrato: ¿Se cumplen los 5 criterios? Sí, hay aprobación (orden de compra), derechos definidos (acceso a la plataforma), términos de pago claros, sustancia comercial (cambios en los flujos de efectivo), probabilidad de cobro (cliente pequeño pero con historial de pago).
• Identificar obligaciones: Una obligación de desempeño única: acceso a la plataforma durante el mes.
• Determinar precio: ₡50.000 fijo, sin consideración variable (salvo si hay límites de consumo u otros cargos).
• Asignar precio: Todo ₡50.000 a la obligación única.
• Reconocer ingresos: ¿A lo largo del tiempo o punto en el tiempo? El cliente recibe y consume simultáneamente el beneficio cada mes (criterio 1 NIIF 15.35), así que reconocer ₡50.000/mes a lo largo del mes o ₡50.000 al final del mes cuando se ha entregado el servicio completo. (La mayoría de entidades elige lo primero.)
• Identificar el contrato: Sí, contrato válido.
• Identificar obligaciones:
• Licencia de software (obligación 1)
• Servicio de aplicación (obligación 2)
• Servicio de soporte mensual durante 12 meses (obligación 3, serie de 12 servicios que pueden ser una obligación única si son sustancialmente los mismos)
• Determinar precio: ₡10.000.000 fijo.
• Asignar precio según PVI:
• Licencia: observable, se vende por ₡6.000.000
• aplicación: ₡2.500.000 (estimado de proyectos similares)
• Soporte: ₡1.500.000 (₡125.000/mes × 12)
• Total PVI: ₡10.000.000 (coincide exactamente)
• Asignación: cada obligación recibe su PVI
• Reconocer ingresos:
• Licencia: ₡