Servicios e intangiblescharacterization-tree

Software, licencias y SaaS intercompañía: separar servicio, regalía y reembolso

Llamar SaaS al contrato no resuelve la naturaleza fiscal de cada derecho, soporte y componente tecnológico.

Corte de fuentes: 2 de agosto de 2026. Verifique cambios posteriores antes de aplicar este material.

Respuesta ejecutiva

Un cargo “SaaS” puede contener acceso remoto a una aplicación, derecho de copia, modificación, distribución, hosting, capacidad de nube, implementación, soporte, mantenimiento, datos y compras de terceros. Cada componente puede tener funciones, riesgos, base, método y tratamiento fiscal distintos. El nombre del producto o contrato no decide.

Primero delimite qué recibe México y qué puede hacer. Después identifique quién presta, posee derechos, contrata proveedores, controla arquitectura y asume riesgos. Sólo entonces determine si existe licencia, servicio, reventa, reembolso, contribución de costos u otra operación, y analice plena competencia, deducción, retención, IVA, comprobantes y declaraciones.

No existe una respuesta universal para software. La clasificación depende de LISR, tratado aplicable, derechos contractuales y conducta. Un benchmark de margen no sustituye el memorando legal y fiscal; un análisis de retención no sustituye el pricing.

Inventario de componentes

Componente Pregunta Evidencia Posible análisis
Acceso SaaS ¿Sólo usa funcionalidad remota? usuarios, términos, logs servicio/acceso según hechos
Copia ¿Puede reproducir localmente? licencia, instalación derechos de software
Modificación ¿Puede alterar código? repositorio, permisos licencia/desarrollo
Distribución ¿Puede sublicenciar o vender? contrato, clientes explotación de derecho
Hosting ¿Quién aporta infraestructura? arquitectura, consumo servicio/capacidad
Soporte ¿Qué nivel y personal? tickets, SLA servicio
Implementación ¿Proyecto específico? SOW, hitos servicio/proyecto
Datos ¿Quién accede y explota? derechos, flujos activo/servicio según hechos
Tercero ¿Quién compra y controla? factura, contrato reventa/pass-through
Desarrollo ¿Quién crea mejoras? código, roadmap DEMPE/servicio/intangible

La columna final no es conclusión fiscal. Señala preguntas que requieren análisis.

Árbol de caracterización

  1. ¿México obtiene un derecho sobre software o sólo accede a funcionalidad?
  2. ¿Puede copiar, modificar, distribuir, sublicenciar o explotar comercialmente?
  3. ¿El proveedor conserva código, infraestructura y control?
  4. ¿Existen implementación, soporte o mantenimiento separables?
  5. ¿La relacionada agrega valor a una licencia de tercero?
  6. ¿Asume obligación, riesgo y control frente al proveedor?
  7. ¿El costo se traslada sin modificación ni función?
  8. ¿Hay desarrollo o mejoras para México o para el grupo?
  9. ¿Quién posee esas mejoras y controla riesgos?
  10. ¿El contrato, factura y arquitectura coinciden?
  11. ¿Qué ley y tratado aplican al pago específico?
  12. ¿Los componentes requieren precios y retenciones separados?

Documente cada respuesta. “No se entrega código” es relevante, pero no resuelve por sí sola todo tratamiento.

Acceso frente a derechos

En un modelo SaaS típico, el usuario accede a funciones alojadas por el proveedor y no obtiene derechos para reproducir o explotar código. Sin embargo, contratos corporativos pueden conceder instalaciones, APIs, personalización, copias de respaldo, desarrollo o sublicencia. Lea anexos y conducta.

Defina usuarios, territorio, dispositivos, volumen, almacenamiento y restricciones. Un fee por empresa puede incluir capacidad disponible; uno por usuario depende de población. Concilie licencias activas, no sólo adquiridas.

Si México distribuye el producto a clientes, analice su papel: revendedor, agente, licenciatario o prestador. Los derechos y riesgos cambian el método y margen.

Servicios separables

Implementación puede incluir configuración, migración, integración, pruebas y capacitación. Soporte puede ser mesa de ayuda, mantenimiento, disponibilidad o desarrollo. Determine si el cliente puede comprar cada componente por separado y si tiene valor independiente.

Separar no significa necesariamente facturar por documentos distintos. Un contrato combinado puede tener un schedule que permita precio y análisis por componente. Evite asignaciones arbitrarias; use tarifas, horas, costos, comparables o valor relativo según hechos.

Documente entregables, personal, tickets, niveles y aceptación. Una cuota de “soporte” sin evidencia puede enfrentar problemas de materialidad.

Licencias de terceros y reembolsos

Una matriz puede negociar licencias globales y repartir costo. Determine si actúa como agente de compras, revendedor o proveedor integrado. ¿Selecciona solución, negocia, administra usuarios, garantiza servicio, asume crédito o integra herramientas? Las funciones pueden justificar remuneración.

Un traslado exacto de factura no es automáticamente reembolso neutral. Debe existir beneficio, criterio de asignación y vínculo con receptor. Revise quién es parte contractual y tiene derecho de uso. Un receptor no incluido en licencia puede no estar autorizado.

Separe costos pass-through de servicios propios. Si el centro añade soporte, cobre y documente por separado o mediante una base transparente. Evite margen sobre impuestos o partidas sin valor añadido sin análisis.

Desarrollo y mejoras

Cuando equipos mexicanos configuran o desarrollan módulos, mapee DEMPE: quién define roadmap, controla código, financia, prueba, protege y explota. Una personalización puede pertenecer al cliente, proveedor o grupo según contrato y hechos.

El costo adicionado puede remunerar desarrollo rutinario bajo control de otra entidad. Contribuciones únicas o control de riesgos pueden requerir otro enfoque. No describa programadores automáticamente como rutinarios.

Revise open-source y terceros. Restricciones pueden afectar derechos y valor. Conserve repositorios, tickets, decisiones y cesiones de empleados/proveedores.

Si una sola factura mezcla licencias, nube, soporte y desarrollo, construya el mapa de componentes antes de aplicar un margen o tasa de retención uniforme.

Base y claves de reparto

Para licencias globales, usuarios, consumo, capacidad, transacciones o dispositivos pueden ser claves. La elección debe aproximar beneficio. Ingresos rara vez mide uso tecnológico por sí solo. Identifique capacidad reservada aunque no se consuma.

Concilie factura del tercero a pool, depuración, clave y cargo. Excluya entidades sin acceso; incluya beneficiarios reales. Controle licencias inactivas y sobrecompra. Documente moneda y true-up.

Para infraestructura, mida almacenamiento, cómputo, tráfico o instancias. Para soporte, tickets ponderados o usuarios. No mezcle impulsores sin segmentar costos.

Precio de plena competencia

Un comparable directo puede existir en listas o contratos con terceros, pero revise volumen, territorio, derechos, nivel y bundle. Descuentos empresariales y compromisos mínimos importan. Precios públicos rara vez reflejan todas las condiciones.

Para servicios propios puede usarse costo adicionado si funciones y comparables lo permiten. Para reventa, evalúe margen de distribuidor. Para intangible único, considere otros métodos. Documente alternativas descartadas.

Evite doble margen en cadenas regionales. Siga costo y valor añadido por entidad. Una central de compras y un integrador pueden merecer remuneraciones distintas.

Retención, tratado e IVA

Clasifique cada pago conforme a derechos y normas aplicables. Verifique si la LISR y el tratado tratan el componente como regalía, beneficio empresarial, servicio u otra categoría. Revise residencia, requisitos y documentación. No use una tasa por analogía con otro producto.

El pago digital puede tener efectos de IVA y comprobación distintos. Coordine fecha, tipo de cambio, retención, acreditamiento, importación de servicios y entero según proceda. Este artículo no sustituye análisis legal del contrato concreto.

Si componentes tienen tratamientos diferentes, asigne contraprestación de manera defendible y documente. No fraccione artificialmente para reducir impuestos; tampoco agregue todo por conveniencia.

Contrato y arquitectura

Jurídico y tecnología deben revisar juntos. El contrato puede decir “nube” mientras la arquitectura muestra instalación local; o “licencia” mientras sólo existe acceso web. Prepare un diagrama de usuarios, datos, código, servidores, proveedores y flujos.

Incluya derechos, niveles, seguridad, privacidad, continuidad, mejoras, terminación, portabilidad de datos, auditoría, impuestos y precios. Identifique quién responde ante fallas. La conducta operativa debe coincidir.

Revise anexos de proveedor final y cadena de sublicencias. El intercompany agreement no puede conceder más de lo que la relacionada posee.

Expediente recomendado

  1. Catálogo de componentes.
  2. Diagrama de arquitectura y flujos.
  3. Contratos de tercero e intragrupo.
  4. Derechos y restricciones.
  5. Usuarios, consumo y beneficio.
  6. Servicios y evidencia.
  7. Desarrollo, DEMPE y propiedad.
  8. Cost pool y claves.
  9. Método y comparables.
  10. Caracterización fiscal y tratado.
  11. IVA, comprobantes y pago.
  12. Conciliación y declaraciones.

Señales de riesgo

  • Una descripción “servicios TI” para todo.
  • Contrato que no coincide con arquitectura.
  • México paga usuarios inexistentes.
  • Reembolso sin derecho de uso.
  • Margen sobre toda factura de tercero.
  • Desarrollo local sin cesión o remuneración.
  • Misma tasa fiscal para componentes distintos.
  • Datos sin derechos ni controles.
  • Cadenas con margen sobre margen.
  • Factura, cálculo y balanza diferentes.

Caso ilustrativo

La matriz compra un ERP global, opera nube y presta mesa de ayuda. México recibe 300 usuarios, implementación y soporte. El cargo debe abrir licencia de tercero, infraestructura, proyecto y servicio interno. Usuarios pueden repartir licencia; consumo, nube; horas/hitos, implementación; tickets, soporte.

La matriz negocia y administra, por lo que no todo es reembolso. Pero su margen no se aplica automáticamente al costo de licencia. El contrato debe permitir uso, y el análisis fiscal debe caracterizar componentes. El schedule reconcilia todo a una factura.

El resultado es operable y defendible: un pago puede permanecer consolidado, pero su construcción es transparente.

Gobierno

Tecnología mantiene arquitectura, usuarios y consumo; compras conserva contratos; jurídico revisa derechos y datos; fiscal analiza retención e IVA; precios de transferencia revisa método; contabilidad concilia. El comité aprueba nuevas herramientas y cambios.

Revise al renovar, migrar nube, añadir módulos, cambiar proveedor, desarrollar código o expandir usuarios. La política debe evitar “shadow IT” y cargos sin beneficiario.

Monitoree presupuesto, uso y margen trimestralmente. El cierre anual no debe ser la primera reconciliación.

Seguridad, continuidad y datos

La infraestructura digital también asigna riesgos. Identifique quién decide controles, responde incidentes, contrata seguros, mantiene respaldos y activa recuperación. Un centro que sólo ejecuta instrucciones no necesariamente controla riesgo; uno que diseña arquitectura y acepta interrupciones puede aportar más valor.

Documente ubicación, acceso, cifrado, portabilidad y eliminación de datos. Determine quién puede usar analítica y modelos derivados. Estos hechos pueden afectar precio, contrato y regulación, aunque no convierten automáticamente los datos en intangible separable.

Los niveles de servicio deben tener medición y consecuencias. Compare disponibilidad prometida con real, incidentes y créditos. Si México acepta un nivel menor o requiere capacidad exclusiva, el comparable debe reflejarlo.

Conciliación de factura digital

Prepare un schedule por componente, proveedor, moneda, periodo, base, clave, margen, impuesto y receptor. Recorra desde factura final hasta contrato y costo original. Explique reservas, descuentos, créditos, licencias abandonadas y true-ups.

Revise que el concepto contable coincida con naturaleza y que activos capitalizados no se cobren también como gasto. Coordine cuentas por pagar y activos fijos. Un único pago puede cubrir varios periodos; asigne correctamente.

Preguntas antes de aprobar

  1. ¿Qué funcionalidad y derechos recibe México?
  2. ¿Qué servicios son separables?
  3. ¿Quién controla proveedor y arquitectura?
  4. ¿La entidad que factura agrega valor?
  5. ¿Cada usuario o consumo existe?
  6. ¿La clave refleja beneficio?
  7. ¿El margen aplica a esa base?
  8. ¿Qué tratamiento fiscal corresponde por componente?
  9. ¿Contrato y arquitectura coinciden?
  10. ¿La cifra concilia con contabilidad y pago?

Las respuestas deben enlazar evidencia y responsable. Si el contrato no permite distinguir componentes, añada un anexo prospectivo sin fabricar historia.

Fuentes y fecha de corte

Contenido verificado al 2 de agosto de 2026. Consulte la LISR vigente, el portal del SAT sobre tratados y precios de transferencia, las Guías OCDE 2022 y el perfil OCDE de México. Verifique el tratado y contrato específicos.

El Digital Charge Review de Zugzwang separa derechos, acceso, infraestructura, soporte, desarrollo y reembolsos para alinear pricing, retenciones, contratos y registros.

Continúe el análisis

PT-031Servicios intragrupo: materialidad, beneficio y deducibilidad en MéxicoServicios PT-033Claves de reparto para servicios compartidos: cómo elegir allocation keys defendiblesServicios PT-036Regalías entre partes relacionadas: precio, sustancia y retencionesServicios e intangibles

Un caso específico

Convierta la pregunta en una decisión defendible.

Este artículo es información general. Continúe por WhatsApp para identificar el tema y revisar los hechos.

Revisar este tema por WhatsApp