HOME / GUIDES

GUIDE · FITMENT DATA

Duplicate applications: the fitment claims you didn’t know you made twice

A duplicate application is the same fitment claim stated more than once: identical part, part type, vehicle configuration and qualifiers appearing in a file two or more times — or, in the costlier variant, two different part numbers mapped to exactly the same configuration with nothing to tell a buyer which one belongs. The first kind bloats files and trips validators. The second kind quietly competes with your own products on every receiver that ingests it.

Where duplicates come from

Duplicates are the residue of normal catalog life. Two team members map the same new coverage in the same week. A year-range gets extended twice — once as a range edit, once as new rows. An interchange import brings applications your catalog already had under another number. Two files get merged for a line review and nobody deduplicates the union. None of these mistakes look like mistakes at the time; they look like work getting done.

The two-part-numbers variant has a more strategic origin: supersessions and tiering. The old number stays mapped after its replacement launches, or a Good and a Better part both get the whole vehicle instead of splitting it with a manufacturer label the shopper can act on. Both numbers are "right," and that is exactly the problem — the data gives the receiver no reason to show one over the other.

What duplicates cost

Exact duplicates inflate file sizes, slow receiver processing, and show up as warnings or outright rejections on submission — some receivers bounce a file for duplication alone. The conflicting kind does deeper damage: on marketplaces, two of your SKUs claiming one configuration split your own sales history, confuse fitment filters, and invite the return that follows a coin-flip purchase. One brand came to us after a receiver's vendor alleged 81,346 of its records were invalid; forensic review traced most of the claim to stale tooling, but the genuine issues underneath were exactly this pattern — supersession leftovers and twice-stated coverage.

Finding duplicates: the application key

Every ACES application reduces to a key: vehicle (BaseVehicle or Year/Make/Model plus any submodel, engine or attribute references), part type, position, the full set of qualifiers, quantity, and the part number itself. Group your file on that key. Any group with more than one row where the part numbers match is an exact duplicate — safe to collapse to one record. Any group where the part numbers differ is a conflict that needs a decision, not a delete: a supersession to honor, a tier to label properly, or a mapping error to correct.

The discipline that keeps the cleanup honest is logging. When we deduplicate, every removed or altered row is recorded — what it said, why it changed, what replaced it — so the brand can defend the file to any receiver and reverse any decision. Nothing about catalog cleanup should be a black box.

Keeping them from coming back

Deduplicate once and you have a clean file; change the process and you have a clean catalog. The habits that work: one source of truth that every edit flows through, dedupe-on-merge whenever files combine, a supersession rule that unmaps the old number the day the new one ships, and a validation pass before every submission rather than after every rejection. Our monthly monitoring does exactly this for brands that would rather not staff it — but whether you do it or we do, do it before your receiver does.

Frequently asked questions