Who updates the price list?

A new price book arrives from one of the dealer's five manufacturers. Between that file landing in an inbox and a salesperson quoting from it with confidence sits a process — and whether that process was designed or improvised is half of what the system will cost to run. This is what the update path looks like in a system built to survive twelve months of real cycles.

Count the formats first

Start by counting the source formats — not the manufacturers. The two numbers are not the same. Manufacturers send price lists per product series, and different series arrive in different formats and different file types from the same factory. One series comes as a structured spreadsheet; the next, from the same brand, as a PDF laid out for print. A dealer with five brands is rarely dealing with five formats. Five is the floor.

This is not a Polish peculiarity or a machinery peculiarity. ETIM International — the standards body for technical product data — describes the same landscape across technical trade generally: suppliers differ in language, units, field semantics, identifiers, update timing, and file structures, and the receiving side spends its time retyping, converting, and chasing what is missing. The count takes an afternoon. Everything downstream — tooling, effort, and what the update path costs — follows from it.

Ask the factory to standardize — then plan for no

The first move is the cheap one: ask the manufacturer for a consistent format. It costs one conversation, and where the relationship is strong it sometimes works. We propose it on every engagement.

The honest read, after enough of these conversations: if a manufacturer has not standardized its price lists by now, the probability that it will do so for one importer is low. Classification and exchange standards exist — ETIM 10.0 is open and free, BMEcat has been an exchange format for years — and they genuinely help where a manufacturer uses them. But a dealer's update path cannot assume them. It has to be built for the price books that actually arrive, in the shapes they actually arrive in.

Run the first cycles by hand

**On our current builds, we run the price-list updates ourselves for the first three to six months. Forklift price books change roughly every six months, so that window covers at least one full real cycle across the brands. During the window we build the extraction tooling — AI-assisted where the documents cooperate, hand-written where they do not — against the files the manufacturers actually send, not against a sample someone cleaned up for the demo.

There is a threshold worth writing down: only after roughly 80 percent of the update cycles have gone through by hand is there enough evidence to judge whether automating them is honest engineering or a promise. Before that point, nobody knows which formats break, which fields arrive half-empty, or which series quietly changed structure since the last book.

And there is a trade-off to name plainly, because it runs against the instinct of every software vendor including us. Prices change twice a year. A full self-service update product — the interface, the validation, the training — can cost more to build than years of assisted updates cost to run. Sometimes the right answer is that the vendor keeps doing the updates under the availability commitment, and the automation is never built. That is not a failure of ambition. It is arithmetic, and it should be run per dealer, not assumed in either direction.

Build the approval path before the automation

A price-list update is not dragging a spreadsheet into a window. In a system that has to survive audit questions and old quotes, the path from received file to published price runs through eight distinct steps — and each one has an owner.

Step	What happens	Who owns it
Intake	File received, series identified, format recognized	Dealer office / vendor
Extraction	Values proposed out of the spreadsheet or PDF	Vendor tooling
Mapping check	Every value lands in the right place in the data model — model, configuration, instance	Vendor
Confidence split	Each value classed as read with confidence, uncertain, or missing	Vendor tooling
Comparison	Proposed values set against what the database holds today	System, reviewed by a person
Approval	A named person confirms; nothing publishes without it	Dealer
Publish	New prices go live with an [effective date](/glossary/effective-dated-pricing), as a new version	System
History	The superseded list stays retrievable — old quotes still reference it	System

The middle of the table is the part vendors skip in demos. A person walking through the update needs to see three classes of values, not one: the numbers the system read with confidence, the numbers it is unsure about and someone must confirm, and the numbers that are missing entirely. That takes a dedicated interface — its own screens, its own backend — and it takes a walkthrough, because the person clearing the queue is an office employee or a salesperson, not an engineer. Note what the path does not require: the Comarch or SAP ERP. List prices flow from the catalog to quotes, not through the ERP — which is part of why quoting is the workable place to start, before any integration project. Building this is why "the system updates the price list" is a feature the size of a small application.

The shape of the whole path is worth keeping in view: catalogs and spreadsheets load into a database in the right format, the application reads from the database, and any AI in the system works at the extraction step, proposing values for review — never in the live path between a salesperson and a price. Why the work concentrates there, and what the raw material looks like, is the data problem nobody quotes for.

Where it breaks

The skipped quarter. The symptom is a customer pointing out that the quote is wrong — the price list on their desk is newer than the one in the system. The cause is almost never the software; it is that the update had no named owner, and the person who "usually did it" was busy for six weeks. The fix is boring and works: the update is a job with a name and a recurring slot in the calendar, not a task that happens when someone remembers. What happens when the named person disappears is its own question, and it deserves to be asked before the build, not after.

Two brands, two rhythms. The symptom is a mixed quote — two manufacturers on one offer — correct on one line and stale on the other. The cause is designing the update path as if there were one refresh cycle, when each manufacturer runs its own. The fix is a per-brand cycle calendar and staleness warnings in the application, so a salesperson can see that one catalog is four months older than the other before the customer does.

Discounts drift from prices. The symptom is margin quietly slipping while every list price is current. The cause is that prices and discounts are separate layers — fixed list prices, variable discount rules — and the update refreshed one without anyone re-checking the other. The fix is an approval step that shows both deltas side by side: what changed in the list, and what that does to every discount rule that references it.

What to verify before you sign off

Six checks, each one runnable by the dealer, none requiring an engineer.

• Every source format has been seen once. A sample file from every manufacturer and every product series went through the path before the update process was priced — not a cleaned-up example.
• Uncertain values have a queue and the queue has a person. The system separates confident, uncertain, and missing — and someone is named to clear the middle column.
• Approval is a person, not a default. Nothing publishes to the live catalog without a named sign-off.
• History is retrievable. Pick an old quote and open it: it renders with the prices it was sent with, not with today's.
• The cycle has an owner and a calendar. A name and a recurring date, per manufacturer, written down.
• The exit from manual is a decision point, not a promise. After the first cycles, automation gets judged on the evidence — and "we keep doing it for you" is allowed to be the answer.

On one engagement we underestimated the data-preparation side of this by roughly four weeks; the customer accepted the shifted timeline, and the lesson stayed. We do not propose automated price-list ingestion in a first proposal anymore — the first cycles are manual on purpose, priced as work, and they are where the real format landscape shows itself.

The update path above is the data half of the two decisions that set what a quoting system costs over five years — who maintains the data, and who operates it. A dealer who can answer both before the build has priced the system; one who cannot has priced the demo. Worth doing carefully.