Technical Submittal Package for Electrical Safety Equipment: How to Prepare Technical Approval Documentation for EPC and Utility Projects

In electrical safety equipment projects, the role of a Technical Submittal is not simply to ‘send datasheets, test reports and certificates to the client’.

For EPC, utility, railway, substation, data center, and large-scale industrial projects, the more important task of a technical submittal is to establish a clear chain of technical evidence:

Project Requirement → Offered Product → Technical Data → Drawing / Configuration → Test Evidence → Deviation → Approval

Upon opening the document package, the reviewer should be able to quickly answer several questions:

  • What product is the supplier actually providing?
  • Which requirement in the specification does the product correspond to?
  • What are the actual model, rating, dimensions, and configuration?
  • Which document proves that it meets the requirements?
  • Are there any deviations?
  • Which revision is currently being submitted?
  • Is this documentation ready to proceed to the next stage?

Therefore, the essence of a high-quality Technical Submission Package is not that ‘the more documents, the better’, but rather:

Every project requirement must correspond to clear product parameters and technical evidence.

Follow local regulations and your site safety procedures.

Quick Answer: What should a Technical Submittal really demonstrate?

A complete Technical Submittal typically needs to demonstrate four things.

Clear product identification

The reviewer should be able to confirm:

  • Product
  • Model
  • Class
  • Rating
  • Size
  • Configuration
  • Applicable Standard

Clear response to project requirements

Do not simply submit a generic catalog.

It should specify:

What the client requires, and what we are actually providing.

Technical evidence must correspond

Documents such as Test Reports, Certificates, drawings, and Datasheets should clearly support the corresponding specification requirements.

All deviations are proactively declared

If the offered product does not fully comply with the specification, this should be clearly stated in a Deviation Schedule, rather than concealing the discrepancies within the Datasheet.

A more reasonable approval process is:

Specification → Compliance Matrix → Product Data → Evidence → Deviation → Revision Control → Approval

What is the difference between a Technical Submittal and a Tender, FAT or Site Acceptance?

These stages are often confused with one another.

In fact, their purposes are entirely different.

StageMain Purpose
Tender / RFQDefining Procurement and Technical Requirements
Technical SubmittalObtain formal technical approval
Approved Drawing / ConfigurationFreeze Production Configuration
ProductionManufacture According to Approved Specifications
FATVerify that the finished product conforms to the approved configuration
Shipping DocumentsConfirm the Actual Shipment Contents
Site AcceptanceConduct identity, documentation, and on-site inspections upon delivery
O&M / Asset RecordsOngoing Maintenance and Lifecycle Management

The Technical Submittal is situated:

after the RFQ

and

before Production

Its core task is to establish:

the Approved Technical Baseline

Subsequent production, FAT, and delivery should all be verified against this baseline.

For a comprehensive overview of the procurement process, please refer to our Substation Electrical Safety Equipment Procurement Guide.

Step 1: Create a Document Index

Do not merge all PDF files together in the first step.

It is recommended to create a document index first.

For example:

NumberDocumentsRevisionMain Uses
01Cover / TransmittalRev.0Document Control
02Document IndexRev.0Package Navigation
03Compliance MatrixRev.0Specification Correspondence
04Technical Data ScheduleRev.0Actual Supply Parameters
05DatasheetRev.AProduct Technical Information
06DrawingRev.BSpecifications, Dimensions, Interfaces
07BOMRev.AParts List
08Test Report—Technical Evidence
09Certificate—Statement or Certification
10Marking LayoutRev.AProduct Identification
11InstructionsRev.AUsage and Inspection Information
12Deviation ScheduleRev.0Technical Deviation
13Comment RegisterRev.0Approval Comments Closed

The purpose of the Document Index is to ensure that the Reviewer does not have to search through dozens of documents for information.

Step 2: Prepare the Cover / Transmittal Sheet

A Technical Submittal should have a clear package identity.

It is recommended that it includes at least the following:

  • Project Name
  • Customer
  • EPC / Consultant
  • Supplier
  • Submittal Title
  • Submittal Number
  • Revision
  • Date
  • RFQ / PO Reference
  • Specification Section
  • Product Family
  • Models Included
  • Prepared By
  • Checked By
  • Submission Status

For example:

Electrical Safety Equipment Technical Submittal

Submittal No.: TSE-001

Revision: Rev.1

Status: For Technical Approval

This ensures that, should a resubmission occur later, it can be clearly distinguished:

  • Rev.0
  • Rev.1
  • Rev.2

Avoid:

final.pdf

final-new.pdf

final-new2.pdf

This method of naming files makes version control unmanageable.

Step 3: The Compliance Matrix should serve as the main navigation for the entire package

The Compliance Matrix is one of the most valuable documents within a Technical Submittal.

It should not merely consist of:

Comply
Comply
Comply

but should establish a structure of:

Requirement → Supplier Response → Evidence

For example:

Specification RequirementClient requirementsSupplier ResponseEvidenceStatus
StandardIEC xxxxIEC xxxxTR-01Comply
ClassClass 2Class 2DS-01 / TR-01Comply
Width1000 mm1000 mmDWG-01Comply
MarkingRequiredProvidedML-01Comply
ColorGreenRedDEV-01Deviation

In this way, the reviewer does not have to guess for themselves from dozens of pages of documentation:

Which page proves this requirement?

Step 4: Prepare the Technical Data Schedule

The Technical Data Schedule should only list the actual supplied configuration.

Do not copy all of the supplier’s product parameters into it.

For example, when procuring an Electrical Insulating Mat, the actual project may only require:

  • Class 2
  • Black
  • 1000 mm width
  • Specific roll length
  • Specific surface area
  • Specific marking

The Technical Data Schedule should therefore list these parameters directly.

Similarly, when procuring a High Voltage Detector, the following should be clearly specified:

  • Model
  • AC / DC
  • Voltage Range
  • Detector Principle
  • Contact Type
  • Indication Method
  • Applicable Standard
  • Pole Interface

The purpose of the Technical Data Schedule is to inform the client:

What are we actually preparing to supply?

Step 5: The Datasheet should only highlight the actual model being supplied

Suppliers often submit a complete catalog, which may contain:

  • 10 models
  • 5 classes
  • 8 sizes
  • various accessories
  • various voltage ranges

However, the client may actually be procuring only one model.

In such cases, the datasheet should:

  • Clearly indicate the offered model
  • Indicate the actual rating
  • Indicate the actual size
  • Indicate the actual configuration
  • Remove or downplay irrelevant models
  • Ensure consistency with the compliance matrix

Do not leave it to the reviewer to decide:

“Which model is it exactly?”

The technical submission should eliminate this uncertainty.

Step 6: When are drawings and a BOM required?

Drawings are not mandatory for all electrical safety equipment.

Whether drawings are required depends on whether the project needs to confirm:

  • Configuration
  • Dimensions
  • Interface
  • Customisation
  • Assembly
  • Connection
  • Marking position

Portable Earthing Set

Drawings and a BOM are usually essential.

This is because the following need to be confirmed:

  • Phase Clamp
  • Earth Clamp
  • Cable Cross-Section
  • Cable Length
  • Cluster
  • Ferrule
  • Topology
  • Operating Pole
  • Accessories

For detailed guidance on reviewing drawings, please refer to How to Review a Portable Earthing Set Drawing Before Production.

Electrical Insulating Mat

If the project involves:

  • Custom Width
  • Warning Edge
  • Special Colour
  • Logo
  • Special Marking

A drawing or marking layout is also highly valuable.

Voltage Detector + Operating Pole

If the following are present:

  • Adapter
  • Custom Interface
  • Detector-to-Pole Combination

A Configuration Drawing can help confirm the complete assembly.

Standard PPE

For standard models and specifications, a separate shop drawing may not be required.

Therefore:

Drawings should be used when it is necessary to confirm product configurations, interfaces, or customization requirements, rather than being applied mechanically to all products.

Step 7: Map Test Reports to Specific Requirements

One of the most common issues in technical submissions is:

A test report is submitted, but it is not specified what it verifies.

A better approach is to reference it directly in the Compliance Matrix.

For example:

Electrical Insulating Mat

A Test Report may be used to support:

  • Electrical Class
  • Dielectric Performance
  • Mechanical Properties
  • Oil Resistance
  • Flame Resistance

Voltage Detector

A Test Report may be used to support:

  • Voltage Range
  • Detection Principle
  • Threshold
  • Visual Indication
  • Audible Indication
  • Self-Test

Hot Stick

It is necessary to distinguish between:

  • Material Evidence
  • Tube / Rod Evidence
  • Complete Tool Evidence
  • Mechanical Evidence

For specific Hot Stick document reviews, please refer to How to Read a Hot Stick Test Report Before Purchase.

Portable Earthing Set

Fault-Duty Evidence must correspond to:

  • Rated Current
  • Rated Time
  • Peak Factor
  • Cable
  • Clamp
  • Ferrule
  • Cluster
  • Configuration

For guidance on this type of evidence, please refer to the Portable Earthing Kit Fault-Current Rating Guide.

A Technical Submission does not need to repeat the full technical details of every report.

Its actual purpose is:

to inform the Reviewer which piece of Evidence supports which Requirement.

Step 8: Correct Use of Certificates and Declarations

Certificates, Test Reports, Certificates of Conformity (CoC) and Batch Records should not be confused with one another.

Different documents address different issues.

Document Primary Purpose

DocumentMain purpose
Test ReportSupport for technical performance or design
Type TestSupport Design / Product Type
Routine / Production RecordSupport for production inspections
Batch RecordSupport for specific production batches
CertificateSupport for specific certifications or declarations
CoCSupplier’s Declaration of Conformity
Packing ListConfirm the actual contents of the consignment

Do not use:

Certificate Available

Instead:

What specific certificate is it? What does it certify? Which model does it correspond to?

For Electrical Insulating Mats, please refer to Type Test vs Batch Test Records for Electrical Insulating Mats.

Step 9: The Deviation Schedule must be prepared separately

If there are discrepancies between what the supplier actually provides and the Specification, these differences should not be concealed within the Datasheet.

For example:

Customer requirement:

Width = 1000 mm

Supplier’s actual delivery:

Width = 900 mm

This should be recorded directly in the Deviation Schedule.

It is recommended that the following details be included as a minimum:

ProjectContent
RequirementThe client’s original requirements
OfferedActually supplied by the supplier
ReasonWhy are they different?
Technical ImpactTechnological Impact
Evidence ImpactDoes this affect the existing test evidence?
Commercial ImpactWill this affect the price/delivery time?
ApprovalIs customer confirmation required?

Deviations should be proactively declared, rather than waiting for the Consultant to discover them.

Step 10: Product Marking – Best confirmed prior to production

For Electrical Safety Equipment, marking should not be reviewed for the first time during the Factory Acceptance Test (FAT).

Different products may require the following markings:

  • Model
  • Class
  • Voltage Range
  • Standard
  • Serial Number
  • Batch
  • Cable Cross-Section
  • Length
  • Warning
  • Asset Number
  • Manufacturer

For example, a Portable Earthing Set may require:

  • Kit ID
  • Cable ID
  • Clamp ID
  • CSA
  • Length
  • Fault Duty Reference

An Electrical Insulating Mat may require:

  • Class
  • Standard
  • Manufacturer
  • Traceability Information

Therefore, the following can be included in the Technical Submission:

Marking Layout

This allows the following to be confirmed prior to production:

  • Label content
  • Label location
  • Product ID
  • Project ID
  • Customer Asset ID

Step 11: Include Manufacturer’s Instructions and Inspection Guidance

The Technical Approval stage does not typically require a complete final O&M Dossier.

However, the project may need to confirm:

  • User Instructions
  • Inspection Guidance
  • Storage Guidance
  • Cleaning Guidance
  • Maintenance Guidance

Please note:

Manufacturer’s Instructions

and

Final O&M / Closeout Package

are not entirely the same document stage.

The Technical Submittal stage primarily verifies:

How the product should be correctly used, inspected, and stored.

It is only at the final handover stage that the following may be finalized:

  • Final Approved Datasheets
  • O&M Manual
  • Inspection Records
  • FAT Records
  • Asset Data
  • Spare Parts Information

Step 12: Standardize checks on Model, Rating, Standard and Revision

Many Technical Submittals are rejected not because of missing documents,

Rather, it is because there are conflicts between the documents.

For example:

Datasheet

Model A

Drawing

Model B

Test Report

Model C

Or:

Compliance Matrix

Class 2

Drawing

Class 3

In such cases, even if each document appears complete in isolation, the entire package still fails to form a reliable chain of technical evidence.

Before submission, check at least the following:

  • Model
  • Rating
  • Class
  • Dimension
  • Material
  • Configuration
  • Applicable Standard
  • Standard Edition
  • Drawing Revision
  • Datasheet Revision
  • Marking
  • BOM
  • Test Report Reference

The core principle is:

Document completeness is not enough. All documents must describe the same offered configuration.

Recommended Structure for a Technical Submittal Package

A complete Technical Submittal for Electrical Safety Equipment can be organized according to the following structure:

SectionDocumentMain Purpose of the Approval Process
01Cover / TransmittalPackage Control
02Document IndexFile Navigation
03Compliance MatrixSpecification Correspondence
04Deviation ScheduleTransparency of Deviations
05Technical Data ScheduleActual parameters
06DatasheetsProduct Statement
07DrawingsSpecifications, Dimensions, Interfaces
08BOMComponent Control
09Standards ListStandard path
10Test ReportsTechnical Evidence
11CertificatesDeclarations and Certifications
12Marking LayoutProduct Identity
13Manufacturer InstructionsUse and Inspection
14Samples / PhotosAssist with the approval process where necessary
15Comment RegisterReview closure

This structure is not a fixed format that must be replicated exactly for all projects.

The actual content should be adjusted according to:

  • Contract
  • Consultant Procedure
  • Utility Requirement
  • Product Complexity

Key documents vary depending on the type of Electrical Safety Equipment

Technical Submittals should not use exactly the same template for all products.

Electrical Insulating Mat

Key elements typically include:

  • Datasheet
  • Class
  • Dimensions
  • Surface
  • Applicable Standard
  • Test Evidence
  • Marking
  • Custom Layout

For the Test Report, please refer to the Electrical Insulating Mat Test Report Guide.

High Voltage Detector

Key elements typically include:

  • Exact Model
  • Detection Principle
  • AC / DC
  • Voltage Range
  • Contact Method
  • Indication
  • Applicable Standard
  • Test Report
  • Pole Interface

Please refer to the High Voltage Detector Test Report Guide.

Hot Stick

Key points typically include:

  • Tool Type
  • Fixed / Telescopic / Sectional
  • Length
  • Head Interface
  • Applicable Standard
  • Electrical Evidence
  • Mechanical Evidence
  • Complete Tool Evidence

Portable Earthing Set

Typically requires more comprehensive information:

  • Drawing
  • BOM
  • Topology
  • Cable Schedule
  • Clamp Schedule
  • Fault-Duty Evidence
  • Marking
  • Traceability

Insulating PPE

Key points that typically require confirmation include:

  • Product Type
  • Class
  • Size
  • Model
  • Applicable Standard
  • Test Evidence
  • Marking

Therefore:

Whilst the structure of a Technical Submittal can be standardized, the technical evidence for each product cannot be mechanically replicated.

How should Consultant Comments and Resubmissions be managed?

Technical Submissions are rarely approved at the first attempt.

The following may arise during a project:

  • Clarification
  • Comment
  • Technical Query
  • Revision Request
  • Rejection
  • Conditional Approval

It is recommended to use a Comment Register.

For example:

CommentSupplier ResponseDocument RevisedRevisionStatus
Width not clearAdded actual widthDatasheetRev.BClosed
Test evidence missingAdded TR-02Compliance MatrixRev.1Closed
Marking unclearAdded layoutML-01Rev.AClosed
Clamp interface wrongDrawing revisedDWG-02Rev.CClosed

Do not simply reply via email or WhatsApp with:

“Amended.”

The reviewer should be able to see:

Which comment → which document has been amended → what is the current revision number?

Resubmissions must have the revision number re-controlled

If the consultant proposes amendments:

First Submission

Rev.0

Comments Received

Record reviewer comments

Revised Submission

Rev.1

Further Revision

Rev.2

Do not directly replace old files, but retain the same revision number.

Otherwise, the following may occur:

  • Production uses the old drawing
  • Purchasing uses the old datasheet
  • FAT uses the new BOM
  • The customer retains a different version

One of the benefits of a technical submission is to prevent version control issues.

The technical approval status should be clear

Different EPCs, consultants, and utilities use different approval statuses.

Common logic may include:

StatusGeneral meaning
ApprovedWe can proceed to the next stage in accordance with the project procedure
Approved with CommentsAmend or implement in accordance with the comments
Revise and ResubmitPlease resubmit
RejectedThe current proposal is not accepted
For InformationFor information purposes only; does not constitute technical approval

Specific names and codes should be implemented in accordance with the project contract.

Technical Submittals should not make the assumption that:

“No response = Approved”.

Only the formal status defined by the project should be used for production release.

What happens after Technical Approval?

Approval of a Technical Submittal does not mean the entire project is complete.

It merely establishes:

Approved Technical Baseline

Subsequent steps typically proceed as follows:

Approved Technical Submittal

↓

Approved Drawing / Configuration

↓

Production

↓

FAT

↓

Shipment

↓

Site Acceptance

For example, after production of Portable Earthing Equipment is complete, it must also pass FAT against:

  • Approved Drawing
  • Final BOM
  • Finished Product
  • Marking
  • Test Records

Please refer to our Portable Earthing Set FAT Checklist.

Therefore:

A Technical Submittal is technical approval prior to production, whilst FAT is verification of the finished product after production.

Do not confuse these two stages.

Common Technical Submittal Errors

Casually merging all documents into a single large PDF

A large number of files does not equate to a clear package.

Lack of a Document Index

Reviewers are unable to locate evidence quickly.

Datasheet does not specify the actual model

The customer does not know exactly which product is being supplied.

Compliance Matrix simply states ‘Comply’

There is no evidence mapping.

Test Report does not match the Offered Product

The report exists, but cannot verify the actual model.

Using a Certificate in place of Test Evidence

Certificates and Test Reports serve different purposes.

Inconsistent parameters in Drawings, Datasheets and BOMs

This is a very common document conflict.

No Deviation Schedule

The client is left to identify discrepancies themselves.

Unclear Standard Edition

Particularly when the project does not align with the current standard version.

Submitting an outdated Revision

This can easily introduce errors into the production environment.

No Marking Layout for Custom Products

Labeling errors are only discovered during the FAT.

A large number of irrelevant catalog items have been included

This increases the reviewer’s workload.

Comments have not been formally closed

It is subsequently impossible to verify whether modifications have been completed.

Modifying documents without updating the revision

This leads to version control issues.

Confusing the Technical Submittal with the FAT Package

The two relate to entirely different project phases.

Waiting until production is complete to prepare technical documentation

By this stage, many configurations can no longer be modified cost-effectively.

How should we prepare the Technical Submittal for Electrical Safety Equipment?

When preparing a Technical Submittal for a project, the focus should not be simply on sending out all existing documents.

We must first establish a correspondence between the project requirements and the product evidence.

We begin by reviewing the Project Specification

to confirm:

  • Product
  • Standard
  • Class
  • Rating
  • Dimension
  • Configuration
  • Documentation
  • Marking

We create a Requirements Matrix

Each requirement must have a clear Supplier Response.

We confirm the actual product model

to avoid submitting models that are unrelated to the actual quotation.

We prepare the technical data

with parameters consistent with the quotation, drawings and test evidence.

Where necessary, we prepare drawings and a bill of materials (BOM)

in particular for:

  • Portable earthing sets
  • Custom mats
  • Detector + pole assemblies
  • Project-specific configurations

We map the test evidence

Each report should specify:

Which specific requirement does it support?

We confirm the applicable standards

and check that the standards and editions are consistent across different documents.

We declare deviations separately

and do not conceal discrepancies within the datasheet.

We confirm the marking

to ensure that mass-produced products correspond to the approved documentation.

We carry out a revision consistency check

focusing on:

  • Model
  • Rating
  • Drawing
  • BOM
  • Test Report
  • Marking

We create a Document Index

enabling reviewers to locate documents quickly.

We record Comments

All technical comments enter a controlled response process.

We freeze the Approved Technical Baseline

Approved models, drawings, BOMs, and specifications should form the basis for production control.

The purpose of this process is not to increase the volume of documentation.

Rather, it is to reduce:

  • Technical rejections
  • Incorrect production
  • Rework
  • FAT failures
  • Delays in site acceptance

FAQ

Does a Technical Submittal Package always require a Drawing?

Not necessarily. Drawings are particularly important only when the project requires confirmation of configuration, dimensions, interfaces, customization or assembly.

What is the difference between a Datasheet and a Technical Data Sheet?

A Datasheet is general product technical information; a Technical Data Sheet places greater emphasis on the actual supply parameters for this specific project. The latter should only detail the actual offered configuration.

Must all Test Reports be included in a single package?

This depends on the project requirements. The focus is not on the number of reports, but rather on whether each report has a clear relationship to the actual product and project requirements.

Can a Certificate be used in place of a Test Report?

Generally, they cannot simply be substituted for one another. Certificates, Test Reports, Certificates of Conformity (CoC), and Batch Records address different aspects of evidence.

What is a Compliance Matrix?

It is used to establish a one-to-one correspondence between the customer’s specifications and the supplier’s response, the offered product, and the supporting evidence.

Where should deviations be placed?

It is recommended to use a separate Deviation Schedule, rather than leaving it to the reviewer to locate them in the datasheet or drawings.

Can goods be dispatched immediately after the Technical Submission has been approved?

Generally not. Following approval, further stages such as Production, FAT, Pre-Shipment Review and Site Acceptance may still be required.

What is the key difference between a Technical Submission and a FAT Package?

A Technical Submission is primarily used for pre-production technical approval; a FAT Package is primarily used to demonstrate that the finished products actually produced comply with the approved configuration.

Practical Project Summary

An Electrical Safety Equipment Technical Submittal should not merely be a collection of documents.

It should constitute a controlled technical approval system.

The most important logic is:

Project Specification

↓

Compliance Matrix

↓

Actual Product Model

↓

Technical Data

↓

Drawing / Configuration

↓

Test Evidence

↓

Deviation

↓

Marking

↓

Revision Control

↓

Technical Approval

A well-structured Technical Submittal should enable the reviewer to quickly ascertain:

  • What the client requires
  • What the supplier provides
  • How the product is configured
  • Which document supports which requirement
  • Whether any deviations exist
  • What the current revision is
  • Whether it is permissible to proceed to the next stage

The objective of a Technical Submittal is not:

To provide more documents.

Rather:

To provide a clearer, more consistent and easier-to-audit chain of evidence.

For complex projects, the Technical Submittal should also maintain continuity with subsequent stages such as Drawing Approval, Production, FAT and Site Acceptance.

Only in this way can a truly complete project documentation lifecycle be established:

Tender → Technical Submittal → Approved Configuration → Production → FAT → Shipment → Site Acceptance → Asset Records

Fill in your information