TecDoc vs ACES and PIES: automotive catalogue data standards compared
TecDoc serves Europe, ACES and PIES serve North America. How the two standards differ, why K-Types and Base Vehicle IDs do not map one to one, and how to feed both from one product database.
.jpg)
A parts supplier that sells in Europe has to speak TecDoc. One that sells in North America has to speak ACES and PIES. Both describe the same thing - which part fits which vehicle, and what that part is - but they identify vehicles differently, classify products differently and are maintained by different organisations. If you want to sell on both sides of the Atlantic, the question is not which standard is better. It is how to keep one product database that can produce both without retyping anything.
TecDoc vs ACES and PIES in one paragraph each
Two standards, two markets
TecDoc is the catalogue data standard and platform run by TecAlliance for the independent aftermarket. Suppliers deliver article data, technical attributes, vehicle linkages, OE and reference numbers, GTINs and images, and the catalogue makes them searchable by vehicle, number or registration [7]. TecAlliance lists 12.8 million articles, 1,200+ brands, 260,000+ vehicle types and 724 million+ vehicle linkages [1].
ACES and PIES are two XML standards maintained by the Auto Care Association and used across the Americas. ACES (Aftermarket Catalog Exchange Standard) carries fitment: which vehicles a part fits. PIES (Product Information Exchange Standard) carries everything else about the product: descriptions, pricing, packaging, dimensions, attributes and images [3, 5].
The structural difference is already visible here. TecDoc is one model and one platform: fitment and product data travel together into a catalogue that TecAlliance operates. In North America the job is split into two exchange formats, backed by reference databases that both sides of a trade relationship subscribe to: VCdb for vehicles, Qdb for qualifiers, PCdb for product classification, PAdb for attributes and the Brand Table [3, 4].
The real difference: how each standard identifies a vehicle
Everything else can be mapped with a spreadsheet and patience. Vehicle identification is where projects stall. ACES identifies a vehicle through a Base Vehicle ID from the VCdb, essentially a year, make and model, refined with further VCdb attributes and Qdb qualifiers. TecDoc identifies a vehicle type with a K-Type number, which already bundles make, model, engine and a production date range [6].
The two keys are not cut along the same lines. One K-Type can correspond to several Base Vehicles, because a production range crosses model years. One Base Vehicle can correspond to several K-Types, because one model year covers several engines. OptiCat, which built a translation aid between the two standards, says plainly that the primary identifiers do not map one to one, and that a translation may need extra information or may imply a wider set of applications than the supplier intended [6].
A fitment that is exact in one standard can become too broad or incomplete the moment it is converted mechanically into the other.
For a buyer at the counter, that is the difference between a correct part and a return. The supplier sees it later, as a complaint about wrong fitment from a market they were proud to have entered.
TecDoc vs ACES and PIES side by side
Table 1. TecDoc compared with ACES and PIES
| Aspect | TecDoc | ACES and PIES |
|---|---|---|
| Maintained by | TecAlliance | Auto Care Association |
| Main market | Europe and global independent aftermarket | North America and the wider Americas |
| Scope | One model for articles, attributes, linkages and numbers | ACES for fitment, PIES for product information |
| Vehicle key | K-Type number (vehicle type with engine and date range) | Base Vehicle ID from VCdb, refined by attributes and Qdb qualifiers |
| Product classification | Generic articles | PCdb part types and categories |
| Attributes | Technical criteria per generic article | PAdb attributes, delivered in PIES |
| Delivery | TAF file packages or IDP API | XML files exchanged between trading partners |
| Quality signal | Data quality KPIs, Certified and Premier Data Supplier status | Assessment tooling against the standard, partner requirements |
| Latest change | Continuous KPI and validation updates | ACES 5.0 and PIES 8.0, April 2026 |
Two lines of the table deserve a comment. On delivery, TecDoc now offers two routes: TAF, a file-based exchange format processed as complete packages, and IDP, which sends individual records and changes through an API with direct validation feedback [2]. On the North American side, the April 2026 release brought ACES 5.0 and PIES 8.0, adding digital assets in ACES, Extended Producer Responsibility packaging data in PIES and new versions of every reference database [5].
On quality, TecDoc measures suppliers against KPIs and rewards the best with Certified or Premier Data Supplier status. We covered what those KPIs are and what they are worth in euros in our article on TecDoc data quality. Quality also affects how a supplier is positioned in the TecDoc directory, which is why in the parts catalogue project for Dr. Motor we also managed the product data and its export to TecDoc.
How to serve both markets from one product database
The tempting shortcut is to treat one standard as the master and convert its export into the other. It works for a pilot and fails at scale, for the reason above: every conversion inherits the mismatch between K-Types and Base Vehicles, and every correction has to be made twice.
The approach that holds up keeps one internal model of the product and of its fitment, richer than either standard. Each part carries its attributes in your own units and names, its OE and reference numbers, and its fitment described in enough detail - engine code, production dates, body type, position - to be expressed as a K-Type linkage and as an ACES application. TecDoc and ACES/PIES files are then generated outputs, each with its own mapping table, rather than sources of truth. This is the shape of the dedicated PIM we built for Optimal, which holds 200,000 parts and 6 million vehicle linkages and is integrated with TecDoc and the ERP.
THE RULE IN ONE LINE
Store fitment and product data once, in your own model, and generate TecDoc and ACES/PIES from it. Never maintain one standard by translating the other.
This is exactly the job of a product information management system built for the aftermarket. In the product data platform we built for LKQ Europe, suppliers without TecDoc data can be onboarded from a plain CSV and served through the same product API, because the internal model does not depend on any single external standard.
The standards are output formats. Your product model is the asset.
Where TecDoc to ACES mapping usually goes wrong
The first trap is vehicle granularity, already described: one-to-many links between K-Types and Base Vehicles, resolved by guesswork instead of by the engine and date data the supplier actually has [6].
The second is product classification. A TecDoc generic article and a PCdb part type rarely line up one to one, so a single mapping table per category has to be agreed and owned by someone, rather than improvised per export. The third is attributes: TecDoc criteria and PAdb attributes differ in names, allowed values and units, and a dimension that is fine in millimetres in one feed must be stated with the right unit code in the other.
The fourth is free text. Fitment notes such as "with air conditioning" or "rear axle" are often typed by hand. In ACES they should become Qdb qualifiers and positions; in TecDoc they belong in criteria. Left as text, they are invisible to search and impossible to validate. The last is timing: vehicle databases on both sides change with every release, so mappings need a regular review, not a one-off project.
Most of these issues are cheaper to catch before export than after a partner rejects a file. Validation and completeness rules in the PIM, and a research step for missing cross-references like the one in our AI-driven catalog intelligence case study, move the work upstream.
A quick test before you plan a new market: take your 20 best-selling parts and check how many have fitment detailed enough to express both as a K-Type linkage and as an ACES application - engine, production dates and position, not just make and model. If fewer than half do, that is the work to start with. See how PIM4B keeps one catalogue ready for TecDoc, ACES and PIES.
FAQ
What is the difference between TecDoc and ACES/PIES?
TecDoc is the catalogue data standard and platform of TecAlliance, used mainly in Europe, where articles, attributes and vehicle linkages are delivered in one model. ACES and PIES are two XML standards of the Auto Care Association used in the Americas: ACES carries fitment, PIES carries product information. The biggest technical difference is vehicle identification: K-Type numbers versus Base Vehicle IDs.
Can TecDoc data be converted to ACES automatically?
Only partly. Product attributes and classifications can be mapped with maintained tables, but vehicle fitment cannot be converted one to one, because TecDoc K-Types and ACES Base Vehicle IDs are cut along different lines. One identifier can match a range of vehicles in the other standard, so reliable conversion needs engine, date and position data from the supplier.
What is a K-Type number in TecDoc?
A K-Type is the TecDoc identifier of a vehicle type, combining make, model, engine and production date range into one number. Parts are linked to K-Types to state fitment, and catalogues and shops use those links to show only parts that fit a selected car. TecAlliance lists more than 260,000 vehicle types and over 724 million vehicle linkages in TecDoc.
Which databases do ACES and PIES use?
ACES and PIES rely on reference databases maintained by the Auto Care Association: the Vehicle Configuration database (VCdb), the Qualifier database (Qdb), the Product Classification database (PCdb), the Product Attribute database (PAdb) and the Brand Table. ACES uses VCdb and Qdb for fitment; PIES uses PAdb for attributes. The April 2026 release brought ACES 5.0 and PIES 8.0.
Do I need both TecDoc and ACES/PIES?
Only if you sell in both markets. European trading partners and catalogues expect TecDoc data; North American retailers and distributors expect ACES and PIES files. A supplier selling on both sides should keep one internal product and fitment model, typically in a PIM, and generate both outputs from it rather than translating one standard into the other.
Sources and assumptions
- TecAlliance (2026). TecDoc. Figures on articles, brands, vehicle types and linkages, accessed October 2026.
- prodexa (2025). What is TecDoc TAF?. TAF file packages compared with IDP API delivery.
- SPS Commerce. ACES and PIES Explained: A Primer on Automotive Catalog Data. Scope of ACES and PIES and supporting databases.
- Auto Care Association. What are the supporting databases used in the ACES and PIES data standards?. VCdb, Qdb, PCdb, PAdb and Brand Table.
- Vehicle Service Pros (2026). Auto Care Association Releases ACES 5.0 and PIES 8.0 Data Standards. Release of 2 April 2026 and changes per standard.
- AftermarketNews. OptiCat Announces Its New TecDoc, ACES Translation Aid. Base Vehicle ID and K-Type do not map one to one.
- prodexa (2025). What is TecDoc?. Data types and delivery channels of TecDoc.
Key takeaway
TecDoc (TecAlliance) and ACES/PIES (Auto Care Association) both describe auto parts and their fitment, but identify vehicles differently: K-Type numbers versus Base Vehicle IDs, which do not map one to one. Suppliers selling in Europe and North America should keep one internal product and fitment model, for example in a PIM, and generate both outputs from it instead of converting one standard into the other.
