Por qué los márgenes por obra nunca cuadran con tu cuenta de resultados (y cómo arreglarlo)

La escena se repite todos los meses en muchas constructoras. El jefe de obra entra a la reunión con un Excel propio y dice: «este mes la obra del Cl. Mayor está perdiendo dinero, hemos consumido más cemento del previsto». El controller llega con la cuenta de resultados del ERP y dice: «no, esa obra va con un margen del 12%, está perfectamente». La discusión se alarga, alguien sugiere que «hay que cuadrar los Excels», y al final del día nadie decide nada.

Lo curioso es que los dos tienen razón. No están mintiendo, ni hay errores de registro, ni nadie está calculando mal. Están midiendo la misma obra con datos distintos porque están mirando fechas distintas. Y, hasta que ese desajuste se resuelve, el comité de obra es una conversación de sordos que nadie gana.

Las 3 razones por las que el coste contabilizado nunca es el coste real de obra

Antes de hablar de soluciones, vale la pena entender de dónde viene el desajuste. En cualquier obra de cierta complejidad hay tres fuentes estructurales por las que el coste contable y el coste real divergen mes a mes:

1. Certificaciones a final de mes. La subcontrata factura su trabajo el día 30 al cierre del mes operativo. Esa factura llega registrada al ERP el día 5 o 6 del mes siguiente. Para la contabilidad, ese gasto es del mes nuevo. Para la obra, fue consumo del mes anterior.

2. Subcontratas con desfase. El albañil termina la fase del forjado el 15 de mayo. La factura llega el 20 de junio (porque la subcontrata factura quincenalmente o porque hay un retraso administrativo). Mayo aparece artificialmente barato en el ERP; junio, artificialmente caro.

3. Regularizaciones de cierre. Cada cierre trimestral, alguien repasa la obra y mete provisiones por trabajo ejecutado pendiente de certificar. Esas provisiones se imputan en el cierre, pero corresponden a meses anteriores —a veces a meses de un trimestre o un año previos—.

Multiplica las tres causas por todas las subcontratas activas en una obra (en una obra de tamaño medio puede haber 15-30) y por todos los meses de duración (típicamente 8-18 meses) y obtienes la distancia estructural entre el coste contable y el coste real.

El caso típico: una obra de 8 meses con margen del +5% al +14% según cuándo la mires

Supongamos una constructora pequeña/mediana ejecutando una obra concreta: rehabilitación integral de un edificio en una ciudad mediana, 1,2 millones de euros de presupuesto, 8 meses de duración (febrero a septiembre), márgenes objetivo del 12%.

Los costes de obra se reparten así (acumulados mes a mes), comparando lo que ve el controller (por fecha de factura) vs lo que ve el jefe de obra (por fecha del consumo real, también llamada «fecha analítica»):

Mes cerrado	Coste contable acumulado	Coste real acumulado	Margen contable	Margen real
Febrero	145.000 €	168.000 €	+18 %	+5 %
Marzo	295.000 €	305.000 €	+12 %	+9 %
Abril	410.000 €	445.000 €	+14 %	+7 %
Mayo	560.000 €	580.000 €	+13 %	+10 %
Junio	720.000 €	745.000 €	+12 %	+9 %
Julio	855.000 €	870.000 €	+13 %	+12 %
Agosto	980.000 €	980.000 €	+12 %	+12 %
Septiembre (cierre)	1.060.000 €	1.060.000 €	+12 %	+12 %

Hay tres lecturas en esta tabla y conviene parar a entenderlas:

Primera lectura — al cierre, ambas vistas convergen. En septiembre, mes de cierre de la obra, los dos márgenes son del 12%. Lógico: cuando llegan todas las facturas y se imputan todas las provisiones pendientes, el coste contable iguala al coste real. La cuenta de resultados anual de la empresa va a salir bien.

Segunda lectura — durante la obra, el margen contable es siempre más optimista. En febrero la obra parece haber ganado un 18% según el ERP, pero la realidad operativa era del 5%. En abril, el ERP marca +14% cuando el dato real era +7%. Esta discrepancia es sistemática y predecible: las facturas llegan tarde, así que el ERP «infla» los primeros meses de la obra.

Tercera lectura — las decisiones se toman durante la obra, no al cierre. Si en abril el comité técnico ve un margen contable del +14% y decide comprometer 100.000 € adicionales de presupuesto en otra obra paralela basándose en ese dato, está tomando una decisión sobre un margen real del +7%. La probabilidad de que esa segunda obra arranque con problemas de tesorería se multiplica.

Por qué los Excels del jefe de obra suelen tener razón

El jefe de obra trackea costes el día que ocurren físicamente en obra: cemento entregado, hora de albañil trabajada, máquina alquilada. Su Excel paralelo (siempre lo hay) refleja la realidad operativa con bastante precisión. Si dice que la obra del Cl. Mayor está perdiendo dinero en mayo, probablemente sea cierto, aunque el ERP marque que va con +13%.

El controller, en cambio, solo ve facturas. Su realidad es la del registro contable —que llega con desfase—. Si dice que la obra va bien, también es cierto, dentro del marco de lo que él puede ver.

El conflicto entre los dos es estructural, no personal. Y se manifiesta en reuniones donde dos profesionales miran la misma obra con datos distintos sin saber por qué, hasta que alguien explicita el desfase fecha factura ↔ fecha del consumo real. Cuando eso pasa, suele ser un alivio: ambos descubren que tenían razón a la vez.

La solución: dos fechas por movimiento + estructura de proyecto en el ERP

Resolver este problema requiere combinar dos cosas:

1. Una estructura de proyecto dentro del ERP que registre cada coste con asignación a la obra, fase y partida correspondiente. Esto lo hace dvproject, que añade a Business Central toda la maquinaria de gestión de obra: presupuestos, partidas, certificaciones, partes de trabajo, contradictorios, márgenes por proyecto.

2. Dos fechas por movimiento: la contable (la que va al SII y a Hacienda, idéntica a hoy) y la analítica (la del consumo real en obra: fecha del albarán de cemento, fecha de la jornada del albañil, fecha de la certificación). Esto lo hace dvdata-analysis, que añade el campo de fecha analítica en facturas, partes y certificaciones —tomando la fecha del documento previo cuando existe—, sin tocar la fecha contable original.

Como ya analizamos en el artículo sobre el desfase del SII, este patrón aplica a cualquier sector con desfase entre el hecho económico y la factura. La construcción es uno de los casos donde el problema se ve con más claridad.

Resultado de combinar ambos: una sola fuente de verdad dentro del ERP. El controller filtra movimientos por fecha de factura para reportes fiscales y conciliación bancaria. El jefe de obra y el director técnico filtran por fecha analítica para ver márgenes reales mes a mes. Los dos miran la misma base de datos, simplemente con un filtro distinto.

Cómo se ve esto en la realidad de una constructora

Una vez instaladas dvproject y dvdata-analysis, cada función de la empresa usa la fecha que necesita:

• Cuenta de resultados mensual de la empresa (todas las obras): por fecha analítica. Refleja la actividad operativa real.
• Cuenta de explotación oficial (modelos AEAT, declaraciones SII): por fecha contable. Cumple con la ley.
• Margen por obra dentro del comité técnico: por fecha analítica. Refleja la rentabilidad real de cada obra mes a mes.
• Conciliación bancaria y tesorería: por fecha contable. Cuadra con extractos bancarios.
• Comparativas año vs año: por fecha analítica. Sin ruido por desfases puntuales.
• Bonus del jefe de obra y comisiones de comerciales: por fecha analítica. Premia actividad real, no facturación oportunista.

El día después del cambio

El cambio tangible se nota en la primera reunión de obra con el sistema funcionando. Es una observación que escuchamos en proyectos reales:

• Las reuniones dejan de discutir números. Pasan a discutir estrategia.
• El jefe de obra y el controller llegan a la reunión con la misma cifra —solo cambia el filtro temporal—, no con dos versiones de la verdad.
• El bonus del jefe de obra se calcula sobre datos reales. Deja de premiar el oportunismo de las facturas.
• El comité financiero decide la cartera de obras nuevas con visibilidad de los márgenes reales acumulados, no de los contables inflados.
• Los Excels paralelos que llevaban controller y jefe de obra desaparecen. La información que antes vivía en hojas de cálculo aparte vive ahora dentro del ERP, junto al movimiento.

No es un cambio que requiera convencer al equipo: en cuanto el controller ve que la cuenta de resultados oficial sigue siendo la misma (porque la fecha contable no se toca), y el jefe de obra ve que su Excel deja de ser necesario, ambos lo adoptan rápido.

¿Por dónde se empieza?

Depende de qué tengas hoy:

• Ya tienes dvproject (o estás a punto de tenerlo): añadir dvdata-analysis es trabajo de 1 día. La extensión hereda la fecha del parte de trabajo o de la certificación automáticamente, así que la configuración es mínima. Empezarías a ver márgenes por fecha analítica desde el cierre del mes siguiente.
• Tienes Business Central pero no dvproject: lo lógico es valorar el combo. dvproject estructura la obra dentro de BC; dvdata-analysis añade la fecha analítica encima. Por separado funcionan, pero juntos resuelven el caso completo.
• No tienes Business Central todavía: el primer paso es la migración. Davisa puede orientar sobre qué versión y licenciamiento encaja, antes de hablar de extensiones.

Las preguntas que hace siempre el director financiero de una constructora

¿Esto sirve igual para empresas que hacen rehabilitación que para construcción nueva?

Sí. La rehabilitación es incluso un caso más extremo porque tiene más subcontratas con desfase: oficios especializados (albañilería, instalación eléctrica, fontanería, carpintería, pintura) trabajando en paralelo, cada uno con sus plazos de facturación. La distorsión por fecha de factura suele ser mayor en rehabilitación que en obra nueva. La solución es la misma: fecha analítica + estructura de proyecto.

¿Cómo se trata una contradictoria que se firma 2 meses después?

Una contradictoria es un acuerdo de modificación de la obra que ajusta el presupuesto a posteriori. En dvproject se registra como una modificación del presupuesto vigente, con su fecha de firma. En dvdata-analysis, los costes derivados de la contradictoria reciben como fecha analítica la fecha del consumo real, no la de la firma. La contradictoria afecta al importe del presupuesto (no a la fecha del consumo).

¿Puedo aplicar esto solo a obras grandes o tiene que ser a todas?

Se puede aplicar a todas o solo a las grandes. La extensión se activa por compañía en BC, así que afecta a todos los movimientos contables del tenant. Pero el uso operativo (filtrar reportes por fecha analítica) lo decide cada equipo. Una empresa puede tener obras pequeñas que se gestionan por fecha factura sin más, y obras grandes donde se usa la fecha analítica intensivamente. El campo está siempre disponible; cómo se explota depende del equipo.

¿Mi controller actual va a aceptar trabajar con dos fechas?

Sí, una vez ve que la contabilidad oficial no cambia. La fecha contable —la que va a Hacienda, al SII, a los modelos trimestrales— sigue siendo exactamente la misma de siempre. La fecha analítica es un campo adicional que se rellena solo desde el documento previo. El controller no tiene que mantener nada; solo gana visibilidad de cuándo ocurrió cada cosa cuando alguien le pregunta.

¿Y si la subcontrata factura mucho después del cierre del trimestre?

Es el caso para el que esta solución resuelve mejor. La factura se registra en el trimestre que toca fiscalmente (la fecha contable la determina el SII, no se toca). Pero la fecha analítica se rellena con la fecha del parte de trabajo o de la certificación previa, que sí está dentro del trimestre del consumo real. Los márgenes por obra se calculan con la fecha analítica, así que las facturas tardías ya no distorsionan el cierre del trimestre operativo.

En resumen

• En cualquier constructora con cierta complejidad, el coste contable y el coste real de obra divergen estructuralmente mes a mes por tres razones: certificaciones a fin de mes, subcontratas con desfase y regularizaciones de cierre.
• El margen contable durante la obra es siempre más optimista que el real (+18% vs +5% en el primer mes del ejemplo). Al cierre convergen, pero las decisiones se toman durante la obra.
• El conflicto típico jefe de obra ↔ controller no es personal: ambos miran datos correctos pero distintos. La solución es estructural, no metodológica.
• La combinación que funciona: dvproject (estructura de obra en el ERP) + dvdata-analysis (fecha analítica adicional). Una sola fuente de verdad, distintos filtros temporales según función.
• Implantación rápida si ya hay dvproject: 1 día. Si hay BC sin dvproject, valorar el combo.

¿Quieres ver el margen real de tu obra desde el primer mes?

Si tu equipo de obra y tu controller llegan a las reuniones con cifras distintas sobre las mismas obras, podemos enseñarte en una sesión de 30 minutos cómo encajaría esto en tu instalación de Business Central. Sin compromiso, con un caso concreto tuyo.

Agendar consultoría gratuita →