Revelando el caos de la facturación: El plan de 90 días para SaaS

SaaS‑Sprawl es 2026 en los equipos de nube de medianas empresas ya no una teoría, sino una fricción palpable en la contabilidad mensual de costes. Marketing, Recursos Humanos (RRHH), Ventas y equipos de Ingeniería adquieren herramientas con tarjeta de crédito, sin que Tecnología de la Información (TI), Compras o FinOps (operaciones financieras de la nube) lo sepan. Quien quiera cambiarlo de forma sistemática no necesita un Big‑Bang, sino un programa de 90 días compuesto por tres componentes: análisis de tarjetas de crédito para detectar compras en la sombra, conciliación de logs de Single Sign‑On (inicio de sesión único) para el uso real y una pipeline automática de recuperación de licencias para licencias no utilizadas. La comprobación práctica muestra cómo se puede aplicar esto en una empresa mediana de entre 200 y 2.000 empleados (en la región DACH, que incluye Alemania, Austria y Suiza).

Lo más importante en breve

Por qué el SaaS‑Sprawl será más perceptible en 2026

¿Qué es SaaS‑Sprawl? SaaS‑Sprawl describe el crecimiento descontrolado de licencias y suscripciones de software en la nube dentro de una empresa, sin que la función de TI (tecnología de la información), FinOps (gestión financiera de operaciones de TI) o compras tenga una visión completa. En el contexto de la región DACH (Alemania, Austria y Suiza), SaaS‑Sprawl es un fenómeno cada vez más relevante. Las aplicaciones son adquiridas por empleados o equipos individuales mediante tarjeta de crédito, luego se trasladan a cuentas corporativas o permanecen en estructuras sombra. El resultado son licencias redundantes, suscripciones sin uso, ausencia de descuentos por volumen y riesgos de cumplimiento en el procesamiento de datos y la gestión de identidades.

Tres impulsores han intensificado el efecto para 2026. Primero: herramientas de IA. Cada departamento desea Claude, Gemini, Copilot o una herramienta vertical especializada, a menudo de forma paralela y sin coordinación. Segundo: plataformas consolidadas de proveedores. Microsoft, Google y Salesforce venden paquetes que solapan internamente herramientas individuales. Quien no esté atento paga la misma herramienta dos veces. Tercero: rotación de empleados. Cada salida suele dejar entre tres y siete licencias SaaS activas que nunca se desactivan.

La magnitud se puede cuantificar bien para una empresa mediana. Una compañía con 500 empleados gasta en herramientas SaaS, en promedio, entre 1,5 y 3,5 millones de euros al año. Una auditoría bien gestionada de SaaS‑Sprawl recupera entre el 15 % y el 25 % de esa cifra. Son entre 250.000 y 875.000 euros al año que vuelven al presupuesto propio sin pérdida de funcionalidad de las herramientas. La inversión en el programa de 90 días suele situarse en el rango bajo de seis cifras. El retorno de la inversión (ROI) es alcanzable dentro del primer año.

Bloque 1: Minería de tarjetas de crédito para compras ocultas

La fuente más sencilla y, a menudo, la más eficaz es la facturación de tarjetas de crédito. Los empleados adquieren herramientas SaaS con tarjetas corporativas, habitualmente en un rango de 10 a 200 Euro al mes. Quien revisa sistemáticamente las facturas de tarjetas de crédito de los últimos 24 meses descubre decenas o incluso cientos de proveedores que no aparecen en la arquitectura TI central. Herramientas como Vendr, Tropic o Zluri ofrecen rutas de minería automatizadas que extraen los nombres de los proveedores de los cargos y los comparan con bases de datos internas de SaaS.

Un proceso típico se desarrolla así: el departamento de contabilidad entrega los datos de tarjetas de crédito de los últimos 24 meses en formato CSV. Un script de minería o una herramienta especializada agrupa la información por proveedor, frecuencia y volumen. En un plazo de dos a cuatro semanas se genera una lista de entre 50 y 300 proveedores SaaS. Cada proveedor se asigna a un responsable y se refleja en la base de datos central de activos. Las duplicaciones, herramientas descontinuadas y licencias fantasma quedan visibles. La reacción inicial en muchas organizaciones es la sorpresa ante la longitud de la lista.

La repercusión cultural no debe subestimarse. Quien comunica la minería de tarjetas de crédito de forma clara transmite a los empleados un sentido de responsabilidad sin etiquetarlos como “delincuentes de compras”. Un tono abierto - «queremos ver el uso real, no atraparlos» - sustenta el programa. Quien inicia con desconfianza pierde la colaboración de las áreas funcionales y, con ello, el mayor palanca de acción.

Bloque 2: Comparación de registros SSO para uso real

La segunda fuente de datos es el sistema de Single Sign-On (SSO). Los proveedores de identidad (Identity Provider) como Okta, Microsoft Entra, Google Workspace o Auth0 registran qué empleado se conecta, cuándo y a qué aplicación. Quien cruza estos registros con el inventario de licencias detecta dos patrones relevantes. Primero: herramientas que están licenciadas pero se usan rara o nunca. Segundo: herramientas que se utilizan intensamente pero no aparecen en el inventario de licencias, por ejemplo porque operan con cuentas de nivel gratuito (Free‑Tier).

Ambos patrones conllevan acciones concretas. Las licencias no utilizadas pueden reducirse en la próxima negociación contractual, a menudo con ahorros significativos. Las aplicaciones de nivel gratuito con alto uso deberían migrarse a contratos de licencia formales, tanto por motivos de cumplimiento normativo como para garantizar la seguridad de los datos. Quien no da este paso deja sus datos empresariales críticos en sistemas de terceros sin control.

La arquitectura técnica es sencilla. Una extracción semanal de datos del sistema SSO, un mapeo contra la base de datos de inventario de Software como Servicio (SaaS) y un panel de control con perfiles de uso por herramienta y por grupo de empleados son suficientes. Proveedores como Productiv, BetterCloud y Zluri ofrecen integraciones listas para los proveedores de identidad (IDP) más habituales. Quien cuenta con un equipo de TI reducido obtiene resultados más rápido con una herramienta estándar que con un desarrollo propio.

Módulo 3: Canal automatizado de recuperación de licencias

El tercer módulo aborda el ciclo de vida. Las licencias asignadas a una empleada que ha dejado la empresa deben desactivarse automáticamente o reasignarse a otra persona. Las licencias que no se hayan utilizado durante 60 días deberían marcarse automáticamente y, tras 90 días, revocarse. Esta canal solo funciona si Recursos Humanos (HR), Tecnologías de la Información (IT) y Operaciones Financieras (FinOps) trabajan con un modelo de datos común.

La arquitectura típica combina los datos maestros de Recursos Humanos (alta, baja, cambio de puesto) con la actividad de Single Sign‑On (SSO), el inventario de licencias y motores de flujo de trabajo como ServiceNow, Atlassian Jira Service Management u otras herramientas similares. Quien lo implemente automatiza la recuperación de licencias y reduce notablemente la gestión manual. En los primeros seis meses se pueden recuperar, sin esfuerzo adicional, entre 5 y 15 por ciento de las licencias existentes.

Es fundamental la cadena de escalada. Una licencia no se revoca sin previo aviso, sino con un período de carencia de 14 días y una notificación a la persona usuaria y a su superior. Quien ignore este proceso genera frustración y pierde la aceptación del programa. La disciplina en la escalada determina el éxito, más que la madurez de la herramienta.

Un programa de 90 días para FinOps (Finanzas Operativas) y Procurement (Compras)

Tres meses son suficientes para obtener una primera posición fiable. Los siguientes hitos se han demostrado como un ritmo realista en varios equipos de nube de tamaño medio.

Lo que los equipos de nube aprenden tras los primeros 90 días

Las experiencias de los primeros programas son sorprendentemente similares en muchas organizaciones. Tres lecciones destacan especialmente. En primer lugar: la lista de proveedores de SaaS (Software como Servicio, muy extendido en el entorno DACH) encontrados siempre resulta más larga de lo esperado. Duplicar la cantidad estimada inicialmente no es raro. Los directivos deben prepararse para esta sorpresa y no caer en el reflejo defensivo inicial.

En segundo lugar: los ahorros provienen menos de la eliminación de herramientas que de la consolidación de volúmenes. Quien tiene tres herramientas de marketing con funciones similares rara vez logra negociar una reducción de herramientas, porque los departamentos defienden sus herramientas favoritas. En cambio, quien alinea los plazos de los contratos en un punto de renovación común y negocia un precio mejorado con cada proveedor, captura sistemáticamente el potencial de ahorro.

En tercer lugar: el impacto cultural es al menos tan valioso como el financiero. Los empleados que forman parte de un programa transparente compran de forma más consciente en los meses siguientes. Registran las herramientas a tiempo, evalúan las opciones gratuitas (Free Tier) con mayor rigor y aceptan los procesos formales de adquisición. Quien logra establecer esto evita el 80 por ciento de los futuros efectos de proliferación descontrolada.

Para la alta dirección resulta útil una observación adicional. Las auditorías de proliferación de SaaS (SaaS‑Sprawl) suelen revelar cuestiones estructurales más allá del tema de licencias. Si tres equipos de marketing adquieren de forma independiente el mismo software, hay un problema de comunicación. Si el área de ingeniería compra constantemente herramientas SaaS para tareas que la plataforma interna no cubre, hay un problema de plataforma. El debate sobre la madurez FinOps recibe, gracias a las auditorías de proliferación SaaS, una recopilación concreta de casos. Ambos aspectos están estrechamente vinculados.

Cómo el programa pasa a la operación regular

Después de los primeros 90 días, la fase de transición determina el éxito a largo plazo. Tres componentes aseguran la operación regular. Primero: un foro permanente de FinOps-Procurement con dirección mensual y un presupuesto fijo. Segundo: una línea de reporte trimestral a la dirección con tres KPI claros. Tercero: un anclaje en las directrices de adquisición de la empresa, que vincula cada nueva compra de SaaS a un flujo de trabajo de aprobación corto pero vinculante.

Un conjunto típico de KPI para la visión de la dirección incluye el número de aplicaciones SaaS activas, la utilización media de licencias y los costos de SaaS como porcentaje del presupuesto de TI. Estos tres números son suficientes para una rápida evaluación trimestral. Quien pueda construir una línea de tendencia sobre cuatro trimestres tendrá un instrumento de control fiable. En la mediana empresa de 2026, precisamente esta línea de tendencia es el objetivo real del programa, no un informe de auditoría único.

Una observación complementaria vale para la comunicación con el consejo de administración: los equipos de cloud que realizan auditorías de SaaS sprawl de manera rutinaria ganan argumentos para la próxima negociación del presupuesto de TI. Un seguimiento documentado de ahorros es más efectivo en una conversación con el CFO que cualquier afirmación abstracta de eficiencia. Quien construya el reporting de manera consciente, se construirá una palanca suave para la próxima inversión en plataforma, herramientas o talento.

Preguntas frecuentes

Fuente de la imagen: Pexels / Lukas Blazek (px:577195)