A tender re-issued mid-bid: how to find what changed without re-reading 1,000+ files
When a tender is re-issued mid-bid, you compare revisions in three narrowing passes (which documents changed, which clauses inside them changed, and which of your bid responses are affected) rather than re-reading the whole pack. Build a document register for both the original issue and the re-issue to isolate the handful of files that actually moved, diff each changed document clause-by-clause against the version you already responded to, then trace every material change through to the returnable, price line and compliance position it touches. Do not rely on the addendum note alone: it is a summary written by the issuer, not the binding change. This is exactly the kind of document-intensive work you can hand to Elora Grid and have done for you: send both issues and it returns the document register, a clause-level diff and a cited change-impact list, so your team reviews decisions instead of re-reading files.
How do you compare tender revisions?
You compare tender revisions in three narrowing passes: document, clause, then impact. First, list every file in the original issue and in the re-issue and compare the two registers, so you isolate the documents that were added, revised or withdrawn, usually a small fraction of the pack. Second, diff each changed document clause-by-clause against the version you already responded to, classifying every obligation that was inserted, deleted, reworded or had a value changed. Third, trace each material change to the returnable schedule, price line, supplier package and compliance row it affects, so you update only what moved. Re-reading all 1,000+ files is neither necessary nor safe under a deadline; a structured diff is both faster and more complete.
Why isn't the addendum note enough?
The addendum note is not enough because it is a summary written by the issuer, not the binding change itself. An addendum (also called a revision, amendment or bulletin) usually arrives with a cover note listing the changes, but in practice that note omits consequential edits, describes them vaguely ('various clarifications to Section 8'), and rarely maps a change to the exact clause or drawing it touches. Standard conditions of tender make this decisive: most state that addenda take precedence over the documents they amend, and that a later addendum overrides an earlier one. The legally binding requirement therefore lives in the revised document, not in the friendly summary. Treat the note as an index of where to look, never as the diff.
How do you find which documents actually changed?
To find which documents actually changed, build a document register (a manifest of every file and its revision marker) for both the original issue and the re-issue, then compare the two. Categorise each file as unchanged, revised, added or withdrawn. The revision field in a drawing's title block or a document's header is authoritative; the filename is not, because issuers rename and re-bundle files between revisions. This single step collapses a thousand-file re-issue to the documents that moved, and it catches the two changes teams miss most often: a new document quietly slipped into the pack, and an existing document withdrawn from it.
How do you diff a changed document clause-by-clause?
To diff a changed document, align the two versions on their clause and section numbers and compare obligation by obligation, not page by page. A raw text or PDF compare drowns you in formatting noise (re-pagination, reflowed tables, restyled headings) that hides the handful of substantive edits. Aligning on clause IDs also separates renumbering from real change: a clause that simply moved from 8.3 to 8.4 is not a change of substance, while a single reworded 'shall' inside it can flip your compliance position. Four change types matter for a bid: an added obligation, a removed obligation, a reworded obligation, and a changed value such as a rating, quantity, date or hold point. Each carries a different commercial consequence (see the table below).
How do you trace a change through to your bid?
To trace a change through to your bid, map every confirmed change to the artefacts you have already built: the compliance matrix row, the returnable schedule field, the price line, the supplier RFQ package, and the conflict and variation register. One change frequently touches several at once: a revised protection-relay rating on a single-line diagram can move a compliance position, a priced line and a supplier package in a single edit. The output of this pass is a change-impact list: every change, the artefacts it affects, and the action it forces. That list is what lets the team re-price and re-clarify only what moved, with nothing carried forward silently.
What does comparing revisions reliably look like?
Comparing revisions reliably comes down to three disciplines, whether you do it by hand or with a tool: compare registers before reading, diff by clause rather than by page, and trace each change to its impact with a citation to the document and page it came from. This is precisely the document-intensive, deadline-bound work you can hand off rather than do by hand. Send both issues to Elora Grid and it runs the comparison as a deterministic diff for you: it builds the register for both issues, aligns each changed document by clause, classifies every insertion, deletion and reworded obligation, and returns a tracked-changes pack and a cited change-impact list, with each change traced to its source document and page. The re-price, re-clarify and qualify decisions stay with your team: the model reads the documents and shows its working; it does not decide what a change means for your number.
The four change types in a re-issued tender
| Change type | What it looks like | Why it matters to your bid |
|---|---|---|
| Added obligation | A new 'shall' clause, a new document, or a new returnable to complete | You must price and resource scope you had not seen; miss it and you bid non-conforming |
| Removed obligation | A clause, drawing or returnable withdrawn from the pack | You may be carrying cost or a qualification for work that is no longer required |
| Reworded obligation | The same clause number, but the wording is tightened or loosened | A 'preferred' that becomes 'mandatory' (or the reverse) flips your compliance position |
| Changed value | An altered rating, quantity, date, hold point or separable portion | Directly moves a price line, a delivery commitment or an ITP, often with no note |
Three ways to compare tender revisions
| Approach | Coverage | Time under deadline | Risk of missing a change | Audit trail |
|---|---|---|---|---|
| Re-read the whole pack | Complete in theory | Not feasible for 1,000+ files | High (volume and fatigue) | None unless noted by hand |
| Trust the addendum note | Only what the issuer chose to list | Fast | High (summaries omit and generalise) | The note, which is not the binding text |
| Diff registers, clauses, then impact | Every changed document and clause | Hours, not days | Low | Every change cited to source and page |
- 01Build a document register for both issues. List every file and its revision marker in the original issue and the re-issue, reading the revision from each document's title block or header rather than its filename.
- 02Compare the registers. Categorise each file as unchanged, revised, added or withdrawn, so you isolate the handful of documents that actually moved out of the full pack.
- 03Diff each changed document by clause. Align the two versions on their clause and section numbers and compare obligation by obligation, ignoring pagination and formatting differences.
- 04Classify every change. Mark each edit as an added obligation, a removed obligation, a reworded obligation, or a changed value such as a rating, quantity, date or hold point.
- 05Trace each change to your bid artefacts. Map every material change to the compliance row, returnable, price line, supplier package and variation register it affects, building a change-impact list.
- 06Route each change to a human. Hand the change-impact list to the estimator and engineer so they decide what to re-price, re-clarify or qualify; keep that judgment with people.
Common questions
What is the difference between an addendum and a revision?
An addendum, revision, amendment and bulletin all refer to an official change a tender issuer publishes after the tender is released. The exact label varies by region and issuer, but the effect is the same: the changed content becomes part of the contract and usually overrides what it amends. Treat any of them as a binding change you must diff against the version you already responded to, not as optional reading.
Does an addendum override the original tender documents?
Usually, yes. Most conditions of tender state that addenda take precedence over the documents they amend, and that a later addendum overrides an earlier one. The binding requirement therefore lives in the revised document, not in the cover note summarising it. Confirm the order-of-precedence clause in the conditions of tender, then treat the latest issue of each document as the version you must comply with and price against.
How do you avoid re-reading every file when a tender is re-issued?
Compare document registers before you read anything. List every file and its revision marker in both the original issue and the re-issue, then categorise each as unchanged, revised, added or withdrawn. That isolates the small fraction of documents that actually moved, so you only open and diff those. Re-reading the full pack under deadline is precisely how a consequential, silently reworded clause gets missed before submission.
Can comparing tender revisions be automated?
The mechanical comparison can. A tool can build the register for both issues, align each changed document by clause, classify every insertion, deletion and reworded obligation, and cite each change to its source document and page. What should not be automated is the decision: whether a change forces a re-price, a clarification or a qualification is a commercial judgment that stays with your team. Automate the finding; keep the deciding.
Can Elora Grid compare tender revisions for you?
Yes. This is exactly the kind of document-intensive, deadline-bound work Elora Grid is built for: you hand over the original issue and the re-issue, and it returns the document register, a clause-level diff and a cited change-impact list, so you skip the manual re-reading. Every change is traced to its source document and page, and your team keeps the commercial decisions about what to re-price, re-clarify or qualify.
Send a real tender. Get the output back.
Hand Elora Grid one real task and judge the result yourself.