The quantity check: do the Qto values in an IFC file match the model?
Summary
Most IFC files carry quantity sets: volumes, areas, lengths and dimensions for every wall, slab, beam and column. People use those numbers directly, for cost estimates, tenders, maintenance budgets and asset registers, because they look authoritative. They are not. In the files we test, a large share of these quantities does not match the object they are attached to, and some are wrong by a factor of a thousand or a million.
The uncomfortable truth about Qto values
An IFC quantity is not measured by the person who receives the file. It is calculated once, by the exporter of the authoring tool, at the moment of export, and then written into the file as a plain number. Nothing in IFC ties that number to the geometry next to it. If the exporter calculates it differently, in the wrong unit, or not at all, the file is still perfectly valid.
That leads to a situation most owners do not realise they are in:
- Nobody checks them. Schema validation, the buildingSMART validation service and the usual property-set checks (including our own naming check) test whether a quantity is well-formed: right name, right data type, allowed on this kind of object. None of them asks whether the value is right.
- Every tool calculates them its own way. Is a wall's length measured on the centreline, the outside face or through the corner? Is a slab's area net of openings or not? Is a roof layer's volume its own, or that of the whole roof? The IFC definitions leave room, and exporters fill it differently, sometimes per version.
- Units go wrong silently. A file declares square metres as its area unit, and an exporter writes one quantity in square millimetres. The number then looks plausible to software and is a million times too large.
- Values are copied, not calculated. Some exporters write nominal sizes from a type or a parameter (a wing wall described as 5 × 4.5 m while its real shape is a trapezoid), or put a value that belongs to the whole assembly on each of its parts.
- They look trustworthy. A quantity is a number with four decimals in a standard property set. It is exactly the kind of data people copy into a spreadsheet without a second look.
None of this is visible in a viewer. The object on screen is fine; only the number attached to it is wrong.
What we found in real files
We ran the check on a test set of building and infrastructure models from five different authoring tools. Volumes are mostly reliable: net volume matched the geometry on 99–100% of objects in most files. The trouble is in areas, dimensions and gross values, and it is concentrated in specific quantities from specific exporters. A few examples, without project names:
| Export | What the quantities said | What the geometry says |
|---|---|---|
| Revit 2018, IFC2x3, structural | Gross side area of every wall in mm² in a file that declares m²: a 4.24 × 9.44 m wall reports 40,025,600 m². Slab net area 2.2 times its gross area. | 40.0 m² for that wall. All 259 walls affected; 141 objects declare a net value larger than the gross. |
| Revit 2019, IFC2x3, architectural | Gross volume of all slabs written in litres as m³. A stair landing of 3.8 m² reports 50.7 m². | A factor 1,000 on every gross volume; landing volumes 3–5 times too large. |
| Revit 2024, IFC4, student model | Cross-section of a 50 × 150 mm curtain wall mullion: 0.49 m². A roof layer: 24.9 m³. | 0.0075 m² and 0.57 m³. 289 of 300 members have a cross-section around 37 times too large. |
| ArchiCAD 18, IFC2x3, housing | Wall tiles and facade insulation (vertical coverings) report their horizontal projection as area: 0.03 m² of tiles. | 6.5 m² of tiles. All volumes in the same file are correct. |
| Script-generated bridge, IFC 4.3 | Railing post length 0.14 m (the profile width). One abutment wall with length and width swapped, so its side area is 4.9 m². | Posts of 1.0 m; a wall side of 45.5 m². |
| Plug-in exporter, IFC 4.3, bridge | Lengths and heights in millimetres in a metre file; a wing wall of 0.024 m³. | Only 3% of the quantities match. That wing wall is 8.1 m³. |
Several files in the set were clean, with 96–100% agreement, among them the steel fabrication and prefab facade exports. So it can be done right; it simply is not guaranteed. These results describe particular exports with particular settings and versions, not a verdict on a software product. The same tool can produce correct quantities with different settings.
How the check works
forensicBIM already turns every object into a 3D mesh to measure the size of the asset. The quantity check reuses those meshes, so it adds little time to the analysis. For each object it reads the declared quantities, converts them to SI units using the units the file declares (or the unit attached to the quantity itself), measures the same thing from the geometry and compares.
| Declared quantity | Measured from the geometry as |
|---|---|
NetVolume, GrossVolume, Volume | The volume enclosed by the object's surface. Only when the surface is closed; otherwise the value is marked as not checkable. |
NetSurfaceArea, GrossSurfaceArea | The total surface of the object. |
OuterSurfaceArea | The total surface minus the two end faces of a beam, column or member. |
NetArea, GrossArea, NetSideArea, GrossSideArea | One face of a plate-like object (slab, roof, wall, plate, covering, pavement). Only for objects that are actually thin. |
GrossFootprintArea, NetFootprintArea, floor areas of spaces | The area the object covers in plan. |
CrossSectionArea | Volume divided by length, for beams, columns, members, piles and segments. |
Length of beams, columns and members | The extrusion length of the profile when the object is modelled that way, otherwise the length of the object. |
Width, Height, Depth, Thickness and other lengths | Must match one of the object's main dimensions or its height. We don't guess which dimension a tool calls "width". |
NetWeight, GrossWeight | Not compared with geometry: the weight divided by the declared volume must give a plausible density (50–25,000 kg/m³). |
The check reads the standard sets (Qto_…BaseQuantities in IFC4 and 4.3, BaseQuantities in IFC2x3) in full. For vendor sets such as ArchiCADQuantities it only checks volumes and dimensions: a name like "Surface Area" means different things for different objects in those sets, and we would rather not check than guess. Doors and windows are left out, because their quantities describe the opening, not the object.
Agree, deviate, wrong
Every compared value gets one of these outcomes:
| Outcome | Meaning |
|---|---|
| Agrees | Within 3% for volumes, lengths and dimensions, 5% for areas (8% for outer surface, where the end faces are estimated). That leaves room for rounding and for curved surfaces drawn as facets. |
| Deviates | Outside tolerance but within 25%. Usually a different way of measuring, such as wall length through the corner, rather than a broken value. |
| Wrong | More than 25% off the geometry. |
| Unit error | Off by a clean unit factor (1,000 for mm, a million for mm², a billion for mm³, a thousand for litres) and close once corrected. Imperial factors (feet, square feet) only count when they match exactly. |
| Not checkable | The geometry cannot give a reliable value: the surface is not closed, the object is curved, or a "beam" is really a plate so it has no defined length axis. These values are counted, but never called wrong. |
Being fair to the file
A check that cries wolf is worse than no check, so a few rules keep it honest:
- Gross values on objects with openings. The geometry we measure has the openings cut out. A gross quantity on a wall with windows is therefore allowed to be larger than the measured body; it is only wrong when it is smaller.
- Measuring conventions. When nearly all values of one quantity are off by the same percentage, for example every beam length 5.9% longer than the beam (measured to the grid rather than the cut length), we report it once as a convention, with low severity, and not as hundreds of errors.
- Unit errors count once. When most values of one quantity share a unit error, that becomes one finding for the quantity: it is one export setting, and one fix.
- Curved objects. A box around a curved kerb or tunnel lining says nothing about its width or thickness. The check detects curved objects and leaves their dimensions out.
Next to the comparison with geometry, three internal checks need no geometry at all: a net value larger than its gross counterpart on the same object, an implausible density, and quantities of zero or less.
Reading the result
- Agreement: the share of checked quantities that agree with the geometry. This is the number to quote. Above 95% the quantities can be used with normal care; below about 80% they should not be used without checking.
- Counts: how many objects carry quantities, how many were checked, and how many values agree, deviate, are wrong, have a unit error or could not be checked. On large models the check takes a sample per object type, so the figure is an estimate; the result then says sampled.
- Per quantity: one row for each quantity name in each set (for example
Qto_WallBaseQuantities.NetSideArea), with its agreement, the typical ratio between declared and measured values, and any unit error. This is where the pattern shows: usually one or two quantities are broken and the rest is fine. - Per object type: agreement for walls, slabs, beams and so on.
- Findings: ranked by severity, in plain language, ready to send to whoever made the file.
- Worst objects: the individual objects with the largest differences, with their GlobalId, so they can be found in any viewer.
How it counts in the score
The quantity check is part of the Consistency score. Its score is the agreement, minus the share of values that are wrong or have a unit error, so those count twice. A file with 96% agreement and 2% gross errors scores 94.
The check is scored once at least 10 values could be compared. A file that declares no quantities is not marked down here: that gap shows under Quantity coverage on the Information page.
One check among many moves the overall score by only a point or so, while a single quantity in the wrong unit can make a cost estimate wrong by a factor of a million. So unit errors do not depend on the score: when at least three values of a quantity, and at least a fifth of them, are in the wrong unit, the report lists it under Needs work on the overview and puts Quantities in the wrong unit first in the improvement plan, as a high-impact action that names the quantities to correct.
What to do with a finding
- Unit errors: almost always an export setting or an exporter bug in a particular version. Ask the supplier to check the IFC export's unit and quantity settings, or to export with a newer version. This is usually a quick fix with a big effect.
- A whole quantity wrong (for example every cross-section, every covering area): the exporter calculates that quantity differently from the IFC definition. Ask for it to be exported with the quantities recalculated from the geometry, or not exported at all. A missing quantity is better than a wrong one.
- Scattered wrong values: often objects that were edited after their quantities were set, or parts that carry the value of the whole assembly. Use the worst-objects list to point at them.
- Deviations and conventions: not errors, but decide which convention your cost or maintenance process expects, and say so in your information requirements.
If you set information requirements for deliveries, add a simple rule: quantities in the IFC file must match the geometry within 5%. This check is a way to verify it on every delivery.
Frequently asked questions
Should I trust Qto values at all?
Trust them after checking, not before. Net volumes are right in most of the files we see. Areas, side areas, cross-sections, footprints and gross values are where it goes wrong, and those are the ones estimators like to use. The check tells you, per file and per quantity, which ones you can use.
Why not just recalculate all quantities from the geometry and ignore the declared ones?
For many uses that is the better option, and forensicBIM does measure the size of the asset from the geometry. But the declared quantities are what other people's software reads, and some of them, like a wall length to the grid or a net floor area by local rules, carry a convention the geometry alone cannot tell you. The point of the check is to show whether the file says what the model shows.
The file passed validation. How can its quantities be wrong?
Validation checks that a quantity is allowed and well-formed. It does not compare its value with anything. A wall side area of 40 million m² is a perfectly valid IFC value.
Why are some of my quantities marked "not checkable"?
Because we could not measure them reliably: the object's surface is not closed so it has no volume, the object is curved, a plate is modelled as a beam, or a face area was declared on an object that is not thin. We would rather say we could not check than report a false error.
Does the check change my file?
No. forensicBIM only reads the file. The findings tell you which quantities to have corrected at the source.
Which files are checked?
Every IFC2x3, IFC4 and IFC 4.3 file whose objects carry quantity sets. Files without quantities get no result for this check, and their absence is reported in the data audit instead.