Compare supplier quotes through a reviewable procurement workflow.

1. Define the request before automating document reading.

Give the request an identifier and specify the item, quantity, unit, delivery location, required date and mandatory criteria. Separate requirements from preferences. When the specification changes, create a revision: offers based on different requests must not be treated as directly equivalent.

Decide which fields must match and which may represent an alternative. A compatible replacement offered by a supplier remains an explicit variant; it must not silently replace the requested item code. This preparation reduces ambiguities that document extraction alone cannot resolve.

2. Extract values with their source references.

For each offer, retain supplier, quote number, date, revision, validity and original document. The system may propose line items, quantities, stated prices and notes, but reviewers need to see the source page for each material value. Missing information remains an open clarification.

Pay attention to merged cells, lines split across pages and terms at the end of the document. Microsoft’s document-confidence guidance distinguishes fields and tables. Procurement comparison needs checks both on individual values and on whether they were associated with the correct line.

3. Normalise only what can be compared.

These values are invented to explain the method and are not market prices. A does not yet have a complete total; B can be converted to a common unit after its pack contents are verified; C is not directly comparable until the variant is assessed. Sorting only by unit price would conceal those differences.

Scroll the table to compare all columns.

4. Maintain a clarification queue.

Assign each question to a person and connect the answer to the correct offer revision. AI may prepare a clarification draft; sending it to a supplier requires authorisation within the process. A received document is evidence to inspect, not an instruction that may change comparison criteria, recipients or workflow permissions.

• Quantity, unit or currency differs from the request.
• Delivery is an estimate without a verifiable date or condition.
• The offer has expired, has been superseded or lacks a reference.
• Transport, installation, commissioning or support is unclear.
• Technical alternatives or mandatory requirements remain unverified.

5. Separate comparison from purchasing approval.

The final comparison distinguishes satisfied requirements, unresolved differences and assumptions. Identify who checked the terms and which offer revisions were used. If your organisation weights quality, delivery or price, define those weights before selection and make them visible rather than having the model invent them.

After approval, retain the request, offers, clarifications and selection rationale. Creating a purchase order is a separate handoff with its own ERP checks. A revised supplier offer must not silently modify an already-approved order. Additional jurisdiction-specific purchasing requirements belong with the relevant internal owner.

6. Test one reasonably consistent category.

Choose a recurring category whose differences a named owner can judge. Repeat comparisons using historical offers and measure corrections, missed clarifications and effort needed to produce an approvable comparison. Start with drafts and no automatic supplier messages or purchase orders; expand only the steps that show practical value.

• A versioned request and three representative offers.
• An expected comparison prepared by the purchasing owner.
• At least one unit mismatch and one missing condition.
• Distinct technical validation and purchase approval owners where the process requires them.

Practical questions