Tender / RFQ document analysis & requirements extraction

A single public tender can ship with dozens of files: invitation letter, specification, contract terms, bills of quantities, forms and declarations. Missing one knock-out criterion or deadline means the bid is excluded. AI reads the whole pack, extracts every requirement with its source location, separates mandatory from scored criteria and produces a checklist that bid managers verify, instead of reading everything linearly.

Problem & value

• Today: bid managers, engineers and lawyers read the documents manually, copy requirements into Excel and chase deadlines. Hidden requirements (a certificate in an annex, a different deadline in the cover letter, contradictions between documents) are a classic reason for exclusion. Many SMBs skip tenders because the reading effort is too high.
• AI value: faster first triage (bid/no-bid), complete and traceable requirement registers, fewer exclusions for formal errors, and a reusable base for proposal writing (LANG-006).
• Market context: public procurement is about 14 % of EU GDP (roughly EUR 2 trillion per year); EU-wide publication on TED is required above the thresholds, from 1 Jan 2026 EUR 216,000 for supplies/services (most authorities) and EUR 5,404,000 for works [1]. Below that, notices are scattered across national and municipal portals.
• Vendor claims, not independent measurements: Patterno states it analyses 100+ pages in about 30 seconds and detects deadlines and exclusion criteria automatically [2]. No independent accuracy benchmark was found; measure recall on your own tenders before relying on any figure.

Variants

• Bidder side, public tenders (Germany/EU): knock-out criteria, Eignungs- and Zuschlagskriterien, VOB/UVgO/VgV specifics, Eigenerklärungen.
• Bidder side, private RFQs: industrial customers' specifications and technical delivery terms; quote-ready extraction feeds AGENT-027.
• Construction: Leistungsverzeichnis (bills of quantities, GAEB) checked for scope, trades and unusual risk clauses.
• Contracting-authority side: consistency check of own tender documents, comparison of bids against requirements (supports, does not replace, the evaluation committee).
• IT / software RFPs and security questionnaires: requirement lists for compliance matrices; answer drafting is LANG-006.
• Private use: not relevant.

How it works

1. portal download / email / ZIP
2. file unpacking + document classification (DOC-008)
3. parsing: layout, tables, forms, scans (DOC-014)
4. segmentation into clauses/requirements with page + paragraph anchors
5. LLM extraction against a schema (type, mandatory?, deadline, evidence required, scoring weight)
6. cross-document consistency check (conflicting dates, versions, amendments)
7. matching with company profile, references, certificates (RAG)
8. checklist + bid/no-bid brief + compliance matrix draft
9. human review (bid manager, legal)
10. proposal workflow

• Parsing is the weak link: bills of quantities, nested tables, scanned annexes and spreadsheets decide extraction quality more than the LLM.
• Extraction: long-context LLMs return JSON per requirement, each with a quote and page reference so reviewers verify in seconds. Separate passes for "must/shall" requirements, formal criteria, deadlines and evidence are more reliable than one big prompt.
• Human-in-the-loop: every knock-out criterion and deadline is confirmed by a person; the system flags uncertainty and contradictions instead of resolving them silently. Submission and legal declarations stay human.

Data preparation

Tender packs arrive from procurement portals as ZIPs (PDF, DOCX, XLSX bills of quantities, eForms XML) or as RFQs by e-mail. Your own side lives in the CRM, the DMS and in people's heads: references, certificates, product catalogue, price lists and past bids. Typical gaps: scanned annexes, password-protected or split PDFs, contradictory versions after clarifications, outdated certificates, and references that exist only as slide fragments. Access rights matter for competitor-sensitive pricing.

Steps: (1) maintain a current company profile with references, certificates and expiry dates, see PREP-013; (2) collect won and lost bids with their requirement checklists as gold examples, see PREP-016 and PREP-020; (3) unpack and parse portal files, see DOC-014; (4) define a requirement taxonomy (knock-out, eligibility, award criterion), see PREP-019; (5) build a test set of 10-20 past tenders with the checklist as the bid manager would have written it, see PREP-018. Tools: portal exports, Docling or an OCR API, n8n. Roughly 25-35 % of the effort goes into preparation, mostly in the company profile.

Implementation paths

Which path for whom

• SMB: Path A — tender-monitoring and bid-analysis products exist at SMB prices and the process (requirements register, deadlines) is standard.
• Enterprise: Path B — integration with CRM, reference databases and the bid process matters, and cloud APIs in EU regions scale to many tenders.
• Public: Path B on a sovereign EU/German cloud — contracting authorities need own control over award documents and procurement-law traceability; Path C if cloud use is not allowed.
• Developer: Path B — API models plus own schemas for requirements, and eForms XML parsing, give flexibility without GPU operations.

Path A — Buy (recommended for most SMBs)

• Tender platforms with AI analysis (mostly German): Patterno (Frankfurt hosting stated, knock-out and deadline detection) [2], Vergabepilot.AI (AI assistant, evaluation checklist) [3], DTAD (AI assistant "Frank" extracts eligibility and award criteria), ibau (notice service, construction focus), auftragone (formerly auftrag.ai; topic-based matching, decision brief) [4]. Check: hosting location, processing agreement, portal coverage, whether document analysis works on the full pack including ZIP/XLSX.
• RFP/sales-side: Response-management tools such as Loopio or Responsive are common for private-sector RFPs; evaluate their data residency.
• Choose A when: you bid regularly, volumes are moderate, and search plus first triage are the main pain.

Path B — Build on cloud APIs

• Parsing: Azure Document Intelligence (layout model with Markdown output, EU regions) [5], Mistral OCR (EU provider), Google Document AI.
• Extraction/reasoning: long-context frontier models in EU regions (Anthropic Claude via AWS Bedrock/Google Vertex EU, OpenAI via Azure EU Data Zone, Mistral Large/Medium) with structured output (JSON schema). Use a stronger reasoning model for contradiction checks and a cheaper one for bulk extraction.
• Orchestration: n8n or Power Automate for intake from portals/email, vector DB (pgvector, Qdrant) for company references; output to Excel/SharePoint/CRM.
• Integration points: CRM (bid pipeline), DMS, calendar for deadlines.

Path C — Self-host (open source)

• Parsing: Docling (MIT, LF AI & Data, air-gapped capable, includes the Granite-Docling vision model) [6]; alternatives are MinerU and Unstructured.
• Models: open-weight 30–120B LLMs (Mistral/Magistral family, Qwen3 family, Llama or gpt-oss class) with vLLM; embeddings such as BGE-M3 or multilingual E5. German legal text works best on the larger tier.
• Hardware: HW3 (one 48–96 GB GPU) gives acceptable quality for 100-page packs with chunked extraction; HW2 works with smaller models and more human review.
• When sensible: confidential bids, defence/critical infrastructure suppliers, strict on-prem policies. Ops effort: one engineer part-time.

Path D — Custom training

Rarely needed. Worth considering only for a high-volume bidder with thousands of annotated past tenders: fine-tune a small encoder/LLM for requirement classification or for a domain such as GAEB bills of quantities. Needs several hundred to thousands of labelled requirements with outcomes (won/lost, excluded). Usually prompt engineering plus a golden test set is enough.

State of the art (2026)

• Long-context LLMs with structured output are the standard; the practical gains of the last two years came from better document parsing (vision-language parsers, layout-aware tables) and from agentic multi-pass extraction with citations.
• Typical failure modes: missed requirements hidden in annexes or footnotes; conflating "shall" with informational text; wrong handling of amendments (Änderungen/Bieterfragen answers supersede the originals); tables spanning pages; scanned forms; hallucinated requirements; and misreading of conditional clauses ("unless", "if the bidder relies on subcontractors").
• Mitigations: mandatory source quote and page for every item, completeness checks (count of "must" sentences vs. extracted items), a golden set of past tenders for regression tests, and human sign-off on knock-outs.
• Structured notices (eForms XML on TED) can be consumed without AI via the eForms SDK [7]; AI is needed for the unstructured documents behind them.

Shared resources & combinations

• Shared building blocks: document parsing (DOC-014), classification/mailroom (DOC-008), embeddings + vector DB + reranker for company references (KNOW family), LLM extraction harness with JSON schemas, workflow engine.
• Natural combinations: KNOW-017 (find tenders) → DOC-015 (analyse) → LANG-006 (write response) ; DOC-009 (contract clauses and liability terms in the tender contract) ; DOC-016 (rule-based compliance checks); AGENT-027 (RFQ-to-quote for make-to-order manufacturers); AGENT-005 (procurement agent on the buyer side); DATA-015 (spend/price benchmarks); ANOM-020 (collusion risk scoring for authorities).
• Hardware: the same HW3 GPU box that serves DOC-009/DOC-014 can run this; peak load is bursty (tender deadlines).

Effort, cost & KPIs

• Path A: days to weeks; subscriptions in the range of tens to a few hundred euros per month for SMB tiers (Vergabepilot lists from EUR 60/month on annual billing [1]); enterprise pricing on request.
• Path B: 2–6 weeks for a pilot; cost driven by tokens per pack (100–500 pages) and parsing pages; usually a few euros per tender.
• Path C: 1–3 months incl. GPU procurement; mostly engineering and evaluation effort.
• KPIs: requirement recall/precision on a golden set, knock-out recall (target: no misses), reading time per tender, bid/no-bid decision lead time, number of tenders reviewed per month, formal exclusion rate, win rate.

People & change

Involve: management (bid/no-bid rules), the sales or bid-management lead, legal/compliance for procurement-law questions, and the bid managers who will use it daily. IT connects portals and the DMS; the DPO checks personal data in references and CVs.

Works council: usually no under §87(1) no. 6 BetrVG, since the tool analyses external documents; it becomes relevant if it logs per-person performance of bid managers. Inform under §90(1) no. 3 and, in a company with a works council, agree that no individual metrics are collected. Data protection: tender packs include names and CVs of third parties; an AVV with the provider is required, see GUIDE-005; a DPIA is normally not needed.

AI literacy: support bid managers with training on verifying extracted requirements against the source page, see GUIDE-006. Pilot: 3-5 live tenders processed in parallel with the manual method. Concerns: fear of missing a knock-out criterion - mitigate with mandatory human sign-off on the checklist and clickable source locations. The bid decision and the signature stay with people. See GUIDE-009 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: analysing tender documents is not listed in Annex III [8], so the typical bidder-side use is minimal risk (AI literacy, Art. 4). A contracting authority using AI to score or rank bidders should keep it assistive; fully automated award decisions raise legal-fairness issues under §97 GWB (equal treatment, transparency) [9] even without AI Act high-risk status. Art. 50 applies if generated text is published as AI-generated content [10].
• Procurement law: GWB, VgV, UVgO, VOB/A; deadlines and formal requirements are legally binding, so treat AI output as a draft. Document in the file which parts AI supported.
• GDPR: tenders contain personal data (references, CVs of key staff, signatories); choose EU hosting and a data processing agreement. Tender documents may carry confidentiality clauses or trade secrets; check whether use of external AI is allowed, and prefer EU/on-prem options for sensitive bids.
• Risks: missed knock-out (mitigate with mandatory verification), outdated document versions, prompt injection from document content (treat document text as untrusted), vendor lock-in.

Getting started

1. Collect 10–20 past tenders (won, lost, excluded) and annotate requirements, knock-outs and deadlines as a golden set.
2. Trial one Path A tool (Patterno, Vergabepilot) on the golden set and compare against manual results.
3. If you need customisation, build a Docling + LLM prototype that outputs a requirements table with page references.
4. Define the review workflow: who confirms knock-outs, deadlines, and Eigenerklärungen.
5. Connect tender discovery (KNOW-017) and response drafting (LANG-006) once extraction quality is stable.

Sources

1. Patterno, "Tender software Germany comparison 2026" (thresholds, vendor coverage, Vergabepilot prices; vendor-authored) – https://www.patterno.de/en/resources/blog/tender-software-germany-comparison-2026
2. Patterno product page (document analysis, knock-out detection, Frankfurt hosting, vendor claims) – https://www.patterno.de/en
3. Vergabepilot.AI on Capterra – https://www.capterra.com/p/10049359/Vergabepilot-AI/
4. auftragone (formerly auftrag.ai) features – https://auftragone.com/en/features
5. Microsoft Learn, Azure Document Intelligence overview – https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/overview
6. Docling project (MIT, LF AI & Data) – https://github.com/docling-project/docling
7. TED eForms documentation and SDK – https://docs.ted.europa.eu/eforms/latest/
8. EU AI Act Annex III – https://artificialintelligenceact.eu/annex/3/
9. §97 GWB – https://www.gesetze-im-internet.de/gwb/__97.html
10. EU AI Act Article 50 – https://artificialintelligenceact.eu/article/50/