How AI Can Read RFQ Documents Automatically

A meaningful share of a supplier's quoting time isn't spent quoting at all. It's spent transcribing — reading an emailed spreadsheet, a scanned purchase list, a PDF tender extract, or a photo of a handwritten materials list, and re-keying the contents into whatever produces the quote. The work is slow, mind-numbing, and error-prone in exactly the way that transposing "item 14, qty 250" across forty lines invites.

This transcription layer is now genuinely automatable. Modern AI reads RFQ documents in the formats they actually arrive in, extracts the structured request hiding inside, matches it against a supplier's catalogue, and hands back priced line items. Here's how that works, where it's reliable, and where honest systems still hand over to a person.

The formats RFQs actually arrive in

Anyone who thinks RFQs arrive as tidy structured data has never worked a supplier's inbox. The real distribution:

• Free-text emails. "Hi, please quote 300m 20mm conduit, saddles and couplings to suit, delivery to site in Rustenburg." Conversational, incomplete, full of implied context.
• Spreadsheets. Anything from clean item/qty columns to merged-cell monsters with pricing history in hidden columns.
• PDFs. Formal RFQ documents from procurement systems; tables spanning pages; terms buried in footers.
• Scans and photos. A site foreman's handwritten list, photographed and WhatsApped.
• Chat messages. Increasingly, requests typed straight into a website assistant.

A useful reading system has to handle this whole zoo, not just the clean cases.

What "reading" actually involves: four steps

1. Getting the text out

For digital documents, text extraction is straightforward parsing. For scans and photos, optical character recognition (OCR) converts pixels to text — a technology that has improved dramatically and now copes with reasonable handwriting, skewed photos, and low contrast. Table structure matters as much as characters here: knowing that "250" sits in the quantity column of row 14, not the price column of row 13, is the difference between a quote and a liability.

2. Understanding what's being requested

This is the step that was impossible until large language models. Extracted text is not yet a request — "conduit + fittings to suit" requires interpretation: recognising that line items are being requested, inferring the implied accessories, noting the delivery location, spotting that "to suit" means compatibility with the 20mm conduit in the previous line.

LLMs perform this interpretation remarkably well because it's fundamentally a language task. The model identifies line items, quantities, units, specifications, delivery requirements, and deadlines from prose that a rules-based parser would find hopeless.

3. Matching against your catalogue

An interpreted request still needs grounding: "20mm galvanised conduit" must become your SKU at your current price. This is where retrieval-augmented generation (RAG) earns its keep — the AI searches an indexed knowledge base built from the supplier's own uploaded catalogues and price lists, and matches each requested line to real products, with the source citation attached.

Grounding is the integrity guarantee. The system can only quote items that exist in your documents at prices that exist in your price list. No document, no price — the AI has nothing to hallucinate from. The broader architecture is described in RAG AI Explained for Businesses.

4. Knowing when it doesn't know

The step that separates production-grade systems from demos. Real RFQs contain genuine ambiguity — "the usual brackets," two catalogue items that both plausibly match, a handwritten quantity that could be 60 or 80. A well-designed system attaches confidence to each match and, below threshold, asks or escalates rather than guesses. A confidently wrong line item on a formal quotation is far more expensive than a clarifying question.

From reading to quoting

Reading is the front half of a pipeline. Once lines are matched, the rest is deterministic: current prices applied, totals and tax computed, an itemised branded PDF quotation generated, the request and document logged. Platforms like Mavumium run this full path — a customer can paste a materials list into the website assistant or upload their document, answer one or two clarifying questions, and receive a complete quotation in the same conversation, at any hour.

The compound effect on a supplier's day is larger than any single step suggests: the 40-minute decode-lookup-price-format cycle becomes a review of pre-matched lines, and only for the requests that need review at all. The capacity math is worked through in How AI Helps Suppliers Respond to More RFQs.

Honest limits

Where current document-reading AI still earns an asterisk:

• Terrible source material. A blurry photo of faint pencil on damp paper will defeat OCR. (It defeats humans too; the failure mode is the same, just faster.)
• Genuinely engineered requests. "Quote me what I need to reticulate this building" is a design task wearing an RFQ costume. AI can assist; a person should own it.
• Catalogue gaps. The matching is only as good as the documents behind it. If your price list is stale or your catalogue descriptions are thin, fix that first — the system will be fast and wrong otherwise.
• Adversarial fine print. Unusual legal terms buried in a tender PDF deserve human legal eyes, not automated acceptance.

None of these are reasons to keep transcribing spreadsheets by hand. They're reasons to design the escalation path deliberately.

What this means in practice: a short scenario

A steel merchant receives a 60-line RFQ as a PDF from a construction group at 6:15am. The system extracts the table, matches 56 lines against the catalogue with high confidence, flags two lines where the spec could match two products, and identifies two items not stocked — suggesting the nearest equivalents. By 7:30am, a salesperson reviews the four flags over coffee, confirms the substitutions with one call, and the complete quotation is with the buyer before their morning meeting. The old version of this story ends on Thursday.

Frequently asked questions

How accurate is extraction from spreadsheets and PDFs? On digital (non-scanned) documents with recognisable structure, extraction is highly reliable; the residual risk sits in ambiguous matching, which is exactly what confidence thresholds and escalation exist for. Accuracy problems in practice are usually catalogue-data problems.

Can it handle handwritten lists? Legible handwriting photographed reasonably: yes, routinely. Illegible: it will fail visibly rather than silently, which is the correct behaviour.

Does the buyer have to change how they send RFQs? No — that's the point. The system meets requests in whatever format they arrive. Over time, buyers often drift toward the chat/upload path voluntarily because it's faster for them too.

What do we need to prepare on our side? Clean, current price lists and catalogues, uploaded once and updated when prices change. The preparation checklist is the same as for RFQ automation generally.

The takeaway

The transcription layer between "customer sent a document" and "customer received a quote" no longer needs to exist. AI reads the email, the spreadsheet, the PDF, and the photographed list; matches them against your own catalogue with citations; asks when it isn't sure; and feeds a quotation engine that does the rest in minutes. What remains for people is judgement — which was the only part of the job that ever deserved them.

Mavumium includes document-aware quoting as part of its SmartDocs and AI assistant stack — see the features, or book a demo and bring the ugliest RFQ document your inbox received this month.