Auto Parts Store Software: Fixing Fitment, Cores, and Counter Chaos

Why parts software makes or breaks an auto parts retailer

Your counter guy has three screens open. Epicor Eagle for the sale, Nexpart or Turn 14 in a browser to check what the warehouse distributor actually has, and a spreadsheet on the third monitor that tracks which core came back from which shop and whether the credit ever posted. A customer is standing there with a 2014 F-150 and no idea which of the three brake rotor variants fits, because the truck has the heavy duty tow package and the catalog does not know that unless someone typed the VIN correctly. That lookup takes ninety seconds when it should take fifteen. Multiply ninety seconds by four hundred counter tickets a day across five stores and you are burning roughly two full labor days every day, on lookup alone.

Then there is the money you cannot see. Wrong fitment comes back as a return, and a return on a special order part that shipped from a WD two states away costs you the freight both ways plus a restock fee plus the counter time plus, quietly, the customer. Cores sit in a milk crate behind the counter with a Sharpie note. At year end your controller finds a core liability nobody can reconcile against actual returns, and half of it gets written off because the paperwork trail died three months ago. The commercial accounts, the shops that make up sixty percent of your revenue, get invoiced on a matrix somebody set up in 2017 and nobody has audited since, so some of them are buying at cost and nobody noticed.

The tools are not bad. Epicor Eagle, Epicor Vision, MAM Autopart, and ARI are real products built by people who understand parts. The problem is that they were architected for a single store with a paper catalog next to the register, and every multi-location, high-volume, delivery-heavy thing you do since then has been bolted on or worked around by a human. The human is the integration layer. That is the leak.

Problem: fitment data is right in the catalog and wrong at the counter

ACES and PIES exist. Your suppliers publish to them. And yet your counter still sells the wrong water pump for a 2016 Silverado twice a month, because the ACES application record for that part has a qualifier, engine RPO code, that your point of sale does not surface, does not store, and cannot filter on. So the screen shows four options and the counter picks the one that has been right most of the time.

It gets worse at scale. You carry lines from eight or ten different suppliers, and each one publishes ACES on its own schedule with its own interpretation of qualifiers. Dorman's application data and your OE-equivalent line's application data disagree on the same vehicle. Your point of sale ingests both, flattens them, and shows a list. Nobody resolves the conflict. The counter guy does, badly, at 4pm on a Friday.

Why Eagle or MAM cannot fix it: their catalog layer is a viewer, not a reconciler. They ingest supplier ACES and display it. They have no concept of "these two suppliers disagree about this vehicle and here is which one your returns data says is correct." You cannot add a qualifier field they did not anticipate, and you cannot teach the system from your own return history.

What a custom build does: you own a normalized fitment store that ingests ACES XML from every supplier on a schedule, keys everything to the VCdb base vehicle ID, and stores qualifiers as first-class structured data instead of a display string. On top of that you run a conflict resolver: when two suppliers claim different applications for the same base vehicle, the system flags it and ranks by your own evidence, which parts actually came back as wrong-fit returns. That return data is the asset nobody else has. After eight months of tickets you know that for the 5.3L Silverado with the RPO code your counter never asks about, line A is wrong sixty percent of the time. The system stops offering it.

Where AI actually helps here: VIN decode plus natural language. The customer says "it's the F-150, the one with the tow package, and the noise is coming from the front." You capture the VIN off a photo of the door jamb sticker with an extraction model, decode it to the exact base vehicle plus options, and the symptom text narrows the part category. That turns a ninety second lookup into fifteen seconds, and it removes the most expensive human judgment call in your building.

Problem: cores are an accounting fiction

Core charges are real money. A remanufactured caliper carries a $40 core, a transmission carries $400, and at volume you are floating six figures of core liability across your stores and your commercial accounts at any given moment. Your point of sale tracks the core charge on the ticket. It does not track the core.

The concrete scene: a shop takes eight alternators on a Tuesday, returns six cores on Thursday in a mixed bin with no paperwork, and your driver signs for "6 cores." Which tickets? Which of them are actually good cores versus a cracked housing the supplier will reject? Your counter posts credits against whichever open tickets look close. Three weeks later the supplier rejects two cores on inspection and debits you back, and now the shop has a credit for a core you were not paid for. Nobody reconciles this. At my last count on a five-store client, unreconciled core float was running about $140k with roughly $35k a year quietly written off.

Why the incumbent cannot fix it: Eagle and Vision treat the core as a line item charge on a sale, not as a tracked physical asset with a lifecycle. There is no core state machine. There is no chain of custody from your counter, to the shop's bench, to your driver's van, to the WD's inspection dock.

What a custom build does: every core becomes an object with a state, sold, out, received-pending-inspection, accepted, rejected, and a link to the originating ticket line. Your driver scans a printed core tag on pickup on a phone, the app photographs the core, and the state moves. When the WD rejects it, you have the photo from the moment of pickup and the dispute takes four minutes instead of dying. Your controller gets a real-time core liability number by account and by store, not a year-end surprise. On the client above, tightening the chain of custody recovered most of that write-off in the first year, which by itself paid for a meaningful chunk of the build.

Problem: commercial pricing runs on a matrix nobody understands

You have 180 commercial accounts. Each is on a pricing tier, and the tiers were built as cost-plus or list-minus matrices layered by line, by category, and sometimes by individual part where a shop pushed back hard in 2019. The matrix lives in Eagle. Nobody has audited it end to end because auditing it means exporting to Excel and reading 40,000 rows.

What actually happens: your best shop is buying a fast-moving line below your landed cost because the supplier raised cost eleven percent and your matrix is list-minus, not cost-plus, on that category. You find out at quarter end when gross margin on that line is negative. Meanwhile a marginal account is paying near list and is three weeks from leaving for the competitor down the road.

Why the incumbent cannot fix it: the matrix is a static config table with no analytics on top. There is no "show me every account, line, and SKU where realized margin is below X." There is no alerting when a supplier cost change breaks a rule. The system will happily sell at a loss forever and never mention it.

What a custom build does: pricing becomes a rules engine that evaluates against live landed cost, not a frozen table. Every rule carries a margin floor. When a supplier price file lands and a rule would breach the floor, the affected accounts and SKUs surface on a dashboard before the next ticket, not after the quarter. You get realized margin by account, by line, by SKU, refreshed nightly, which is the single report that changes how you negotiate with both your WD and your shops. Forecasting on top of it is where a model earns its keep: given eighteen months of ticket history, predict which commercial accounts are trending down in order frequency, because a shop that drops from four orders a day to two is leaving and you have about six weeks to notice.

Problem: delivery and hotshot dispatch is a phone and a whiteboard

A shop calls at 10:40 for a part they need on the lift now. Your counter writes it on a ticket, walks it to the back, and someone yells at a driver. Three drivers are out. Nobody knows where they are or what is already in the van. The shop calls back at 11:20 asking where it is and your counter says "he's on the way," which may or may not be true.

At one store, the whiteboard works. At five stores with fourteen drivers doing 300 stops a day, the whiteboard is why your on-time rate is whatever your loudest customer says it is.

Why the incumbent cannot fix it: Eagle and MAM have delivery modules in the sense that they can print a delivery ticket. They do not do live driver location, dynamic route batching, or an ETA the shop can see. The category's DMS vendors are not logistics companies and it shows.

What a custom build does: a driver app, a dispatch board, and an ETA the shop gets by text. The build is not exotic: stops keyed to tickets, driver location on a five-second poll, batching by geography and promise time, proof of delivery by signature or photo, and core pickup on the same run. The payoff is that you can finally put a real number on delivery performance per account, and stop the thing where your worst shop gets three dedicated runs a day for $180 in gross profit.

Problem: inventory decisions are made per store, by feel

Store three has four of a part that store one has been ordering from the WD daily for two weeks. Both are running Eagle. Nobody looked. Your min/max levels were set when the store opened and get touched when someone complains. Lost sales, the part a customer wanted that you did not have, are not recorded anywhere, so your demand data only contains demand you already satisfied.

Why the incumbent cannot fix it: multi-store visibility in these systems is technically present and practically unusable, because it was designed for a chain of two stores on the same LAN. Real-time cross-store availability with a transfer workflow that a counter person will actually use at 4pm is a different product.

What a custom build does: one availability view across all stores plus your WD feeds, with the transfer decision built into the sale flow rather than being a separate task nobody does. Capture the no-sale: when a counter searches a part you do not have and the ticket does not close, that is a data point, and after a year it is the most valuable stocking input you own. Forecasting per SKU per store on real demand including lost demand, with seasonality that the model learns from your actual history and not a generic curve, is where inventory management software stops being a ledger and starts making you money. Expect to be carrying less total inventory with a higher fill rate. That is the trade every parts operator wants and no off-the-shelf system delivers.

What this costs and how long it takes

These are Digital Heroes delivery bands from across 2,000-plus projects, not a market survey. A focused first release, one problem solved properly, runs $60k to $130k and ships in 12 to 16 weeks. In this category the right first release is almost always either the fitment layer or the core lifecycle, because both have a hard dollar number attached that you can measure in ninety days. A full platform, counter workflow plus fitment plus cores plus commercial pricing plus dispatch, runs $150k to $400k phased over 6 to 12 months.

What drives the number up specifically here:

Supplier integration count is the biggest single lever. Two WD feeds is a normal build. Nine WD feeds, each with its own flavor of ACES and PIES, its own price file format, and one of them still on flat files over FTP, is a different project. Every integration is real work and some suppliers will make you wait weeks for credentials.

Coexisting with the incumbent point of sale rather than replacing it costs more up front and less in risk. If Eagle stays as the accounting and general ledger spine and your build sits alongside it, you are writing a sync layer, and Eagle's data access story is not generous. Budget for that honestly. It is still usually the right call.

Catalog data cleanup is the invisible line item. If your SKU master has duplicate parts under three supplier numbers and no consistent part terminology ID, somebody has to fix that before any of the good stuff works. On a 60,000 SKU master expect a real chunk of the first phase to be data work. It is unglamorous, and nothing above it functions until it is done.

Build versus buy: take the position

Buy, genuinely, if you are one or two stores doing mostly DIY walk-in with under 25,000 SKUs and light commercial. Epicor Eagle at that size is a good product for a fair price and building anything is a bad use of your capital. Same answer if your business is stable and you are not fighting a competitor on delivery or fill rate. The incumbent is fine. Go run your stores.

Build when these show up. You have three or more locations and cross-store visibility is a phone call. Commercial is more than half your revenue and you cannot produce realized margin by account without a week of Excel. Your core liability is a number your controller guesses at. You are paying for two or more bolt-on tools plus a headcount whose actual job is retyping data between systems. Or, the clearest signal, a competitor is beating you on delivery promise time and you cannot even measure your own.

The mistake operators make is framing it as replace-everything-or-nothing. The right move in this category is almost always to leave the point of sale as the system of record for money, and build the layer above it where the specific things that make you money or lose you money actually live. Fitment, cores, commercial margin, dispatch. Those four are yours. Nobody is going to build them for your business but you.

How to choose a developer for auto parts store software

Ask them to explain ACES and VCdb without you prompting. If a developer cannot tell you what a base vehicle ID is, why qualifiers matter, and how PIES differs from ACES, they will spend your first $40k learning it on your clock. This is the single fastest filter and almost nobody passes it.

Ask what they have integrated. Not "we do integrations." Ask specifically: have you pulled from Epicor's data layer, have you worked with a WD punchout or Nexpart, have you parsed a supplier price file that arrives as a fixed width text file at 2am. The answer tells you whether the estimate is real.

Ask how they will handle the data migration and the cleanup, and make them scope it separately. If migration is a line item that says "data migration, $8k," they have not looked at your SKU master. A firm that has done this will ask for an export before they quote.

Get code ownership and the deployment story in writing before you sign. You should own the repository, the infrastructure accounts should be in your name, and there should be a documented path where another firm can pick this up. If a developer resists that, the software is not the product they are selling you. Your dependency is.