RFQ automation with LLMs: parsing, part matching and human review

RFQ automation with large language models means turning an inbound request for quotation, an email body, a PDF, a spreadsheet or a portal export, into a draft quote: extracted lines, matched articles, prices from your contracts, and a per-line confidence that tells a reviewer where to look. The reviewer approves, and only then does a quote leave the company.

This article covers the pipeline stage by stage, how to read messy RFQ documents, how to match lines to articles without trusting the model too much, how pricing stays deterministic, how to design the review queue, and what the business case can honestly claim. The quote as a versioned workflow object and the pricing engine itself are separate topics; this post consumes both.

What does RFQ automation actually change?

It automates preparation, never the offer. Retyping positions, looking up part numbers and checking contract prices are what take an inside-sales team’s time, and those are the steps a pipeline can do in seconds. Deciding what to offer stays with a person.

The failure costs are asymmetric. An unmatched line that a reviewer resolves in twenty seconds is normal operation. A wrong article at the wrong price on a sent quote is the only failure that really matters, because the customer may accept it. Design everything around that asymmetry. Also be clear about what automation does not fix: missing contract prices, articles you do not sell, and bad customer master data stay problems after the pipeline exists.

The pipeline from inbox to draft quote

The pipeline has six stages, and each produces an artifact that a reviewer can inspect: the original document, parsed text with positions, a typed array of lines, a match per line with its path, a price per line with its source, and the draft quote with a confidence per line.

Extraction into a typed array is where structured outputs help, and also where they stop. Strict modes accept only a subset of JSON Schema. Azure OpenAI’s documentation, for example, requires every field to be required, needs additionalProperties: false, does not support pattern, minimum or maxItems, and caps schemas at 100 properties and five nesting levels (Microsoft Learn). So quantity ranges, unit-of-measure enums and part-number formats are validated in code after extraction, as described in structured outputs with JSON Schema.

How do you read the RFQ document?

Route each document by what it is, because the cheapest reliable route differs per format. What actually arrives is mixed: email bodies with a table pasted as text, Excel sheets, scanned PDFs of an old spreadsheet, portal exports, and occasionally a structured order message.

Peppol’s ordering documents are a useful target shape even when nobody sends them: their code lists distinguish buyer, seller and manufacturer item identifiers, use UN/ECE Recommendation 20 units of measure, and ISO 4217 currencies (Peppol BIS). Normalize every route toward that shape. Prices from the table come from Google, AWS and Mistral pricing pages as of October 2026, and the models churn: Mistral deprecated OCR 4.0 on 29 September 2026 and retired it a day later (Mistral), so keep the extraction layer swappable. The general parsing trade-offs are in PDF parsing for RAG.

German RFQs add their own long tail: “Stk.” and “VE” as units, “Lfd. Nr.” as a position column, decimal commas, and compound nouns in descriptions. That is a normalization problem, not a translation problem, and it belongs in a small, tested set of rules rather than in the prompt.

How do you match RFQ lines to articles?

Use a waterfall: exact identifiers first, then a customer cross-reference table, then semantic search, and record which path produced each match. The path decides how much review the line needs, so a semantic hit must never carry the confidence of an exact one.

• Normalize per identifier type. Buyer, supplier and manufacturer part numbers are different identifier types; normalize case, spaces and separators per type, and look them up in a dedicated identifier index, not in the shop’s product search.
• Treat cross-references as an asset. A table that maps a customer’s own article number to your SKU grows from every human correction, and over time it moves lines from the expensive path to the cheap one.
• Semantic search proposes, it does not decide. Hybrid retrieval with reranking, as in semantic product search for B2B, produces a candidate list for the reviewer, not an answer.
• Description-only catalogs need attributes. If neither side has stable identifiers, match on classified attributes, for example ETIM, whose newest model release is 10.0, or ECLASS, currently at Release 16.0 (ETIM, ECLASS), and expect low auto-accept rates.

// Match waterfall (sketch): exact identifiers first, semantic last, never the same confidence
type MatchPath = 'exact' | 'xref' | 'semantic'
type Match = { sku: string | null; path: MatchPath; review: 'optional' | 'light' | 'required'; evidence: unknown }

// normalize(id) applies per-type rules: case, spaces and separators for supplier numbers, etc.

async function matchLine(line: RfqLine, customer: string): Promise<Match> {
  for (const id of line.identifiers) {                      // buyer, supplier, manufacturer numbers
    const hit = await idIndex.get(id.type, normalize(id))      // dedicated identifier index, not the shop search
    if (hit) return { sku: hit.sku, path: 'exact', review: 'optional', evidence: id }
  }
  const xref = line.buyerPartNo && await crossRef.get(customer, line.buyerPartNo)
  if (xref) return { sku: xref.sku, path: 'xref', review: 'light', evidence: xref }

  const candidates = await hybridSearch(line.description, { rerank: true, k: 5 })
  return { sku: candidates[0]?.sku ?? null, path: 'semantic', review: 'required', evidence: candidates }
}

Where do the prices come from?

From the same path the shop uses, never from the model. Each matched line is priced by the pricing service or the ERP with the customer’s contract prices, tiers, currency and validity, and the draft stores the source and timestamp of every price.

A line has two legitimate states: priced, with source, or price on request. The second is a normal business state and should look like one in the review queue. Surface the edge cases explicitly: contract prices that expire before the quote’s validity ends, minimum order quantities and packaging units that change the requested quantity, items that are not available to promise, and lines that match a cross-reference but no longer a sellable article. Configured products are a rules problem; hand them to the configurator, as described in headless product configurators for B2B.

How should the review queue work?

Treat the review queue as the product, because reviewer minutes per line are the main cost. Sort failures into two groups. Dangerous ones: wrong article, wrong price, an invented line. Harmless ones: an unmatched line, an ambiguous unit, a missing delivery date, a typo in the customer’s own part number. The queue exists to make the first group impossible to send and the second group fast to fix.

• Confidence from signals, not from the model alone. Combine the match path, the identifier check and the retrieval score. Verbalized model confidence is useful for ranking; Tian et al. found it better calibrated than token probabilities for RLHF models (EMNLP 2023), but it is still not a probability you can threshold blindly.
• Evidence next to the line. Show the source cell from the document, the matched article and the price provenance side by side, so review means checking, not searching.
• Keyboard-first, per line. Accept, correct or reject each line with one key; allow bulk accept only for exact-identifier lines.
• Corrections write back. Every correction on the semantic path becomes a cross-reference row for that customer.

The same idea drives my jev-decide skill: each item gets an explicit decision with a confidence, and low confidence goes to a human instead of a global on or off switch for the AI. For the queue, I would also add an end-to-end test with Playwright MCP that loads an anonymized historical RFQ, checks the extracted line count and matches, and asserts that nothing is sent without an explicit click.

What is RFQ automation worth?

It is worth the touch minutes it removes and the response time it shortens, and both have to be measured on your own data. No peer-reviewed or otherwise primary study measuring RFQ response time against win rate was found, and the article will not borrow one.

The closest published evidence is about sales leads, not RFQs. Harvard Business Review audited 2,241 US companies and found an average response time of 42 hours among those that answered within 30 days; in a second dataset of 1.25 million leads, firms that contacted a lead within an hour were nearly 7 times as likely to qualify it as those waiting an hour longer, and more than 60 times as likely as those waiting 24 hours or more (HBR, March 2011). That data is lead-level, mostly B2C and fifteen years old, so it supports the direction, not a number.

The cost side can be computed. Extraction is cheap per page; staff time is not. A reference point for the wage term is the US median wage for order clerks, $22.20 per hour in 2025 according to O*NET, about $0.37 per minute before overhead. Use your own loaded cost:

cost per RFQ = pages × OCR price per page
             + LLM tokens × token price
             + review minutes × loaded cost per minute

illustration, not a benchmark (as of October 2026):
  3 pages × $0.004 (Mistral OCR 4.1)           = $0.012
  review minutes × $0.37 (US order clerk median wage $22.20/h, unloaded)
  → staff time dominates; measure your own minutes before and after

For a head of sales or COO at a distributor, the phrase that matches the need is “reduce quote turnaround time”, and the two headline metrics are review minutes per line and the wrong-match rate that reaches a customer, which the human gate keeps at zero.

When is RFQ automation not worth it?

Skip it when RFQ volume is small, because the review interface costs more than it saves; when your catalog has no stable identifiers at all; when contract prices are out of reach of any system, because the draft would be guesswork; and in any workflow where a wrong quote would be binding without a person in between.

A checklist for an RFQ automation pilot

1. Build a golden set of 50 to 200 historical RFQs with known-correct lines, articles and prices.
2. Measure touch minutes per RFQ before the pilot.
3. Report acceptance per line, split by match path: exact, cross-reference, semantic.
4. Validate units, quantities and part-number formats in code after extraction.
5. Price only through the contract and ERP path; mark the rest price on request.
6. Make every sent quote traceable to the source document region and the price record.
7. Feed corrections back into the cross-reference table.
8. Pin the extraction model version and re-run the golden set on every swap.

After more than ten years of B2B commerce and PIM work, my experience is that the PIM side is usually clean and the incoming customer documents are not, so I would spend more of a pilot on intake and the review queue than on the model. A fixed-scope pilot on a few hundred historical RFQs is the honest way to find the numbers; if you want to scope one, see my B2B e-commerce work.

Sources

1. Harvard Business Review: The Short Life of Online Sales Leads (March 2011)
2. Mistral AI: OCR 4.1 model card
3. Mistral AI: models overview and deprecations
4. Google Cloud: Document AI pricing
5. Google Cloud: Document AI deprecations
6. Amazon Textract pricing
7. Microsoft Learn: Azure OpenAI structured outputs
8. Tian et al.: Just Ask for Calibration (EMNLP 2023)
9. Peppol BIS Upgrade 3: ordering profiles and code lists
10. ETIM International: model releases
11. ECLASS: classification standard
12. O*NET OnLine: Order Clerks (43-4151.00)