ACES File Rejections Why receivers send your fitment file back.

You send a fitment file to a retailer or a marketplace and get back an error report, a short note that the file "failed validation", or nothing at all, and the vehicles never show up on the listing. Most rejections come from a handful of causes, and almost all of them can be caught before the file leaves your hands.

How a receiver checks a file

The Aftermarket Catalog Exchange Standard (ACES) is the Auto Care Association's standard for exchanging product fitment data: which parts fit which vehicles [1]. An ACES file is XML, and Auto Care publishes the technical specification, code values and an XML schema (XSD) that define what a valid file looks like [1]. The companies that take these files in, such as retailers, distributors, electronic catalog providers and marketplaces, are called receivers.

A receiver's checks run in layers, and a file can fail at any of them:

• Is it readable XML? The XML standard treats broken structure (an unclosed tag, a bad character) as a fatal error, after which normal processing must stop [13]. One bad character can stop the whole file.
• Does it match the schema? Elements must be the ones the ACES version allows, in the order it allows, with the values it allows.
• Does every record carry the required elements? Auto Care requires four in every application: a base vehicle, a part type, a quantity and a part number [14]. Everything else in a record is there to qualify the part. A record missing one of the four fails [10].
• Does every record point at something real? Each application (an "App" record) refers to codes from Auto Care's reference databases rather than spelling vehicles and parts out in words [3]. If a code does not exist, or the combination is not a real vehicle, that record fails.

<App action="A" id="1">
  <BaseVehicle id="…"/>   year + make + model, from the VCdb
  <EngineBase id="…"/>    the engine it fits, from the VCdb
  <Qty>1</Qty>
  <PartType id="…"/>      what the part is, from the PCdb
  <Position id="…"/>      where it goes, from the PCdb
  <Part>EX-1001</Part>
</App>

Those codes come from the Vehicle Configuration Database (VCdb) for vehicles, the Product Classification Database (PCdb) for part types and positions, and the Qualifier Database (Qdb) for coded conditions [3]. Every record is only as valid as the codes inside it.

The usual reasons records fail

An old version of the standard. Auto Care supports only the current and previous versions of ACES; today that is ACES 5.0 and ACES 4.2 [1]. ACES 5.0 and PIES 8.0 were released in April 2026 [2]. Auto Care's own list of common mistakes starts with files built on outdated versions [6]. A receiver that has moved on may not accept a file built to a version it no longer reads.

Codes that have gone out of date. The reference databases are not fixed. Auto Care publishes VCdb, PCdb and Qdb updates monthly as downloads and daily through its API [4], and its release notes announce deletions and replacements of existing codes [9]. A file built against last year's databases can carry codes that no longer exist.

Vehicle details that do not belong together. A submodel or engine that was never offered on that year, make and model is an invalid vehicle. Walmart Marketplace, for example, lists invalid vehicle information (id, year, make, model, submodel or engine) among the reasons it rejects ACES records, along with a missing part type, base vehicle or part number [10].

Identifiers that do not match exactly. A receiver can only attach fitment to a product it can find. Walmart, for example, matches fitment to its catalog mainly on brand and manufacturer part number [15], so a part number written one way in the file and another way in the item setup leaves the fitment with nowhere to go. The brand code in the file comes from Auto Care's Brand Table, the aftermarket's brand identification database [5]. An inactive or mistyped brand code breaks the link between the file and the products.

Overlaps and thin qualifiers. When two different part numbers claim the same vehicle, part type and position with nothing to tell them apart, a receiver cannot tell a buyer which one to pick. Auto Care names overlapping data and too few qualifiers as common mistakes [6].

Missing assets. A file that references images or diagrams the receiver never gets is another mistake on Auto Care's list [6].

What a rejection really costs

A whole-file rejection is the obvious cost: the file comes back, someone has to find the cause, and the products wait. The quieter cost is a partial rejection, where the file is accepted and some records are not.

eBay's developer documentation describes exactly that behavior for vehicle compatibility: as long as at least one compatibility row is valid, the listing goes up with the valid rows, and the invalid ones are reported as errors and left out [11]. Nothing looks broken on the listing. The vehicles are simply missing, and so are the buyers who search for them.

Missing fitment also costs sales on Amazon. Amazon's automotive style guide explains that shoppers use its Part Finder to check fit, that an item with no fitment data cannot be checked, and that Part Finder reduces returned or cancelled orders [12].

• Products that sit unlisted while a file is fixed and resent
• Vehicles silently dropped from listings that look complete
• Staff time spent reading error reports instead of building coverage
• A receiver's growing doubt about every file that follows

What a clean file looks like

A file that clears a receiver's checks has a few things in common:

• Built to a supported version, and to the version the receiver asked for.
• Built against current reference databases. Auto Care's Data Standards API, opened to the industry in January 2025, delivers the VCdb, PCdb, Qdb and other reference databases directly to software [8], so a catalog can stay current without waiting for a manual download.
• Every record resolves to a real vehicle configuration and a real part type, and any position given is valid for that part type.
• Coded qualifiers instead of free text. The Qdb exists to replace free-text qualifier expressions with coded ones [3].
• No unexplained overlaps between part numbers, and every referenced asset delivered.

Auto Care also offers its subscribers a free Catalog Data Assessment tool designed to identify discrepancies in ACES and PIES files [7]. A second check before a first submission is cheap insurance.

What to look for in a solution

Whether the work happens in software, a spreadsheet or a service bureau, these questions separate a process that prevents rejections from one that reacts to them:

1. Is every record checked against the current VCdb, PCdb and Qdb before export, not after a receiver complains?
2. When a record is invalid, does it say why, at the level of that one record, in words a catalog manager can act on? A count of errors is not a diagnosis.
3. How do the reference databases stay current? Is the API used, or does someone remember to download them?
4. Are overlaps and duplicates found across part numbers, with the cause shown?
5. Is the exported file checked against the ACES schema for the version the receiver requested?
6. Is anything ever dropped or changed silently? Every record that does not make it into a file should be listed with a reason.
7. Can it read fitment from the formats your suppliers actually send, and report what did not map rather than guess?