ACES vs PIES: A Fitment Data Checklist for Parts Sellers

What ACES and PIES each describe

ACES is used to exchange aftermarket application and fitment data; PIES handles product information. Auto Care Association maintains the standards and their supporting reference databases. Format versions, database licensing, and a recipient’s accepted specification all matter. Check those requirements with your source and destination before building an import.

For a practical distinction, a brake component’s images, dimensions, packaging, and product description belong to its product-information problem. The vehicles and configurations it fits belong to its application problem. Neither establishes whether your warehouse has a sellable unit today. Inventory is a third record with its own owner.

Build a small catalog acceptance pack

Before loading a full supplier file, choose a representative sample: a straightforward item, a part with several applications, an application with qualifications, a product with multiple packages, and a record missing a required field. Keep an expected result for each sample so your team can compare what was supplied with what appears after import.

Include deliberately invalid examples. A system that accepts everything without surfacing missing information may create more cleanup downstream. Ask who owns rejected records, how corrections are applied, and whether the original source can be traced after an update.

• Confirm supplier part number, brand, internal SKU, and duplicate handling.
• Review units, package quantities, images, and required product attributes.
• Preserve application qualifications rather than flattening everything to year/make/model.
• Record source version, receipt date, and the owner of future updates.

Test the destination, not just the file

A successful import is only one checkpoint. Marketplaces and trading partners can require their own field mappings and validation. eBay’s parts guidance explains that compatibility data helps buyers find suitable parts and make a purchase decision. It also makes sellers responsible for the accuracy of the applications they provide.

Inspect what the buyer actually sees. Confirm how a qualified application is displayed, how missing fitment is handled, and what happens after a correction. A description mentioning a vehicle should not be treated as proof that structured compatibility has been accepted by the destination.

Find the cause behind a wrong-part return

Classify the return before changing the catalog. Was the application wrong, the selected vehicle configuration incomplete, the warehouse pick incorrect, or the package mislabeled? These problems need different fixes. Changing product data will not correct a shortcoming in picking verification.

As an illustrative review, compare a returned part with the exact listing version and application information available when the order was placed. Then compare the ordered SKU with the shipped item. Keep the outcome tied to a correction owner, and check whether the same issue affects other active listings.

What to ask in a 1XA walkthrough

Bring a non-sensitive sample structure and the destinations you need to serve. Ask how catalog records, fitment-related data preparation, inventory, and listing review will fit together. Confirm supported imports, exports, standards versions, licensing responsibilities, and channel actions rather than assuming every format is native.

Evaluate the workflow on correction effort, rejected records, and fitment-related inquiries using your own baseline. 1XA catalog, inventory, and multichannel modules can be evaluated as a focused scope before a broader ERP rollout.