What does BR18 require of static documentation?

Static documentation, in practice, has two parts that are often confused. The static calculation shows that the structures - foundations, beams, columns, slabs and load-bearing walls - can carry the loads they're subject to, both from the building's own weight and from external effects like wind, snow and use.

The control part shows something different: that both the calculation and the actual execution on site have been checked along the way, not merely assumed correct. It's the control part that DS1140 regulates in detail - the control plan, control report and as-built documentation.

Many building owners and contractors first encounter the requirement properly when the certified structural engineer asks for documentation they don't have on file. That typically happens late in the build process - often around final sign-off - where it's far more expensive and disruptive to fix than it would have been from the start.

The more complex the structure, and the greater the consequence of a failure for people or the building's function, the more extensive the control requirement becomes. A simple garden shed faces a different bar than a multi-storey building with many occupants.

Responsibility is split. The designing engineer is responsible for the static calculation itself and for setting the building's structural class. The contractor is responsible for carrying out and documenting self-inspection on site. And the certified structural engineer is responsible for approving that the overall picture - calculation and control together - holds up.

The building owner usually ends up with the practical responsibility for making sure it's all coordinated, even if they aren't the one doing the work. That's why many owners bring in an advisor to keep an overview through the whole process.

In practice, it means static documentation needs to be planned before control work on site begins - not assembled afterwards. A control plan written only once the building is already underway rarely covers the control points that have already passed.

If you're unsure what your specific building requires, it's usually faster to clarify it early - ideally before the first spade goes in the ground - than to discover the gaps at handover, where fixes cost both time and money.

The most common mistake is treating static documentation as paperwork that can be handled at the end. Another is assuming a lower structural class than the real one, because a project looks simple on the drawings but turns out more complex in execution. A third is letting several people on site share responsibility for the control documentation informally, with no one holding the overall picture.

It's not unusual for missing static documentation to surface only once a building is well underway - for example during a site inspection or an occupancy application. In that situation, the first priority is pinning down exactly what's missing: the calculation, the control part, or both.

Often the missing documentation can be caught up without stopping site work, provided the relevant structures are still accessible for inspection or can be assessed from other records, such as photos or material certificates.

Static documentation is closely linked to the occupancy permit, but the two aren't identical. Some approval processes allow phased occupancy once the calculation part is in place, while the full documentation - including the control part under DS1140 - still needs to be complete before final sign-off.

That means a building can, in some cases, be partially occupied while the control documentation is still being finalised, but the structural engineer's approval of the complete picture remains the deciding factor for full sign-off.

Static documentation doesn't only matter for the structural engineer's approval. If a structural issue emerges years after handover, an insurer or warranty provider will typically ask for the original control records before settling a claim. A building with a complete, well-organised file is in a materially stronger position than one where the documentation has to be pieced together retrospectively.

That's one of the strongest arguments for treating static documentation as a long-term asset rather than a box to tick for handover - it keeps paying off well after the project is technically finished.

Where static documentation used to live in binders and site diaries, it's increasingly kept in digital systems that timestamp entries and flag missing control points automatically. That shift doesn't change what BR18 requires, but it does reduce the chance that a gap goes unnoticed until the structural engineer's final review, when it's far more disruptive to fix.

The choice of system matters less than the discipline behind it - a digital tool used inconsistently produces the same gaps as a paper file used inconsistently.

On a new build, static documentation typically follows a clean, predictable sequence from control plan through to as-built. On a renovation or extension, part of the existing structure is often already hidden or only partly accessible, which can make it harder to establish a clear starting point for the documentation. In that situation, it's often necessary to supplement the plan with an assessment of what can be adequately documented from existing drawings and materials, versus what genuinely requires physical access.

Buildings completed before the current requirements took effect aren't automatically covered by the same documentation obligations retroactively - but as soon as changes are made that affect the load-bearing structure, the requirement typically applies to those specific parts. It makes sense to check this specifically for your building, rather than assuming an older structure is automatically exempt.

Beyond the structural engineer, static documentation is regularly requested by insurers assessing a claim, by a buyer's surveyor during a property sale, and occasionally by the building authority if a structural concern is raised later. Each of these audiences reads the file slightly differently, but all are looking for the same thing: a clear, dated record that the load-bearing structure was checked as it was built.

That range of possible readers is itself a good argument for writing the documentation clearly enough that someone outside the original project team can follow it without help.

BR18 doesn't prescribe a particular tool or format for keeping static documentation - the requirement is about content, not whether it's kept in Excel, Word or a dedicated app. That gives you freedom to choose whichever solution fits your process best, as long as the content meets the requirements.

In practice, most disputes over static documentation come down to gaps in content, not disagreements about which format was used to keep it.

Having drawings, a description of the structure's load-bearing elements, and a sense of the building's intended use ready in advance tends to make the initial scoping conversation with an advisor go considerably faster. Without this material, the first meetings usually spend more time gathering basic information than actually assessing the documentation need.

Static documentation tends to go more smoothly when it's built into the project's overall schedule as its own tracked item, with milestones alongside the physical construction milestones, rather than treated as background paperwork with no explicit deadline of its own. Giving it a visible place in the schedule makes it far less likely to be quietly deprioritised when the project gets busy.