CPSC eFiling Data Requirements: Required, Conditional, or Not Required?

Required vs. conditional vs. optional or not applicable

Start with the vocabulary used by the specific official document. The Product Registry CSV guide uses Required Fields, Contingent Fields, and Optional Fields. CATAIR record tables use status markers such as mandatory, conditional, optional, and not applicable. Similar labels do not make the two data structures interchangeable.

On small screens, swipe the table horizontally. Always use the condition and accepted values in the current official guide or template.

What data does CPSC eFiling require?

There is no single field list that applies unchanged to every interface. CPSC’s Quick Start Guide identifies seven high-level certificate data elements: product identification, citation codes, manufacture date, manufacture place, product test date, testing laboratory, and point of contact for test-result records. The detailed Product Registry and CATAIR instructions break those elements into fields and add workflow-specific identifiers, control records, conditions, and formats.

For a broader source-by-source inventory, use the existing CPSC eFiling data requirements checklist. This page focuses on deciding a field’s status rather than repeating that checklist.

Product Registry requirements and CSV conditions

The CPSC Product Registry stores and manages certificate data for Reference PGA use. Importers can enter data in the interface, upload a CSV, or integrate through the API. For CSV, CPSC says required column headers must be present and a blank required value produces an error for that product row.

Do not infer “not required” from a blank-looking spreadsheet column. First determine whether another field activates it, whether an existing trade-party identifier satisfies it, and whether the current template classifies it as required, contingent, or optional.

Product Registry data is not the same as CATAIR / ACE transmission data

For the filing-path comparison, see CPSC Full PGA vs. Reference PGA.

Citation Codes and Intended Use Codes answer different questions

“Data is not required per agency guidance” and CPSC Disclaim B

Searchers sometimes encounter the phrase “data is not required per CPSC guidance.” In the CATAIR layout, closely related wording describes Disclaim B. It is a reason code in a Disclaim Message Set—not a general instruction to omit an unresolved required field.

• Disclaim A

  CPSC guidance describes defined situations in which no certificate is required, including products outside CPSC jurisdiction or products for which no CPSC rule requiring certification applies.

• Disclaim B

  CPSC describes narrow product situations where a rule exists but the agency is exercising enforcement discretion and does not require a certificate. Use the current official eligibility guidance; do not extrapolate from the label.

A Disclaim is not a missing-data workaround. CPSC says Disclaim Message Sets are optional and intended for entry lines that do not require certificate data. When a Disclaim is filed, an Intended Use Code is required.

Importer vs. customs broker responsibilities

CPSC expects importers to work with manufacturers, laboratories, brokers, software providers, and other trade partners, but its Quick Start Guide says importers are ultimately responsible for product certification. A customs broker may transmit the PGA Message Set; that does not automatically make the broker the owner of product applicability, testing, or certificate decisions.

What happens when required information is missing?

In a Product Registry CSV upload, CPSC says missing required headers fail the upload and blank required values return an error for the affected row. Contingent fields also produce a gap when their condition is true. An optional or N/A designation must come from the applicable guide—it should not be assigned merely because the team cannot find the value.

Treat missing information as a routed work item: identify the source owner, record what condition applies, obtain or review the evidence, and then regenerate the filing data. If the question is whether a product, testing exclusion, citation, or Disclaim legally applies, escalate it to a qualified compliance professional.

A practical CPSC eFiling data-preparation workflow

1. 1

   Choose the filing path

   Confirm whether the entry will use Full PGA, Reference PGA, or—only for a qualifying no-certificate situation—an optional Disclaim Message Set.

2. 2

   Identify the exact product and certificate

   Match the shipment to the finished product, product version, CPC or GCC record, and responsible certifier.

3. 3

   Collect source records

   Bring together manufacturer and factory data, manufacture date, test reports, laboratories, test date, records contact, and reviewed certificate information.

4. 4

   Apply conditions field by field

   For each Product Registry or CATAIR field, record the official status and the condition that makes it required. Do not use one workflow’s column rules for another.

5. 5

   Resolve gaps with the owner

   Send missing manufacturer data to the supplier, testing questions to the laboratory, and applicability decisions to the responsible compliance professional.

6. 6

   Prepare the broker handoff

   For Full PGA, provide the reviewed certificate data in the required message structure. For Reference PGA, provide the current Certifier ID, Product ID, and Version ID.