ACES Notes vs Attributes When the note and the fitment disagree.

An application that maps a truck with no engine, then adds the note "diesel engine only", says two things at once. Its coded data says the part fits every version of that truck; its note says it fits only one. Every system that reads the coded data believes the first statement, and the shopper who trusted it ends up with a part that does not fit.

What an application really claims

In the Aftermarket Catalog Exchange Standard (ACES), each application record states which vehicles a part fits [1]. Auto Care requires four elements in every application: a base vehicle (year, make and model), a part type, a quantity and a part number [14]. Anything mapped beyond those four is there to qualify the part, so that the record claims exactly the vehicles the part fits.

The Vehicle Configuration Database (VCdb) is built to describe a vehicle "with as much or as little detail as necessary" [2]. A floor mat may need only the base vehicle; an intake part may need the exact engine. The flip side matters just as much: every attribute a record leaves unmapped is a claim that the part fits every value of it. A record with no engine says the part fits every engine offered on that vehicle. A record with no submodel, fuel type, engine code, body type or number of doors claims all of them too.

Take a 2015 Chevrolet Silverado 2500 HD. In the VCdb, that one base vehicle is offered with 6.0L and 6.6L engines running on gasoline, flex fuel, compressed natural gas (CNG) and diesel [2]. A diesel-only part mapped to the base vehicle alone claims to fit the gasoline, flex-fuel and CNG trucks as well, along with every submodel and body of each.

A note that contradicts the fitment

Writing the limit in a note does not change that claim. It is a common shortcut and directly against Auto Care best practice: when the VCdb can describe a detail, such as the engine, fuel type, drive type or body, it belongs in its coded field, not in a note or a manufacturer label. A note is free text. Auto Care's Qualifier Database (Qdb) exists to replace free-text notes with coded qualifiers, because free text invites inaccurate interpretation and cannot be validated in scalable ways [3].

The industry calls the result a conflict: a record that disagrees with itself. The coded data says "fits this whole base vehicle"; the note says "only fits diesel". Notes also drift from the standard's own vocabulary. A note reading "2WD" may sit on a configuration the VCdb offers only as 4WD, and the VCdb has no "2WD" value at all; it calls that drive type RWD. Software that matches vehicles reads the coded data. eBay, for example, matches compatibility on year, make, model, trim and engine, and keeps notes in a separate free-text field for details such as placement [6]. The note travels with the listing, and so do the vehicles it was meant to exclude.

✗ Wrong - the limit written as a note. Against Auto Care
  best practice: the coded data claims every engine and fuel
  type on the vehicle, while the note says diesel only.
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <Note>Diesel engine only</Note>
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-2002</Part>
</App>

✓ Right - one application per diesel engine
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <EngineBase id="…"/>      first diesel engine
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-2002</Part>
</App>
<App action="A" id="2">
  <BaseVehicle id="…"/>
  <EngineBase id="…"/>      second diesel engine
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-2002</Part>
</App>

✓ Also right - one application, fuel type only
<App action="A" id="1">
  <BaseVehicle id="…"/>
  <FuelType id="…"/>        diesel
  <Qty>1</Qty>
  <PartType id="…"/>
  <Part>EX-2002</Part>
</App>

When a note is the right place

Notes are not banned. There are two cases where a note is the accepted way to qualify an application:

1. The VCdb has no field for the detail. Gear ratio, driveshaft diameter or length, number of teeth, and with or without air conditioning are not VCdb attributes. When one of them is needed to qualify the part unambiguously, it has to be stated another way. Auto Care keeps coded qualifiers for details no vehicle attribute covers in the Qdb [3], so a coded qualifier comes first where one exists, and a note covers what is left.
2. The VCdb has the field, but only "unknown" for that vehicle. Some configurations carry a value such as "U/K" (unknown) or "N/A" instead of a real one. A 2018 Toyota Hilux was offered with both rear-wheel and four-wheel drive, yet its VCdb drive type is "U/K" [2]. A 4WD-only part cannot be limited with a drive type that does not exist for that vehicle, so a "4WD" note is the correct way to say it.

In both cases the note does a job the coded data cannot. That is the test: if the VCdb can carry the detail, map it; if it cannot, say it in a qualifier or a note.

How the conflict creeps in

Records like this are rarely careless. They usually come from one of three places.

A note doing an attribute's job. Typing "diesel only" is faster than finding the right engine or fuel type, and it reads correctly to a person. It does not read correctly to the systems that build listings.

Source data with less detail than the standard. Supplier spreadsheets and legacy catalogs often list fitment by year, make and model, with any limits in a comments column. Converting the comments into notes, instead of into coded attributes, produces exactly this conflict.

Two fitments with no reason given. Auto Care's list of common catalog mistakes includes fitment logic problems: when the same vehicle appears under two fitments, such as front-wheel and all-wheel drive, the reason for the difference has to be specified [4], and specified in coded data, not in words.

The price of a wrong fit

Amazon's guide to providing ACES data asks sellers to make sure they are accurately mapping products to vehicles [7]. The same guide explains that Amazon treats every ACES feed as an update and needs explicit delete records to remove incorrect fitment [7], so a vehicle that was claimed by mistake can stay on a listing after the file has been corrected.

eBay tells sellers to be accurate when adding compatible vehicles, to avoid returns [5]. Listings with year, make, model, trim and engine compatibility can show buyers a fit check for their vehicle under eBay Guaranteed Fit. If the part does not fit, the buyer can return it with the reason "Doesn't fit my vehicle", and eBay pays the return shipping [8]. The label is covered; the sale is still lost. Since July 15, 2025, most new fixed-price parts and accessories listings over $10 in the US must also offer free returns for at least 30 days [9].

Walmart Marketplace says accurate vehicle compatibility data minimizes returns, asks for the most complete configuration data available, and treats a seller's fitment entries as the seller's affirmation that the information is accurate [10] [11].

Returns are expensive across retail. The National Retail Federation estimated that consumers would return 15.8% of annual retail sales in 2025, and 19.3% of online sales [12]. A return caused by a wrong fit is one that accurate data could have prevented. The Federal Trade Commission's guidance for online sellers also starts from a plain rule: sellers are responsible for the claims they make about their products [13], and a fitment record is a claim.

What accurate fitment looks like

The goal is a record that claims exactly the vehicles the part fits, in coded data every receiver can read.

• Required elements, then only what qualifies the part. Base vehicle, part type, quantity and part number are required [14]. Everything mapped beyond them should qualify the part unambiguously: everything the fit depends on, and nothing it does not.
• Attributes first. Engine, fuel type, drive type, body, submodel and the other vehicle attributes narrow a record. Auto Care keeps qualifiers that are not covered by a vehicle attribute in the Qdb [3], which gives a clear order: attribute, then qualifier.
• Notes carry a limit only when the VCdb cannot. A detail the VCdb can describe belongs in its attribute; written in a note instead, it conflicts with the mapped data rather than narrowing it.
• Known values, not "unknown". Amazon ignores ACES applications that carry "unknown" attribute values [7]; a record that cannot say what it fits does not help anyone.
• No fitment where none belongs. Universal parts, fluids and tools have no vehicle fitment, and that is correct, not a gap to fill.

Questions to ask of any solution

This kind of record hides well: the file passes validation and the listing looks rich. These questions show whether a tool or service can find it:

1. Does it flag notes and manufacturer labels that name an engine, fuel type, drive, body or transmission the VCdb could carry, so a limit written in words can become a coded attribute, while leaving notes the VCdb cannot replace alone?
2. Can it show how many vehicle configurations a single record really claims once it is expanded?
3. When fitment is researched or imported, is each vehicle backed by evidence you can see, or is coverage added to look complete?
4. Can you see what a marketplace listing actually carries after it is sent, not just what you meant to send?
5. When a vehicle is removed, are the delete records that channels such as Amazon require produced automatically?
6. Does it treat products with no vehicle fitment as normal, rather than pushing you to map them?