TecDoc vs ACES and PIES: automotive catalogue data standards compared

A parts supplier that works with European catalogues and distributors will usually be asked for TecDoc data. One that supplies North American retailers will usually be asked for ACES and PIES files. 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. Which formats you need depends less on geography than on the trading partners, catalogues and sales channels you serve, and many companies end up maintaining both. 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

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 the ACES and PIES world the job is split into two exchange formats, backed by licensed reference databases that both sides of a trade relationship use: VCdb for vehicle configurations, Qdb for qualifiers, PCdb for product classification, PAdb for attributes and the Brand Table [2, 3].

The real difference: how each standard identifies a vehicle

Product classification and attributes can usually be handled with maintained mapping tables, although even that work needs people who understand what the data means and validation of the result. Vehicle identification is where projects stall.

ACES identifies a vehicle through a BaseVehicle ID from the VCdb, essentially a year, make and model, refined with further VCdb attributes and Qdb qualifiers [2, 4]. TecDoc identifies a passenger car type with a K-Type number, defined in the TecDoc Data Format as the unambiguous number of the vehicle type [5]. A K-Type sits below make and model and carries a production period and technical data, but it does not always correspond to a single engine code: TecAlliance's own API documentation shows one K-Type returned with three engine codes [6]. Where that matters for a part, exact fitment is expressed with additional criteria on the part-to-vehicle linkage [5]. TecDoc also uses other identifiers, for example N-Type numbers for commercial vehicles, and engines and axles as separate linkage targets [5].

The two keys are not cut along the same lines. One K-Type can correspond to several BaseVehicles, because a production period crosses model years. One BaseVehicle can correspond to several K-Types, because one model year covers several engines and versions. OptiCat, which built a translation aid between the two standards, makes the same point: a vehicle in one standard does not necessarily cross to one vehicle in the other, and a translation may need added information or may imply a wider range of applications than intended [7].

A fitment that is exact in one standard can become too broad or incomplete if it is converted into the other without the data needed to resolve the difference.

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

Two lines of the table deserve a comment. On delivery, TecDoc offers two routes: complete packages of TAF-formatted data, which replace the brand's data when published, and the IDP Data Supplier API, which processes individual business objects such as articles, linkages or images [8]. On the ACES and PIES side, the 2 April 2026 release brought ACES 5.0 and PIES 8.0 [9]. Earlier ACES versions could already send a digital asset with an application, but only one per application and with a single description [10]. ACES 5.0 extends this with multiple non-diagram digital assets per application and multiple descriptions per asset, while PIES 8.0 adds Extended Producer Responsibility packaging data [9]. The release also brought new schema versions of the reference databases: VCdb 2.0, Qdb 2.0, PCdb 2.0, PAdb 5.0 and Brand Table 2.0 [9].

On quality, TecDoc measures supplier data against defined KPIs and awards Certified Data Supplier status for meeting core requirements and Premier Data Supplier status for additional advanced KPIs, including product content quality and differentiation [11]. TecAlliance publishes these statuses in its data supplier list and says they strengthen a supplier's visibility and credibility in the TecDoc Catalogue [11, 12]. We covered what those KPIs are and what they can be worth in our article on TecDoc data quality. For Dr. Motor's parts catalogue project we also managed the product data and its export to TecDoc, where data quality was a central requirement.

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. Direct conversion can work. It needs source data detailed enough to resolve the vehicle differences described above, mapping tables that someone maintains as reference data changes, review of exceptions and validation of the output against the target standard. Conversion services exist, and TecAlliance itself offers ACES and PIES mapping [13], but a service does not remove the need for detailed source data and checks. The risk grows with the size of the catalogue and the number of channels: when a fix is made in one output rather than at the source, it has to be repeated in every other output.

For companies that maintain several formats and channels, i4B recommends a different architecture: one internal model of the product and its fitment, at least as detailed as each output requires. Each part carries its attributes in your own units and names, its OE and reference numbers, and every fitment constraint that actually matters for that part, such as engine code, production dates, body type or mounting position, in a form that can be expressed both as a TecDoc linkage and as an ACES application. TecDoc and ACES/PIES files are then generated outputs, each with its own mapping tables and validation, rather than sources of truth.

The dedicated PIM we built for Optimal follows this shape: one golden record for 200,000 parts and 6 million vehicle linkages, integrated with TecDoc and the ERP. That project serves European channels. Adding an ACES/PIES output to a model like this is a further mapping and validation step, not a change of the source of truth.

This is the job of a product information management system built for the aftermarket: an internal product model that 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 BaseVehicles, resolved by guesswork instead of by the engine, date and other data the supplier actually has [6, 7].

The second is product classification. You cannot assume that a TecDoc generic article and a PCdb part type line up one to one, so the mapping per category has to be agreed and owned by someone who understands both, 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. Both mappings need validation, not just a lookup table.

The fourth is free text. Fitment notes such as "with air conditioning" or "rear axle" are often typed by hand. Text like this can be indexed, searched and checked to a degree, but it is hard to interpret consistently, map to the other standard, filter on and validate semantically at scale. The Auto Care Association makes the same point: coded Qdb qualifiers replace free-form notes with consistent terms, improve searchability and can be validated, which free-form text cannot in scalable ways [14]. ACES still allows notes, and Auto Care's own data quality award criteria assess notes alongside Qdb use [15]. The practical rule is to use qualifiers and positions in ACES, and criteria in TecDoc, wherever a suitable standard value exists, and to keep text for what genuinely has no coded equivalent.

The last is timing: reference data on both sides keeps changing, and the April 2026 release came with new schema versions of every Auto Care reference database [9]. 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 move that work upstream.

FAQ

What is the difference between TecDoc and ACES/PIES?

TecDoc is the catalogue data standard and platform of TecAlliance, strongest in Europe and used globally, where articles, criteria and vehicle linkages are delivered in one model. ACES and PIES are two XML standards of the Auto Care Association, widely used in North America and increasingly in Latin America: ACES carries fitment, PIES carries product information. The biggest technical difference is vehicle identification: K-Type numbers versus BaseVehicle IDs.

Can TecDoc data be converted to ACES automatically?

Partly, and with care. Product classifications and attributes can be mapped with maintained tables that still need validation. Vehicle fitment cannot be assumed to convert one to one, because TecDoc K-Types and ACES BaseVehicle IDs are cut along different lines. Conversion can work when the source data includes the engine, date, position and other constraints that matter for each part, and when mappings, exceptions and output are reviewed and validated.

What is a K-Type number in TecDoc?

A K-Type is the TecDoc number of a passenger car type, below make and model, with a production period and technical data. It does not always correspond to a single engine code, so exact fitment may need additional criteria on the part-to-vehicle linkage. Commercial vehicles use N-Type numbers. 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, with PCdb and the Brand Table; PIES uses PCdb, PAdb and the Brand Table. The April 2026 release brought ACES 5.0 and PIES 8.0 together with new schema versions of these databases.

Do I need both TecDoc and ACES/PIES?

It depends on who you exchange data with, not only on where you sell. Many European catalogues and trading partners expect TecDoc data, and many North American retailers and distributors expect ACES and PIES files, but a company active in one market may still need both if it receives data in one standard and must deliver it in the other. If you maintain both, i4B recommends one internal product and fitment model, typically in a PIM, with both outputs generated and validated from it.

Sources and assumptions

Facts about the standards come from the sources below. The recommendation of a shared product and fitment model, the 20-part test and its threshold are i4B's own architectural advice and rule of thumb. Sources [10] and [13] describe a pre-release review and a commercial offer respectively, and are cited only for those points.

1. TecAlliance. TecDoc. Positioning, data validation and figures on article data, brands, vehicle types and linkages. Accessed 27 October 2026.
2. Auto Care Association. Aftermarket Catalog Exchange Standard (ACES). Scope, current version 5.0, supporting databases and adoption. Accessed 27 October 2026.
3. Auto Care Association. Product Information Exchange Standard (PIES). Scope, current version 8.0 and supporting databases. Accessed 27 October 2026.
4. Auto Care Association. Vehicle Configuration database (VCdb). Coverage and use with ACES. Accessed 27 October 2026.
5. TecAlliance. TecDoc Data Format, Data Format Version 2.7, document version 2.0.33. 5 October 2026. K-Type and N-Type definitions, linkage targets and linkage criteria.
6. TecAlliance. TecDoc API: Vehicle search. Example response with one K-Type and several engine codes. Accessed 27 October 2026.
7. AftermarketNews. OptiCat Announces Its New TecDoc, ACES Translation Aid. Undated industry news. Identifiers that do not cross one to one.
8. TecAlliance. A revolution in product data processing. Undated. Complete TAF packages and the IDP Data Supplier API. Accessed 27 October 2026.
9. Auto Care Association. Auto Care Association Releases ACES 5.0 and PIES 8.0. 2 April 2026. Release, digital asset changes, EPR packaging data and reference database schema versions.
10. Auto Care Association, T. Schiavo. ACES 5.0 and PIES 8.0 are Ready for Industry Review!. 2 April 2025. Digital asset support in ACES 4.2 and earlier compared with 5.0 (industry review stage).
11. TecAlliance. TecDoc Data Quality Management. KPIs, Certified and Premier Data Supplier status. Accessed 27 October 2026.
12. TecAlliance. Data Supplier List. Presentation of Premier, Certified and standard data suppliers (list marked Q1/2026). Accessed 27 October 2026.
13. TecAlliance. Meet us at Taipei AMPA 2026. Event 14 to 17 April 2026. ACES and PIES mapping listed as a service.
14. Auto Care Association. Qualifier database (Qdb). Coded qualifiers compared with free-form notes. Accessed 27 October 2026.
15. Auto Care Association. ACES and PIES: Year, Make, Model Applications Only (ACPN Content Excellence Awards). Award criteria, including assessment of notes and Qdb use; not mandatory rules of the standard. Accessed 27 October 2026.