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.
| Stage | Main Purpose |
|---|---|
| Tender / RFQ | Defining Procurement and Technical Requirements |
| Technical Submittal | Obtain formal technical approval |
| Approved Drawing / Configuration | Freeze Production Configuration |
| Production | Manufacture According to Approved Specifications |
| FAT | Verify that the finished product conforms to the approved configuration |
| Shipping Documents | Confirm the Actual Shipment Contents |
| Site Acceptance | Conduct identity, documentation, and on-site inspections upon delivery |
| O&M / Asset Records | Ongoing 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:
| Number | Documents | Revision | Main Uses |
|---|---|---|---|
| 01 | Cover / Transmittal | Rev.0 | Document Control |
| 02 | Document Index | Rev.0 | Package Navigation |
| 03 | Compliance Matrix | Rev.0 | Specification Correspondence |
| 04 | Technical Data Schedule | Rev.0 | Actual Supply Parameters |
| 05 | Datasheet | Rev.A | Product Technical Information |
| 06 | Drawing | Rev.B | Specifications, Dimensions, Interfaces |
| 07 | BOM | Rev.A | Parts List |
| 08 | Test Report | — | Technical Evidence |
| 09 | Certificate | — | Statement or Certification |
| 10 | Marking Layout | Rev.A | Product Identification |
| 11 | Instructions | Rev.A | Usage and Inspection Information |
| 12 | Deviation Schedule | Rev.0 | Technical Deviation |
| 13 | Comment Register | Rev.0 | Approval 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 Requirement | Client requirements | Supplier Response | Evidence | Status |
|---|---|---|---|---|
| Standard | IEC xxxx | IEC xxxx | TR-01 | Comply |
| Class | Class 2 | Class 2 | DS-01 / TR-01 | Comply |
| Width | 1000 mm | 1000 mm | DWG-01 | Comply |
| Marking | Required | Provided | ML-01 | Comply |
| Color | Green | Red | DEV-01 | Deviation |
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
| Document | Main purpose |
|---|---|
| Test Report | Support for technical performance or design |
| Type Test | Support Design / Product Type |
| Routine / Production Record | Support for production inspections |
| Batch Record | Support for specific production batches |
| Certificate | Support for specific certifications or declarations |
| CoC | Supplier’s Declaration of Conformity |
| Packing List | Confirm 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:
| Project | Content |
|---|---|
| Requirement | The client’s original requirements |
| Offered | Actually supplied by the supplier |
| Reason | Why are they different? |
| Technical Impact | Technological Impact |
| Evidence Impact | Does this affect the existing test evidence? |
| Commercial Impact | Will this affect the price/delivery time? |
| Approval | Is 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:
| Section | Document | Main Purpose of the Approval Process |
|---|---|---|
| 01 | Cover / Transmittal | Package Control |
| 02 | Document Index | File Navigation |
| 03 | Compliance Matrix | Specification Correspondence |
| 04 | Deviation Schedule | Transparency of Deviations |
| 05 | Technical Data Schedule | Actual parameters |
| 06 | Datasheets | Product Statement |
| 07 | Drawings | Specifications, Dimensions, Interfaces |
| 08 | BOM | Component Control |
| 09 | Standards List | Standard path |
| 10 | Test Reports | Technical Evidence |
| 11 | Certificates | Declarations and Certifications |
| 12 | Marking Layout | Product Identity |
| 13 | Manufacturer Instructions | Use and Inspection |
| 14 | Samples / Photos | Assist with the approval process where necessary |
| 15 | Comment Register | Review 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:
| Comment | Supplier Response | Document Revised | Revision | Status |
|---|---|---|---|---|
| Width not clear | Added actual width | Datasheet | Rev.B | Closed |
| Test evidence missing | Added TR-02 | Compliance Matrix | Rev.1 | Closed |
| Marking unclear | Added layout | ML-01 | Rev.A | Closed |
| Clamp interface wrong | Drawing revised | DWG-02 | Rev.C | Closed |
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:
| Status | General meaning |
|---|---|
| Approved | We can proceed to the next stage in accordance with the project procedure |
| Approved with Comments | Amend or implement in accordance with the comments |
| Revise and Resubmit | Please resubmit |
| Rejected | The current proposal is not accepted |
| For Information | For 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


