Si trabajas con mediciones en España, has mandado y recibido BC3 cientos de veces. El arquitecto lo exporta de su programa, el aparejador lo abre en el suyo, la constructora lo carga en el de ella para ofertar. Casi siempre funciona. Y cuando no, lo que falla no avisa: un capítulo con las tildes convertidas en jeroglíficos, una partida que costaba 48,00 € y ahora cuesta 47,63 €, o un presupuesto que cuadra en el total y no tiene ni una línea de medición.
Nada de eso es mala suerte. El formato tiene unas cuantas costuras conocidas, y saber dónde están ahorra la tarde de comparar dos pantallas partida a partida.
Qué hay dentro de un BC3
BC3 es la extensión; el formato se llama FIEBDC-3, Formato de Intercambio Estándar de Bases de Datos de la Construcción. Lo mantiene la asociación del mismo nombre desde mediados de los noventa, y por eso lo entienden Presto, Arquímedes, TCQ y casi cualquier programa de mediciones que se venda en España, además de los bancos de precios oficiales que publican varias comunidades autónomas.
Por dentro es un fichero de texto. Cada registro empieza por una tilde y una letra, y sus campos van separados por la barra vertical | y, dentro de un campo, por la barra invertida \. Los que importan para entender los fallos son pocos:
- ~V, la cabecera: quién escribió el fichero, con qué programa y, sobre todo, con qué juego de caracteres.
- ~K, los coeficientes: decimales con que se redondea cada cosa y los porcentajes de costes indirectos, gastos generales, beneficio industrial, baja e IVA.
- ~C, cada concepto (la obra, un capítulo, una partida, un ladrillo, una hora de oficial) con su código, unidad, resumen y precio. Un código acabado en
##es la raíz de la obra; uno acabado en#, un capítulo. - ~D, la descomposición: qué hijos tiene cada concepto y en qué cantidad. Es lo que convierte una lista de precios en un árbol de capítulos, partidas y recursos.
- ~M, las líneas de medición de cada partida: comentario, unidades, largo, ancho y alto.
- ~T, el texto largo de cada concepto, el que va al pliego.
Con eso basta para ver que un BC3 no es «el presupuesto» sino sus piezas, y que el programa que lo lee tiene que volver a montarlo. Los problemas aparecen justo en ese montaje.
Las tildes rotas: una cuestión de codificación
«Excavaci�n en zanja», «Hormig├│n HA-25». El texto está entero en el fichero; lo que pasa es que se ha leído con una tabla de caracteres distinta de la que se usó al escribirlo. El estándar prevé varias, entre ellas ANSI (la de Windows) y las páginas de código antiguas de MS-DOS, y cada fichero declara la suya en la cabecera. El problema viene cuando un programa escribe en una y declara otra, o cuando el que lee no hace caso de lo declarado.
La tentación es corregir a mano las descripciones. No merece la pena: son cientos, y en la siguiente exportación vuelven a salir mal. Lo que hay que hacer es volver a importar indicando la codificación correcta, o pedir al que envía que exporte en ANSI, que es la que mejor viaja.
Una barra en la descripción parte el registro
FIEBDC-3 no tiene forma de «escapar» sus separadores. Si alguien escribe en el resumen de una partida «Puerta 1 hoja | 82 cm», esa barra vertical es, para el programa que lee, el final de un campo. Lo que viene detrás se desplaza: la unidad acaba en el precio, el precio en la fecha, y la partida entra rota o no entra. Lo mismo con la barra invertida en campos que tienen subcampos, y con la virgulilla (~) escrita suelta, que algunos lectores toman por el comienzo de un registro nuevo.
El programa que exporta debería sustituir esos caracteres antes de escribir. No todos lo hacen, y por eso conviene evitarlos en las descripciones de los bancos propios.
El precio que cambia: descompuesto contra precio cerrado
Es el fallo que más discusiones provoca, porque toca dinero. Una partida tiene un precio descompuesto(tanto de oficial, tanto de peón, tanto de material) que suma 47,63 €, y en el presupuesto alguien la dejó a 48,00 € porque era el precio pactado o porque quedaba más limpio. En el programa de origen se ve 48,00 €. Al exportar viajan las dos cosas: el precio escrito en el ~C y la descomposición en el ~D.
Lo mismo le pasa a un precio contradictorio pactado como cifra cerrada: si no se justifica con su descomposición, el programa de destino puede cambiarlo.
Y muchos programas, al leer, hacen caso a la descomposición: recalculan el precio de la partida desde sus recursos e ignoran el que venía escrito. La partida vuelve a 47,63 €, y si el redondeo se repite en doscientas partidas, el total ya no es el que firmaste.
Un precio que no se justifica con su descompuesto no debería viajar con él. O se ajusta la descomposición para que sume lo que tiene que sumar, o la partida se exporta como precio cerrado, sin descompuesto, que es lo que el resto de programas respeta.
Hay una variante con los porcentajes. Los medios auxiliares y los costes indirectos van como conceptos de tipo porcentaje dentro de la descomposición, y no todos los programas escriben igual ese porcentaje: unos lo ponen como fracción en el rendimiento, otros como número entero. Si el que lee interpreta un 3 % como 3 en lugar de 0,03, el coste indirecto de esa partida sale multiplicado por cien. Se ve enseguida en el total, pero conviene saber de dónde viene.
Los coeficientes del ~K
El registro ~K lleva los decimales y los porcentajes globales del presupuesto. Si el programa de destino no lo lee, o lo lee y no aplica alguno de sus valores, el presupuesto de ejecución material puede cuadrar y el de contrata no. Los dos puntos a mirar son el porcentaje de costes indirectos, que unos programas aplican al precio de cada partida y otros muestran aparte, y la baja, que no todos trasladan.
Los decimales también importan más de lo que parece. Un banco de precios puede traer materiales con tres o cuatro decimales; si el programa los recorta a dos al importar, cada descompuesto se mueve unos céntimos y el total, unos euros.
Las mediciones: lo más frágil del fichero
Las líneas de medición van en registros ~M propios, separados de la partida, y se enganchan a ella por el código del capítulo, el de la partida y su posición dentro del árbol. Si el programa que lee monta el árbol en otro orden, o si una misma partida aparece en dos capítulos, alguna medición puede ir a parar a donde no toca.
El caso más traicionero es el fichero incompleto. Los registros de medición suelen ir al final, así que un BC3 cortado a mitad de descarga, o pegado de un correo que lo truncó, puede traer todos los capítulos y partidas con su precio correcto y ninguna medición. Si el programa no avisa, lo único que lo delata es que todas las cantidades salen a cero o que el total no se parece en nada al esperado.
El árbol no siempre es un árbol
FIEBDC-3 permite que un mismo capítulo cuelgue de dos padres, porque la descomposición es una relación entre códigos y no una carpeta. Algunos bancos lo usan para no repetir un grupo de partidas. Cada programa resuelve eso a su manera, y si duplica el capítulo, las cantidades de las dos copias pasan a ser independientes: cambiar una ya no cambia la otra.
Cómo comprobar un BC3 en cinco minutos
- El PEM total, al céntimo. Pide al que te lo envía el presupuesto de ejecución material de su programa y compáralo con el que te sale. Si cuadra, la estructura y los precios han llegado.
- Capítulo a capítulo. Si el total no cuadra, el capítulo que se desvía te dice dónde mirar: suele ser uno con precios manuales o con porcentajes.
- Partidas con medición. Cuenta cuántas traen líneas de medición. Si en el origen eran doscientas y a ti te llegan cero, el fichero está cortado.
- Tres descripciones con tildes. Abre tres partidas al azar y lee el resumen. Si salen bien, la codificación es correcta.
- El PEC. Con gastos generales, beneficio industrial e IVA aplicados, el total de contrata tiene que coincidir también. Si el PEM cuadra y el PEC no, el problema está en los coeficientes.
Una diferencia de pocos céntimos en el total suele ser redondeo del precio unitario, y es normal entre programas que redondean en sitios distintos. Una de cientos de euros no lo es.
Cómo lo hace Rucob, y hasta dónde llega
El módulo de mediciones de Rucob lee y escribe BC3, y lo hemos contrastado con ficheros reales de Presto 8.7 y de Arquímedes 2022. Al importar, detecta la codificación que declara la cabecera y la usa; respeta la estructura de capítulos y subcapítulos en todos sus niveles; conserva las líneas de medición; y al terminar enseña un resumen con el PEM calculado frente al precio de la raíz del fichero, para que veas de un vistazo si cuadra. Si el último registro no está cerrado, avisa de que el fichero parece truncado. Si un capítulo cuelga de varios padres, lo dice y explica que se ha duplicado.
Al exportar, sustituye los caracteres que partirían un registro, escribe en ANSI y solo manda la descomposición de una partida cuando su precio cuadra con ella; si no cuadra, la partida sale como precio cerrado, para que el otro programa no te la recalcule.
Y lo que no hace: si el ~K del fichero declara una baja, Rucob la señala en el resumen pero no la aplica al PEM. Importar BC3 está incluido en el plan Gratis, de modo que puedes abrir tu propio presupuesto sin pagar nada; exportar a BC3, Excel o Word es de los planes de pago, aunque los dos primeros meses de cualquier cuenta nueva tienen el plan Max entero abierto. Los límites exactos están en precios.
Si lo que te interesa es qué pasa después del presupuesto, sigue con cómo se calcula una certificación de obra.
Fuentes
Especificación en la que se apoya este artículo, consultada el 4 de octubre de 2026. El estándar se revisa cada pocos años: conviene leer siempre la versión vigente.
- Asociación FIEBDC: Formato de Intercambio Estándar de Bases de Datos de la Construcción: especificación del formato FIEBDC-3: estructura de registros, separadores, juegos de caracteres y codificación de capítulos, descomposiciones y mediciones.
Los fallos descritos (precios recalculados, porcentajes, ficheros truncados, capítulos compartidos) no salen de la especificación sino de la práctica: son los casos que hemos encontrado al contrastar nuestra importación con ficheros reales.