Executive Summary
Standards make data exchange possible. They do not make your catalog commerce-ready. The competitive advantage is the data architecture you build on top.
ACES and PIES are data standards; TecDoc is a data ecosystem with its own model. All three solve exchange. Wrong-fit orders, returns, weak search, and rising catalog maintenance costs come from what is missing on top of them.
- A valid feed is not a finished catalog. Compliance, completeness, correctness, and commerce readiness are four different things. The standards guarantee only the first, and each of the other three has its own commercial cost when it is missing.
- TecDoc is not “ACES and PIES for Europe.” It is a separate data ecosystem with its own vehicle and product model. Selling across both markets means building and maintaining a mapping layer, not running a lookup.
- ACES 5.0 and PIES 8.0 change how you run ingestion. Track which version each supplier sends, validate old and new versions in parallel, and capture the new asset, multilingual, and packaging fields instead of dropping them.
- The advantage is the architecture on top. Two validation gates, a canonical model, provenance on every value, governed versions, maintained crosswalks, and telemetry.
Why Standardized Aftermarket Data Still Produces Wrong-Fit Orders
Two businesses can load the same validated supplier feeds and end up with very different catalogs. One sells the right part the first time. The other ships wrong-fit orders, absorbs the returns, hides products from buyers who are searching for them, and stays hard for AI shopping systems to interpret. Same standards, same supplier data, different commercial outcomes.
The difference is not the standard. ACES and PIES carry fitment and product data across the Americas, and the TecDoc ecosystem plays a similar role across much of the European independent aftermarket. They solve one problem: exchange. A manufacturer’s data can move to a distributor, a retailer, and a platform without being rebuilt at every handoff, which is why the industry works at all. But a standards-compliant feed is structurally valid, not commercially complete. The standards do not guarantee that supplier data is complete or correct, that two suppliers agree, that your own enrichment exists, that European and American vehicle models line up, that supersession chains resolve end to end, or that search, storefronts, marketplaces, and AI systems can consume the result.
A valid feed is not a finished catalog. Standards make data exchange possible. They do not make your catalog commerce-ready. The competitive advantage is the data architecture you build on top, and that layer is what this article is about: what each standard gives you, what it leaves to you, and what to build.
A Valid Feed Is Not a Finished Catalog: Four Levels of Catalog Readiness
Before looking at any individual standard, separate four things a catalog can be. The standards guarantee only the first. Each of the other three carries its own commercial cost when it is missing.
- Standards compliance. The incoming data is structurally valid: it parses against the schema, its references resolve against the reference databases, and required fields are present. When this fails, the cost is supplier rework and delayed listings.
- Completeness. The data contains enough to sell and discover the product: the attributes buyers filter on are populated, descriptions exist and are yours, and coverage extends to the vehicles your customers drive. When this is missing, products drop out of filtered search and lose conversions to better-described competitors.
- Correctness. The applications, attributes, and relationships are actually true. A structurally valid application can still put the wrong part on the wrong car. When this is missing, the cost is wrong-fit orders, returns, and customers who buy elsewhere next time.
- Commerce readiness. Search, storefront, commerce APIs, marketplaces, and AI systems can consume the data reliably, from one model, without reconciling at runtime. When this is missing, every new channel becomes a new integration project, and catalog maintenance costs grow with each one.
From a valid feed to a finished catalog. The standards guarantee level one; each missing level has a commercial cost.
The common failure is to measure the first level and assume the other three. A feed that validates feels finished. It is not, and the gap between level one and level four is where avoidable returns, weak search conversion, and poor AI visibility come from, even when competitors work from the same supplier data. Our product data quality piece covers completeness and enrichment in depth. The rest of this article shows where each standard stops, and the architecture that closes the gap.
ACES, PIES, And TecDoc Compared: Two Standards And One Data Ecosystem
ACES and PIES are data standards, both maintained by the Auto Care Association. TecDoc is a different kind of thing: a vehicle and product data ecosystem run by TecAlliance, with its own data model. The last two rows are the ones that matter commercially.
| ACES | PIES | TecDoc | |
|---|---|---|---|
| What it is | Data standard for vehicle fitment | Data standard for product information | Data ecosystem with its own vehicle and product model |
| Question it answers | Which vehicles does this part fit? | What is this part? | What is this part, and which vehicles does it fit? |
| Main market | Americas | Americas | European independent aftermarket, with broader global use |
| Maintained by | Auto Care Association | Auto Care Association | TecAlliance |
| Built on | VCdb, Qdb, PCdb, Brand Table | PCdb, PAdb, Brand Table | KTypes, NTypes, generic articles, criteria, application linkages |
| Does not guarantee | Complete or correct fitment | Complete or commercially useful product data | A complete seller-specific or cross-market catalog |
| Business risk if you stop at compliance | Wrong-fit orders and returns | Weak search, filtering, and conversion | Conflicting fitment across markets and duplicated catalog work |
ACES: What the Fitment Standard Covers, And Where Fitment Breaks
ACES (Aftermarket Catalog Exchange Standard), maintained by the Auto Care Association, defines vehicle fitment: the structured mapping between a part and the vehicles it applies to. Its accuracy depends on the reference databases it resolves against.
The vehicle side runs on VCdb, the Vehicle Configuration Database, the industry’s shared registry of vehicles from base vehicle (year, make, model) down through the configurations that split otherwise identical vehicles: engine, transmission, drive type, body style. Qdb, the Qualifier Database, carries the conditions plain configuration cannot express: “with heavy-duty towing package,” “from production date,” “except models with electronic parking brake.” Part types come from PCdb, the Product Classification Database, so a “brake pad set” is the same part type in every application, and brands are identified through the Brand Table.
An ACES application record ties these together: this part number, from this brand, of this part type, applies to this base vehicle with this engine under these qualifiers. That structure is what lets a platform answer “will this fit?” deterministically. It is also where the first commercial exposure sits. If the ingestion pipeline does not enforce those references, an application that points at a vehicle configuration that no longer resolves against the current VCdb, or that carries a qualifier as free text instead of a Qdb reference, does not fail at load time. It surfaces later as a missing or incorrect fitment result, and potentially as a wrong order or a return.
What this means commercially: Fitment data decides whether the customer receives a part that fits. For a retailer, an unresolved application is a potential wrong-fit order or a vehicle that never appears in search. For a manufacturer, it is a product that distributors and marketplaces cannot sell with confidence.
PIES: What the Product Standard Covers, And Why Thin Product Data Loses Sales
PIES (Product Information Exchange Standard), also from the Auto Care Association, defines the product side: what the part is, independent of what it fits. Its structure is segmented, and the segments map directly onto what a platform needs. The item segment carries identity: part number, brand, GTIN. Description segments carry the copy fields, from short labels to marketing descriptions. The attribute segment carries the structured technical properties buyers filter and compare on, drawn from PAdb, the Product Attribute Database. Pricing, packaging, and digital-asset segments carry the commercial and media data. And the interchange segment carries cross-reference relationships to other part numbers, OE and competitor, which is what makes a catalog navigable from whatever number the buyer walks in holding.
ACES answers “what does it fit?”; PIES answers “what is it?” A working catalog needs both, mapped to each other by brand and part number, and many problems diagnosed as “fitment problems” turn out to be mapping problems between the two. The commercial consequence is the same either way. A part that is correctly described but wrongly linked, or correctly linked but thinly described, becomes harder to find and harder to buy correctly.
What this means commercially: PIES attributes power the filters buyers use to narrow results, and interchange decides whether a buyer holding an OE or competitor number finds your part at all. A part with thin PIES data still exists in the catalog. It just loses the search, the filter, and the sale.
TecDoc: Why the European Data Ecosystem Does Not Map Cleanly to ACES and PIES
TecDoc, maintained by TecAlliance, is the dominant product and vehicle-data ecosystem across much of the European independent aftermarket, with broader use beyond it. It covers concepts that overlap with both ACES and PIES, but its vehicle, product, and application model is its own. Vehicles are identified through TecDoc vehicle types, the KType for passenger cars and the NType for commercial vehicles being the best known. Products are organized as articles, named through standardized generic articles, described through criteria, and linked to vehicle types through application linkages.
The concepts rhyme with the Auto Care stack: a vehicle registry, a product classification, an attribute vocabulary, a set of linkages. The structures do not. A KType is not a VCdb base vehicle plus configuration; a generic article is not a PCdb part type; criteria do not map one-to-one to PAdb attributes. Treating TecDoc as “ACES and PIES combined for Europe” is a useful first sentence and a bad implementation plan.
TecDoc is also moving in the same direction as Auto Care on delivery. In May 2026 TecAlliance introduced the IDP Data Receiver API, which delivers new, updated, and deleted objects as deltas rather than as complete data-package files. Its initial scope covers KTypes for passenger cars, motorcycles, and light commercial vehicles, the engines connected to them, generic articles, criteria, and the key tables some criteria depend on. The delivery mechanism is changing; the underlying model is not converging with VCdb. That is why the next section exists.
What this means commercially: A business that sells in both markets, or sources European parts for American buyers, cannot bolt TecDoc onto an ACES and PIES catalog. Without a deliberate mapping layer, the same part carries two fitment answers, and the catalog has no rule for which one is right.
Cross-Market Catalogs: 6 Challenges of Combining ACES, PIES, And TecDoc Data
Any business selling in both markets, or buying from suppliers on both sides, has to turn two data models into one catalog. That is an engineering problem, not a lookup table. Six challenges decide whether it works, and each one carries a direct commercial cost.
1. Choose one master vehicle model. Master on VCdb, on TecDoc vehicle types, or on a neutral internal model that both map into. Search, storefront, and agent-facing APIs then read that one model instead of reconciling two at runtime.
Business cost: The choice decides which market’s coverage gaps you inherit.
2. Map KTypes to VCdb configurations. There is no clean one-to-one: one KType can match several VCdb configurations, or part of one. The mapping needs explicit rules for where the models disagree.
Business cost: A best-guess join produces wrong-fit orders.
3. Normalize part types and attributes. PCdb part types against TecDoc generic articles, and PAdb attributes against TecDoc criteria: each pair needs a maintained crosswalk with a named owner.
Business cost: Without one, the same product filters differently in each market, and buyers miss it.
4. Track where every record came from. Each record carries its supplier, standard, and version, so a correction in one market can be traced and does not silently overwrite the other.
Business cost: Without provenance, every fitment complaint becomes a manual investigation.
5. Resolve supplier conflicts. Two suppliers sending the same part with different fitment or attributes is normal. The catalog needs a precedence rule that is visible to whoever investigates the complaint.
Business cost: Without one, the answer customers see depends on which feed loaded last.
6. Protect your own corrections. Overrides and enrichment must sit outside the supplier record so they survive the next refresh.
Business cost: When they do not, the next feed erases them and your team pays to fix the same error again.
The standards solve exchange inside their own ecosystems. A coherent cross-market catalog is a maintained data and application layer on top of both. Treating those crosswalks as a one-time migration artifact creates a predictable problem: the mappings decay as the source models change. The shape of that layer looks like this.
Two data models, one canonical model. Standards validation resolves every inbound reference; the canonical layer, wherever it is implemented, holds the crosswalks and your overrides; commercial validation decides what is fit to sell.
ACES 5.0 And PIES 8.0: What Changed And What Businesses Need To Do
ACES 5.0 and PIES 8.0 are now the current versions. The Auto Care Association formally announced the release on 2 April 2026, after a yearlong industry review, with updated reference-database schemas alongside them: VCdb 2.0, Qdb 2.0, PCdb 2.0, PAdb 5.0, and Brand Table 2.0. The changes are specific rather than sweeping.
ACES 5.0 adds vehicle- and part-specific non-diagram digital assets in the application segment, multiple descriptions for a single digital asset, and multiple languages for the MfrLabel field. It is also a major schema version: elements and attributes were renamed and removed, and XSD restrictions changed, so a file that validated under 4.2 will not necessarily validate under 5.0.
PIES 8.0 adds Extended Producer Responsibility packaging data for regulatory compliance, multiple package configurations at a single pack level, and file hashing and record sequencing for digital assets.
The feature list matters less than what it changes in how you run ingestion, content, and compliance. Five actions follow from this release.
Find out which version every supplier sends. Suppliers will move to ACES 5.0 and PIES 8.0 at different speeds, and ACES 4.2 and PIES 7.2 files will keep arriving. Record the version per supplier and validate each file against the version it claims. The free AutoCareVIP Catalog Assessment tool now accepts both.
Run both versions in parallel. ACES 5.0 renamed and removed elements and changed XSD restrictions, so a pipeline built for one version will reject valid files written in the other. Plan a dual-version period, not a cutover date.
Update reference-data loaders, not just feed parsers. VCdb, Qdb, PCdb, PAdb, and the Brand Table all moved to new schema versions in the same release. Loaders and internal mappings tied to the old schemas need the same review as the feed parsers.
Capture the content suppliers can now send. ACES 5.0 lets vehicle- and part-specific digital assets and multilingual labels travel inside the standard instead of in side files. If your platform ignores those fields, that content never reaches the product page.
Map EPR packaging data if you sell into regulated markets. PIES 8.0 gives Extended Producer Responsibility packaging data a standard home. Capture it at ingestion, before compliance teams build a workaround outside the catalog.
The Auto Care Reference-Database API: Why Catalog Freshness Is Now An Engineering Choice
A separate development, often conflated with the version release, is the Auto Care Association’s reference-database API. Opened to the whole industry in January 2025, it provides API access to VCdb, Qdb, PCdb, PAdb, and the Brand Table in JSON, as full tables or as changes, as often as daily. At the same time, manual portal downloads of Qdb, PCdb, and PAdb moved from weekly to monthly (VCdb was already monthly), with the Brand Table staying daily.
The API updates the reference databases: the vehicle registry, the qualifiers, the part types, the attributes, the brands. It does not turn your suppliers’ ACES and PIES files into a live feed; those still arrive on whatever cadence each supplier publishes. What it removes is the lag between a new vehicle configuration appearing in VCdb and your catalog knowing it exists.
The architectural advantage is real. A catalog that consumes reference changes programmatically validates incoming applications against the current VCdb rather than last quarter’s. It surfaces the newest vehicles on the road as soon as any supplier covers them. And it can treat reference-data latency as a monitored number rather than a calendar reminder. A catalog still replacing reference tables by hand is validating against a target it can only see monthly. The practical risk is delayed coverage of newly added vehicles, even when suppliers already have applications available for them.
What this means commercially: Moving from manual downloads to the API is one of the few catalog improvements that needs no new supplier data, only integration work. Every month of lag is a month in which new vehicles your suppliers already cover stay out of your search results.
What To Build On Top Of The Standards: Six Architecture Disciplines
This is the layer where competitive advantage is decided. Six disciplines separate a standards implementation that holds up from one that gets rebuilt at every migration.
Separate Standards Validation From Commercial Validation
Ingestion should enforce the standard first, and that means two checks, not one: schema conformance, so the file is valid against the version it claims, and reference integrity, so applications are rejected when their base vehicles or configurations do not resolve, products are rejected when required segments are missing, and qualifiers are checked against Qdb rather than passed through as text. A second, separate gate then applies your commercial rules: minimum attribute coverage for the category, description presence, image presence, price and availability. Keeping the two gates apart matters because their failure reports mean different things. A schema failure is a supplier ticket. A commercial failure is a merchandising decision. Blending them produces a single rejected pile that nobody owns.
Maintain A Canonical Internal Model
Do not make ACES, PIES, or TecDoc your internal commerce domain model. They are exchange formats built for transmission, not for the queries a storefront, a search index, or an agent-facing API runs. Ingest into your own model, with your own vehicle entity, product entity, relationship graph, and provenance fields, and map each standard into it. That model can live in the PIM, an MDM, or a dedicated data layer; what matters is that one place owns it and the storefront, search, and agent-facing APIs read from it rather than from the raw feeds. This is also what makes the cross-market problem tractable: a canonical model gives both standards something to map into, rather than forcing one to impersonate the other. Commercially, it is what lets you add a marketplace, a new market, or an AI channel without rebuilding the catalog each time.
Preserve Source And Override Provenance
Every value in the catalog should be able to answer two questions: who supplied this, and has anyone here changed it. Supplier, standard, version, and load time on every inbound value; author, reason, and time on every override. Without this, corrections are invisible, supplier refreshes overwrite them, and the same catalog error keeps returning with no record of having been fixed before.
Govern Versions And Reference Data
Track which standard version and which reference-database version every inbound source uses. With ACES 5.0 and PIES 8.0 now official, earlier versions still in use by suppliers, and reference data now available daily, a catalog that cannot say “this supplier is on 4.2 against a March VCdb” cannot diagnose why its applications stopped resolving. Without version tracking, a supplier upgrade looks like a catalog outage.
Treat Cross-Market Mapping As A Maintained Capability
The KType-to-VCdb crosswalk, the generic-article-to-part-type crosswalk, and the criteria-to-attribute crosswalk are living tables with owners, change logs, and test cases, not a spreadsheet produced during migration and never opened again. Both reference models change on their own schedules, and a crosswalk built against last year’s versions decays silently. A decayed crosswalk shows up as wrong-fit orders in the market nobody was watching.
Instrument Ingestion And Data Health
Monitor rejected records, unresolved references, mapping failures, update latency against each source, and quality by supplier, as standing telemetry with thresholds. Dead-end supersession chains, where the referenced successor was never ingested, and stale vehicle coverage, where the reference database moved and the applications did not, are two examples of silent catalog failures, and both are detectable programmatically. A standards implementation is not a project with an end date. It is a pipeline with a health dashboard, and the dashboard is what tells you the floor is still holding.
FAQs
ACES defines vehicle fitment, which vehicles a part applies to, resolved against the VCdb vehicle registry with qualifiers from Qdb. PIES defines the product itself: identity, descriptions, attributes, pricing, packaging, assets, and interchange. ACES answers “what does it fit?”; PIES answers “what is it?” A working catalog requires both, mapped together by brand and part number.
The Auto Care Association reference databases the standards resolve against. VCdb is the registry of vehicles and their configurations and Qdb the qualifying conditions that refine fitment; both serve ACES. PCdb standardizes part types and terminology and PAdb the attributes that describe parts; PCdb is used by both standards and PAdb chiefly by PIES. The Brand Table identifies brands for both. An application or product record is only as good as its resolution against the current versions of these.
TecDoc is TecAlliance’s product and vehicle-data ecosystem for the European independent aftermarket, covering vehicle identification (KTypes and NTypes), generic articles, criteria, and application linkages. Sellers operating only in the Americas can run on ACES and PIES. Businesses selling in or sourcing from Europe carry TecDoc too, and the mapping between the two vehicle models requires a maintained data-mapping layer, not simple configuration.
Released by the Auto Care Association on 2 April 2026, after a yearlong industry review. ACES 5.0 adds vehicle- and part-specific digital assets in the application segment, multiple descriptions per asset, and multilingual MfrLabel, and is a major schema version with renamed and removed elements. PIES 8.0 adds Extended Producer Responsibility packaging data, multiple package configurations per pack level, and digital-asset file hashing and record sequencing. Reference-database schemas were updated in the same release. In practice, businesses need to track which version each supplier sends and validate old and new versions in parallel during the transition.
No. The API provides access to the reference databases (VCdb, Qdb, PCdb, PAdb, Brand Table) as often as daily, in full or as changes. Supplier ACES and PIES files still arrive on each supplier’s own cadence. What the API changes is how quickly your catalog learns about new vehicles, part types, attributes, and brands, which is what lets it validate and cover new vehicles sooner.
No. A valid feed is not a finished catalog. Validation proves structure, not completeness, correctness, or commerce readiness. Two businesses with identical validated feeds can have very different catalogs, and the difference is in the enrichment, corrections, cross-market mapping, and architecture built on top.
Programmatically, on five measures: application resolution rate against the current reference databases, supersession-chain completeness, cross-market mapping failure rate, attribute consistency across suppliers, and update latency against each source. All five can run as standing telemetry rather than an annual review.
