ACES and PIES Data: AI Cleans and Checks Your Parts Catalogue

An auto parts seller can clean and check ACES and PIES data with AI by exporting both files to spreadsheets, asking AI to help write checks for mismatched part numbers, wrong codes and missing fields, then sampling records against source data. AI finds suspicious rows; a person confirms fitment and product facts from the manufacturer's information.

ACES covers fitment, PIES covers product information, and many rejected listings come from the two disagreeing with each other or with the reference databases. That makes the job a comparison task, which is what AI and a spreadsheet are good at. Deciding that a part really fits a vehicle is not a comparison task, and no model should be trusted with it.

Follow me on Instagram@sagnikteaches

What the two standards cover, in plain terms

Both standards come from the Auto Care Association, and both are exchanged as structured files in XML format. The association publishes the documentation (free to read once you sign in to its Digital Hub) and the reference databases (an annual paid subscription). It supports only the current and previous version of each standard: as of November 2026 that means ACES 5.0 and 4.2, and PIES 8.0 and 7.2. Check which version your trading partners expect before you generate anything.

Connect on LinkedInSagnik Bhattacharya

The reference databases matter more than they sound. The vehicle database gives every vehicle configuration an identifier; the product classification database gives every part type an identifier; the attribute database lists the attributes that apply to each part type. A file that uses an identifier that does not exist, or has been retired, will fail the receiver's validation. Obtaining current copies of these databases is the first practical step, and the association's own subscription page tells you what is available and at what price.

Subscribe on YouTube@sagnikteaches

Main example: a small online seller with 6,200 parts

Illustrative. A small seller of brake and suspension parts has 6,200 part numbers from eight manufacturers, a fitment file built by a previous employee, product data pulled from manufacturer spreadsheets, and a marketplace that keeps rejecting 300 or so listings a month. The owner suspects fitment, but is not sure. The work breaks into stages, each with a clear human check.

Stage 1: get both files into tables you can read

Convert the XML files to spreadsheet tables (the AI can write a short script, or a spreadsheet tool can import XML). Keep one row per fitment application in the ACES table and one row per part in the PIES table. Describe the columns to the AI, with ten sample rows with any private data removed, and ask for a summary:

Below are the column names and 10 sample rows from two tables built from my
ACES and PIES files. Describe in plain English what each column holds, which
columns should link the two tables (for example part number and brand), and
which columns I should check for blanks or odd values. Do not assume anything
about values that are not in the sample.

This is the cheapest useful step. The assistant will tell you that part number and brand identify a part in both files, and will list the columns most likely to contain problems. It reduces the learning time and exposes surprises, such as a part number column with trailing spaces.

Stage 2: the mismatch checks between the two files

These checks are mechanical and very effective. Ask the AI to write spreadsheet formulas or a short script for each:

1. Parts in ACES but not in PIES. A part with fitment but no product record. Count them first: each one is a vehicle lookup that leads to a listing with nothing to show.
2. Parts in PIES but not in ACES. Products with no fitment. Some are universal parts and expected; the rest are lost sales.
3. Part number formatting. Leading or trailing spaces, dashes in one file and not the other, letter O and zero confusion, lowercase against uppercase.
4. Brand mismatches. The same part under two brand identifiers, or a brand identifier not in the brand table.
5. Part type disagreement. The ACES part type for a part differs from the PIES part type, such as brake pad in one and brake rotor in the other.
6. Retired or unknown identifiers. Vehicle or part type identifiers that are not in the current reference database.
7. Duplicate fitment rows. The same part, vehicle and qualifier appearing twice, or overlapping rows with different quantities.

Illustrative results on the 6,200-part example: 212 parts are in ACES but missing from PIES, 87 are in PIES but missing from ACES (61 are genuinely universal items), 140 have part numbers with a trailing space in one file, 38 have a part type that disagrees between files, and 9 vehicle identifiers are no longer in the current database. After trimming spaces and aligning the 212 missing records, the marketplace rejection count falls on the next upload; the numbers here are made up, but the order of work, formatting first and then missing records, is the part to copy.

Stage 3: field-level checks on the PIES product data

Ask the AI to suggest sanity rules for each part type, then apply them with formulas. Examples in a brake-parts catalogue: weight greater than zero; length, width and height all present and in the same unit; a pad set's weight within a plausible range for its type; a description that mentions the part type and position; a package quantity that matches the sales unit. A prompt that works:

Here are 40 rows of product data for brake pads: part number, brand, part
type, description, length, width, height, weight, unit of measure, package
quantity. Write checks I can apply in a spreadsheet to flag rows that look
wrong: missing values, mixed units, weights or dimensions that are
implausible relative to the others in this sample, descriptions that
contradict the part type. List each rule with the formula and say what a
flagged row means. Do not correct any value.

Illustrative output: "Flag rows where weight is blank or zero. Flag rows where weight is more than 3 times or less than one-third of the median for the same part type. Flag rows where the description contains 'rear' and the position data says front." Expect one or two rules to throw false flags on the first run; adjust the thresholds and run them again. The key sentence is the last: correct nothing. Flagged rows go to someone with the manufacturer's data sheet.

Stage 4: reading error reports from marketplaces and partners

Trading partners return rejection reports in their own wording. Paste a batch (without any account identifiers) and ask the AI to group them by cause and say which of your files must change:

Below are 40 error lines from a catalogue upload rejection report. Group them
by likely cause (unknown vehicle identifier, missing required attribute,
invalid brand, wrong part type, formatting). For each group, say which file
needs the fix (fitment or product data), give two example lines, and suggest a
check that would find the same problem across the whole file.

This turns a long report into four or five work items. The assistant may mislabel a cause, so open two examples in each group and confirm.

Sample audits: how to find out how wrong the data really is

Checks on structure find formatting problems, but they cannot tell you whether the fitment is true. A sample audit does that, and it is the part no tool can replace.

1. Draw the sample. Pick 50 part numbers at random, plus 20 from the top sellers and 20 from the parts with most returns. Ask the AI to write the random selection, or use a spreadsheet's random function.
2. Verify against source. For each part, compare the fitment rows with the manufacturer's current catalogue or engineering data, and the product data with its datasheet or the part itself.
3. Record the result. Per part: fitment correct, fitment missing, fitment wrong; product data correct, incomplete, wrong. Note the type of error.
4. Calculate the error rate. Wrong fitment on 4 of 50 random parts is 8%; on a 6,200-part catalogue that suggests several hundred parts to review, and a returns problem to match.
5. Trace causes. Are errors concentrated in one manufacturer's data, one vehicle range or one person's edits? A concentrated cause means a fix at the source, not 400 fixes in the file.
6. Repeat. After corrections, draw a fresh sample the next month.

Illustrative: the sample finds 3 wrong-fitment parts out of the 90, and all three come from the same manufacturer's older catalogue year. The seller asks the manufacturer for current fitment data and replaces the file in one go. That is cheaper than correcting those rows one at a time.

Ask the AI to build the audit sheet and the summary, but let people do the verifying. A returns spreadsheet is also a good source: parts returned with the reason "does not fit" should be the first stop in the audit, since they are fitment errors already found by customers. The pattern work in spotting patterns in complaints, returns and defects applies directly.

A filled-in audit sheet for one batch of ten parts

Here is how the verification record might look after a morning's work on a ten-part slice of the sample. All identifiers are invented.

Seven of ten parts have at least one issue. Only one, BP-1043, is a fitment error that could send a buyer the wrong part; SH-2211 is missing fitment (a lost sale rather than a wrong one), and SH-2230's description contradicts its position data, which could mislead anyone reading the text. Three issues sit in the seller's own tables, where a script fixes them for every part at once. Count the errors by "fix source" column and the work divides: send the manufacturers a short list of two parts, fix the three table issues with formulas or a script, and do two datasheet look-ups by hand. Ask the AI to produce that count and the follow-up emails from the filled-in sheet. The emails should list part numbers and what you found, and ask for current data, nothing more.

Using returns to prioritise: a quick sum

You will not have time to audit everything, so aim at where the money is lost. Take 12 months of returns with reason "does not fit". Say there are 180, concentrated in 35 part numbers. Ask the AI to group the returns by part number and vehicle, and to rank the part numbers by returns. Illustrative: the top 10 part numbers account for 74 of the 180 returns. Audit those first. If each wrong-fit return costs about $18 in postage and handling (take the figure from your own books), those 74 returns cost $1,332 a year before counting the lost sales, so fixing the ten parts is worth more than adding images to a hundred listings. Note down what each return cost you, so the effort has a number against it, and avoid quoting savings you have not measured.

An illustration of the XML, and why not to hand-edit it

An ACES fitment record is a small block of XML. A simplified, invented example looks something like this. The identifiers are made up and the real element names and required fields come from the current schema, so check them against the documentation:

<App action="A" id="10231">
  <BaseVehicle id="99999"/>
  <Qty>1</Qty>
  <PartType id="9999"/>
  <Position id="99"/>
  <Part>BP-1042</Part>
</App>

Reading it: one application record for part BP-1042, with a quantity, a part type and a position, for a vehicle identified by a database number. Hand-editing thousands of these is how errors creep in, so make changes in the table and regenerate the file with whichever tool or script produces your exports. Ask the AI to explain a record or a rejection line in plain English whenever you meet something unfamiliar; it tends to be good at explaining formats. It is not a substitute for reading the schema and the reference data when a change matters.

Position, supersession, attribute and version cases

Position and qualifier problems

A brake pad listed as fitting a vehicle without saying front or rear invites the wrong order and a return. Ask the AI to find fitment rows for part types that normally need a position (pads, shocks, control arms) where position is blank, then split them into "check source" and "universal". Treat the output as a to-do list for someone with the manufacturer data.

Superseded part numbers

A manufacturer supersedes BP-1042 with BP-1042A. Your PIES file lists both, ACES lists only the old one. Ask the AI to compare the supersession list from the manufacturer with both files and report parts where only one side has been updated. The AI reads the list; a person decides which number you sell.

Attribute gaps for a marketplace

Suppose a marketplace starts requiring pad material and thickness for every brake pad. The attribute database lists the attributes for the part type. Ask the AI to compare your PIES data against a list of required attributes you supply, and produce a missing-attribute count by manufacturer. Where the manufacturer sheet has the value, filling it is clerical; where it does not, ask the supplier, since guessing a material is a product-liability risk. The product data enrichment tutorial covers filling gaps from sources safely.

Before and after on one product description

Before: "BRAKE PAD SET front ceramic fits many". After, written from the datasheet: "Front ceramic brake pad set, four pads, with hardware. See fitment for vehicle compatibility." The after version drops the vague "fits many", because fitment belongs in the fitment file, not in the text. Ask the AI to rewrite descriptions to a template with the fields you supply, and to leave a field blank when it is not in the source.

A trading partner still on the previous version

Say your files move to the current PIES version while one distributor still receives the previous one, and that distributor's rejection report suddenly fills up. The data in your tables has not changed; the file format has. Keep one master table, generate each partner's file in the version it accepts, and validate it against that version's schema. Ask the AI to sort the new error lines into "version difference" and "data problem" by comparing them with last month's report, then confirm the version-difference group with the partner before changing any data. Record each partner's version in a small settings table, so the next upgrade is a planned change, not a surprise.

How AI misleads you with catalogue data

• It fills gaps. Asked to complete missing attributes, it will invent plausible ones. Instruct it to leave blanks, and always compare filled values with source.
• It trusts your column names. A column called "front" may hold anything. Ask it to report distinct values before using a column.
• It loses rows in large pastes. Make it report the row count it received, or run full-file checks in a script.
• It treats formatting as meaning. A tidy description is not a correct one. Only the datasheet settles that.
• It explains a rejection confidently and wrongly. Check the schema and reference data for anything you would act on.

A routine that keeps the data clean

Once the first clean-up is done, keep a monthly cycle: refresh reference databases and check the version your partners require; run the seven mismatch checks; run the field rules on new and changed parts; draw a 50-part audit sample; triage rejection reports; and keep a log of errors by cause. Quarterly, review the log with the AI's help: "which three causes account for most errors, and which supplier or process step do they trace to?" Fix the source, not the symptom. If you later set prices on the same records, the price matrix tutorial depends on clean part types and costs, and the wider data readiness checklist will help you judge the rest of your records. For general spreadsheet clean-up prompts, see cleaning messy data.

What it costs, and what to protect

The main costs are the reference-data subscription, the time of whoever verifies fitment, and an hour or two of an assistant's help in writing checks. Fitment and pricing files are commercial assets, and suppliers sometimes restrict how their data may be used. Send samples, not the whole catalogue, use a business plan that does not train on your content, and read your supplier agreements. Never publish fitment you have not verified: a wrong fit costs a return, a reshipment and a customer.

Questions about ACES, PIES and AI

What is the difference between ACES and PIES?

ACES carries fitment: which of your parts fit which vehicles, with any qualifiers such as position or engine detail. PIES carries product information: descriptions, brand, attributes and specifications, dimensions and weights, pricing, warranty and digital assets such as images. A listing needs both, and the part numbers must match across the two.

Can AI decide whether a part fits a vehicle?

No. Fitment must come from your manufacturer's or supplier's engineering data, the vehicle database and physical checks. AI can find records that look inconsistent, such as a front brake pad fitted to a rear position, and queue them for a person to verify against source data.

Do I need to pay for the reference databases?

In practice, yes. The Auto Care Association says using PIES requires an annual paid subscription to its reference databases, and ACES relies on its own set of them, so check the association's subscription page for what your business needs and the current cost. Without current reference data, any validation you run will be incomplete.

Should I upload my full catalogue to an AI tool?

Usually you do not need to. Send samples, error reports and column summaries, and run the full-file checks with scripts the AI helps you write. Fitment and pricing files can be commercially sensitive, so use a business plan that does not train on your content and check your supplier agreements.

Further reads

• How to Clean Up Customer Records Before You Add AI — The same clean-up habits applied to customer records.
• AI Tools for Cataloguing Stock: From Photos to Item Records — Build item records from stock photos.
• How to Clean Up a Messy CRM With AI — Merge duplicates and fix blanks in another messy dataset.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Auto Care Association pages on the ACES and PIES data standards (current and previous versions, XML format, reference databases VCdb, Qdb, PCdb, PAdb and Brand Table, subscription), checked November 2026; example identifiers in this tutorial are invented. Always check the current documentation and schema.