Tender document review AI earns its keep in one specific place: between documents. A single tender is rarely one file. It is a set of conditions, declarations, specifications and design briefs written by different people at different times, and the expensive mistakes hide where they do not agree. For a construction and development group that bids on public work, we took the smallest public design tender we could find, the capital repair of a short village street, and read all of it. Ten documents, 47 PDF pages and five Word files. We found four places where the documents contradict each other or leave a gap that costs money.
The problem: the risk sits between documents, not inside them
A bid team reads the technical specification carefully. It reads the contract. It fills in the declarations. What it rarely has time to do is hold all ten documents in mind at once and check that they describe the same job. That is where these four findings came from:
- A contradiction about the type of work. The title page, the design brief and the technical task call the job a capital repair. The technical specification calls the same road works a reconstruction in 10 places. Under construction law these are different procedures, with different permits, approvals and limits on what may be changed.
- A gap in scope. The technical specification asks for pedestrian and cycle paths. The design brief, which defines what must actually be designed, lists only the carriageway, surface water drainage and lighting. On a 4.5 m wide street over 436 m, paths are not a detail; they change the cross-section of the whole section.
- A second gap in scope. One document adds sewage networks to the purpose of the structure; another lists only roads and streets. A second structure group means a separate project part and different qualification requirements for the designers.
- An unclear boundary. The contract limits design supervision to 36 months, while the specification requires defects to be fixed until construction is completed, and the construction tender has not even been announced. Whoever prices the bid carries that risk.
None of these is visible from any one document.
What we built
A tender check that reads the whole package and reports only what needs attention:
- Read every document in the package. PDFs page by page, Word files clause by clause, with a note of anything that could not be read (in this case, a scanned site plan with no text layer).
- Extract requirements into one list. Deadlines, penalties, qualification demands and technical parameters, each with the document and page or clause it came from.
- Compare documents against each other. Findings are classified as a contradiction, a gap or an unclear boundary, because each needs a different answer from the bid team.
- Show the evidence. Every finding comes with the exact quote and a crop of the source page, so the team checks the original in seconds.
- Prove the search works. Cross-references that must agree are checked too. In this package, both control checks matched, which is how you know “nothing found” means nothing is there.
What changes for the bid team
| Before | With tender document review AI | |
|---|---|---|
| Reading | Each person reads the documents relevant to their part | The whole package is read and cross-checked |
| Contradictions and gaps | Found by chance, often after submission | Listed before pricing, with type and source |
| Evidence | “I think it said somewhere…” | Quote, document and page or clause for every finding |
| Clarification questions | Written late, if at all | Drafted from the findings while the question window is open |
| Confidence in “nothing found” | Unknown | Control checks show the search actually works |
Where people stay in control
The review does not decide whether a finding matters or how to price it. It gives the estimator and the bid manager the evidence and a clear question: ask the contracting authority, price the risk, or accept it. We are also explicit about what was not read, such as scanned drawings or clarification rounds behind a login, so nobody mistakes an unread document for a clean one.
Where else this works
The same cross-document check applies wherever several documents describe one obligation:
- Main contractors: subcontractor offers compared against the tender scope.
- Real estate: lease agreements checked against billing rules and the ERP.
- Financial services: onboarding files checked against the institution’s own rulebook.
For teams that review tenders every week, our product extriq extracts requirements from tender packs with a source reference for every answer.
Related use cases: Subcontractor bid comparison · Competitor policy monitoring · Insurance policy document extraction. All Document checks & reconciliation use cases · How we deliver this: Custom AI solutions · Document extraction as a product: extriq
FAQ
What can AI find in tender documents that people miss?
Mostly problems between documents: the same work described differently, requirements that appear in one document but not in the scope that defines the price, and deadlines or obligations that do not fit together.
How do we know the findings are correct?
Every finding comes with the exact quote and the source page or clause, so it can be checked against the original in seconds. Control cross-references are checked as well to confirm the search itself works.
Does it work with scanned documents?
Text PDFs and Word files are read in full. Scanned drawings without a text layer are listed as not read, so the team knows what still needs a human look.
Send us a tender you are pricing now and we will show you where its documents disagree. Talk to us