ACES and PIES Explained: Fitment, Product Data and the Version Trap

ACES and PIES are the two data standards that move automotive aftermarket catalogues between suppliers and their trading partners. The difference between them takes one sentence: ACES says which vehicles a part fits, PIES says what the part is. Everything else about them, the reference databases, the version politics, the validation failures, follows from that split.

Both are XML standards owned by the Auto Care Association and both are specific to the automotive aftermarket in North America. If you sell brake pads, filters, sensors or trim into US or Canadian retailers and marketplaces, someone will eventually send you a spreadsheet and then ask why you cannot just send an ACES file instead. This is what they are asking for.

What ACES and PIES stand for

ACES is the Aftermarket Catalog Exchange Standard. The Auto Care Association describes it as the industry standard for the management and communication of product fitment data, covering light, medium and heavy duty vehicles, powersports and off-highway equipment. A single ACES record is an application: this part, in this quantity, at this position, on this vehicle, under these conditions.

PIES is the Product Information Exchange Standard. It carries features and benefits, marketing descriptions, pricing, warranty, product specifications, hazardous materials data, kit composition, interchanges and digital assets. A PIES record is an item, and it is where the GTIN, the part number, the dimensions and the images live.

The two files join on part number plus a four-character brand code, the BrandAAIAID, taken from the Auto Care Brand Table. A PIES item carries an ACESApplications flag set to Y to declare that fitment for it exists in a matching ACES file. Auto Care's own quality criteria require that all part numbers in an ACES file appear in a matching PIES file, which tells you how the pair is meant to be used: never one without the other.

Ownership sits with the Auto Care Association, governed through its Technology Standards Committee, with industry workgroups doing the detailed work. The association was previously the Automotive Aftermarket Industry Association, which is why the brand identifier is still called an AAIA ID in nearly every receiver document you will read.

Current versions are ACES 5.0 and PIES 8.0. Both were published on 2 April 2025 for a one-year industry review and became official on 26 March 2026, with the formal release announcement following on 2 April 2026. ACES 5.0 added vehicle-specific and part-specific non-diagram digital assets in the application segment, multiple descriptions for a single digital asset, and expanded multilingual handling for the MfrLabel field. PIES 8.0 added Extended Producer Responsibility packaging data, multiple package configurations at a single pack level, and digital asset file hashing with record sequencing.

The reference databases you cannot avoid

This is the part that surprises people. ACES and PIES files contain almost no readable text. They contain integers that point into five separate reference databases, all maintained by Auto Care and all accessed through the Auto Care Vehicle Information Portal. Without a current subscription to the right ones, you cannot produce a valid file at all.

• VCdb, the Vehicle Configuration database. Over 175,500 vehicle applications, over 2,400,000 vehicle system configurations and over 16,500 off-highway vehicle and equipment records. This is the fitment target for ACES.
• PCdb, the Product Classification database. Over 40,000 part terminologies, plus the positions a part can occupy on a vehicle.
• PAdb, the Product Attribute database. Over 9,700 part attributes and over 141,700 attribute associations, assigned per PCdb part terminology. This is the PIES subscription.
• Qdb, the Qualifier database. Over 26,000 coded fitment qualifiers that replace free-text notes.
• Brand Table. Over 28,000 parent companies, brands and sub-brands as four-character codes, updated daily.

ACES needs VCdb, Qdb, PCdb and the Brand Table. PIES needs PAdb, which includes PCdb and the Brand Table. Manual downloads are monthly; a JSON API added in early 2025 allows daily pulls of complete tables or changes only. Keeping five reference datasets current against a live catalogue is the reason standards mapping software exists in this market at all.

Geographic scope matters here and it is frequently misread. VCdb covers the USA, Canada, Mexico and Latin America, with recent expansion into Colombia, Chile, Brazil, Argentina, Ecuador, Peru and Costa Rica. It does not describe the European vehicle parc. More on that below.

Inside an ACES file

An ACES file is a header, a body of application records, and a footer. The header carries the sender's details, the brand code, the submission type, and three fields that turn out to matter more than anything else in the file: VcdbVersionDate, QdbVersionDate and PcdbVersionDate. The vintage of the reference data you mapped against is declared inside the file, and a receiver running last quarter's VCdb can and will reject IDs that only exist in this month's.

What identifies a vehicle

The anchor is BaseVehicle id, a pointer into the VCdb BaseVehicle table, which resolves a year, make and model combination. For off-highway and equipment applications the anchor is EquipmentBaseID instead.

A base vehicle is then narrowed using any of the VCdb configuration attributes, of which there are 43. They include submodel, body type and number of doors, drive type, engine base, engine designation, engine VIN, aspiration, fuel type and delivery, transmission base and number of speeds, bed length, wheelbase, brake system, front and rear brake type, ABS, spring types, steering, and region. Every attribute you use must be a valid combination for that base vehicle, and receivers check.

What identifies a part

PartType id points at a PCdb PartTerminologyID, the standardised name for the kind of part. Position id points at a PCdb position, front or rear, left or right, upper or lower, and the part type and position combination must itself be valid. The part number goes in Part, and the brand comes from the file header unless overridden on the part element itself.

What a qualifier does

A qualifier replaces a free-text fitment note with a code. Auto Care's own illustration is the best one: "With Air Conditioning", "w/ Air Conditioning", "w/ A.C.", "w/Air Conditioning" and "With Air Cond." all map to Qdb qualifier 2341. Qualifiers can be combined into compound expressions and can contain placeholders for variable data, which is why 26,000 qualifier records can cover an industry's worth of notes.

Receivers police the boundary between qualifiers and notes hard. Advance Auto Parts forbids VCdb attributes in the Note tag, forbids PCdb position IDs in the Note tag, and rejects duplicate notes on a single application. If the information is codeable, code it.

A worked application record

Reading one of Auto Care's own published examples in English: add an application, sender's internal reference 12646047, for VCdb base vehicle 1120, only where that vehicle has air conditioning (Qdb qualifier 2341), quantity one, part type 6832 which is the PCdb terminology for a cabin air filter, at PCdb position 6133, with the manufacturer's own label "Particulate", part number 3338.

Six integers and two strings. That is a complete, valid fitment statement, and it is also completely unreadable without the reference databases open beside it. The minimum viable record in practice is a vehicle anchor, a part type, a quantity, a part number and a brand code.

Inside a PIES file

PIES is a header, a set of item records with child segments, and a trailer. The segments, in document order: Header, Price Sheet, Item, Description, Pricing, Extended Product Information, Product Attribute, Package, Hazardous Material, Interchange, Digital Assets, Trailer. Auto Care's own training material also names Item Market Copy and Kits.

The Item segment is where the identifiers sit. A real item carries a hazardous material code, an ItemLevelGTIN with a qualifier declaring which GTIN type it is, the part number, the brand code, a brand label, the ACESApplications flag, an item quantity and unit of measure, effective and available dates, and the PCdb PartTerminologyID. If you have read how GTINs, UPCs and MPNs actually differ, the GTIN qualifier will make sense immediately; if not, it is the field that tells the receiver whether the 13 digits you sent are a UPC padded to 13 or a genuine EAN-13.

Descriptions are coded rather than free-form, with a type code, a language code and a sequence number: ABR for abbreviated, SHO for short, DES for description, FAB for feature and benefit. Generating four description lengths per item across a large catalogue is one of the few parts of PIES that automated content generation handles well, because the source specification is already structured. Product attributes are PAdb-coded, not free text. Packages carry a GTIN per packaging level along with dimensions and weights.

One caveat worth stating plainly, because a lot of published guidance blurs it. The field-level mandatory and optional designations in the standards themselves sit behind an Auto Care login, and the reference databases behind a paid subscription. Every "required field" list you will find publicly, including the ones in this article, comes from a specific receiver's manual rather than from the specification. Advance Auto Parts and Walmart publish theirs; treat those as that receiver's requirements, not as the standard's.

Who actually asks for ACES and PIES

Three receivers publish their requirements openly, and the differences between them are instructive.

• Walmart Marketplace. Feed types FITMENT_ACES and FITMENT_PIES, submitted zipped through the Bulk Item Update API, 50 MB maximum, one file type per submission. XLSX is accepted as a fallback. Walmart runs gap reports against ACES coverage and against missing fitment attributes. Its published version requirement is simply "the current fitment file specification".
• Amazon. Its own published document accepts ACES 3.2 XML, plain or gzipped, up to 1 GB uncompressed, validated against aces3_1.xsd. Application records with a Region other than 1 are ignored, so US only. All ACES feeds are treated as updates rather than replacements. Processing takes up to a week for existing products and three weeks for new ones. PIES is explicitly refused on that channel.
• Advance Auto Parts. Accepts ACES 2.0, 3.0, 3.1 and 3.2, full replacement files only, by SFTP with a fixed filename convention. Its PIES manual specifies PIES 7.1.2.

Beyond those three, be careful. eBay is very widely described as requiring ACES, but eBay's own developer and seller documentation does not mention ACES or the Auto Care Association anywhere; it describes its own compatibility structure, which third parties convert ACES into. AutoZone, O'Reilly, NAPA, Epicor, OptiCat, Turn 14, Keystone, PartsTech and RockAuto are all routinely listed as ACES and PIES receivers by vendors, and their requirement documents sit behind supplier portals. Ask each one directly rather than trusting a list.

What ACES and PIES cost

Two separate questions with two different answers. The standards are free: a no-charge Auto Care account gets you the technical documentation, coded values, XSD schema and best practices. The reference databases are a paid annual subscription, and you cannot produce a valid file without them.

Pricing is tiered across 14 levels by company global revenue, with member and non-member rates. At the time of writing, the VCdb packages run from $3,150 to $8,625 a year for members and $4,410 to $12,075 for non-members, per vehicle segment. PAdb, the PIES subscription, runs from $1,050 to $7,763 for members. There is an ACES and PIES Entry Level Package at $2,500 that bundles all five databases, but it is member-only and capped at under $1M global revenue.

So a supplier doing both standards for US and Canadian light duty needs one VCdb package plus PAdb, which at the lowest tier is about $4,200 a year as a member. Add another VCdb package for each extra vehicle segment: heavy duty, off-highway, Latin America. Those are the only verifiable cost figures in this area. Anyone quoting you a total cost or a timeline to become ACES compliant is estimating, because Auto Care publishes neither.

The version problem nobody warns you about

Line up four published facts and the picture is uncomfortable. Auto Care supports only the current and previous versions, which today means ACES 5.0 or 4.2 and PIES 8.0 or 7.2. Amazon's published document asks for ACES 3.2. Advance Auto Parts accepts up to 3.2 and requires PIES 7.1.2. Auto Care's own 2026 award criteria ask for ACES 4.2 and PIES 7.1 or 7.2. Walmart does not state a version at all.

A supplier on the current standard is therefore being asked, simultaneously, for a version the standards body no longer supports, a version two generations back, and an unstated version. This is not a hypothetical; it is documented on the receivers' own pages. The practical consequence is that "are you on ACES 5.0?" is the wrong question. The right question is which version each receiver wants this quarter, and the right architecture is one internal model with several output versions generated from it. That is the same pattern standards mapping tools use for ETIM and eCl@ss releases, and it applies here unchanged.

There is a second, quieter version axis. Because every file declares the vintage of the reference data it was mapped against, and VCdb publishes monthly, sender and receiver drift apart by default. Auto Care processed over 40,000 change requests in a single monthly VCdb publication in February 2022. Pin your reference data vintage per receiver, and record which vintage each export used.

Why ACES and PIES files fail validation

Auto Care's own published list of top mistakes runs: outdated versions, overlapping product data, inconsistent data entry across a cataloguing team, insufficient use of qualifiers, fitment logic problems such as failing to mark a part as universal, and asset references pointing at files that are missing.

Walmart's published rejection causes are more specific. An ACES file is rejected for a missing part type ID, base vehicle ID or part number, or invalid vehicle information. A PIES file is rejected for a missing item-level GTIN, brand AAIA ID, part number or part terminology ID. And then there is the failure that catches everyone, because the file validates and ingests and still produces no fitment: the part terminology ID, AAIA brand ID and manufacturer part number must match exactly between the two files, including spaces and punctuation. One trailing space in a part number and the join silently produces nothing.

The open-source ACESinspector validator, whose changelog names Auto Care staff as contributors, catches a wider set of structural problems that are worth knowing as a checklist: duplicate applications; overlaps where different part numbers claim the same base vehicle; comment-no-comment overlaps where two applications differ only by a note; invalid base vehicle codes; orphaned engine base IDs that were deleted from a later VCdb; qualifier parameter count mismatches; quantity outliers per part type and position; blank or questionable notes; and attribute consistency within a group, meaning that if engine base is used on one application in a group it must be used across the whole group. That last rule is a genuine trap, because partial use of an attribute reads to a receiver as a coverage gap.

You will also see widely circulated statistics about aftermarket file quality: that 5 to 10 per cent of vendor files are schema invalid, that around 40 per cent show overlapping applications, that a fifth are missing primary images. Those numbers come from a single vendor blog with no stated methodology. Do not build a business case on them.

What good looks like, according to Auto Care

There is no ACES or PIES certification. What exists is a Catalog Assessment Tool inside Auto Care VIP, and an annual Content Excellence Award run by the Automotive Content Professionals Network with published weightings. Those weightings are the most concrete public definition of good aftermarket data anywhere, so they make a usable internal quality bar:

• ACES side. Header completion 1 per cent. Valid configurations 10 per cent, where anything over 1 per cent invalid VCdb coding scores zero. No overlaps or duplicates 20 per cent, where anything over 1 per cent scores zero. Qdb usage 10 per cent. Valid part terminology 3 per cent. PIES cross-reference 3 per cent.
• PIES side. Header 1 per cent, Item 7 per cent, Extended Product Information 8 per cent, Attributes 12 per cent, Marketing and Description 10 per cent, Digital Assets 10 per cent, Packaging 5 per cent.

Those weightings also make a reasonable specification for a product data quality check run before every export rather than after every rejection. The two hard gates are the ones with the cliff edges: under 1 per cent invalid configurations and under 1 per cent overlaps. On a catalogue with tens of thousands of applications, that is a demanding target and it is where most of the remediation effort goes.

ACES and PIES outside North America

They do not travel. VCdb describes the North and South American vehicle parc, so an ACES file cannot express fitment for a European vehicle. The European equivalent is TecDoc, from TecAlliance, and it shares no machinery with ACES at all. The TecDoc Data Format is delivered as fixed-length records or semicolon-delimited CSV rather than XML, and vehicles are identified by KTypNo for passenger cars and light commercials and NTypNo for commercial vehicles, not by base vehicle ID. The TecDoc specification does not mention ACES, PIES or the Auto Care Association, and no published crosswalk between them exists. Commercial TecDoc-to-ACES converters are sold, which is itself evidence that the conversion is a bespoke commercial problem rather than a standards-body mapping.

For a distributor trading on both sides of the Atlantic that means two fitment systems, two vehicle identity schemes and two file formats against one product catalogue. The only sane way to run it is to hold the product and fitment data once in a neutral internal model and generate each output from that, which is what a fitment data layer is for.

It is also worth being clear about what ACES and PIES are not related to. There is no published mapping between PCdb part terminologies and UNSPSC commodity codes, and none between ACES and ETIM either. ETIM does roughly what PCdb and PAdb do together, classify a product and give it typed attributes, but it has no vehicle fitment model at all, which is the entire point of ACES. If you need both, you maintain both.

Key takeaways

• ACES carries fitment, PIES carries product information, and they join on part number plus the four-character AAIA brand code. Send both or neither.
• Both are XML. The JSON that Auto Care launched applies to the reference databases and the API, not to the exchange files.
• The files are mostly integers pointing into VCdb, PCdb, PAdb, Qdb and the Brand Table. Those subscriptions are the real cost of entry, roughly $4,200 a year at the lowest member tier for both standards.
• Every receiver wants a different version, and several want versions Auto Care no longer supports. Build one internal model and generate multiple outputs.
• The reference data vintage is declared inside the file. Pin it per receiver and record what each export used.
• The failure that wastes the most time is not a schema error, it is a part number, brand code or part terminology ID that does not match exactly between the ACES and PIES files.
• Under 1 per cent invalid configurations and under 1 per cent overlaps is Auto Care's own quality bar. Use it as yours.
• ACES and PIES stop at the Americas. Europe runs TecDoc, with no official mapping between them.