The data problem nobody quotes for in machinery-dealer AI

The bottleneck in a machinery dealer's quoting is almost never the quote. It is the data underneath it — and that data arrives as five manufacturers' price books, in five formats, none of which was built to be compared. A quoting tool that assumes clean input is solving the part of the problem that was already easy. This essay is about the part that is not, because that part is the project.

We build custom software with applied AI for machinery dealers, and the quoting engagements all pass through the same room before they get anywhere near a model. It is worth being precise about what is in that room. A forklift is not a product; it is a model with a mast, a battery, a cab, and a list of options, and each of those has its own price and its own compatibility rule. Multiply by the number of variants, then by five brands, and the catalog is not a spreadsheet — it is a small, contradictory database that lives across PDFs, Excel files, and one salesperson's memory.

Where the mess actually is

The dealers we work with rarely describe their problem as a data problem. They describe it as quoting: it takes too long, the offers are inconsistent, every salesperson keeps their own, and nobody can see anyone else's. But walk backward from any of those symptoms and you arrive at the same place. There is no single, current, trusted representation of what the dealer sells and what it costs. The quote is slow because the data is scattered; the offers disagree because the price lists do.

This is the part that does not show up on the demo. In a demo, the catalog is one clean file from one manufacturer. In production, a mid-market distributor carries several brands whose lists arrive on different schedules, in different structures, with model codes that overlap and options that mean different things depending on the series. One manufacturer thinks in series; another thinks in individual models. Reconciling that into one addressable catalog is invented work — the dealer never needed a canonical product code before, because a person held the mapping in their head.

That work is not glamorous and it does not demo well, which is exactly why it is underpriced. The market sells the five minutes where a tool reads a PDF. The engineering is in the structure the PDF gets read into, and in keeping that structure true.

Extraction is the easy 20%

There is a fair claim that modern models read documents well, and for clean documents they do. The trouble is that manufacturer price books are the hard case, not the clean one — long, tabular, footnoted, with merged cells and effective dates buried in the header. On a benchmark of long real-world PDFs, the best frontier model of 2024 reached an F1 of 44.9 on document questions, and roughly a fifth of the questions could not be answered from the document at all (Ma et al., 2024). A broader document-parsing benchmark the same year found accuracy dropping sharply on complex layouts, with missing content and hallucinated content among the observed failure modes (Ouyang et al., 2024).

So extraction is not a solved step you can trust blind. It is a candidate-generation step whose output has to be reviewed before it becomes a price anyone can quote from. This is not a Syndicai opinion; it is how the US standards agency built its own technical-document annotation system — as machine assistance for a human reviewer, not full automation (NIST, 2024). The design pattern that survives production is: the model proposes, a person accepts, and only accepted data becomes the catalog the quoting app reads. We wrote about where that boundary sits, and why a model must never be the final calculator for a price, in the pillar of this cluster.

Which reframes what "automating extraction" buys you. It does not remove the review; it changes what the reviewer is doing — from typing to checking. If the tool is good, the checking is faster than the typing was. If the tool is trusted when it should not be, the checking disappears and the errors ship. The honest measure of an extraction step is not how fast it reads the PDF. It is corrections per hundred fields, and how many of those corrections a tired reviewer will actually make on a Friday afternoon.

Maintenance is the product

Here is the fact that decides these projects, and it is the one no proposal mentions: the catalog is not built once. Manufacturer prices change every three to six months, and each change is a new list in the old messy format. The dealer who was sold an "AI quoting tool" discovers, one quarter later, that the tool is only as current as the last painful import — and that the import is now their job.

This is the long tail of the system, and the consulting engagement model is structurally bad at pricing it. The first import is a project with a budget. The fourth import, in month ten, is an operational cost nobody scoped. So the actual product we ship is not the first clean catalog. It is a repeatable release process for prices: a new list comes in, the model re-extracts, the reviewer sees only what changed, the change set is approved, and a new catalog version is published that the app reads from. Old quotes still resolve against the version they were sent under. There are two ways this usually goes — the dealer treats price updates as a recurring, owned release, or they treat them as an emergency every quarter — and only one of them is a system.

None of this is a new discipline in the abstract. Product information management and master data management have named the "one trusted product record" problem for years. What is specific here is the dealer shape of it: heterogeneous manufacturer price books, a visible verification cost, AI used during ingestion rather than on every live quote, and a versioned catalog-to-database-to-app path. The industry data lines up with what the room looks like. In one manufacturing survey, 30% of respondents named poor data quality as a top obstacle to industrial AI (Manufacturing Leadership Council, 2024); in another, only 29% of technology leaders strongly agreed their data was ready for the AI they wanted to build on it (IBM, 2024). The model was never the constraint. The input layer was.

What a clean catalog actually looks like

On the multi-module platform we are building now for a Polish industrial-equipment distributor, the catalog is not a table — it is three layers. A model, a configuration, and an instance, with a deliberate split between fixed prices and variable discounts, so that the thing a salesperson selects and the thing that gets priced are not the same object. Quote versioning is handled as an immutable snapshot per send, so a quote is always reproducible exactly as the customer received it. This is the substructure the quoting screen sits on. The screen is simple on purpose; the catalog under it is where the care went.

The comparison worth drawing is between the two ways a dealer can hold this.

	Scattered price books	A versioned catalog
Source of a price	Whichever file the salesperson opened	One current, approved catalog version
When a manufacturer updates	Someone edits several spreadsheets by hand	Re-extract, review the diff, publish a new version
Reproducing last month's quote	Hope the file still exists	The immutable snapshot it was sent under
Who can quote consistently	Whoever has the latest files	Everyone, from the same source
What AI is doing	Nothing, or generating prices live	Reading and structuring the input, once, for review

What to get right before the tool

If you are evaluating an AI quoting vendor, the questions that predict production are not about the model. They are about the data: which manufacturer formats can it ingest, what does the human review step look like, how are price updates handled three months from now, and who owns the catalog version when a wrong number is found. A vendor who answers those with "our AI handles it" is describing the demo. A vendor who answers with a review queue, a diff, and a version history is describing a system.

The interesting engineering work in a dealer quoting project is almost never the model; it is the catalog and the release process that keeps it true. The intelligence belongs in the data behind the offer, not in writing it — and the system that ships is a simple app the sales team quotes from, built on a catalog someone can keep current. Where those prices come from once the catalog exists, and whether feeding your data to a model is safe, is the next question in this cluster. Worth doing carefully.