Managing CPSC Compliance Data Across Multiple SKUs
A practical data model for keeping products, versions, manufacturers, evidence, certificates, and Product Registry references connected as a catalog grows.
- Author:
- VelaCert Editorial Team
- Published:
- Updated:
VelaCert is not CPSC, a testing laboratory, customs broker, or law firm. This page distinguishes official requirements from operational recommendations, but it is not legal advice or a product-specific compliance determination. Confirm current requirements with the official CPSC sources below.
How do you manage CPSC compliance data across multiple SKUs?
Maintain a SKU-centered source of truth that connects each finished product and product version to its manufacturer, applicable CPSC citations, supporting test reports and laboratories, current CPC or GCC, and—when Reference PGA is used—the matching Product Registry identifiers. Preserve historical versions, assign owners, and reuse evidence or certificate data only after confirming that it applies to every covered product. This is a practical internal control model, not a CPSC requirement to buy software or use a specific database.
The operating problem
Why CPSC compliance becomes a data problem at scale
One product record may draw from a product master, supplier profile, factory address, regulatory assessment, laboratory report, CPC or GCC, and broker handoff. With many SKUs, the difficult question is not simply whether each file exists. It is whether the current product version points to the correct facts and evidence.
Aliases multiply
A finished product may be known by an internal SKU, model, UPC or GTIN, retailer SKU, style, or Registry Product ID.
Relationships overlap
One manufacturer, laboratory, or report may relate to several products, but its applicability still needs review for each product version.
Records change at different times
A product, factory, citation decision, test report, certificate, or Registry version can change without the others changing on the same date.
Scale turns document collection into relationship management: teams must know which version of which product is supported by which evidence.
CPSC requirements versus internal operating recommendations
CPSC defines certificate, testing, recordkeeping, and eFiling obligations. It does not prescribe the internal software architecture below. The distinction matters when designing a process.
| Category | What it means |
|---|---|
| CPSC requirement or official workflow condition | An applicable product must be covered by an accurate CPC or GCC based on the required testing or testing program; required certificate elements depend on the product and rules. |
| CPSC requirement or official workflow condition | A Reference PGA filing identifies a certificate already certified in the Product Registry with its Certifier ID, Product ID, and Version ID. Full PGA does not require the Registry. |
| CPSC requirement or official workflow condition | Certain children’s-product records under 16 CFR part 1107 must be maintained for five years. Electronic access may satisfy the record-access requirement, but the regulated party remains responsible. |
| Internal operating recommendation | Assign one controlled internal product identity and preserve all SKU, model, GTIN, UPC, style, and retailer aliases that point to it. |
| Internal operating recommendation | Use explicit current, superseded, and under-review states so an older test report or Registry Version ID is not selected accidentally. |
| Internal operating recommendation | Require a documented review before extending one report, certificate, manufacturer record, or Registry version to another SKU. |
The five-year example above is specifically scoped to certain children’s-product records under 16 CFR part 1107. Other products and records may have different obligations.
The seven records a multi-SKU compliance model should connect
The following is a recommended operating model. It helps preserve traceability without treating every internal SKU as automatically requiring its own certificate.
| Record | Purpose | Recommended control |
|---|---|---|
| Product and internal SKU | The commercial identifier used to order, stock, or sell the finished product. | Connect aliases such as model, UPC, GTIN, style, or retailer SKU to one controlled product identity. |
| Product version | The specific design, materials, components, factory arrangement, or certification state being evaluated. | Keep effective dates and preserve superseded versions instead of overwriting their history. |
| Manufacturer or factory | The party and location associated with manufacture of the product covered by the certificate. | Use a reusable trade-party record, but preserve the product-version relationship and manufacture details. |
| Applicable CPSC citations | The rules, bans, standards, or regulations addressed by the certificate, plus any valid testing exclusions. | Store the compliance determination separately from a laboratory’s test-method wording. |
| Test report and laboratory | Evidence, test dates, sample identity, laboratory identity, and report scope supporting the certification decision. | Link the source file and document identifier to every product version it genuinely supports. |
| CPC or GCC | The certificate type and current certificate record for the covered product or products. | Track coverage, issue or update date, certifier, records contact, and the evidence reviewed. |
| Product Registry record | When Reference PGA is used, the certified record identified by Certifier ID, Product ID, and Version ID. | Map the current Registry version to the matching internal product and certificate version. |
A practical SKU-centered data model
Start with the finished product and version being sold or imported. Connect reusable parties and source documents to that version, then connect the version to the certificate decision and filing identifiers.
- 1
Resolve the product identity
Choose one controlled internal product record. Store every SKU, model, GTIN, UPC, style, and customer-specific alias that refers to it.
- 2
Create a version boundary
Record what makes the version distinct—such as design, materials, components, factory arrangement, or certification state—and when it became effective.
- 3
Attach parties and requirements
Link the manufacturer or factory, responsible certifier, records contact, applicable citations, and any valid testing exclusions.
- 4
Attach evidence
Link test reports, tested samples, dates, laboratories, component evidence, and the reviewer’s applicability decision to the product version.
- 5
Attach the certificate
Identify whether a CPC or GCC applies and which products or versions it actually covers. Preserve the issued record rather than silently rewriting it.
- 6
Attach filing references
If Reference PGA is used, map the matching Certifier ID, Product ID, and current Version ID. Keep these separate from internal version numbers.
How to handle shared manufacturers and test reports
Reuse the party or document record; do not automatically reuse the compliance conclusion. A manufacturer can supply many SKUs, and one report may cover more than one product, but each product-version relationship needs a defensible scope decision.
Before sharing a manufacturer record
- Confirm the legal party and actual manufacturing location.
- Preserve the manufacture date and place tied to the covered product.
- Do not assume a supplier headquarters is the factory.
- Track when a product moves to another factory.
Before sharing a test report
- Match the tested sample to every covered product version.
- Review materials, components, construction, and manufacturing differences.
- Confirm the cited rules and test scope remain applicable.
- Document who approved the relationship and when.
Do not infer coverage from naming alone. Two SKUs can look related in a catalog while differing in material, age grading, components, manufacturing source, or applicable requirements.
Version the relationships, not just the files
A filename such as “final-report.pdf” does not show which product state it supports. Keep effective dates and change reasons on the product, evidence decision, certificate, and Registry mapping.
Current
Approved for the present product version after the latest review.
Under review
A source or relationship changed and cannot yet be relied on.
Superseded
Preserved for history but replaced by a newer product, certificate, or Registry version.
Not applicable
Reviewed and intentionally excluded, with the reason recorded.
For children’s products subject to 16 CFR part 1107, CPSC guidance addresses periodic testing, material changes, and related recordkeeping. For other products, do not apply that children’s-product rule by analogy without confirming the applicable requirement.
Prepare multi-SKU data for CPSC eFiling and the Product Registry
A Full PGA filing transmits the applicable certificate data with the entry. A Reference PGA filing sends the Certifier ID, Product ID, and Version ID for a certificate already certified in the Product Registry. The Registry is a separate CPSC system and does not submit data to ACE automatically.
CPSC supports manual entry, bulk CSV upload, and API workflows for Registry data. Those methods change how records enter the Registry; they do not eliminate the need to validate the underlying product relationships and current certificate version.
Spreadsheet or structured workspace?
CPSC does not require a particular internal tool, and spreadsheets are not prohibited. Choose the simplest controlled system that can preserve accurate relationships for your catalog and workflow.
| Control question | What to verify |
|---|---|
| Identity | Can users distinguish product, SKU aliases, product version, certificate version, and Registry Version ID? |
| Validation | Can required values, allowed identifiers, dates, and relationships be checked before handoff? |
| History | Can the team see what changed, when, why, and who reviewed it? |
| Documents | Can a user reach the exact supporting report or certificate without relying on ambiguous filenames? |
| Access | Can edits and approvals be limited to the appropriate people? |
| Scale | Can the process handle repeated imports, bulk updates, multiple factories, and shared evidence without silent duplication? |
Multi-SKU compliance data review checklist
- Every SKU and external alias resolves to one reviewed product identity.
- The current product version and its effective date are explicit.
- Manufacturer and manufacture-place records match the covered product.
- Applicable CPSC citations or testing exclusions have an owner and source.
- Each test report is linked only to product versions within its reviewed scope.
- The CPC or GCC identifies the products it covers accurately.
- Superseded records remain available but cannot be selected as current by mistake.
- Reference PGA mappings include the current Certifier ID, Product ID, and Version ID.
- Broker or filer handoffs use the same product and certificate version as the internal review.
- Changes trigger a documented reassessment instead of an automatic copy-forward.
Keep product evidence connected
Build a traceable product-record workflow
VelaCert helps teams organize product versions, manufacturers, testing, certificate records, missing information, and source documents in one workspace. It does not determine legal requirements, issue a CPC or GCC, submit PGA messages, or guarantee CPSC acceptance.
Official CPSC Sources
- eFiling Frequently Asked Questions— U.S. Consumer Product Safety Commission
- CPSC Product Registry— U.S. Consumer Product Safety Commission
- eFiling Document Library— U.S. Consumer Product Safety Commission
- Product Registry User Guide V3— U.S. Consumer Product Safety Commission
- Children’s Product Certificate guidance— U.S. Consumer Product Safety Commission
- General Certificate of Conformity FAQ— U.S. Consumer Product Safety Commission
- Initial Certification Testing FAQ— U.S. Consumer Product Safety Commission
Frequently asked questions
How should a company manage CPSC compliance data across many SKUs?
A practical approach is to maintain one product-centered source of truth that links each internal SKU and product version to its manufacturer, applicable CPSC citations, supporting test reports and laboratories, current CPC or GCC decision, and any Product Registry identifiers. This is an internal control recommendation, not a CPSC-mandated software architecture.
Does every SKU need a separate CPC or GCC?
Not automatically. Certificate coverage depends on the actual product, applicable rules, and supporting evidence—not the existence of an internal SKU alone. CPSC’s CPC guidance says the product description must identify the products covered and no others. CPSC’s GCC FAQ also explains that one GCC may cover multiple materially unchanged batches or lots when the certificate remains accurate. Confirm the appropriate scope for each product and certificate.
Can one test report support multiple SKUs?
Possibly, but only when the report’s tested product, samples, materials, construction, manufacturing conditions, citations, and other scope genuinely support each product covered by the certificate. A shared supplier, visual similarity, or related SKU number is not enough by itself. Have the responsible compliance professional or laboratory confirm product-specific applicability.
Is the CPSC Product Registry required for every SKU?
No. CPSC says the Product Registry is used for the Reference PGA workflow and is not required for Full PGA filings. If a company uses Reference PGA, the certified Registry record provides the Certifier ID, Product ID, and Version ID used in the entry reference.
Can a company use spreadsheets for CPSC compliance data?
CPSC does not prohibit spreadsheets, and its Product Registry supports bulk CSV upload. A spreadsheet may work for a smaller, controlled catalog. As volume and change frequency grow, companies should assess whether it provides adequate validation, access control, version history, document links, and prevention of stale references. Software is an operational choice, not a universal CPSC requirement.
When should a CPSC compliance record get a new version?
Update the operational record whenever product identity, manufacturer details, applicable citations, testing, certificate data, or supporting evidence changes. For Product Registry records, follow CPSC’s current versioning instructions. Separately, children’s products subject to 16 CFR part 1107 may require retesting after a material change; that rule should not be generalized to every CPSC-regulated product.