EICR Limitations Explained
No condition report covers absolutely everything — the limitations section is where you set out honestly what was and wasn’t inspected, and getting it right is what protects you if something you couldn’t reach later goes wrong.
On this page
An Electrical Installation Condition Report reflects the condition of an installation at the time of inspection, within a defined scope. That scope is rarely the whole installation to the last screw — some things are agreed off-limits in advance, some can’t be reached on the day, and some are checked by sampling rather than in full. The limitations section is where all of that is recorded.
This guide explains the difference between agreed and operational limitations, the extent-and-limitations part of the report, how sampling fits in, and why recording limitations properly is one of the most important protections you have as the inspector.
Key takeaways
- Agreed limitations are settled with the client before the inspection; operational limitations are found on the day.
- The extent-and-limitations section defines what the report does and does not cover.
- Operational limitations include things like a circuit that can’t be isolated or a locked room.
- Sampling — inspecting a proportion rather than every accessory — must be declared with the extent used.
- Recording limitations honestly protects both the client’s understanding and your own position.
Agreed versus operational limitations
Agreed limitations are those settled with the person ordering the work before the inspection begins. A client might agree that a particular area is excluded, that trunking need not be opened, or that the inspection is confined to certain circuits. Because they are agreed in advance, they shape the scope the report is written against and should be recorded as such.
Operational limitations are the ones you meet on the day — constraints that stop you inspecting or testing something even though it was within the intended scope. A circuit that can’t be isolated because it feeds something that mustn’t be switched off, a room that is locked and no key is available, or an accessory you can’t safely access all fall into this group. The distinction matters: agreed limitations were a choice; operational limitations were an obstacle.
Agree the scope before you start
Settling agreed limitations with the client up front avoids arguments later and gives you a clear scope to work to. Anything you then hit unexpectedly on the day is recorded separately as an operational limitation.
The extent-and-limitations section
Every condition report has a section that sets out the extent of the installation covered and the limitations that apply. This is not boilerplate to skim past — it is the definition of what your "satisfactory" or "unsatisfactory" verdict actually applies to. A report that says the installation is satisfactory means satisfactory within that stated extent, and no further.
Filling it in properly means being specific: which parts of the installation were covered, which were excluded and why, and what limitations — agreed or operational — applied. Vague or blank limitations undermine the whole report, because the reader can no longer tell what the conclusion is based on.
Sampling
On larger installations it is often impractical to inspect and test every single accessory and connection. In those cases a proportion is examined — sampling — on the basis that it gives a reasonable picture of the installation’s overall condition. Sampling is a legitimate approach, but it is itself a limitation and has to be treated as one.
That means declaring that sampling was used and stating the extent of it, so the reader understands the report is based on a representative check rather than a complete one. If sampling turns up defects, that may be a reason to widen the sample — a fault found in the sampled portion can point to systemic problems beyond it.
Why recording limitations protects you
Limitations are, in the end, about honesty and about liability. Recording them accurately tells the client exactly what has and hasn’t been assessed, so they can arrange for excluded or inaccessible parts to be looked at later. It sets a fair expectation of what the report covers.
It also protects you. If a fault later emerges in a circuit you clearly recorded as unable to be tested, or in a room you recorded as locked and inaccessible, the report shows you flagged it rather than missed it. A limitation left off the report, by contrast, reads as something you should have inspected and didn’t — which is exactly the position you don’t want to be in.
Capture it as you go
TradePlanr lets you record the extent and limitations alongside your observations and issue the EICR PDF on site, so what you couldn’t reach on the day is documented on the report rather than left to memory.
Frequently asked questions
What’s the difference between agreed and operational limitations?
Agreed limitations are set with the client before the inspection — deliberate exclusions to the scope. Operational limitations are obstacles found on the day that stop you inspecting something within scope, such as a circuit that can’t be isolated or a locked room.
Is sampling allowed on an EICR?
Yes, on larger installations it is often necessary to inspect and test a representative proportion rather than everything. Sampling is a limitation, so it must be declared along with the extent used, and defects found may justify widening the sample.
Why do limitations matter?
They define exactly what your satisfactory or unsatisfactory verdict applies to. Recording them tells the client what was and wasn’t assessed and protects you, because a properly recorded limitation shows you flagged an inaccessible part rather than overlooked it.
From guidance to action
Related guides
EICR Code FI: Further Investigation
What FI means, why it makes a report unsatisfactory, and how it differs from a C1, C2 or C3.
EIC vs EICR: What’s the Difference?
When you issue an EIC versus an EICR versus a Minor Works Certificate, and why it matters.
Initial Verification: The BS 7671 Testing Sequence
The correct dead-then-live testing sequence for initial verification, step by step.