What ACES and PIES Actually Are (And Why Shopify Does Not Speak Either)

If you sell aftermarket parts, you have almost certainly been handed a data package and told it is "standardized." It is. ACES and PIES are genuinely good standards, maintained by the Auto Care Association, and they solved a real problem: before them, every manufacturer described a brake pad differently and every reseller rebuilt that description by hand.

What they did not solve is your storefront. ACES and PIES were designed to move parts data between trading partners in an industry that mostly ran on catalogs and distributor systems. Shopify was not one of the systems they had in mind, and it shows the moment you try to load a segment into it.

This article covers what each standard actually carries, the shape the data arrives in, and the specific places it gets flattened or dropped on the way into a Shopify catalog. It is written for the person who has the workbook open, not for a procurement committee.

ACES and PIES in one paragraph each

The two standards answer different questions and are almost always used together. Confusing them is the most common reason a data project stalls, because the two halves need different handling.

ACES answers "does this part fit?"

ACES — the Aftermarket Catalog Exchange Standard — carries vehicle fitment. Its unit is the application: a row saying that a given part fits a given vehicle. The vehicle is not free text. It references a base vehicle from a shared vehicle database, then narrows with qualifiers: engine, submodel, drive type, bed length, body style, and so on down a long controlled list.

The practical consequence is volume. A single wiper blade can carry several thousand application rows. A modest catalog segment can carry millions. This is why fitment cannot simply be pasted into a product description field and forgotten — it is relational data pretending to be a spreadsheet.

PIES answers "what is this part?"

PIES — the Product Information Exchange Standard — carries the product itself. Descriptions, prices, package dimensions, digital assets, part attributes, interchange references, hazardous material flags. Critically, PIES does not have one description field and one price field. It has several of each, distinguished by code.

That coding is the part that surprises people. A PIES record does not say "the price is 42.00." It says there is a retail price, a MAP price, and a jobber price, each tagged with its own type code. Likewise it does not carry "the description" — it carries a short description, an extended description, a features-and-benefits block, and an application comment, each tagged separately.

How the data actually reaches you

In theory ACES and PIES are XML. In practice most sellers never see raw XML. Data arrives through a distribution channel — most commonly the SEMA Data Co-op, often just called SEMA Data — which aggregates manufacturer submissions and hands receivers a package.

That package usually lands as a segments workbook: a spreadsheet with one sheet per data segment. Items in one sheet, descriptions in another, prices in another, applications in another, digital assets in another. The sheets relate to each other by part number.

This matters for a Shopify project because the workbook is already normalized in a way Shopify is not. Shopify wants one row per product with its variants attached. The workbook gives you five sheets that have to be joined before that row exists.

Where Shopify disagrees with both standards

Shopify models a product as a title, a description, some media, and up to three option dimensions producing variants. That model is excellent for apparel and unhelpful for parts. Four collisions do the damage.

1. There is no fitment field

Shopify has no native concept of an application row. There is nowhere for "fits 2014–2018 Silverado 1500, 5.3L, excluding LTZ trim" to live as structured data. It ends up as a metafield, a tag soup, a third-party fitment app, or — most often — a spreadsheet somebody maintains alongside the store and updates by hand.

The consequence is not cosmetic. Fitment held outside the product is fitment that drifts from the product, and drifted fitment is the direct cause of a wrong-part return.

2. One price field, several PIES price types

A Shopify variant has a price and a compare-at price. PIES routinely carries three or more price types for the same part. An import has to decide which survives.

Most quick imports keep the retail price and silently discard the rest. You do not notice until someone asks what your MAP exposure is across the catalog, or a dealer asks for jobber pricing and nobody can produce it without going back to the original workbook.

3. One body field, several description codes

The same flattening happens to copy. PIES distinguishes description types by code, and each has a different job.

Concatenate those into a single description field and you lose the ability to use each where it belongs. The features block cannot become bullets, and the application comment — which is often the sentence that prevents a wrong order — gets buried in the middle of a paragraph.

4. Part numbers are not SKUs, quite

A parts catalog carries several identifiers for the same item: the manufacturer part number, your internal SKU, a brand-qualified part number, and often interchange numbers pointing at competitor equivalents. Shopify has one SKU field per variant. Deciding which identifier is canonical, and where the others live, is a decision somebody has to make deliberately rather than discover after launch.

The four places parts data quietly gets lost

Across the projects we see, the same four losses recur. None of them throws an error, which is exactly why they persist.

• Fitment is downgraded to text. Applications become a paragraph rather than structured rows, so the store cannot filter by vehicle and the data cannot be validated.
• Non-retail prices are dropped. MAP and jobber pricing exist in the source and not in the destination, so pricing policy quietly stops being enforceable.
• Description codes are concatenated. Four distinct fields become one, and the application comment stops doing its job.
• The mapping is not saved. The reconciling happens in a spreadsheet, so the next catalog update starts from the top rather than re-running a decision already made.

The fourth is the expensive one. The first three cost you data quality once. The fourth costs you the same week of work every time your data provider ships an update.

What "mapping" actually means here

Mapping is not a file conversion. It is a set of decisions about your catalog, made once and then applied repeatedly. The decisions are specific and they are yours to make:

• Which PIES description code becomes the product body, and which becomes the bulleted features block.
• Which price type is published to the storefront, and which are held as attributes for policy or B2B use.
• How an application row attaches to a product — and whether a part with several thousand applications is one product or many.
• Which identifier is the canonical SKU, and where the manufacturer part number and interchange numbers live.
• What happens when a supersession replaces a part: redirect, merge, or keep both.

No tool can make those calls for you, because they depend on how you sell. What a tool can do is record the decisions so they survive the next workbook, and apply them without a human re-deriving them each quarter.

Where SEMA Data fits, and what it does not do

The SEMA Data Co-op solves distribution, and solves it well. Manufacturers publish once, receivers pull standardized data, and nobody has to chase forty suppliers for forty spreadsheets in forty shapes.

What it does not do is decide how any of that should look in your storefront. The co-op hands you correct, standardized data. It does not know that you sell on Shopify, that you run three storefronts, or that your dealers need jobber pricing while your retail customers must never see it. That translation layer is still yours, and it is where the actual work lives.

Standardized data is not the same as ready-to-sell data. ACES and PIES get everyone speaking one language. Deciding what that language means in your storefront is a separate job.

Doing this without rekeying it

This is the problem Supplier Bridge was built for, and the automotive case is the hardest version of it. It reads the segments workbook, maps its columns to your catalog fields — including the ones that need splitting apart — and keeps the mapping so the next update is a run rather than a project.

For ACES and PIES specifically, that means applications and qualifiers attach to the parts they belong to rather than living in a parallel file; MAP and jobber pricing map to their own attributes instead of collapsing into the variant price; and the four description codes land in four fields.

One honest note on how this works today. Automotive import is not a self-serve upload screen yet. We map a real segment of your data with you on a call and switch the module on for your organization once the mapping is right. A merchant-facing upload step is planned, but we would rather tell you what exists now than what is on a roadmap.

If you want the commercial version of this — what it costs, what it replaces, and how it fits a Shopify parts store — that lives on the automotive aftermarket page.

If you are earlier in the process

Not every parts seller receives ACES and PIES. Plenty are still onboarding suppliers who send ordinary spreadsheets in inconsistent shapes, which is the same problem one step less standardized.

The general version of this work is covered in how to import a supplier CSV into Shopify, and the multi-supplier case in a companion piece on onboarding several suppliers at once. The principles are identical: map once against your structure, save the mapping, and never let the reconciling live in a spreadsheet.

The short version

ACES carries fitment, PIES carries the product, and both arrive together in an SDC segments workbook. Shopify has no fitment field, one price field where PIES has several, and one description field where PIES has four. The work is not importing the file — it is deciding how each of those collisions resolves in your catalog, and recording those decisions so the next update does not repeat them.

If you are staring at a segments workbook and trying to work out where to start, start with the four decisions above. They determine everything downstream.

ACES does not spell any of this out in words — it references numeric IDs that resolve against four Auto Care Association databases. If you are looking at a file full of integers and wondering where the vehicle names went, VCdb, PCdb and PAdb explained covers exactly that layer.