How to compare supplier quotes without a spreadsheet

Every buying team has a version of the same file. It is called something like Quotes_Final_v3_UPDATED.xlsx, it has one column per supplier, and somewhere between the third quote arriving and the meeting where a decision is due, it stopped being trustworthy and nobody wants to say so.

The spreadsheet is not the villain. It is the most honest tool available for a process that was broken before the file was created: quotes that arrived as PDFs and email paragraphs, each defining the purchase slightly differently, hand-copied into a grid that flattens those differences into false comparability. The fix is not a better spreadsheet. It is producing quotes that do not need one.

Why quote comparison goes wrong

Watch what actually happens when three quotes land in an inbox.

Supplier A quotes the list you sent, with delivery included, 30-day terms. Supplier B quotes a slightly different list, because they substituted an "equivalent" item, excluded delivery, and offered 15-day terms with a discount. Supplier C sent a PDF with one total and a sentence promising "full scope as discussed."

None of these are dishonest. Each supplier quoted the way their own systems and habits produce quotes. But the moment you type three numbers into three cells, you have asserted that they answer the same question, and they do not. The grid looks rigorous. The rigor is cosmetic.

Then the process problems stack on top:

• Re-typing is a defect factory. Every number moved by hand from a PDF into a cell is a chance for a transposed digit. The bigger the bill of quantities, the more certain the error.
• Versions multiply. The file gets emailed, edited, re-emailed. By decision day there are four copies and a debate about which one is current.
• Clarifications fork the data. Supplier B revises their price after a phone call. The spreadsheet now disagrees with the email thread, and only one person knows why.
• The reasoning evaporates. The sheet records numbers, not judgment. Six months later, when someone asks why Supplier B won at a higher price, the answer lives in a departed employee's memory.

Where the spreadsheet mechanically fails

Beyond the process problems, the spreadsheet breaks at specific mechanical points. Naming them matters, because each one survives even a careful operator.

Normalization. One supplier quotes per unit, another per box of 24, a third in a different currency. Before any cell is comparable, someone converts, and the conversion assumptions (which exchange rate, which date, rounded where) live only in that person's head. Exclusions are worse. "Delivery not included" is not a number, so it becomes a cell comment, then a footnote, then forgotten, and the grid ends up totalling figures that were never measuring the same scope.

Formula drift. Comparison sheets accumulate logic: a weighting here, a conversion there, a SUM range someone extended for a fourth supplier and half-updated. Nobody reviews spreadsheet formulas the way code gets reviewed, so a broken range or a hard-coded override sits invisibly under a confident-looking total. Whether the sheet's answer is right depends on formulas nobody can inspect from the outside.

No lineage. A number in a cell has no memory of where it came from. Was that price taken from the original PDF, the revision after the call, or the discount mentioned on the phone? The sheet cannot say. When two people disagree about a figure, the only arbiter is re-reading the source emails, which is exactly the work the spreadsheet was supposed to replace.

No shared present tense. The sheet is a snapshot that starts aging the moment it is saved, while the quotes underneath it keep moving. Every revision reopens the question of whether the grid still reflects reality, and close to a deadline nobody has time to re-verify all of it. The decision gets made on the version people hope is current.

The principle: comparability is created at the request, not the comparison

Here is the shift that makes the spreadsheet unnecessary. Comparable quotes are not something you assemble after the fact. They are something you cause, by controlling the question every supplier answers.

That means one structured request, sent identically to every supplier, with:

1. Itemized line items. Quantities, units, and specifications per line, not a paragraph of scope. A supplier cannot silently substitute or exclude when the line forces an answer per item. Writing that item list well is a skill of its own; building a bill of quantities that produces comparable bids covers it in detail.
2. Explicit terms. Delivery point, delivery date, payment terms, validity period. Stated by you, once, instead of proposed differently by each supplier.
3. The same questions for everyone. If warranty, lead time, or certifications matter, ask for them as structured fields, not as whatever each supplier volunteers.
4. One deadline and one channel for questions. When a supplier asks a good question, the answer goes to all bidders, so everyone keeps pricing the same request.

Do this and the "comparison" step nearly disappears. The quotes arrive already aligned, because they were forced into alignment at the moment of asking.

What the structured version looks like in practice

On VEXORS, the flow above is the product. You publish the request once: line items, terms, deadline, and any questionnaire. You invite your own suppliers, and optionally discover new ones by category. Bidding is free for them, so widening the field costs nothing.

The bids come back in the request's structure. Price per line, terms answered, documents attached, questionnaire completed. The side-by-side view exists the moment the second bid arrives, without anyone re-typing anything, and it cannot fork into versions because there is exactly one of it.

Clarifications run in a thread attached to the request. When you answer, every bidder sees the answer, and revised bids replace old ones in place. The comparison always reflects the current state of every offer.

Then the part a spreadsheet never did: evaluation. AI scoring reads every qualifying bid against your criteria, ranks them on price, compliance, and quality, and writes down its reasoning. You can accept the ranking or override it; either way the award decision is recorded next to the bids it chose between. The question "why did we pick them?" has a permanent answer.

Weighted scoring, done honestly

Price is rarely the whole decision, and this is where most comparisons drift into hand-waving. Weighted scoring fixes that, but only when it is done in the right order.

The rule: criteria and weights are set before the bids arrive. Decide up front that price is worth half the decision, delivery time less, warranty the remainder, and write that into the request. Set the weights afterwards and they bend, consciously or not, toward the supplier someone already prefers. A score reverse-engineered from a preference is worse than no score, because it dresses a gut call in the costume of analysis. Choosing the criteria themselves is its own discipline; supplier evaluation criteria that predict performance covers it.

On VEXORS the criteria travel with the request, so every bidder knows how they will be judged before they price. When bidding closes, AI scoring reads each qualifying bid against those declared criteria and produces a ranking with a written rationale per bid: where it scored well, where it fell short, and why it landed where it did.

Two things are worth stating plainly. The scoring explains itself, so you are never asked to trust a bare number. And the ranking is an input, not a verdict. The buyer makes the award, can overrule the ranking, and the decision is recorded next to the reasoning either way. The machine does the arithmetic; the buyer owns the judgment.

A worked example

Here is the shape of a weighted comparison, with deliberately simple, illustrative numbers. Three suppliers, weights declared in the request before bidding opened: price 50%, delivery time 30%, warranty 20%. Each criterion is scored out of 10.

Supplier A is the cheapest and would win any comparison sorted by price alone. But the weights, fixed before anyone quoted, said delivery and warranty together carry half the decision, and A is weak on both. B wins, and nobody has to argue in the award meeting about whether delivery "really matters this time," because that question was settled when the request was written.

The arithmetic is trivial, and that is the point. What the table cannot fake is the sequence: the weights existed before the bids did. A spreadsheet can hold this same grid. What it cannot do is prove to an auditor, or to a losing supplier, that the weights were not adjusted after the numbers came in.

The honest cost-benefit

A spreadsheet is free and familiar. A structured process asks you to write a proper request up front, and that is real work, usually an hour you were previously spreading across three weeks of clarification emails.

What you get back:

• Time. The comparison assembles itself. The chase-and-re-type loop is gone.
• Error removal. No transcription means no transcription errors, on exactly the numbers that matter most.
• Leverage. Because collecting a fourth or fifth comparable quote is nearly free, you can invite more suppliers, and suppliers quoting against real competition sharpen their numbers.
• A record. Every request, bid, revision, and award is timestamped in one place. Audits, handovers, and "what did we pay last time?" become lookups instead of archaeology.

The teams that feel this most are not the largest ones. A two-person buying team drowning in renewals gets the same structural benefit as a procurement department, because the problem was never headcount. It was that every quote answered a different question.

Start with one request

You do not need a migration project. Pick the next purchase where you would normally email three suppliers, and run it as one structured request instead: the free Explore plan covers it, and your suppliers pay nothing to bid. If you would rather not write the request from scratch, the ready-made request templates give you a starting structure. Compare the experience against your last spreadsheet cycle, and let the difference make the argument.