CPSC eFiling Data Elements and CSV Field Requirements
CPSC eFiling data elements connect an imported product to its certificate, manufacturer, manufacturing date and place, applicable safety requirements, testing date, testing laboratories, and test-record contact. In the Product Registry CSV, those certificate facts are organized into required, contingent, and optional fields with specific formats and dependencies.
This field guide explains the seven core data elements used in a Full PGA Message Set, the additional fields required to build and manage Product Registry records, the difference between required and conditionally required CSV columns, accepted values, date formats, trade-party references, laboratory groups, citation codes, product versions, and optional supporting information.
Seven eFiling elements do not equal seven CSV columns
CPSC describes seven core product-certificate data elements for the Full PGA Message Set. The Product Registry CSV represents those same certificate facts through a larger structured record that also supports reusable trade parties, certificate types, product versions, additional identifiers, laboratory-to-citation relationships, and optional product and test-report details.
The broker transmits the seven certificate data elements
Under the Full PGA route, the importer supplies its broker with the Product ID, Citation Codes, Manufacture Date, Manufacture Place, Product Test Date, Testing Laboratory, and Point of Contact. The broker transmits those elements in the CPSC PGA Message Set through CBP ACE.
The full record is stored first, then referenced by three identifiers
Under the Reference PGA route, the importer enters and certifies the certificate data in the CPSC Product Registry. The broker later transmits the Certifier ID, Product ID, and Version ID so the entry can reference the stored certificate.
One certificate fact may require several linked columns
“Testing Laboratory,” for example, is not a single free-text cell. The CSV can require laboratory type, CPSC-ID or trade-party identifier, new-party status, party details, citation codes, test date, and optional test-report references for each numbered laboratory group.
Map source records to field groups, not only column names
A supplier spreadsheet may contain a manufacturer name but no reusable identifier, or a test report may show a laboratory but not the citation codes needed for the certificate. Readiness depends on complete relationships between the fields, not simply whether individual cells contain text.
The seven required CPSC eFiling data elements
These elements describe what product is being certified, which requirements apply, where and when it was manufactured, how and when it was tested, and who maintains the supporting test records. The underlying certificate must be accurate before the data is formatted for either filing route.
Identify the exact product covered by the certificate
CPSC accepts seven Product ID types: GTIN, UPC, SKU, Model Number, Serial Number, Registered Number, and Alternate Identifier. In the Product Registry, the Primary Product ID becomes a certificate identifier and, together with the version, helps identify and update the stored certificate.
List the applicable rules, bans, standards, or testing exclusions
Citation codes connect the certificate to the CPSC requirements supported by the identified testing. When a testing exclusion applies, the relevant exclusion code must be provided. Codes should come from the current official materials and match the actual certification basis.
Provide the month and year of manufacture
The current CSV guide defines Manufacture Date as the month and year the product was manufactured and requires the format MM/CCYY. Keep the spreadsheet cell as Text so Excel does not convert or reinterpret the value during export.
Identify the manufacturer and production location
The Product Registry represents manufacture place through the manufacturer trade-party record. The CSV references an existing manufacturer by GLN or Alternate ID, or creates a new manufacturer record with its identifier, name, complete address, and contact information.
Record the most recent date of testing supporting the certificate
The CSV field is Last Test Date, formatted MM/DD/CCYY. Confirm the date from the supporting test records. It is different from Manufacture Date and from the optional production start and end dates.
Identify every laboratory whose testing supports certification
Each laboratory group has a type and related identifier fields. ITL refers to a CPSC-accepted third-party laboratory and uses a CPSC-ID; LAB uses a GLN or Alternate ID; NOL is used to provide testing-exclusion codes when there is no laboratory entry for that exclusion.
Identify the party maintaining the test-result records
The accepted categories are Importer, Manufacturer, Laboratory, Broker, and Other. When Other is selected, an existing trade-party identifier or full information for a new point of contact may be required so CPSC can identify the records custodian.
Fields required for every Product Registry CSV row
CPSC’s current CSV Upload Guide separates fields into required, contingent, and optional groups. All required column headers must be present. If a required header is missing, the upload can fail; if the header exists but its value is blank for one product, that row returns an error.
State whether the row is new or updates an existing Registry record
Accepted values are Y or N. This field controls whether Current Version ID becomes mandatory and changes how the Registry looks for the corresponding product in the destination Product Collection.
Assign the desired version identifier
The value is alphanumeric with a current length limit of 19 characters. A Version ID is unique for a particular Primary Product ID and distinguishes the certificate version stored in the Product Registry.
Provide the identifier used as the Registry’s product key
The current CSV guide describes an alphanumeric value with a 19-character limit for this required field. Choose an ID that identifies the specific product covered by the certificate and can be communicated consistently to the broker.
Declare what kind of identifier the preceding value contains
Accepted types are GTIN, UPC, SKU, Model Number, Serial Number, Registered Number, and Alternate Identifier. Do not put a value into a field whose stated type does not match the actual identifier.
Specify GCC or CPC
Use GCC for a General Certificate of Conformity or CPC for a Children’s Product Certificate, based on the product and applicable certification rules. The tool should check the supplied value, not choose the certificate type for the user.
Use a recognizable product or model name
This required alphanumeric field currently allows up to 250 characters. Keep it specific enough to connect the CSV row to the product, source records, packing documentation, and certificate evidence.
Reference one manufacturer trade-party record
At least one of these two identifier fields must be provided for each product row. The identifier either links to an existing manufacturer or anchors the new trade-party details supplied in the same row.
Enter the manufacturing month and year as MM/CCYY
This field should remain Text in the workbook. Do not substitute an invoice date, import date, production range, or testing date when the actual manufacturing month and year are required.
Supply at least one laboratory or testing-exclusion group
Lab 1 Type accepts ITL, LAB, or NOL. The corresponding Citation Codes field must contain at least one applicable citation or testing-exclusion code. When several codes are supplied, separate them with semicolons.
Enter the most recent supporting test date as MM/DD/CCYY
Confirm this value from the supporting test information. If several laboratories or test reports support the certificate, maintain the relationship between each laboratory, its citations, and the testing represented by the date.
Select the records custodian category
Accepted values are Importer, Manufacturer, Laboratory, Broker, or Other. Additional point-of-contact columns become relevant when Other identifies a separate existing or new trade party.
Fields required only when another answer triggers them
Conditional rules are a common source of CSV errors. A field may be blank in one row and mandatory in the next because Product Update, an “Is New?” value, laboratory type, or point-of-contact category changed.
Current Version ID becomes required
The Registry uses the existing product and current version information to locate the record being updated. Verify the Primary Product ID, Product Collection, Current Version ID, and intended New Version ID together.
Complete manufacturer details become required
Provide the new manufacturer’s GLN or Alternate ID together with its name, full address, and required contact information. If the manufacturer already exists, reference the stored identifier and use N or leave the new-party field blank where permitted.
Lab CPSC-ID becomes required
The CPSC-ID identifies the accepted third-party laboratory. Use the laboratory identifier supported by the testing records; do not substitute the importer’s internal vendor code or a GLN in this field.
Lab GLN or Alternate ID becomes required
A LAB-type entry references a reusable trade-party record. If the laboratory is new, set Lab {#} Is New? to Y and provide all applicable party details; later rows should reuse the confirmed identifier and mark the lab as existing.
The citation field carries testing-exclusion codes
NOL indicates that no laboratory is being identified for the applicable exclusion. Put the supported testing-exclusion codes in that numbered lab group’s Citation Codes column; do not use NOL to bypass missing laboratory evidence when testing was actually performed.
Add complete sequential Lab 3, Lab 4, and later groups
The template contains two laboratory groups by default. Additional laboratories are allowed, but every added column must follow the official sequential header pattern and keep the fields for each laboratory together.
Identify the separate test-record contact
If Other refers to an existing party, use its GLN or Alternate ID. If POC Is New? is Y, provide the identifier and the complete name, address, and contact group required by the current guide.
Describe the component represented by the laboratory data
The optional Lab {#} Is Component? field accepts True, False, Yes, or No. When it is True or Yes, the related component description explains which component the test results cover.
How manufacturer, laboratory, and contact fields work together
The Product Registry stores manufacturers, laboratories, and certain points of contact as trade parties. This reduces repeated data entry, but only when identifiers, new-party indicators, Product Collection context, and party details are managed consistently.
Use a Global Location Number when it identifies the correct entity
A GLN is not universally mandatory, but it can identify a trade party consistently. CPSC’s current guide notes that GLNs are not automatically validated at this time and that two different trade-party entries cannot share a GLN.
Create stable shorthand for a reusable party
An Alternate ID can be a custom string that identifies the party and links to its full Registry details. It must be unique in the applicable Business Account or private Product Collection context and should remain stable across future certificate rows.
Use Y only when creating that trade-party record
When “Is New?” is Y, the corresponding full details become required. Subsequent references should use the established GLN or Alternate ID and set the indicator to N or leave it blank where permitted. Repeating Y can create update and duplication problems.
Extra name and address fields do not repair a wrong identifier
CPSC states that when a party is marked N or left blank, supplied descriptive details are ignored and the Registry uses the trade-party record matching the GLN or Alternate ID. Verify that identifier before uploading.
Confirm where the reusable party record is visible
Product Collections with Trade Party Privacy enabled keep their trade-party lists private to that collection. Collections without it use the shared account list. The same visible identifier may therefore resolve differently depending on the selected destination.
Associate each laboratory with the requirements it tested
CPSC explains that certificates should identify all testing used to support certification, including relied-upon component-part testing, and connect each testing laboratory with the specific rules, bans, standards, regulations, or exclusions represented by its work.
Choose the structure matching the evidence source
Use ITL when the laboratory is identified by its CPSC-ID, LAB for another laboratory represented as a Registry trade party, or NOL to provide a supported testing-exclusion code. The type controls which related fields are valid or required.
Use the current official codes supported by that laboratory’s testing
The certificate needs at least one citation or testing-exclusion code. Separate multiple codes with semicolons. Do not select a code merely because its description appears close to the product; confirm applicability and evidence.
Use the most recent test date supporting the certificate
Keep the field in Text format and use MM/DD/CCYY. When multiple reports and laboratories are involved, document how the selected date and each laboratory group relate to the certificate’s testing basis.
Link test reports without uploading the report itself
Optional fields include Lab {#} Test Report ID, Test URL, and Test Report Access Key. The current guide allows up to 400 characters for each. If multiple report details are provided in one field, separate corresponding values with semicolons and keep their order aligned.
Record testing relied upon for the finished-product certificate
The certificate remains for the finished product, but CPSC states that testing information relied upon to support it includes applicable component-part testing. Use the component indicator and description to preserve that relationship accurately.
Optional information that can improve identification and traceability
Optional does not mean irrelevant. Additional identifiers, product descriptions, production dates, lot information, component descriptions, and test-report references can help connect the Registry record to products and evidence—but they must still be accurate and correctly formatted.
Add identifiers of a different type from the Primary Product ID
Optional GTIN, UPC, SKU, Model Number, Serial Number, Registered Number, and Alternate Identifier columns support cross-reference. Do not duplicate the identifier type already used as the primary type.
Add trade name, description, color, and style when useful
These fields can distinguish products that share broad model families or supplier descriptions. Keep each value connected to the exact finished product and within the current field length.
Record the production range and lot when supported
Optional Production Start Date and Production End Date use MM/DD/CCYY. Lot Number and the party assigning the lot can support traceability. They do not replace the required Manufacture Date.
Include the CPSC registry identifier when it applies
The optional Small Batch Manufacturer CPSC ID is a specific registry identifier. It should be supplied only when supported by the manufacturer’s status and records, not used as a general manufacturer identifier.
Provide stable references that authorized users can follow
Report IDs, URLs, and access keys can make the certificate easier to verify internally. Avoid public links that expose confidential records, expired temporary URLs, or mismatched keys that point to a different report.
Rules that make accurate data uploadable
Even complete certificate information can fail when spreadsheet software changes its representation. Validate the final CSV structure and raw values after export.
Preserve official field names
Do not rename standard columns. The controlled exception is the addition of laboratories using the official sequential Lab 3, Lab 4, and later naming convention.
Keep sensitive columns as Text
Prevent Excel from changing dates, removing leading zeros, or converting long identifiers to scientific notation. Reopen or inspect the exported CSV to verify the actual stored values.
Remove commas from field values
The current CPSC guide instructs users not to include commas in certificate data because commas separate CSV fields. For example, use “Example Company LLC” instead of “Example Company, LLC.”
Use semicolons in fields that accept a list
Citation codes and optional test-report references can contain multiple values. Separate them with semicolons and keep parallel report fields in a consistent order.
Validate controlled fields before free text
Check Y/N fields, ID types, GCC/CPC, ITL/LAB/NOL, point-of-contact categories, date formats, and current character limits. A visually complete row can still fail if one value is outside the permitted set.
Build a source-to-CPSC mapping before generating the CSV
A repeatable mapping shows where each CPSC field comes from, who owns the information, which evidence supports it, and what should happen when the source is blank or inconsistent.
Choose the primary identifier and define row boundaries
Determine which source record represents one finished product certificate. Separate variants when their manufacturer, production date, testing, citations, or certificate version differs.
Confirm GCC or CPC and the applicable citation set
This decision belongs to the responsible compliance process. Record the confirmed result and its supporting sources; do not ask the conversion layer to determine legal applicability from a product description alone.
Standardize each production location and Registry identifier
Keep the legal or operational name, complete address, contact information, GLN or Alternate ID, and Product Registry status together. Do not collapse different factories under one identifier merely because they belong to the same supplier.
Connect laboratories, reports, dates, citations, and components
Build one reviewable relationship for every testing source used in certification. Include supported exclusions and component testing rather than placing all codes in a single undifferentiated field.
Confirm who can produce the supporting test records
Select the accepted POC category and establish the reusable identifier and details when Other applies. The contact should represent the actual custodian of the relevant test-result records.
Separate format problems from missing evidence
Correctable format issues include header mapping, accepted values, date representation, delimiters, and lengths. Missing lab records, unsupported citations, uncertain certificate type, or unknown manufacturing details require source clarification before file generation.
Continue from field definitions to a complete filing workflow
Use the related guide that matches the next decision: importer obligations, Registry setup, CSV preparation, upload troubleshooting, product scope, seller workflow, or a Foreign Trade Zone entry.
CPSC eFiling Resource Center for U.S. Importers
Open the central hub for compliance dates, filing routes, official sources, preparation guides, and the CSV application.
CPSC eFiling Requirements for U.S. Importers
Review effective dates, covered imports, certificate obligations, Full and Reference PGA routes, and broker coordination.
How to Use the CPSC Product Registry
Understand Business Accounts, Product Collections, users, trade parties, certificate versions, upload, certification, and broker handoff.
CPSC eFiling CSV Template: How to Prepare a Bulk Upload File
Download the current template, preserve its structure, map source data, and export a controlled CSV.
CPSC eFiling CSV Upload Errors and How to Fix Them
Diagnose file-wide failures, missing fields, invalid values, product updates, trade-party dependencies, and citation problems.
Which Products Require CPSC eFiling?
Understand why the finished product’s certification requirement must be resolved before fields are populated.
CPSC eFiling for Amazon and Private-Label Sellers
Organize supplier data, testing records, importer roles, product variants, and repeat imports.
CPSC eFiling Requirements for Foreign Trade Zones
Prepare for the separate effective date and entry workflow for covered merchandise withdrawn from an FTZ.
Verify field rules before preparing each new batch
CPSC can revise templates, accepted values, field lengths, citation materials, and Registry behavior. Use current official documents rather than a saved third-party field list.
eFiling Document Library
Official location for the current bulk-upload template, CSV guide, Product Registry guide, API specification, citation and testing-exclusion files, and implementation materials.
User Guide for CSV Upload, Version 3.0
Official required, contingent, and optional fields; accepted values; formats; length limits; trade-party rules; laboratory groups; and upload instructions.
eFiling Product Registry User Guide, Version 3.0
Official instructions for accounts, collections, trade parties, certificate records, bulk import, product versions, certification, and export.
eFiling Frequently Asked Questions
Official explanations of the seven Full PGA elements, three Reference PGA identifiers, accepted Product ID types, testing information, Registry reuse, and current implementation dates.
Common questions about Product Registry CSV fields
These answers summarize the current CPSC field structure. The official template, guide, Product Registry results, and product records remain controlling.
What are the seven required CPSC eFiling data elements?
For the Full PGA route, CPSC lists Product ID, Citation Codes, Manufacture Date, Manufacture Place, Product Test Date, Testing Laboratory, and Point of Contact.
Why does the Product Registry template contain many more fields?
The CSV builds a reusable certificate record. It includes product and version controls, certificate type, decomposed trade-party details, laboratory-to-citation groups, conditional fields, and optional identification and test-report information.
Can a blank field be valid for one product but invalid for another?
Yes. Contingent fields become mandatory only when another value triggers them—for example, Current Version ID when Product Update is Y, or complete laboratory details when a new LAB-type party is created.
Which Product ID types does CPSC accept?
GTIN, UPC, SKU, Model Number, Serial Number, Registered Number, and Alternate Identifier. Additional identifiers may be supplied in the Registry when their type differs from the Primary Product ID type.
What date formats does the current CSV guide require?
Manufacture Date uses MM/CCYY. Last Test Date, Production Start Date, and Production End Date use MM/DD/CCYY. Keep these spreadsheet cells as Text to prevent automatic reformatting.
Must component-part testing be represented?
CPSC states that certificates must identify testing relied upon to support the finished-product certification, including component-part testing, and associate each laboratory with the applicable requirements it tested.
Can Registry Intelligence determine missing certificate facts?
No. The application can map, validate, and format user-supplied information. It does not determine legal applicability, choose unsupported citations, create laboratory evidence, certify products, submit to CPSC or CBP, or guarantee acceptance.
Check every field group before generating the CSV
Upload one or several supported source files, confirm the mapping, identify missing and inconsistent information, and prepare a CPSC Product Registry-formatted CSV from rows supported by the data you provide.
Use current official files and supported certificate information
Registry Intelligence is not affiliated with, endorsed by, or operated by the U.S. Consumer Product Safety Commission or U.S. Customs and Border Protection. This page provides educational and data-preparation information, not legal advice, customs brokerage, product testing, certification, Product Registry access, or a government filing service. Official rules, current CPSC files, technical instructions, Product Registry results, and product-specific evidence remain controlling.