How Orbid AI Reads a 200-Page Tender in 46 Seconds

A 200-page tender is not one document. It is a bundle: PDF instructions written by the legal department, XLSX compliance tables created by the biomedical engineering team, multi-tab price sheets from procurement, product specification matrices in formats that vary by hospital, annexes referencing regulatory standards, and free-text requirements scattered across sections that were clearly written by different people at different times. Manual teams spend 1–2 full days just extracting and organizing this material before anyone starts the actual work of matching specifications.

What happens when you upload a tender

Orbid AI's Operator module accepts tender documents in any format used in hospital procurement: PDF, XLSX (including multi-tab workbooks), Word documents, and mixed packages where different sections arrive in different formats. Upload happens in one step — drag the file in and Operator begins processing.

The parsing workflow handles four tasks simultaneously:

• Language detection: Automatic identification of the document's language. Multi-language tenders (common in Switzerland, Belgium, Singapore, and UN procurement) are handled by parsing each language section according to its conventions.

• Structure identification: Operator distinguishes administrative clauses from technical requirements, identifies specification tables versus free-text requirements, and separates mandatory pass/fail requirements from scored evaluation criteria. This distinction matters because a missed mandatory requirement means disqualification, while a weak scored criterion means a lower ranking — two very different outcomes.

• Requirement extraction: Every technical requirement is extracted as a structured line item with: the requirement text, measurement units (if applicable), compliance classification (mandatory vs scored), and source location in the original document.

• Cross-reference resolution: When a tender references external standards (IEC 60601-1, ISO 13485, ISO 14971), Operator identifies the implied requirements from those standards that are not stated explicitly in the tender text. A reference to "IEC 60601-1 compliance" implies dozens of specific electrical safety requirements that the evaluator will check — even if the tender does not list them individually.

This entire parsing step takes seconds. The output is a structured requirements table that a human reviewer can verify against the original document — every extracted requirement links back to its exact source page and section.

From unstructured mess to structured line items

The hardest part of tender parsing is not reading text — it is understanding context. A single tender might present requirements in five different ways:

• Specification tables where row headers are requirements and columns are response fields — but the column order varies between hospitals and even between different tenders from the same hospital.

• Free-text sections where requirements are buried in paragraphs of administrative prose. "The device shall comply with IEC 60601-1:2020 and provide evidence of testing by an accredited laboratory" is a requirement. "The hospital reserves the right to reject non-conforming submissions" is not.

• Cross-references to external standards that imply additional requirements. A tender that specifies "ISO 13485 certified manufacturer" is really asking for: valid ISO 13485 certificate, issued by an accredited certification body, covering the product categories being tendered, with a scope statement that matches the tender's intended use.

• Mixed-language content — common in tenders from Switzerland (German/French/Italian), Belgium (French/Dutch), Singapore (English/Chinese), and international organizations (English/French/Spanish).

• Annexes and attachments that override or supplement the main specification table. Some hospitals attach a separate compliance matrix that duplicates some requirements from the main document with additional detail — and the annex version takes precedence when they conflict.

Orbid AI handles all of these patterns. The parsed output tags each requirement with its source location and format type, so reviewers can verify any line item against the original tender in one click.

Semantic matching against your catalog

Once requirements are extracted, Operator matches each one against your product catalog in Arsenal. This is semantic matching — not keyword matching — and the distinction is critical for medical device specifications.

Consider a tender requirement: "Operating frequency: 2.5–10 MHz." Your datasheet says: "Broadband frequency range: 2–12 MHz." A keyword matcher looks for the exact string "2.5–10 MHz" in your documentation and finds nothing. A semantic matcher understands that your product's range of 2–12 MHz encompasses and exceeds the required 2.5–10 MHz range — and scores the match at 94% confidence with an explanation: "Product range exceeds minimum requirement. Full match."

Each match is classified into three categories:

• Full match (green): The product specification clearly satisfies the tender requirement. Confidence score 85–100%. Evidence link to the source document provided.

• Partial match (amber): The product specification is related but not a clear match. Requires human review. Examples: product parameter is close but not within the exact range specified, or the datasheet uses different terminology that may or may not mean the same thing. Confidence score 50–84%.

• Gap (red): No evidence in Arsenal supports the claimed specification. Orbid AI explicitly reports "no evidence found" rather than generating a plausible-sounding but unverified response. This gap detection is critical — in regulated procurement, a false compliance claim leads to disqualification or worse.

46 seconds vs 2 days

In a benchmark test on a 162-row ultrasound tender from a European hospital network, Orbid AI completed requirement extraction and specification matching in 46 seconds. The same tender took a manual team approximately 2 working days — 16 hours of active work spread across the extraction and matching phases.

The manual result had a 4–8% error rate: transposed values from copy-paste errors between datasheets, outdated references from a previous bid template, and three specifications matched against the wrong product variant because the operator was working across multiple product lines simultaneously.

The 46 seconds covers the mechanical work. The human team still reviews edge cases, adds strategic narrative for value proposition sections, makes pricing decisions, and applies judgment to partial matches. But these tasks now happen on Day 1 instead of Day 5, because extraction and matching are already done.

What the team does after Orbid AI finishes

With extraction and matching automated, the team's role shifts from data entry to judgment. On a typical 162-row tender, approximately 138 rows are full matches (green) that need only a quick verification glance. The team focuses on:

• 12–15 partial matches (amber) that need expert interpretation — "is our 2–12 MHz range acceptable when they asked for 2.5–10 MHz, or are they specifically looking for the narrower range?"

• 5–8 gaps (red) that need resolution — either locating additional evidence, selecting a different product configuration, or preparing a clarification response to the procurement authority.

• Strategic sections — value proposition, service and support narrative, competitive differentiation — that require human writing and positioning judgment.

• Pricing strategy — which is now informed by the complete specification match analysis rather than guesswork based on a partially completed response.

The total cycle compresses from 14 days to 2 days. The quality improves because human attention is directed at the 10% of cells that benefit from judgment, not the 90% that are mechanical.

Request a demo to see Orbid AI process your actual tender — we run it live during the call, no sample data.