Procurement receives three offers. One has a lower unit price, another includes delivery, and a third is in stock but comes in larger packs. Highlighting the smallest number can still lead to the most expensive or unsuitable purchase.

AI is useful here as an assistant for making fragmented offers comparable. It gathers information from messages and files, links items to the catalogue and purchase history, and exposes unknown conditions. The decision becomes more transparent when each row leads back to its source. Here is a practical workflow for an ordinary business.

Define the requirement before comparing price lists

Specify what the company needs: characteristics, quantity, units, destination, deadline and permitted substitutes. Without this baseline, AI may compare superficially similar offers that meet different requirements.

“Cable for the project” is not specific enough. Type, cross-section, configuration, length and project requirements can all matter. Other categories may depend on shelf life, included accessories or service.

Separate mandatory and desirable conditions. Mandatory requirements determine eligibility; a noncompliant item cannot become the winner simply by scoring well on price. Preferences help choose among eligible alternatives.

Put incoming offers into a common structure

Suppliers respond through email, PDF, spreadsheets, images and links. Extract items and conditions while retaining the original source, receipt date and version. An unclear field should be flagged for review rather than confidently guessed.

Typical fields include product description and identifier, quantity, selling unit, pack contents, price, currency, delivery, lead time, minimum order and payment terms. The category determines the exact structure.

GS1 US distinguishes GTIN, internal SKU and packaging level in product records. The useful design principle is to store identifiers and packaging explicitly instead of repeatedly inferring them from free text. GS1 US · Product Field Definitions

Codes still need context. Different suppliers can use coincidentally matching internal numbers, and familiar products may be sold individually or by the case. Check versions and included components too.

Establish a common comparison basis

Compare the same quantity of suitable goods delivered to the same place by an agreed deadline. Account for required extras, minimum quantities and differing conditions.

A unit price excluding delivery is not comparable with a delivered total. A case price is not a unit price. Currency comparisons need an agreed rate date and source. Tax treatment should follow verified company rules and specialist review rather than the model's choice.

Keep original values beside normalised calculations so reviewers can reproduce the result and inspect assumptions. Unknown delivery cost must not become zero merely to complete the table.

Example: the lowest unit price does not produce the lowest total

Consider a fictional purchase of 100 identical suitable units. All figures are illustrative Russian-ruble amounts on one agreed calculation basis. Taxes and expenses outside the table are not modelled.

Hypothetical requirement for 100 units: identical goods, different terms
SupplierUnit pricePurchased quantityDeliveryTotalLead time
ARUB 100100RUB 2,000RUB 12,0002 days
BRUB 110100IncludedRUB 11,0005 days
CRUB 95120 minimumRUB 1,000RUB 12,4003 days

Supplier A has a lower unit price than B but a higher delivered total. C has an even lower unit price, yet its minimum order increases spending and leaves 20 extra units. If those units are genuinely needed later, evaluate that as a separate scenario instead of treating surplus as a free benefit.

With a strict three-day deadline, B is ineligible despite having the lowest total. The company must choose an eligible offer or revise its requirement. AI should expose these consequences instead of hiding them in an opaque ranking.

Use purchase history carefully

History can show whether an item was bought before, from whom, in what quantity and under which terms. It may also show returns, shortages and actual lead times where those events are reliably recorded.

Last year's price is not automatically today's benchmark. Volume, specification, currency, delivery and payment conditions may have changed. Normalise the records before explaining the difference.

Distinguish orders, receipts and payments. An ordered price may differ from the amount ultimately paid after adjustments, and a planned date may differ from full delivery. Supplier history is meaningful only when the event being measured is clear.

Incomplete records should remain an explicit limitation. No registered complaints does not prove flawless performance; complaints may have stayed in email outside the available data.

Make supplier ratings explainable

A single score is convenient but can conceal important differences. A low-price supplier with inconsistent delivery may suit planned replenishment and fail an urgent need. The company should choose criterion weights for the situation.

Show evidence first: confirmed deliveries, observation counts, on-time performance under a defined rule, returns and payment terms. An explanatory score can then expose its weights and exceptions.

Missing data is not poor reputation. A new supplier has fewer observations, while several successful small orders do not establish capacity for a large urgent delivery.

AI can suggest verification questions and summarise differences. Unsubstantiated suspicions, fraud accusations or model-generated blacklists should not become procurement evidence.

Automate preparation and preserve decision authority

Good automation candidates include assembling responses, extracting fields, finding history, calculating comparable totals and highlighting gaps. Use conventional software for exact arithmetic and mandatory rules.

Ambiguous product matching, new substitutes, changed requirements and tradeoffs between cost and timing require a responsible specialist. Sending an order, changing bank details and issuing payment are separate actions with defined authority.

The system can draft clarification requests about delivery, contents or charges. A draft and a message actually sent to a supplier are different states; automatic sending needs predefined boundaries.

An urgent request inside an offer does not rewrite the process. A supplier can state its terms without gaining authority over the company's agent.

Preserve the basis of each figure

Keep the source offer, date, page or row, original unit and conversion rule. Link corrected OCR fields to employee confirmation. This makes a comparison reproducible after the price list changes.

W3C PROV describes data origins through relationships among data, activities and participants. For procurement, the useful idea is tracing a row to its document and a change to its reviewer. A pilot does not necessarily require implementation of the entire standard. W3C · PROV Overview: data provenance

References must respect permissions. A summary should not expose purchasing prices to someone barred from the source, while an authorised buyer should be able to open the evidence without searching email again.

Measure the effect on procurement work

Start with time to prepare and review a comparable offer table. Also measure correct extraction of critical fields, missed mandatory terms and repeated clarification requests. Errors in units or delivery matter more than cosmetic wording.

Measure price savings against a defined baseline, such as an actually available comparable offer or approved budget. The difference from an arbitrary highest quote does not establish realised savings.

Do not indiscriminately add price reductions, avoided losses and the value of released staff time. Their bases differ and can overlap. A pilot can honestly demonstrate reduced manual assembly and stronger evidence without promising financial savings.

Start an AI Office procurement pilot

Choose a recurring category with clear characteristics and several typical suppliers. Prepare example offers and available history, then define comparison fields and mandatory requirements. Begin with reading and recommendation preparation while validating real sources and access rights.

AI Office treats procurement roles and document matching as possible project workflows. Catalogue scope, integrations, automatic actions and quality criteria are specified separately. This article's illustration does not imply a universal ready-made connector or guaranteed savings.

Comparable terms, visible unknowns and source-linked history make a buyer's choice easier to explain. That is a useful requirement for procurement AI: less manual assembly and more verifiable grounds for decisions.