A distributor's guide to ACES/PIES fitment data
Why fitment gaps drive wrong-part returns in auto parts ecommerce, the ACES/PIES fields a buyer actually checks, and a brake-rotor checklist to fix it.

A buyer shopping for a brake rotor on a distributor's site is running a silent compatibility check before they ever look at price: year, make, model, engine, trim, sometimes down to the axle position. If the product page can't answer that in one glance, they either guess and order wrong, or they call the counter and tie up a rep who could be doing something else. Both outcomes trace back to the same root cause: fitment data that exists somewhere in the business but doesn't make it onto the page.
ACES and PIES aren't optional back-office plumbing
ACES (Aftermarket Catalog Exchange Standard) and PIES (Product Information Exchange Standard) are the industry's shared language for describing what a part is and what it fits. PIES carries the product attributes: part number, brand, dimensions, packaging, digital assets. ACES carries the fitment: which combination of year, make, model, engine, and sub-model a given part number is valid for, expressed against the Auto Care Association's shared vehicle configuration database (VCdb), position database (PAdb), and qualifier database (Qdb) (Auto Care Association, ACES).
Most distributors already have ACES and PIES files from suppliers or a data provider. The problem is rarely that the standard is missing — it's that the files are incomplete, out of date, or never make it cleanly from the feed into what a shopper sees on the page. A part can be 100% compliant with the ACES schema and still be missing the one qualifier (2WD vs. 4WD, front vs. rear, vented vs. solid) that determines whether it fits the customer's actual truck.
Why this shows up as returns, not just bad data
Auto parts already carry one of the highest return rates in ecommerce — industry trackers put it around 19-20%, well above the roughly 20% average across all retail categories, and fitment mismatches are consistently cited as the single largest driver (ServeRetail, "Auto Parts Return Rate"). One fitment-data vendor's review of aftermarket returns puts the share caused specifically by incorrect or incomplete fitment data at close to 20% on its own (PCFitment, "Using Data Quality & Validation to Reduce Returns"). Online marketplaces run meaningfully higher return rates than brick-and-mortar counters for the same reason a counter person exists in the first place: a human used to catch the mismatch before the sale closed, and now nobody does.
Every one of those returns costs more than the refund. There's the reverse shipping, the restocking, the core charge dispute if it's a rotor or caliper, and the support ticket that comes before the return — a customer trying to figure out over chat whether the part they already ordered is actually going to fit.
What a brake rotor buyer needs answered
Take a front brake rotor. A buyer (or a technician buying on their behalf) is checking for:
- Vehicle fitment: year/make/model/engine, expressed precisely enough to exclude the sub-models it doesn't fit
- Position: front vs. rear, and left vs. right if it's not symmetric
- Rotor type: vented, solid, or drilled/slotted
- Diameter and thickness:
12.6 indiameter, minimum thickness / discard thickness - Hub type: hub-centric vs. lug-centric, and bolt pattern
- Load/brake system rating: whether it's rated for standard or heavy-duty/towing packages, which changes rotor spec on the same base vehicle
Here's what a raw supplier feed typically hands a distributor versus what a buyer actually needs:
| Raw feed description | Enriched attribute |
|---|---|
| "Rotor, front, 12.6 disc" | Fits: 2019-2023 model-year full-size pickup, 2WD and 4WD, standard-duty package |
| (fitment buried in a separate CSV, not linked) | Position: Front, left or right (symmetric) |
| no diameter units, no thickness | Diameter: 12.6 in / Minimum thickness: 1.10 in |
| no hub note | Hub type: Hub-centric, 6-lug pattern |
| no load note | Not for: heavy-duty towing package (requires larger rotor, see SKU xxxx-HD) |
The left column is what a lot of catalogs still show at checkout. The right column is what actually prevents the return.
Ask an answer engine
Increasingly, the buyer isn't typing that query into your search bar at all. They're asking an AI shopping assistant something like "front brake rotor for a 2021 half-ton 4x4 pickup, standard duty, not the tow package" and expecting a direct answer, not a list of ten SKUs to click through. If your fitment attributes are locked in a PDF spec sheet, a flat filename, or a fitment table that never made it past internal ops, that answer engine has nothing structured to read — and it will surface a competitor's page that does.
A distributor's checklist
- Confirm every SKU has a fitment record, not just a category assignment
- Check fitment down to the qualifier level: 2WD/4WD, drive position, duty package, not just year/make/model
- Standardize units and terminology (diameter, thickness, thread, bolt pattern) so "12.6 disc" and "12.6 in rotor" don't read as different products
- Flag SKUs where fitment data is present but not surfaced on the live product page
- Reconcile supersessions — a rotor that replaced a discontinued part number needs the fitment record to carry over, not restart from zero
- Score confidence per attribute so buyers (and support reps) know what's verified versus inferred
Where Anglera fits
None of this requires replacing the PIM or fitment tool a distributor already runs — Anglera works with what's already there, plugging into any PIM or a flat file to continuously score, gap-fill, and enrich the attributes that ACES and PIES data alone don't guarantee make it onto the page. Values are pulled and quality-scored from supplier and source documentation, not invented, and a catalog can go from raw feed to buyer-ready in weeks rather than a multi-year systems project. The fitment standard was never the gap — what happens to that data between the file and the page is.
