Why BC3 and FIEBDC Still Matter for Modern Construction Cost Data

Construction cost data did not start with APIs. In Spain and many Spanish-speaking markets, BC3 and FIEBDC files have carried price books, decompositions, labor references, machinery costs, and unit-price structures for decades. BC3 is the file format defined by the FIEBDC-3 standard, the Spanish construction budget exchange standard, and it is the lingua franca that lets a price book authored in one tool open cleanly in another. Public price databases from regional building institutes, generator software output, and bid packages from public tenders all travel as BC3. If you estimate in Spain or LatAm, you have almost certainly received one.

Under the hood, a BC3 file is a flat text file built from typed records, each prefixed with a tilde and a letter. The header record (~V) declares the version and character set. Concept records (~C) define every entry in the price book, from a raw material up to a full chapter. Decomposition records (~D) describe how one concept is built from others, carrying the yield of each child. Measurement records (~M) hold quantities and takeoff lines, and text records (~T) carry the long descriptions. Coefficient records (~K) set global rounding and percentage rules. The point is not the letters themselves but what they encode: a price is never a bare number. It is a small tree.

That history is useful, but it is difficult to use in modern workflows. Files are often downloaded, imported into desktop tools, copied into spreadsheets, and detached from current supplier prices. Teams get a static reference instead of a living benchmark. The decomposition that made the file valuable, the labor-plus-materials-plus-machinery breakdown, usually flattens into a single cell the moment it lands in Excel. A year later nobody can say which assumption moved when the bottom line drifts.

Omnicost treats BC3 and FIEBDC as source material for a larger cost intelligence graph. Imports extract items, units, categories, decompositions, and prices. The system then normalizes names, maps related items, and makes the data searchable through the catalog, API, and MCP interfaces. Crucially, the decomposition survives the import. We keep the parent-child structure from the ~D records intact, so a unit price stays a tree you can open, audit, and re-cost rather than a frozen figure.

This matters because traditional cost books contain domain structure that web crawls alone do not. A supplier page may show a bag of cement. A BC3 file may show how that cement participates in a concrete unit price with labor, machinery, yield, and waste assumptions.

Take a worked example, with illustrative figures only. Imagine a concept for one cubic meter of reinforced concrete. Its decomposition lists cement, sand, gravel, water, a steel ratio, a concrete mixer, and the bricklayer and laborer hours, each line carrying a yield: so many bags of cement per cubic meter, so many crew hours, a small machinery share. A web crawl can refresh the cement price the day a supplier changes it. But only the decomposition tells you that cement is, say, a fraction of the cubic-meter cost, while labor dominates. So when the agent reports the concrete unit moving, it can attribute the move to the right driver instead of guessing. That attribution is what a flattened spreadsheet throws away.

The Omnicost approach combines both worlds. Historic and professional catalog structures help define what an item is. Live market observations help estimate what it costs today. The agent can then use both when generating budgets or explaining price movements. The same pipeline accepts Presto, the professional estimating format, so teams standardized on either format land in one searchable graph rather than two silos.

BC3 support is not a legacy feature. It is a bridge from existing industry knowledge into a system that can be searched, monitored, priced, and automated. Decades of curated decompositions become a starting structure; the live catalog keeps the numbers honest.