- Los errores del cierre en Excel no son de fórmulas: son de proceso, versiones y datos copiados a mano.
- Los siete se repiten en casi todos los grupos de 2-10 sociedades que hemos visto, con independencia del ERP.
- La mayoría desaparecen cuando el reporting lee directamente del libro diario en vez de un extracto pegado.
El cierre mensual en Excel no falla por Excel. Las fórmulas suelen estar bien. Falla por el proceso que hay alrededor: datos pegados a mano desde el ERP, tres versiones del mismo archivo, un tipo de cambio para todo y una cifra que nadie sabe de dónde sale. Son siete errores, se repiten en casi todos los grupos de 2 a 10 sociedades que hemos visto, y la mayoría desaparecen el día que el reporting lee el libro diario en vez de un extracto pegado.
El cierre mensual es el proceso por el que un grupo da por definitivos los asientos del mes en cada sociedad y produce el P&L, el balance y el cash flow consolidados con los que se toman decisiones.
¿Por qué el cierre en Excel falla aunque las fórmulas estén bien?
Porque Excel no es la fuente del dato: es una copia. Cada mes alguien entra en el ERP de cada sociedad, saca sumas y saldos o el libro diario, lo pega en la pestaña de esa sociedad y arrastra las fórmulas. A partir de ahí, la hoja y el ERP viven vidas separadas. Si alguien corrige una factura de marzo en el ERP el día 8, el Excel de marzo no se entera. Si dos personas tocan el archivo, hay dos archivos. Y cuando el consejo pregunta de dónde sale un número, la respuesta es «de la pestaña de la filial», que es como no responder.
Ninguno de esos problemas se arregla con una fórmula mejor. Se arreglan cambiando quién es la fuente.
¿Cuáles son los 7 errores y cómo se detectan?
| # | Error | Síntoma | Cómo evitarlo |
|---|---|---|---|
| 1 | Pegar el balance de sumas y saldos a mano | El P&L de marzo cambia cuando alguien reabre el ERP y vuelve a pegar | Leer el libro diario completo desde el ERP (API o CSV), no un extracto |
| 2 | Varias versiones del mismo archivo | «Cierre_marzo_v3_FINAL_bueno.xlsx» y nadie sabe cuál se envió al consejo | Una sola fuente, con histórico y fecha de sincronización visible |
| 3 | Referencias rotas entre hojas o libros | #REF! o un total que no suma las 13 pestañas | Consolidado calculado por un motor, no por SUMA de pestañas |
| 4 | Un solo tipo de cambio para todo | El balance no cuadra tras convertir la filial en pesos | Tipo medio para P&L, de cierre para balance, por sociedad |
| 5 | Intercompany eliminado «a ojo» | Los ingresos del grupo suben cuando sube la facturación interna | Identificar por cuenta o contraparte y eliminar con detalle |
| 6 | Asiento de cierre incluido en el P&L | El resultado de diciembre sale a cero o duplicado | Excluir asientos de cierre y regularización del reporting de gestión |
| 7 | Sin trazabilidad hasta el asiento | Alguien pregunta «¿de dónde sale este 47.300?» y no hay respuesta | Cada cifra abre hasta el asiento original de la sociedad |
Cada uno con un caso real, anonimizado:
1. Sumas y saldos pegado. Un grupo de distribución con cuatro sociedades enviaba el P&L de marzo el día 10. El día 14 la asesoría de una de las filiales reclasificó 30.000 € de una compra. El P&L de marzo que tenía el consejo ya no era el P&L de marzo, y nadie lo supo hasta que en abril el acumulado no cuadraba con el mes anterior.
2. Versiones. El controller de un grupo de servicios tenía en la carpeta de marzo cierre_v2.xlsx, cierre_v2_revisado.xlsx y cierre_FINAL.xlsx. La que se envió al inversor fue v2_revisado; la buena era FINAL. La diferencia eran 12.000 € de una provisión.
3. Referencias rotas. Trece pestañas, una por sociedad, y una pestaña de consolidado que las suma. Alguien añade la sociedad 14 en una pestaña nueva y la SUMA del consolidado sigue cogiendo 13. El grupo consolidó sin la nueva sociedad durante dos meses.
4. Un tipo para todo. Filial en México convertida entera al tipo del último día del mes, incluido el P&L. El mes que el peso se movió un 6 %, el margen de la filial «bajó» tres puntos sin que hubiera cambiado ninguna operación.
5. Intercompany a ojo. La matriz empezó a repercutir servicios centrales a las filiales. Los ingresos consolidados subieron un 8 % ese trimestre. Ventas reales a clientes: las mismas.
6. Asiento de cierre en el P&L. El P&L de diciembre de un grupo salió con resultado cero. No porque no hubieran ganado dinero, sino porque el asiento de regularización —que lleva ingresos y gastos a la 129— se leyó como un asiento más y anuló el mes. Aquí está explicado con números.
7. Sin trazabilidad. «Otros gastos: 47.300 €». ¿De qué sociedad? ¿De qué cuentas? ¿De qué facturas? Para responder había que abrir el ERP de cada sociedad, filtrar por mes y por cuenta, y sumar. Media hora por pregunta, y en un consejo hay diez preguntas.
¿Cuál de los siete cuesta más caro?
El séptimo. Los otros seis producen cifras equivocadas, que es malo. El séptimo produce cifras que nadie puede defender, que es peor, porque destruye la confianza en todo el informe, incluidas las cifras que estaban bien.
La conversación que lo delata pasa en todos los comités: alguien señala un número y pregunta «¿este es el bueno?». A partir de ese momento, la reunión ya no va de qué hacer con el resultado. Va de si el resultado es de fiar. Y no se vuelve a la primera pregunta hasta que alguien puede abrir el 47.300 y enseñar las once facturas que lo componen. Cuando eso se puede hacer en un clic, la conversación cambia de «¿es el bueno?» a «¿qué hacemos?», que es la única que vale el tiempo de un consejo.
¿Qué cambia cuando el reporting lee directamente del libro diario?
Que los errores 1, 2, 3 y 7 desaparecen por construcción. No es que se hagan mejor: es que dejan de ser posibles. Si el reporting se sincroniza con el ERP, no hay nada que pegar (1), hay una sola fuente con fecha de sincronización (2), el consolidado lo calcula un motor y no una SUMA de pestañas (3), y cada cifra es una agregación de asientos que se puede abrir (7).
Los otros tres —tipo de cambio (4), intercompany (5) y asientos de cierre (6)— no desaparecen, pero pasan de ser trabajo mensual a ser configuración: se define una vez qué tipo aplica a cada estado, qué cuentas o contrapartes son de grupo, y qué diarios se excluyen del reporting de gestión. A partir de ahí, se aplican solos cada mes.
Así funciona el reporting financiero de Fibady: lee el libro diario de cada sociedad —Odoo, Holded, Tango, SOS Contador y EternumPRO por API; cualquier otro ERP por CSV— y lo demás es configuración que se hace una vez. Un grupo logístico de 13 sociedades pasó de unas 25 horas de cierre a unas 6; la comparativa con Excel desglosa qué parte del tiempo es la que se va.
¿Cuándo Excel sigue siendo la opción correcta?
Cuando tienes una sociedad, un contable y ninguna de estas tres cosas: presupuesto por áreas, varias monedas, o más de una persona tocando el archivo. En ese caso, un buen Excel que lea sumas y saldos del ERP funciona, es barato y lo entiende todo el mundo. Cambiarlo por un software sería resolver un problema que no tienes.
El problema empieza cuando aparece la segunda sociedad. No porque Excel no pueda sumar dos pestañas, sino porque a partir de ahí cada uno de los siete errores tiene un sitio donde ocurrir, y ocurren.