A certificate of insurance is the liability policy's “ID card”: a statement from the insurer that you have a live contract, with a defined content. Clients, main contractors, chambers and tenders ask for it – and anyone who has ever scrambled for a certificate right before a deadline knows: it is worth turning into a routine. This article walks through the process and its pitfalls.
- The certificate is issued by the insurer, based on the contract's data – it can also be arranged through a broker.
- Typical content: policyholder, policy number, type of cover, limits, period of cover – expanded according to the requester's needs.
- The most common mistake: the certificate is general, the requirement is specific – the two need to be matched up.
Who, when, how?
Issuing the certificate is an administrative service from the insurer: once the request arrives, it is put together from the contract's data, typically with a short turnaround – but not instantly, so for a deadline situation (a tender, signing a contract) plan in days, not hours. As a broker's client, the request is simple: you flag the need and the recipient's requirements, and the rest is my job – the formal process and the preparatory data are summarised in the certificate request checklist.
What should it contain?
The basic data set: the policyholder's name and address, the policy number, the type of cover (public liability, professional indemnity, product liability, etc.), the limits (per event and annual), the period of cover. It can be expanded on request: showing the deductible, territorial scope, whether a subcontractor extension exists, the name of a specific project, naming the client. For a foreign recipient, the language and international terminology can also be a requirement (foreign client expectations).
The three typical reasons for rejection
First: the certificate does not contain an element specifically requested in the tender – most often the limit or the precise name of the type of cover. Solution: pass on the requester's requirement wording to the issuer word for word. Second: validity – the certificate reflects the position on the date it was issued; for a long project, an update may be requested, and a new one at renewal. Third: a gap in substance – the certificate itself is fine, but the contract behind it does not meet the requirement; at that point it is not a certificate issue but a cover issue (client requirements, minimum limits).
Make it a routine
Anyone who is regularly asked for a certificate – as a subcontractor, a tender bidder, a chamber member – should build “certificate readiness”: have the contract's content track known requirements, and make refreshing certificates part of the annual-review routine (routine article). The first step toward this is reviewing your current policy: free consultation here.
Example: anatomy of a rejected certificate
A business owner requests a certificate, receives it, forwards it – the client rejects it: “does not comply”. The owner is baffled: they do have insurance! The autopsy takes three minutes: the tender asked for a per-event limit, the certificate shows an annual limit; the tender named professional cover specifically, the certificate proves general liability insurance; and the client had asked for the project to be named, which was left out. None of these is a lack of insurance – all three are communication failures: the requester's requirement never reached the issuer word for word. So the lesson is not complicated: the most important attachment to a certificate request is the recipient's requirement wording, forwarded unchanged. That is all it takes for a certificate to be accepted first time.
A question tailored to your own trade? Book a free 20-minute consultation →
