Why do DS1140 cases get rejected - and what do you do about it?

A rejected B2 plan is typically because the control scope doesn't match the structural class, or the control points are described too loosely. A B3 report with gaps is usually because responsibility for documenting control was spread across several people on site, with no one holding the overall picture. Missing A5 arises when B2 and B3 haven't been kept up to date along the way, so there's nothing solid to gather at handover.

A fourth, less common cause is an incorrectly assumed structural class from the start - which typically means large parts of the B2 plan need to be redone.

The first step is to review exactly what the structural engineer has flagged or requested, and work out which of the three documents it actually concerns. Then fix it directly - rather than trying to rebuild the whole case from scratch, which is rarely necessary.

In many cases, it turns out only one or two specific points are missing or described incorrectly, while the rest of the documentation is fine. Identifying exactly those points is what decides whether a case can be fixed quickly or drags on.

The longer a rejected case sits, the more expensive it typically becomes to fix - partly because construction continues in the meantime, making it harder to re-inspect work already done, and partly because details of what was actually done and when become harder to reconstruct over time.

If a case ends up in an outright dispute between owner and contractor, it's often precisely the documentation's quality and traceability that decides how quickly the dispute can be resolved - a case with clear, ongoing documentation is typically resolved far faster than one where the parties disagree about what actually happened.

When a case has been sitting for a while, when responsibility for documentation is unclear between several parties, or when the structural class requires independent control that was never set up, it's usually faster to bring in an outside party to take over and pull the case together than to keep trying to solve it internally.

That's especially true if you don't have your own experience with how a structural engineer typically reads and assesses that type of documentation - an experienced advisor can often see quickly where the real problem lies, rather than reviewing the whole case from scratch.

We start by reviewing the structural engineer's specific comments and comparing them against the existing B2, B3 and any A5 material. From there, we assess whether the missing points can be documented directly, whether something requires a re-inspection, or whether parts of the plan need to be redone. Most cases we take over turn out to be fixable faster than feared, precisely because the problem is rarely the entire documentation.

One case was rejected because the B3 report lacked documentation for three control points. On review, it turned out the control had actually been carried out, but never written down correctly. The three points could be documented by gathering supplementary information from the contractor and cross-checking it with photos taken on site - and the case was approved within a few days.

Had the same three points instead required a physical re-inspection of structures already covered up, the fix would have taken markedly longer and been more expensive.

If a structure is already covered - for example by subsequent pouring or cladding - a missing control point can, in the worst case, require destructive investigation or a conservative safety assessment from the designing engineer. That's one of the strongest reasons to document as you go, rather than relying on being able to reconstruct it later.

When a case has been rejected, it's a good idea to gather all the structural engineer's comments in one place before you start fixing them - rather than fixing them piecemeal as each comment is read. That gives you an overall view of whether several comments actually point to the same underlying issue, such as a general lack of clarity in the control scope.

It also makes it easier to prioritise which fixes to make first, if some points are more time-critical than others for the building's progress.

If a case is rejected, it's often better to give the building owner an honest, concrete status - what's missing, and how long the correction is expected to take - rather than downplaying the issue. An owner given a clear plan for the correction typically reacts far less negatively than one who only discovers the delay after the fact, without having heard about it along the way.

Turnaround varies, but most structural engineers prioritise a resubmitted, corrected case faster than a brand-new one, precisely because they already know the project. If you're unsure of the expected turnaround, it's entirely reasonable to ask directly, so you can plan the rest of the schedule around it.

If you have several projects with rejected cases running at the same time, it makes sense to prioritis them by how close they are to handover and how significant the consequence of delay is - not necessarily by which case looks simplest to fix. A case close to handover with a pressed building owner should typically be handled first, even if another case is, in isolation, faster to resolve.

If a structural engineer's rejection seems unreasonably strict, it's better to ask for a more detailed justification than to challenge the assessment directly. In the great majority of cases, a detailed justification reveals either a genuine gap that was overlooked, or a misunderstanding that can be quickly cleared up - both of which are easier to handle than a prolonged disagreement about the assessment itself.

Whatever the outcome, it pays to keep a short, dated record of exactly what the structural engineer flagged and how it was addressed. That record is useful not only for the current case, but as a reference the next time a similar issue comes up on a different project - it's often faster to check what worked before than to work out the same answer from scratch.

Before resubmitting a corrected case, double-check that the fix actually addresses everything the structural engineer flagged, rather than only the most obvious point. A partial correction that misses a smaller, secondary issue often results in a second round of rejection, which costs more time overall than getting the correction right the first time.

If the same type of issue keeps triggering rejection across multiple submissions, it helps to ask the structural engineer directly what a fully acceptable version of that particular control point would look like, rather than guessing again at each resubmission. A concrete example from the engineer usually resolves the pattern faster than several more rounds of trial and error.

Once a rejected case is finally resolved, you'll want to keep a short note of what triggered the rejection and how it was fixed, filed alongside the project's other documentation rather than discarded once the engineer signs off. That short note is often the fastest way to recognise and avoid the same issue on a future project, well before it reaches the point of another rejection.