ACES and PIES are the two XML data standards that underpin automotive aftermarket cataloguing.
ACES answers the question “does this part fit this vehicle?”
PIES answers “what is this part, and what does it cost?”
If your parts catalogue depends on fitment search, supplier data feeds, or an ecommerce channel, you will be working with both.
What ACES and PIES are
The Auto Care Association, the US-based trade body for the automotive aftermarket industry, created and maintains both standards. They exist because the aftermarket faces a data problem no single organisation can solve on its own: thousands of parts suppliers, millions of part numbers, and hundreds of thousands of vehicle configurations, all needing to connect reliably across every link in the distribution chain.
Before these standards existed, every distributor had to build custom data mappings for each supplier relationship. ACES and PIES give the industry a shared language.
- ACES stands for Automotive Catalog Exchange Standard. It is an XML file format that maps part numbers to vehicle applications. A single ACES record might say: part number BR1042 fits 2015 to 2020 Ford Focus, 1.6L TDCi diesel, with the qualifier “not applicable to models with Powershift transmission”.
- PIES stands for Product Information Exchange Standard. It is an XML file format containing everything else about the product:
® Descriptions
® Attributes
® Pricing
® Package dimensions
® Digital assets
® Hazardous materials classifications
The two files are designed to be used together. ACES tells a buyer’s website whether the part fits their vehicle. PIES tells the site what to display once it does.
ACES vs PIES: why they are not the same thing
This is worth stating directly, because many teams conflate the two.
ACES and PIES are not alternatives to each other, and they are not interchangeable shorthand for “automotive data standards”. They are separate files solving separate problems. A supplier who sends you a complete PIES file, but an incomplete ACES file, has given you usable product content and broken fitment data. The reverse is equally possible.
The distinction matters operationally because the two problems typically sit with different teams inside a distributor. Fitment data, the ACES side, is usually owned by technical or catalogue teams. Getting it wrong means customers order the wrong part, return it, and rarely come back. The financial and reputational cost is significant.
Product content, the PIES side, is usually owned by ecommerce or merchandising teams. Thin or inaccurate PIES data produces weak product listings, poor organic search visibility, and conversion rates that plateau below benchmark.
We see this division clearly in the work we have done (see our GSF Car Parts case) and Maxiparts. At project level, the fitment data challenges and the product content challenges look different, require different tooling, and need different owners inside the business. Treating ACES and PIES as a single problem is the fastest way to mismanage both.
How ACES works in practice
An ACES file is structured around applications: records that combine a part number, a vehicle configuration, and any qualifiers needed to restrict or clarify the fit.
Vehicle configurations reference the Vehicle Configuration Database (VCdb), maintained by the Auto Care Association. VCdb assigns standardised IDs to every year, make, model, sub-model, engine, and transmission combination. When a supplier writes an ACES file, they use VCdb IDs rather than free-text vehicle names. That standardisation is what makes the data machine-readable across different systems.
Part type classifications reference the Parts Classification Database (PCdb), also maintained by the Auto Care Association. PCdb assigns standardised part type IDs so that a distributor’s system knows what category to assign an incoming part record.
A simplified ACES application record looks like this:
| Field | Example value |
| Part number | BR1042 |
| Vehicle year range | 2015-2020 |
| Make | Ford |
| Model | Focus |
| Sub-model | Titanium |
| Engine | 1.6L TDCi |
| Qualifier | Solid disc models only |
In a real ACES file, each of these is represented as an XML element referencing VCdb or PCdb IDs, not plain-text strings. Opening an ACES file in a spreadsheet and expecting it to be readable without the reference databases is a common first mistake.
The current ACES versions in common use are 3.2 and 4.0. Version 4.0 adds native support for digital asset references within the fitment record and improved handling of complex qualifiers. If you receive ACES files from suppliers, check which version they are exporting. Different versions use different XML schemas, and import tooling needs to be configured to handle both if your supplier base is mixed.
Fitment data in ACES files has a staleness problem that is easy to underestimate. Suppliers maintain their own application data, and errors are common: over-coverage (parts listed against vehicles they do not actually fit), under-coverage (vehicles that are missing from the record), and outdated applications that have not been revised for newer model years. Receiving a well-formed ACES file is not the same as receiving accurate fitment data. Validation cannot be skipped.
How PIES works in practice
PIES files are built around EXPI codes, Exchange Product Information codes that define each attribute type within the standard. EXPI codes cover:
- Product descriptions (up to six types: short, long, features, installation notes, slang, marketing copy)
- Pricing (list price, jobber price, core charge, net price)
- Package dimensions and weights at each level (each, inner, master carton)
- Digital assets, referenced by URL or filename (images, PDFs, installation videos)
- Hazardous materials classifications (UN number, hazard class, packaging group)
- Country of origin
- Kitting and interchangeability relationships between part numbers
The quality challenge with PIES is not usually format compliance. It is depth. A supplier can send a technically valid PIES file containing only a part number, a short description, and a list price. That file passes schema validation. It will not support a competitive product listing.
Across the automotive distributor catalogues we have worked with as part of our product data services practice, supplier PIES files vary enormously in content completeness. Some suppliers populate thirty or more EXPI codes per SKU. Others send five. The thin files are technically valid. Commercially, they are next to useless.
This was a central problem in the supplier data onboarding programme we ran with Maxiparts. The task was not simply to receive and process PIES files. It was to define minimum acceptable content thresholds for each product category, validate incoming files against those thresholds before data entered the catalogue workflow, and establish an escalation path for suppliers whose files consistently fell short.
ACES and PIES in UK and Australian markets
ACES and PIES are North American standards, created and governed by the Auto Care Association in the US. Their presence in UK and Australian markets is real but uneven.
In the UK, European parts suppliers typically use TecDoc, the equivalent framework maintained by TecAlliance. A UK distributor like GSF Car Parts receives data in both formats depending on where the supplier originates: ACES and PIES from North American manufacturers and those with US parent companies, TecDoc linkage data from European counterparts. Managing the two in parallel is standard practice for any UK distributor with a broad supplier base.
In Australia, the picture is similar. Suppliers with North American ownership tend to export ACES and PIES. Australian-specific suppliers and some Asian manufacturers may use TecDoc, proprietary formats, or flat-file spreadsheets with no standardised structure at all.
The practical implication for any UK or Australian distributor:
ACES and PIES fluency is necessary, but not sufficient on its own.
Your data ingestion process needs to handle TecDoc linkage data alongside ACES fitment records without treating them as equivalent. The vehicle identification systems used by ACES and TecDoc are different. They do not map directly to each other, and any approach that conflates them will produce fitment errors.
This is one of the reasons why PIM for automotive parts distributors is more complex than in most other sectors. It is not just a storage and enrichment problem. It is a multi-standard normalisation problem, and the tooling and workflow need to be built around that reality.
Common problems with ACES and PIES data
These are the patterns we see most often across automotive distributor projects.
1. Stale fitment data
ACES files from suppliers are not always updated when new model years arrive. A 2025 Ford Focus application may simply be missing from a supplier’s file that was last updated in 2023. Without a process for identifying coverage gaps, those applications silently return no results for customers.
2. Thin PIES content on slow-moving SKUs
Suppliers put effort into PIES content for high-volume parts and cut corners on low-velocity ones. The problem is that customers searching for obscure parts are often the highest-value searches. Thin content on those SKUs means missed conversions precisely where the competitive advantage is largest.
3. Version mismatches
An import process configured for ACES 3.2 will fail silently on an ACES 4.0 file that uses schema elements that aren’t present in 3.2. This is rarely caught until a supplier switches export versions and a catalogue team notices that fitment records have stopped coming through.
4. Ignoring the digital asset section in PIES
PIES includes a digital assets section that links to supplier-hosted product images, installation PDFs, and videos. Many distributors ignore this section and source images separately through manual processes. That duplication adds time and cost. The PIES digital asset feed is not always complete, but it is almost always faster than a manual alternative.
5. No defined inbound data standards
Distributors who accept any format from any supplier end up with a catalogue that requires bespoke processing for each inbound feed. Defining an inbound data standard, including ACES version, mandatory PIES attributes, and content thresholds, and communicating it to suppliers, reduces long-term processing cost significantly.
What good looks like
A well-run ACES and PIES data operation has a few consistent characteristics:
Inbound standards are defined and documented
Suppliers know which ACES version is accepted, which PIES attributes are mandatory by product category, and what content thresholds must be met before data is published. This is not an unreasonable ask for suppliers who already produce these files. It is a specification.
Validation is automated on receipt
ACES files are checked against current VCdb versions on import. PIES files are checked for mandatory EXPI codes before they enter the catalogue workflow. Files that fail validation are quarantined and flagged, not silently discarded.
Fitment data goes through a QA stage before publication
Whether that is automated cross-referencing against a vehicle database or a structured human review, fitment records are not published on the basis of supplier data alone.
Thin PIES content has an enrichment path
Where supplier data falls below threshold, there is a defined process for filling the gaps before the product goes live. This is where product data enrichment typically sits inside an automotive distributor’s operation: bridging the gap between what suppliers send and what the catalogue actually needs.
The platform that hosts this process matters less than the workflow itself. We have seen clean ACES and PIES operations running in relatively simple tooling, and we have seen expensive PIM platforms full of unvalidated fitment data. The platform supports the workflow. Without the workflow defined first, any platform will fill up with the same quality problems.
Key takeaways
- ACES handles fitment data: does this part fit this vehicle? PIES handles product content: what is this part, what does it cost, what does it look like? The two are complementary, not interchangeable.
- Both are XML standards maintained by the Auto Care Association. ACES references the VCdb and PCdb. PIES is built around EXPI attribute codes.
- UK and Australian distributors typically receive ACES and PIES from North American suppliers and TecDoc data from European ones. The two systems use different vehicle identification logic and need to be managed separately.
- A valid ACES or PIES file is not the same as accurate or complete data. Validation and content thresholds need to be defined and enforced as a workflow step, not assumed based on supplier reputation.
- The fitment problem and the product content problem belong to different teams inside your organisation. Giving them a single owner usually means one gets neglected.
Our product data services for automotive distributors typically start with a catalogue audit that maps inbound data quality by supplier and by product category. Our automotive product data work then builds from that baseline into whatever combination of validation tooling, enrichment, and supplier engagement the gap requires. Get in touch today for a discovery call to talk through what that looks like for your business.