ACES vs PIES Two standards, one catalog: which file answers which question.

A retailer or a marketplace asks for "your ACES and PIES", and it sounds like one deliverable. It is two files, built to two different standards, and each answers a question the other cannot. Knowing which is which tells you what a receiver is really asking for, and why one clean file can still leave a listing half empty.

One answers fit, the other answers what

The Aftermarket Catalog Exchange Standard (ACES) is the Auto Care Association's industry standard for managing and communicating product fitment data: which vehicles a part fits [1]. The Product Information Exchange Standard (PIES) is its counterpart for product information: what the part is, and how it is described, priced and packaged [2].

Both are exchanged as XML, a format written for software to read rather than people [3]. Both are used across the supply chain, by manufacturers, distributors, retailers, ecommerce companies and data solution providers [1]. Auto Care supports only the current and the previous version of each: today that is ACES 5.0 and 4.2, and PIES 8.0 and 7.2 [1] [2]. The two current versions were released together in April 2026 [3].

Neither standard spells much out in words. Each record points at coded entries in reference databases that Auto Care maintains, and using either standard takes an annual paid subscription to those databases [1] [2].

Inside an ACES file

A fitment file is a list of applications. Each application ties one part number to one vehicle, or to a narrower slice of that vehicle. Auto Care requires four elements in every application: a base vehicle (a year, make and model), a part type, a quantity and a part number [9]. Anything more is there only to narrow the claim to the vehicles the part really fits. The optional vehicle attributes come in groups: vehicle, engine, transmission, drive, brake, spring, steering, wheel, bed, body and manufacturer body code [9].

The vehicle codes come from the Vehicle Configuration Database (VCdb) [4]. Part type and position codes come from the Product Classification Database (PCdb) [5]. Conditions that no vehicle attribute covers come from the Qualifier Database (Qdb), which replaces free-form notes with consistent, coded expressions [7].

<App action="A" id="1">
  <BaseVehicle id="…"/>   year + make + model, from the VCdb
  <Qty>1</Qty>             how many the vehicle uses
  <PartType id="…"/>      what the part is, from the PCdb
  <Part>EX-2040</Part>     the part number
</App>

By mapping only the minimum, the cataloger is stating one of two things: none of the other attributes matter to this part, or the part fits every configuration of that base vehicle. If neither is true, the record is inaccurate.

Inside a PIES file

A product file is a list of items, one for each part number. In PIES 8.0 every item must carry a part number, a Brand ID, a part type and a flag that says whether the part has ACES applications [10]. Around that core, the standard has room for the rest of what a seller needs to know about a product [2]:

• Descriptions, from short names to marketing copy and features and benefits.
• Pricing and warranty information.
• Attributes, the specifications of the product, such as material, finish or outside diameter, coded against the Product Attribute Database (PAdb) [6].
• Packaging, which in PIES 8.0 includes data for Extended Producer Responsibility (EPR) packaging rules [3].
• Kits, interchanges and hazardous materials information.
• Digital assets, such as the images and documents that go with the part.

An item can also carry a Global Trade Item Number (GTIN) [10], the GS1 number a company uses to uniquely identify a trade item [12].

<Item MaintenanceType="A">
  <PartNumber>EX-2040</PartNumber>
  <BrandID>…</BrandID>                       from the Brand Table
  <ACESApplications>Y</ACESApplications>     this part has fitment
  <PartTerminologyID>…</PartTerminologyID>   what the part is, from the PCdb
  <Descriptions>
    <Description MaintenanceType="A" DescriptionCode="SHO"
      LanguageCode="EN">Front Brake Pad Set</Description>
  </Descriptions>
</Item>

Notice what is missing: there is no vehicle anywhere in the item. PIES describes a product whether or not it fits a vehicle, and the PCdb classifies products that are not vehicle specific as well as those that are [5]. A shop towel or a bottle of fluid has a full item record and no applications. That is correct, not a gap.

ACES and PIES side by side

Where the two files connect

The two are separate documents, and nothing inside one points at the other. They are joined only by what they share: the brand and the part number. PIES states a Brand ID on every item [10]. A fitment file must name the brand too, either once in the header or on every application, never both [9]. Both draw the code from the same Brand Table [8].

Part type is the third thing they share, with one difference worth knowing. PIES names a single part type for the item, while ACES names a part type on every application [9] [10]. No rule says the two must match. One bulb can be a headlight bulb on one application and a fog light bulb on another [11], while its item carries a single part type.

Walmart Marketplace shows how a receiver uses the pair. It accepts ACES XML for vehicle compatibility and PIES XML for other supported product information, and it cautions that not all PIES data maps into its catalog [11]. It matches compatibility records to items mainly on brand and manufacturer part number, and asks that both match the product information exactly [11].

If a receiver wants both, a sensible order is the item first and the vehicles second: PIES establishes the part number, brand and part type, and the applications attach to it. A brand whose products fit no particular vehicle may only ever need the first of the two.

When the pair falls out of step

Each file can pass every check on its own while the pair still fails. The usual gaps are cataloging faults, not faults in the standards:

• A part number with applications and no matching item, or one written with a hyphen in one place and without it in the other. The vehicles have no product to attach to.
• An item flagged as having applications when the fitment file holds none for it. The product is listed and no vehicle search can find it.
• A file in the version the receiver asked for that still carries something its system cannot read. ACES 4.0 added the engine block and the bore and stroke as ways to map an engine [9]. Some receivers ask for a 4.0 or later file and still need the older engine base. Meeting that is the cataloger's job, not the receiver's.

The cost shows up where shoppers are. Walmart says vehicle compatibility data helps customers confirm that a part fits and minimizes returns, and that a listing needs it to appear in the fitment tool on its site [11]. Auto Care counts reduced returns and faster speed to market among the benefits of the standards [1]. A product missing either half gives part of that up: it is found by vehicle and poorly described, or well described and never found by vehicle.

Auto Care's Catalog Assessment tool, free to its data standards subscribers, reports on both kinds of file [13]. It is a useful second opinion before a first submission.

What to look for in software that handles both

Whether the catalog lives in software, in spreadsheets or with a service provider, these questions show whether fitment and product data are managed as one catalog or as two jobs:

1. Are fitment and product information kept together, keyed on the same brand and part number, or in two places that someone has to reconcile?
2. Before anything is exported, does it list part numbers that appear on one side and not the other, and items flagged for applications that have none?
3. Can you see the part type on each item beside the part types on its applications, so that a difference is a choice and not an accident?
4. Are both exports checked against current reference databases and against the schema for the version each receiver asked for?
5. Can it export the versions your receivers still read, not only the newest, and shape each export to what that receiver's system can take, such as an engine base where it cannot read an engine block?
6. Can it take in what suppliers really send, XML, spreadsheets and delimited text, for both standards, and report what did not map rather than guess?
7. Does it treat a part with no vehicle fitment as normal, instead of marking it incomplete?