Auto Parts Store Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the fitment layer keep getting built as a viewer?

Because the requirement gets written as: show the customer which parts fit their vehicle. That is a display problem, so a developer ingests each supplier's application data, flattens it, and renders a list. The list is correct in the sense that everything on it came from a supplier feed. It is useless in the sense that three of the four entries do not fit the truck in front of you.

Two things break specifically in this industry. Qualifiers get dropped. Application records carry conditions such as an engine option code or a tow package that decide the answer, and a system storing applications as a display string cannot filter on them. And suppliers disagree. You carry lines from eight or ten sources, each publishing on its own schedule with its own interpretation, so an aftermarket line and an original equipment equivalent line make different claims about the same vehicle and nobody resolves it.

Build a normalised fitment store instead. Ingest application data from every supplier on a schedule, key everything to the base vehicle identifier, and hold qualifiers as structured fields rather than text. Then add the part nobody else can copy: a conflict resolver ranked by your own wrong fit return history. After eight months of tickets you know which line is wrong most often on a specific engine configuration, and the system stops offering it.

Ask a developer to explain base vehicle identifiers and qualifiers without prompting, and how part attribute data differs from application data. Almost nobody passes, and the ones who fail will learn your industry on your budget.

What goes wrong when the stock keeping unit master gets migrated?

It is worse than anyone admits until somebody opens the export. The same physical part exists three times under three supplier numbers with three descriptions. Part terminology identifiers are inconsistent or absent, so categories cannot be trusted. Superseded numbers point at parts you no longer carry. Kit components exist as separate items in one store and as a single item in another, because the two stores were set up four years apart by different people.

Migrate that as it stands and everything above it fails. Fitment resolution cannot work when one part appears three times. Cross store availability shows nothing because the two stores use different numbers for the same item. Demand forecasting splits one part's history across three records and concludes all three are slow movers.

The fix is unglamorous and it is a real phase. Deduplicate against manufacturer part numbers with a human deciding the ambiguous cases, assign consistent terminology identifiers, resolve supersessions, and normalise kits. On a master of sixty thousand items this consumes a meaningful share of the first release and nothing above it functions until it is done.

Protect yourself in the quote. A proposal listing data migration as a flat few thousand dollars means nobody looked at your export. Send one before signing, and ask what percentage of items they expect to need human review. A specific answer means they have done this before.

Why do warehouse distributor and point of sale (POS) integrations break after launch?

Because each one is a different animal wearing the same word. A distributor punchout is a browser session. A price file may arrive as a fixed width text file over an old protocol at two in the morning. Application data arrives as structured files on a monthly cycle. Your point of sale exposes a data layer that was not designed for anyone else to read.

They break for ordinary reasons. A supplier adds a column to the price file and every downstream field shifts by one, so costs land in the wrong place and the file still imports cleanly. A distributor rotates credentials without notice. A point of sale upgrade changes an export column header and the nightly synchronisation stops, silently, because the job completed with zero rows.

The countermeasures belong in the first release, not the second. Validate every inbound file against an expected shape and reject the whole file rather than importing half of it. Compare row counts and totals against the previous run and hold anything that moves beyond a tolerance for human release. Give every feed a visible last success timestamp on a screen somebody actually looks at. And alert on zero row imports, because zero rows is the most common silent failure and the easiest to catch.

Ask a developer what happens when a supplier price file arrives with an extra column. If the answer is that the import is configurable, they have not run one of these in production.

What happens when core tracking and lost sales are not covered?

Both get cut from scope because neither shows up on a sales report, and both are money.

Core charges are real liability. A remanufactured caliper carries a modest core, a transmission carries a large one, and at volume you are floating a significant balance across stores and commercial accounts at any moment. Most systems treat the core as a charge line on a ticket rather than as a tracked physical object, so there is no chain of custody from your counter to the shop bench to the driver's van to the distributor's inspection dock. Cores come back in a mixed bin, credits get posted against whichever open tickets look close, the distributor rejects two on inspection weeks later, and the reconciliation dies. Model the core as an object with states from sold through out, received, inspected, accepted or rejected, linked to the originating ticket line, with the driver scanning and photographing at pickup.

Lost sales are the second omission. When a counter person searches a part you do not have and the ticket does not close, that is the single most valuable stocking input you own, and almost no system records it. Without it your demand history contains only demand you already satisfied, which is why min and max levels set when the store opened never improve. Capture the no sale from the first day, because it takes a year of accumulation before it becomes useful.

Should you build custom or configure what you already own?

If you run one or two stores doing mostly walk-in retail with under twenty five thousand items and light commercial business, configure Epicor Eagle properly and spend the capital elsewhere. It is a fair product at a fair price for that shape of business, and building anything would be a worse version of what you already have. MAM Autopart is a reasonable alternative and ARI serves parts of the market well.

The more important point applies to larger chains too: the mistake operators make is framing this as replace everything or nothing. In this category the right move is almost always to leave the point of sale as the system of record for money and build the layer above it where margin actually lives. Fitment resolution, core lifecycle, commercial pricing and dispatch are yours, and no register vendor will build them for your specific business.

Build when the signals stack up. Three or more locations where cross store visibility is a phone call. Commercial exceeding half your revenue with no realised margin report by account without a week of spreadsheet work. A core liability figure your controller guesses at. Two or more bolt-on tools plus a person whose real job is retyping data between systems. Or a competitor beating you on delivery promise time while you cannot measure your own.

How do hidden costs get into the quote?

Supplier integration count is the biggest single lever and the one most often underpriced. Two distributor feeds is a normal build. Nine feeds, each with its own file conventions and one still on an old transfer protocol, is a different project, and some suppliers will make you wait weeks for credentials before anything can be tested. Price per feed, not in aggregate.

Coexisting with the incumbent point of sale is the second. It costs more upfront and less in risk, and it means writing a synchronisation layer against a data access story that was never designed to be generous. Budget it honestly rather than assuming an interface exists.

Catalog cleanup is the third, covered above, and it is invisible until somebody opens the file.

Hardware and the counter environment is the fourth. Label printers, scanners, receipt printers and the specific screen resolution on twelve year old counter terminals are all real integration work, and a system that is beautiful on a laptop and unusable on the actual hardware will be abandoned by the people who have to hit a target on a Saturday.

What separates a build that works from one that fails here?

The ones that work pick one problem with a hard dollar number and ship it in one store first. Fitment accuracy or core lifecycle both qualify, because both can be measured in ninety days. Chains that attempt a full platform in one phase run out of patience before anything reaches a counter.

They keep the register. Every operator who tries to replace the point of sale in the first release regrets it, because payment processing, hardware certification and tax handling are surfaces you do not want to own while you are also learning to build software.

They design for the counter person, not the owner. If a lookup takes more keystrokes than the current screen, it will not be used at four on a Friday regardless of how much better the data is. Watch a counter for two hours before writing a specification.

And they settle ownership before signing. You should hold the repository, the cloud accounts should be in your name, and documentation should be good enough for another firm to pick the work up. If a developer resists any of those three, the software is not what they are selling you.