OPEX vs CAPEX en desarrollo de software: la decisión que decide tu EBITDA

Imagen generada por IA para el blog de Orbitant sobre OpEx vs. CapEx en desarrollo de software, que muestra una balanza metálica inclinada hacia el plato con una pila de monedas frente al plato con una maqueta de edificio sobre fondo blanco.

Cuando alguien me dice que se ha gastado un millón de euros en tecnología, la primera pregunta que le hago es: ¿gastado o invertido?

FELIPE POLO
CEO Orbitant

En Orbitant, las finanzas de un cliente le importan a todo el equipo, no solo a quien lleva el título de CTO o al departamento financiero: ayudan a que cualquier persona de tecnología tome mejores decisiones sobre lo que construye, porque cada línea de código termina reflejada en algún sitio de las cuentas de la empresa.

Por eso ofrecí una sesión interna para explicar conceptos como OPEX vs CAPEX en desarrollo de software: la misma hora de trabajo de un equipo de tecnología puede registrarse de dos maneras completamente distintas. Esa decisión cambia el beneficio del año, el EBITDA y hasta la valoración de la compañía.

Esto va más allá de la contabilidad. Cuando un cliente decide activar un desarrollo o contabilizarlo como gasto operativo, está tomando una decisión que afecta a cómo se percibe la salud financiera de su negocio desde fuera, ya sea un inversor, un banco o un comprador potencial. Y quien participa en decidir qué se construye, cómo se prioriza y a qué ritmo, participa también, sin siempre saberlo, en esa decisión financiera.

Balance y cuenta de resultados: dos documentos que hay que cruzar para entender un proyecto

Toda empresa cierra cada mes tres documentos financieros: el balance, la cuenta de pérdidas y ganancias (P&L) y el cash flow. Dejamos aquí el cash flow fuera porque, para entender OPEX y CAPEX, pesan mucho más los otros dos: el balance dice qué tiene la empresa en un momento dado, la cuenta de resultados dice si ese patrimonio está rindiendo y la depreciación es el punto donde ambos documentos se cruzan. Sin estos tres conceptos claros, activar o gastar un desarrollo es una decisión a ciegas: se toma sin saber qué se está moviendo realmente.

El balance: qué tiene la empresa y a quién se lo debe

El balance muestra, en un momento concreto, qué recursos tiene la empresa (los activos) y a quién se los debe (el pasivo y el patrimonio neto). La distinción entre pasivo y patrimonio neto importa porque indica el origen de la financiación: el pasivo es el dinero que la empresa debe a terceros (bancos, proveedores, fondos de deuda), mientras que el patrimonio neto es lo que debe a sus propios socios, es decir, capital que no hay que devolver como una deuda externa porque pertenece a quienes fundaron o invirtieron en la empresa.

Estos dos lados siempre se equilibran con la misma ecuación: activo = pasivo + patrimonio neto. Un préstamo bancario de 10.000 euros, por ejemplo, incrementa la caja de la empresa (un activo) y genera, al mismo tiempo, una deuda equivalente con el banco (un pasivo). Una ampliación de capital de 1.000.000 de euros funciona de forma parecida: ese millón entra en caja como activo, pero en este caso aparece en el patrimonio neto, como aportación de los socios, no como deuda.

Dentro de los activos conviene distinguir dos tipos, según lo rápido que se puedan convertir en dinero:

  • Activos corrientes: caja, inversiones líquidas, facturas pendientes de cobro. Se convierten en dinero con rapidez.
  • Activos no corrientes: inmuebles, maquinaria, software propio. La empresa no puede liquidarlos de un día para otro.

La cuenta de pérdidas y ganancias: si esos recursos rinden

Mientras que el balance es una fotografía de un momento dado, la cuenta de pérdidas y ganancias recoge todo lo ocurrido durante un ejercicio completo: mide si los recursos que la empresa ha conseguido financiar se están usando de forma productiva. Se calcula restando, de arriba a abajo: ventas, coste directo (cost of goods sold), gastos de estructura (overheads), depreciación y amortización, e impuestos.

Gráfico explicativo para el blog de Orbitant con la ecuación del P&L en dos pasos: Ventas menos coste directo y gastos de estructura igual a EBITDA, y EBITDA menos depreciación, amortización e impuestos igual a Beneficio neto.

El coste directo es el gasto ligado a producir lo que se vende (materia prima, depreciación de la maquinaria, el sueldo de quien la opera); los overheads son la estructura que rodea esa producción: ventas, marketing, administración, oficinas. El IVA no entra en ninguna de estas partidas: nunca es un ingreso ni un gasto para la empresa, sino un pasivo o un activo según se cobre o se pague. La empresa actúa como intermediaria: repercute el IVA, pero no gana ni pierde con él. Lo paga el consumidor final. Ese dinero termina en manos de la Administración, no de la empresa.

Dónde se cruzan ambos documentos: la depreciación

El concepto que conecta el balance con la cuenta de resultados es la depreciación. La norma internacional que regula cuándo un activo se puede reconocer como tal describe este mecanismo: repartir en el tiempo el desgaste de un activo, en lugar de registrar todo su coste de golpe el día en que se compra.

Un ejemplo lo aclara. Cuando en Orbitant compramos un ordenador por 2.000 euros, ese gasto no se refleja de golpe en la cuenta de resultados: cambiamos 2.000 euros de caja por un ordenador que vale lo mismo. A partir de ahí, ese ordenador va perdiendo valor contable cada año. Si se deprecia a cinco años, pierde 400 euros de valor cada ejercicio: esos 400 euros son el gasto de depreciación de ese año. El activo baja de valor en el balance. Ese mismo importe aparece como gasto en la cuenta de resultados. Es la misma lógica que conecta OPEX, CAPEX y el EBITDA, como vemos a continuación.

OPEX vs CAPEX en desarrollo de software: la decisión que toma cada CTO

La decisión es esta: cuando un equipo de desarrollo dedica sus horas a un proyecto, ese trabajo se puede contabilizar como gasto operativo o como inversión en un activo, y quien toma esa decisión (normalmente el CTO) determina cómo se ve la cuenta de resultados de la empresa ese año. Antes de ver cómo se aplica en la práctica, conviene fijar los dos términos, porque el resto del razonamiento depende de tenerlos claros:

  • OPEX (operational expenditure, gasto operativo): el coste de mantener el negocio funcionando día a día. Se resta directamente de la cuenta de resultados en el año en que se produce.
  • CAPEX (capital expenditure, inversión en capital): el coste de construir un activo que la empresa sigue teniendo en el futuro. Se registra en el balance y se deprecia durante varios años, como el ordenador del ejemplo anterior.

Todo lo que gasta un equipo de desarrollo se puede contabilizar de cualquiera de las dos formas, en función de su naturaleza. Esa elección pesa como una decisión estratégica que va mucho más allá de la contabilidad pura. Si un CTO decide que el trabajo de su equipo mantiene el negocio funcionando, ese gasto se declara como OPEX y reduce el EBITDA del año. Si decide que ese trabajo construye un activo (un software, una plataforma, una marca), puede activarlo como CAPEX y depreciarlo durante varios años. La depreciación se resta después del EBITDA, no antes: activar un desarrollo no reduce el beneficio operativo de este año, lo reparte en los siguientes.

Esto también aplica, por ejemplo, a la construcción de marca. En nuestro caso, cuando comenzamos nuestra actividad, contratamos una agencia para el branding y la web. Todo lo que le hemos pagado lo hemos activado como activo de marca, porque construye algo que la empresa sigue teniendo dentro de cinco años. El mantenimiento mensual del WordPress, en cambio, es OPEX, aunque nos lo cobre la misma agencia. La diferencia no está en quién cobra, sino en qué se paga: un activo nuevo o el mantenimiento de uno que ya existe.

Lo mismo pasa dentro de un equipo de tecnología:

  • La parte que construye producto nuevo se puede activar como CAPEX.
  • La parte que mantiene infraestructura o da soporte está operando el negocio: ese coste va a OPEX.

Un CTO puede tomar esta decisión proyecto a proyecto, siempre que pueda justificarla si Hacienda pregunta.

Por qué el EBITDA ignora la depreciación (y qué tiene que ver con tu equipo de tecnología)

El EBITDA es la métrica que el mercado usa como estándar para comparar empresas entre sí, tal y como recoge el glosario financiero de Banco Santander. Excluye intereses, impuestos, depreciación y amortización por una razón concreta: esas tres partidas dependen del país en el que opera cada empresa y de cuánto ha invertido en activos, no de si el negocio se gestiona bien. Una compañía que paga un 50% de impuesto de sociedades no es necesariamente peor que otra que paga un 25% en España: solo opera en un entorno fiscal distinto.

Aquí se conecta todo lo anterior. Si un equipo de tecnología cuesta 700.000 euros al año y ese gasto se declara como OPEX, el EBITDA baja 700.000 euros ese mismo año. Si el mismo trabajo se activa como CAPEX y se deprecia a tres años, el EBITDA no se mueve, porque la depreciación aparece más abajo en la cuenta, fuera del cálculo. El coste real es idéntico en ambos casos; lo que cambia es cuándo y dónde se refleja, como explica José A. Dorado en su post sobre cómo funciona la economía de una consultora de software.

Esto explica algo que probablemente ya has visto en empresas con financiación reciente: no les importa gastar rápido en tecnología porque están invirtiendo caja que ya tienen. Activar ese desarrollo no toca el EBITDA del año. Antes de activar un desarrollo, conviene hacerse tres preguntas:

  1. ¿Lo que construye el equipo sigue existiendo como activo dentro de tres o cinco años o es mantenimiento recurrente?
  2. Ante una inspección, ¿ese gasto genera un activo o solo mantiene el negocio funcionando?
  3. ¿El retorno esperado (más ventas, menos costes, un go-to-market más rápido) compensa activar en vez de gastar?

Construir en vez de alquilar: cuándo el CAPEX se convierte en estrategia

El mismo criterio se aplica cuando una empresa deja de alquilar tecnología y empieza a construir la suya. En uno de nuestros proyectos de datos, la plataforma que construimos para Afianza es un activo; el coste de la infraestructura de Azure que la sostiene es OPEX, porque esa infraestructura no es nuestra.

Con un cliente de e-commerce pasó algo parecido con la licencia de una plataforma de pago: mientras la pagaban, ese coste iba directo a OPEX y penalizaba el EBITDA cada mes. Cuando una plataforma de terceros se vuelve cara porque el negocio ha crecido, compensa construir la propia: se sustituye un gasto recurrente por una inversión que se deprecia, mucho más suave sobre el EBITDA.

Uno de nuestros software engineers, Iván Esteban, planteó algo que conecta con esto: cómo se contabiliza la tecnología también depende de la estrategia de salida de la empresa. Si quiere vender en cinco años, puede convenirle seguir pagando licencias ahora o justo lo contrario si acaba de levantar una ronda pensada para financiar su propia plataforma: la estrategia financiera de cada empresa decide qué regla aplica.

Esto mismo se ha discutido a una escala mayor. David Yusta, otro de nuestros software engineers, comentó que varias grandes tecnológicas habían alargado los periodos de amortización de sus servidores. Se preguntaba si eso no era una forma de suavizar beneficios en plena carrera de inversión en IA.

Sin ánimo de dar ningún consejo de inversión, el mecanismo es el mismo que hemos visto aquí, aplicado a otra escala: Google alargó la vida útil de sus servidores de tres a cuatro años en 2021, lo que redujo su gasto de depreciación en varios cientos de millones de dólares en un solo trimestre. Amazon, en cambio, la ha acortado recientemente citando el ritmo de renovación que exige la IA. Ambas son decisiones contables antes que técnicas y mueven el EBITDA reportado sin mover un euro del gasto real.

La próxima vez que alguien te presente un proyecto de tecnología, antes de mirar la arquitectura, pregunta cómo se va a contabilizar. La respuesta dice más sobre la estrategia financiera del proyecto que cualquier diagrama. Puedes ver la sesión completa aquí ⤵️

Sigue nuestro viaje construyendo agentes IA desde dentro