SGCG.es

Desmontando nu despropósito sobre la (no) deflactación del IRPF (2)

Sun, 09 Aug 2026 18:08:14 +0000

Ayer echamos un vistazo inicial a una paparrucha sobre la (no) deflactación del IRPF con la inflación: alguien afirmaba que, aunque le han subido el salario en compensación de la inflación desde 2020, está perdiendo 400 € al mes frente a lo que ganaría si los impuestos y las cotizaciones se hubieran deflactado con la inflación. Es difícil explicar en un solo artículo lo atroz de semejante pamplina, así que vamos a calcular con más precisión un ejemplo de cúanto podríamos acercarnos a esa pérdida de poder adquisitivo.

Hay que adelantar que, naturalmente, con impuestos progresivos, si aumenta el salario para compensar exactamente la inflación y los impuestos no se modifican, el tipo efectivo aumenta y el contribuyente pierde poder adquisitivo. Lo que es absurdo es asumir una pérdida de 400 € al mes como algo representativo del contribuyente español actual.

Hipótesis

Nuestro sujeto es trabajador por cuenta ajena.
Reside en Madrid (las mejores mentiras, las de Madrid).
Cotizaba en 2020 según la base máxima de entonces, que era de 4070,10 € al mes.
Cotiza hoy según la base máxima actual, que es de 5101,20 € al mes.
No tiene derecho a ningún descuento más allá del de otros gastos deducibles de 2000 € que se aplica a todos los contribuyentes.
La inflación en estos años ha sido del 25 % y, por lo tanto, el salario ha subido un 25 % para compensar la inflación.

Unos pocos números

Con un 4,70 % en concepto de contingencias comunes, un 1,55 % en concepto de desempleo y un 0,10 % en concepto de formación profesional, el sujeto cotizaba originalmente 258,45 € al mes, es decir, 3101,40 € al año.

Con un 4,70 % en concepto de contingencias comunes, un 1,55 % en concepto de desempleo, un 0,10 % en concepto de formación profesional y un 0,15 % en concepto de Mecanismo de Equidad Intergeneracional, el sujeto cotiza hoy 331,58 € al mes, es decir, 3978,96 € al año.

El salario de nuestro sujeto ha de ser alto, muy alto, para que salgan las cuentas. Tan alto que se encuentra en el tramo más alto del IRPF, de hecho: por encima de los 300000 € anuales. A partir de esta cantidad, el tipo marginal es del 24,50 % (estatal) más el 20,50 % (autonómico), es decir, del 45,00 %. Por los primeros 300000 € de base liquidable, el trabajador ha pagado 120351,23 €.

Digamos que el trabajador cobraba originalmente una cantidad 𝑥 (el resultado final será independiente de esta cantidad exacta). Entre IRPF y cotizaciones sociales, este trabajador pagó el siguiente tipo efectivo:

𝑇₁ = [120351,23 € + 3101,40 € + 0,45×(𝑥−3101,40 €−2000 €−300000 €)] ⁄ 𝑥.

Tras estos años, el trabajador cobra 1,25𝑥. Entre IRPF y cotizaciones sociales, este trabajador pagará este ejercicio el siguiente tipo efectivo:

𝑇₂ = [120351,23 € + 3978,96 € + 0,45×(1,25𝑥−3978,96 €−2000 €−300000 €)] ⁄ 1,25𝑥.

La diferencia entre lo que va a pagar y lo que pagaría con el tipo efectivo original será:

(𝑇₂−𝑇₁) × 1,25𝑥 = −0,25×120351,23 € + 1,25×(0,45−1)×3101,40 € + (1−0,45)×3978,95 € + 0,25×0,45×2000 € + 0,25×0,45×300000 € = 3943,41 €.

Mensualmente, eso sale a 328,62 €, todavía por debajo de los 400 €. En Madrid, por ejemplo, la diferencia de 400 € al mes sería imposible con una inflación del 25 %. En otros lugares de España, quizá sería posible, pero siempre con salarios elevadísimos.

Desmontando un despropósito sobre la (no) deflactación del IRPF

Sat, 08 Aug 2026 11:38:10 +0000

Lo de la (no) deflactación del IRPF con la inflación es un caballo de batalla machacadísimo del que alguna gente no se cansa. ¡Nadie pone en duda la perogrullada de que el efecto inmediato de una rebaja del IRPF es que se paga menos IRPF! La cuestión es cuánto, y eso dependerá de las circunstancias de cada contribuyente. Ahora bien, el debate está intoxicado por afirmaciones calamitosas. Voy a citar un comentario atroz publicado hace menos de veinticuatro horas:

Mi empresa, por una vez en la vida, me ha subido desde el COVID el salario con la inflacion (incluso por encima en algún caso). Pero por la no deflactación del IRPF (y el MEI y demás mierdas) pierdo 400 € al mes netos.

Esta persona concreta después que no es que cobre menos dinero en términos nominales, sino que dispondría de 400 € mensuales adicionales si se hubiera deflactado el IRPF (y el MEI y demás mierdas, y hay que recordar que el MEI ha sido desde su creación inferior al 1 % de la base de cotización, además de que la parte a cargo del trabajador es una pequeña fracción de esa cantidad).

Desmontando los números escandalosos sin perder demasiado tiempo en ello

¿Tiene sentido lo de pagar 400 € de más? La cantidad exacta de impuestos que paga un contribuyente depende de sus ingresos, de su lugar de residencia y de otras circunstancias personales, así que no tiene mucho sentido hacer un cálculo detallado y preciso.

Centrémonos en el IRPF, porque complicar las cosas con la Seguridad Social no cambia la conclusión, y, para simplificar, asumamos que el tipo autonómico es igual al estatal. Los tipos totales en función de la base liquidable que nos interesan son los siguientes:

19 % hasta los 12500 €.
24 % desde los 12500 € hasta los 20200 €.
30 % desde los 20200 € hasta los 35200 €.

Con estos tramos, habría que pasar de la nada hasta los 22000 € anuales para tener unas retenciones de unos 400 € mensuales. Estos 22000 € de subida son una cota inferior, porque el trabajador tendría que haber cobrado algo inicialmente. ¡No hay manera de deflactar el IRPF con la inflación de estos años para compensar esto!

También podría ser que el salario hubiera siempre de 22000 €. Si asumiéramos una inflación infinita, deflactar el IRPF y las cotizaciones con ella (es decir, bajarlos a 0) supondría el ahorro de esos 400 € mensuales para el trabajador. Tendríamos que irnos a una inflación como la de Zimbabue en 2008 (tan alta que podemos considerarla casi infinita) para que los números cuadraran.

O el autor del comentario miente, o no se entera de nada, o se explica catastróficamente mal.

El robo de Coldcard

Tue, 04 Aug 2026 20:17:57 +0000

Estos días está produciéndose la sustracción de una gran cantidad de bitcoin (más de mil en el momento de escribir estas líneas: más de medio centenar de millones de euros al cambio actual) desde direcciones asociadas a monederos de hardware de la marca Coldcard.

Lo interesante de este ataque es que el error de programación que lo ha hecho posible: los monederos afectados empleaban desde hace más de cuatro años un generador de números aleatorios de tan baja calidad que las claves generadas tenían apenas unos cuarenta bits de entropía en algunos de los modelos afectados. Con un espacio tan reducido, parece viable tanto técnicamente como económicamente generar todas las claves posibles y comprobar si corresponden a direcciones públicas; cada vez que hay una correspondencia, es posible operar con la dirección afectada y dejarla sin fondos. El movimiento se demuestra andando: más de mil bitcoin nos indican que, en efecto, el ataque era viable. Ante una situación así, el único remedio consiste en transferir los fondos a una dirección segura.

Más práctica con secuenciador: On Off 2

Fri, 31 Jul 2026 18:40:45 +0000

He aquí otra pieza que produje con un secuenciador con el que estoy practicando: On Off 2.

Aquí traté de producir algo muy, muy deprisa, partiendo del principio de habilitar y silenciar pistas, así como transponer los patrones melódicos de un compás según una rueda de acordes de ocho compases de duración.

Gnucash 5, Guile Scheme y los menús

Thu, 30 Jul 2026 20:39:28 +0000

Traté de añadir un menú de usuario al programa de contabilidad Gnucash usando Guile Scheme, que es el lenguaje principal para que los usuarios puedan extender Gnucash, modificando mi ~/.config/gnucash/config-user.scm. En el momento de escribir estas líneas, la documentación es muy escasa y los buscadores más populares devuelven resultados entre pobres, obsoletos o, cuando imponen el uso de modelos de lenguaje para inventarse la respuesta a mis consultas, atrozmente incorrectos. La conclusión a la que llego es que parece que, actualmente, no hay una forma «oficial» de añadir menús cualesquiera desde el fichero de configuración.

He aquí lo que averigüé averiguaciones aplicables al menos a las versiones de Gnucash que van de la 5.0 a la 5.16. Puedo tratar de añadir un menú con (gnc-add-scm-extension (gnc:make-menu name path)), donde name es el nombre del menú y path es una lista con la ruta al menú (por ejemplo, si tuviéramos el menú A con un submenú B y quisiéramos añadir nuestro nuevo menú dentro de B, path sería (list "A" "B")). Esto no hace lo esperado normalmente, no obstante: solamente añade submenúes dentro del menú de informes. Probablemente, no se trata de funciones pensadas para su consumo por parte del usuario final.

Añadir nuevos informes al menú de informes, por otro lado, es relativamente fácil. La entrada en el menú se añade de forma declarativa y la wiki de Gnucash contiene un artículo bastante útil que explica cómo hacerlo.

Ejemplos de uso de los bindings de Python de Gnucash (2): movimiento masivo de asientos

Thu, 30 Jul 2026 18:35:09 +0000

He aprendido a hacer cuatro cosas con los bindings de Python del programa de contabilidad Gnucash. Una cosa que puede hacerse es mover masivamente el debe o el haber de muchos asientos de una cuenta a otra, que es algo que puede ser útil si queremos enmendar alguna decisión desafortunada a la hora de hacer anotaciones en nuestra contabilidad doméstica. He aquí unas instrucciones válidas para Gnucash 5 y Python 3 y un programa de ejemplo.

Trabajando con Gnucash 5 en Python 3

Lo que necesitamos para trabajar con un libro de cuentas está en el módulo gnucash. Podemos importarlo así:

import gnucash

Lo primero que hay que hacer es abrir una sesión. Digamos que tenemos un libro de cuentas, contabilidad.gnucash; podemos abrirlo así:

session = gnucash.Session("contabilidad.gnucash") book = session.book root = book.get_root_account()

Así hemos abierto una sesión (session), accedido al libro de cuentas (book) y a la cuenta raíz (root). La sesión puede abrirse así, lo que nos obligará a guardar nuestros cambios (session.save()) y cerrarla (session.end()); de forma alternativa, podemos abrirla como un context manager.

Lo siguiente que hay que hacer es acceder a las cuenta que queremos tocar. Si, por ejemplo, estas cuenta son Gastos (la original) y Gastos.Comida (donde queremos mover los asientos), las seleccionamos así:

source_account = root.lookup_by_full_name("Gastos") target_account = root.lookup_by_full_name("Gastos.Comida")

Ahora podemos acceder a la cuenta original (source_account) y listar todos los desgloses o splits que le tocan con account.GetSplitList(). A partir de estos desgloses, podemos acceder a los asientos o transacciones que afectan a la cuenta y moverlos a otra cuenta diferente. Por ejemplo, si queremos mover todos asientos Pan de la cuenta Gastos a la cuenta Gastos.Comida, podemos hacer los siguiente:

for split in source_account.GetSplitList(): transaction = split.GetParent() if transaction.GetDescription() == "Pan": split.SetAccount( transaction.SetDescription("Pan")

Finalmente, guardamos y cerramos la sesión:

session.save() session.end()

Programa de ejemplo

He recogido lo expuesto arriba en un pequeño programa: batch_move_transactions.py

El programa puede usarse directamente como una herramienta de línea de órdenes normal (que muestra la ayuda con la opción --help) o como una función que puede llamarse desde código de Python. Es un poquito más complicado que lo descrito arriba, ya que usa expresiones regulares para elegir los asientos que mover.

A350 completa un vuelo de más de 24 horas

Tue, 28 Jul 2026 20:23:45 +0000

Un Airbus A350-1000ULR (una modificación del A350-1000 con más alcance) de Qantas ha completado un vuelo de más de 24 horas entre Melbourne y Toulouse. Tripulado por 4 pilotos y 6 ingenieros y con una carga de pago simulada, se trata de un vuelo de prueba dentro del Proyecto Sunrise que pretende conectar Sídney y Londres mediante vuelos directos, que es algo particularmente notable y ambicioso. Aunque la distancia geodésica entre Melbourne y Toulouse es de algo menos de 1700 km (algo más de dos quintos de la circunferencia terrestre), este vuelo siguió un camino algo más largo y, según he podido ver tras descargar la traza, recorrió unos 22000 km (algo menos de tres quintos de la circunferencia terrestre), que es, francamente, un buen alcance para la aviación comercial.

Traza del vuelo. Mapa de fondo de OpenTopoMap con licencia Creative Commons Atribución-CompartirIgual 3.0.

Ejemplos de uso de los bindings de Python de Gnucash (1): renombrado masivo de asientos

Mon, 27 Jul 2026 14:42:39 +0000

He aprendido a hacer cuatro cosas con los bindings de Python del programa de contabilidad Gnucash. Una cosa que puede hacerse es un renombrado masivo de asientos, que es algo que puede ser útil si queremos enmendar alguna decisión desafortunada a la hora de nombrar los conceptos en nuestra contabilidad doméstica. He aquí unas instrucciones válidas para Gnucash 5 y Python 3 y un programa de ejemplo.

Trabajando con Gnucash 5 en Python 3

Lo que necesitamos para trabajar con un libro de cuentas está en el módulo gnucash. Podemos importarlo así:

import gnucash

Lo primero que hay que hacer es abrir una sesión. Digamos que tenemos un libro de cuentas, contabilidad.gnucash; podemos abrirlo así:

session = gnucash.Session("contabilidad.gnucash") book = session.book root = book.get_root_account()

Lo siguiente que hay que hacer es acceder a la cuenta que queremos tocar. Si, por ejemplo, esta cuenta es Gastos.Comida, la seleccionamos así:

account = root.lookup_by_full_name("Gastos.Comida")

Ahora podemos acceder a la cuenta (account) y listar todos los desgloses o splits que le tocan con account.GetSplitList(). A partir de estos desgloses, podemos acceder a los asientos o transacciones que afectan a la cuenta y cambiar las descripciones. Por ejemplo, si queremos corregir una errata en la hemos escrito Pann en vez de Pan, podemos hacer lo siguiente:

for split in account.GetSplitList(): transaction = split.GetParent() if transaction.GetDescription() == "Pann": transaction.SetDescription("Pan")

Finalmente, guardamos y cerramos la sesión:

session.save() session.end()

Programa de ejemplo

He recogido lo expuesto arriba en un pequeño programa: batch_rename_transactions.py

Alcanzado por el fuego el Complejo de Comunicaciones de Espacio Profundo de Madrid en Robledo de Chavela

Sat, 25 Jul 2026 21:21:59 +0000

El fuego no discrimina y los incendios que se producen este verano, además de causar las esperadas pero indeseables pérdidas sobre los bienes de la población y sobre el medio natural, han afectado al Complejo de Comunicaciones de Espacio Profundo de Madrid en Robledo de Chavela. El estado de las instalaciones es incierto, pero existe el consuelo de que el personal fue evacuado a tiempo y que las antenas parecen encontrarse intactas.

El Complejo de Comunicaciones de Espacio Profundo de Madrid, operado por el Instituto Nacional de Tecnología Aeroespacial en apoyo de la NASA, es uno de los tres grandes complejos de antenas repartidos por la circunferencia terrestre que forman la Red del Espacio Profundo que da soporte a las misiones interplanetarias, así como a algunas misiones en órbita terrestre. La red ya opera en torno al límite de su capacidad y la pérdida de cobertura durante varias horas al día puede ser significativa.

Más práctica con secuenciador: Bavaria 2026

Mon, 20 Jul 2026 21:18:14 +0000

He aquí otra pieza que produje con un secuenciador con el que estoy practicando: Bavaria 2026.

Hice esta pieza mientra viajaba.

La productora cinematográfica A24 pide la retirada de contenido relacionado con The Backrooms

Sat, 18 Jul 2026 12:22:10 +0000

Recientemente, A24 Films produjo Backrooms, una película ambientada en el popular universo de ficción The Backrooms. A pesar de que esta ambientación, The Backrooms, es un fenómeno cultural anterior a la película, fruto del esfuerzo colectivo de numerosos artistas independientes, algo así como un nuevo folclore que no pertenece a una única persona u organización, sino que es procomún a todos los efectos, A24 ha enviado avisos de violación de derechos de autor solicitando la retirada de la circulación contenido relacionado con The Backrooms anterior a la propia película. Tras la intervención del director de Backrooms, A24 ha abortado las peticiones de retirada y usa el comodín del clanker para eludir su responsabilidad: al parecer, se trata de un error de un sistema automatizado.