Elora Grid
3 min read

Your price book is lying to you: keeping estimates accurate when supplier quotes arrive as PDFs

Estimating accuracy dies quietly in the gap between supplier PDFs and the master pricing workbook. Four failure modes, the thresholds that catch them, and the safety rules any automation must obey.

Every month, supplier quotes arrive as PDFs and Word attachments. Someone re-types them into the master workbook between other jobs. And every estimate your team produces stands on that workbook being right.

How does a price book actually go wrong?

Four failure modes account for nearly all of the damage:

  1. Transcription errors. A transposed digit on a breaker price doesn't announce itself. It flows into the next estimate, and the margin pays.
  2. Stale quotes. The supplier re-priced in March; your workbook still says January. In volatile categories (copper, switchgear, freight-exposed parts), 60-day-old pricing is fiction.
  3. Flatlines. A price that hasn't moved in twelve months looks stable. More often it means nobody has asked. The correction arrives all at once, mid-project.
  4. Unnoticed spikes. A genuine 30% increase lands in the workbook without anyone asking why, whether it's negotiable, or whether an alternative exists. The information was there; nobody was looking.

Which thresholds are worth flagging?

You don't need machine learning to catch most of this. You need rules that actually run, every month:

CheckThreshold that worksWhat it catches
Movement> 25% vs last monthMarket moves and typos
StalenessQuote > 45 days oldPricing drift in volatile categories
FlatlineUnchanged 12 months"Stable" prices nobody has tested
Peer outlierFar off comparable partsMis-matched or mis-keyed line items

The thresholds matter less than the consistency. A human doing this across a 32-sheet workbook does it well in week one and skips it by month three. Deterministic rules don't get bored.

What must automation never be allowed to do?

If you put software, AI or otherwise, in front of your pricing workbook, three rules are non-negotiable:

  • Never write without a backup. Every change must be revertible to any prior version.
  • Never write without approval. The system proposes; a human disposes. A review copy should explain each change and each flag in plain English before anything touches the master.
  • Never guess a match. When a quote line doesn't clearly map to a workbook row, it gets flagged for a human. A confident wrong match is the original failure mode, automated.

Add one more for completeness: when a supplier hasn't quoted this month, the system should notice and draft the chase email, and stop there. Drafts get sent by people.

What does this look like in practice?

This is the workflow behind Elora Grid's "keep our price book current" task: quotes in PDF and Word are read, matched into the workbook, run through exactly these audit rules, and presented for approval with a color-coded review copy: backup taken first, nothing written until you say so. The page includes an interactive demonstration with a sample quote.

Or skip the reading and send this month's quotes through. You'll get back the updated book, the flags and the chase drafts to judge for yourself.

FAQ

Quick answers

What is a price book in estimating?

The master record of current supplier pricing, usually a multi-sheet workbook covering part categories, that estimators draw on when building quotes. Every estimate built on it inherits its accuracy.

How often should supplier prices be reviewed?

Treat quotes older than 45 days as stale in volatile categories, and chase refreshed pricing monthly. Just as important: flag prices that haven't moved in a year, because unchanged often means unexamined, not stable.

What price movements should be flagged for review?

A movement threshold around 25% month-on-month catches genuine market moves and transcription errors alike. Pair it with staleness (>45 days), flatline (12 months unchanged) and peer-outlier checks for full coverage.

Is it safe to let AI update a pricing spreadsheet?

Only with hard rules: a backup before every write, no write without explicit human approval, unmatched line items flagged rather than guessed, and a review copy that explains every change in plain English.

Send a real tender. Get the output back.

Hand Elora Grid one real task and judge the result yourself.