Your Supplier Wants to Send You an ACES File. Now What?

A supplier tells you they can send their ACES file. You say sure, that sounds official. Two days later there’s a zip in your inbox with 400,000 lines of XML in it and nobody has explained what you’re supposed to do with that.

Here’s the version somebody should have given you first.

What the two things are

ACES is what fits what. One line of it says: this part number fits this exact vehicle configuration, in this position, in this quantity, with these caveats. That’s it. Fitment is just a very long list of those statements, written in a format two companies can agree on.

PIES is what the thing is. Part number, brand, the four different descriptions a catalog needs, weight, box dimensions, images, price. Nothing about vehicles at all.

They come as a pair, and you need both. PIES builds the product page. ACES decides who should be shown it.

The first surprise: there’s barely any English in it

Open an ACES file expecting to read it and you won’t.

It doesn’t say “2019 Ford F-150 XLT.” It says a number. BaseVehicleID, plus more numbers for engine, submodel, transmission, drive type. The words live somewhere else entirely — in a set of reference databases the Auto Care Association maintains and you subscribe to:

• VCdb — the vehicle database. What ID 12345 actually is.
• PCdb — part categories. What kind of thing this is.
• PAdb — the attribute vocabulary PIES items point at.
• Qdb — the standard caveats. with heavy duty cooling. to production date. 4WD only.
• Brand Table — brand and sub-brand IDs.

So the file your supplier sent is unreadable on its own. You need current reference data to turn the numbers back into words, and it gets revised — a file published against a newer VCdb can name vehicles your copy has never heard of.

That’s the first real cost of ACES and it isn’t the software. It’s that you now own a subscription with a release schedule, and a category of bug that only shows up when your copy and theirs drift apart.

Why Shopify has nothing for this

Shopify has products, variants, metafields and metaobjects. Filtering runs over product attributes.

Nothing in that list is a vehicle. There’s no application table and no real many-to-many between a product and a configuration. So every fitment app on Shopify — ours included — is translating ACES into something Shopify does understand. The interesting question about any of them is what shape they translate it into:

• Into the vendor’s own database, with your storefront asking it questions over the network. Handles feed-scale data fine. Your fitment lives somewhere that isn’t your store.
• Into metafields or metaobjects, so vehicles and applications become records inside your store. Portable, readable by anything else you own, and bounded by what the platform will hold.

We think the second is the right default for most merchants and we built ViewForge on it, so weigh that accordingly. The first is genuinely better once you’re reconciling a dozen supplier feeds.

What gets lost: the detail

This is the part that bites in month two.

ACES can say this:

Part 45231 fits a 2019 Ford F-150, 3.5L V6, 4WD, short bed, front position, quantity 2, built before March 2019.

Three dropdowns can say this:

2019 → Ford → F-150

Everything after “F-150” has nowhere to go. Which matters, because the guy with the 2.7L is about to order a part that doesn’t fit his truck and it’s going to come back to you.

Three options, all trade-offs:

1. Add more dropdowns. Submodel, engine. Accurate — and every level is one more thing the customer has to know about their own truck standing in the driveway with a phone. Levels cost you orders.
2. Show the caveats on the page. “Fits 3.5L V6 4WD, built before 03/2019.” The customer does the last bit of checking themselves. Most good storefronts land here, and it’s the honest answer when the situation is genuinely ambiguous.
3. Drop them. The dropdown says it fits. Sometimes it doesn’t. You’ve turned a data problem into a returns problem, and returns are more expensive.

Whoever imports your file is making this choice. If a vendor can’t tell you which of the three they do, that answers a different question you were also asking.

What you still have to build after the import

Say the file parsed clean. You still need all of this before anybody can use it:

• The vehicle records, in whatever structure your storefront can filter on.
• The join from your products to those records. That’s the next section and it’s the hard part.
• A filter that turns a chosen vehicle into a filtered collection fast enough not to feel broken. Its own problem, with its own four causes.
• The front end — dropdowns, the badge on the product page, the fitment table, saved vehicles.
• A coverage report. Which products ended up with no fitment at all. Skip this and you won’t find out that 12% of the catalog is invisible to the filter until a customer tells you, which is the expensive way to learn it.

None of that comes with the standards. ACES is a way to hand data between two companies. It says nothing about how to show it to anybody. A clean import is the start of the project.

The actual project: making the part numbers line up

Your ACES file is keyed to the supplier’s part numbers and brand IDs. Your Shopify catalog is keyed to your SKUs.

Those two agree less often than anyone expects, and never for exotic reasons. It’s always the same five things:

• SKUs with a prefix or suffix your store added years ago.
• Kits you assembled that exist nowhere in the supplier’s catalog.
• The same physical part sold under two brands with two numbers.
• Parts you superseded, where the supplier’s file still lists the old number.
• Whitespace, dashes, and capital letters. Always.

Every one of those is a row that quietly doesn’t match, and a part that quietly doesn’t appear when somebody picks their truck. Nothing errors. Nothing turns red. It just isn’t there.

Put a person’s name on the reconciliation and give them real hours. It is not a checkbox in an import wizard. This is where fitment projects stall after the software is already working, and it’s why “the import ran successfully” is not the same sentence as “it works.”

So do you actually need ACES?

Opinion from here, not fact.

Take it if your suppliers already publish it, your catalog is too big for anyone to maintain fitment by hand, and somebody on your side can own the matching. That’s exactly the job the standards were built for, and doing it by hand instead would be worse in every direction.

Skip it if your fitment currently lives in a spreadsheet, in your product titles, or in your head. Which is most merchants who ask us about this. Adopting ACES in that situation buys you a data subscription, a reconciliation workload and a detail-collapsing decision — to solve a problem you could solve by fixing the spreadsheet.

There’s a middle road, and it’s where most stores actually are: you already wrote the fitment down. It’s in your product titles and descriptions, added over years, one product at a time. “Fits 2015–2019 Ford F-150.” That’s fitment data. It’s messy and inconsistent and it’s yours, and lifting it into a structured table is a far smaller job than onboarding a feed.

That’s why reading existing product copy sits on our $49 tier and ACES/PIES import sits at the top — not because the standards are worse, but because most catalogs aren’t shaped like a feed yet. Pricing’s here if you want the specifics.

---

Questions we get asked

Do I need ACES and PIES to sell auto parts on Shopify? Probably not. ACES and PIES are how suppliers hand data to retailers — they are not something Shopify requires. If your suppliers already send ACES files, take them. If your fitment lives in a spreadsheet or in your product descriptions, adopting the standards is a project that solves a problem you don’t have yet.

What is the difference between ACES and PIES? ACES is what fits what. PIES is what the thing is — part numbers, brand, descriptions, dimensions, images, price. Most suppliers publish both, because you need both: PIES builds the product page, ACES decides who should see it.

Does Shopify support ACES or PIES natively? No. Shopify has products, variants, metafields and metaobjects. There is no vehicle in that list and no application table, so every fitment app on Shopify is translating ACES into something else.

What gets lost when an ACES file is imported into a Shopify storefront? Detail. ACES can say a part fits the 3.5L V6 4WD with the short bed, built before March 2019. Three dropdowns say 2019 Ford F-150. Everything after the model has to be collapsed into another dropdown, shown as a note on the page, or dropped.

Where do the ACES reference databases come from? The VCdb, PCdb, PAdb, Qdb and Brand Table come from the Auto Care Association and you subscribe to them. An ACES file is mostly ID numbers, so without current reference data you cannot read it.

---

Where the facts here come from

The standards belong to the Auto Care Association, who maintain them and license the reference databases. Both get revised, so check the current version and what a subscription costs with them rather than trusting a number in a blog post. We deliberately haven’t quoted one.

Everything about Shopify’s data model, and what the translation costs, is ours from shipping fitment search on it. Where we gave an opinion above, we said so.

Short version

ACES and PIES solve a real problem — getting two companies to agree on what a 2019 F-150 is — and they solve it well. What they don’t do is give you a storefront.

Between that file and a customer picking their truck sits a decision about how much detail you’re willing to lose, a matching job between the supplier’s part numbers and your SKUs, and a front end somebody has to build.

Got the feeds and the person? Take the standards. Got a spreadsheet and a hope? Fix the spreadsheet first. And if the fitment is already sitting in your product descriptions, start there — you have more written down than you think you do.