AstorX Insights

The contradictions hiding in your tender bundle

A tender bundle is written by committee, assembled under deadline, and amended twice after publication. Of course it contradicts itself. The question is whether you find the contradictions before you sign, or after.

How contradictions get into tenders

Nobody writes a contradictory tender on purpose. The technical specification is drafted by the clinical or engineering team, the pricing schedule by procurement, the contract terms by legal, and the amendments by whoever answered supplier questions that week. Each document is internally consistent. The bundle is not.

The most common collisions follow a pattern:

• Timelines: delivery in 30 days from purchase order in the spec; 14 business days in the pricing annex; "as per framework agreement" in the contract, which says something else entirely.
• Quantities: the lot table says 120,000 units annually; the estimate in the award-criteria section says 100,000; the draft contract caps at "the stated quantity" without stating which one.
• Penalties: liquidated damages of 0.5% per day in one document and 1% per week in another. The difference over a two-week slip is not academic.
• Amendments that half-land: Q&A response number 47 changes a requirement, but the consolidated version of the spec never gets updated. Both versions are now in circulation.

Why review processes miss them

Standard review splits the bundle by expertise: regulatory reads the regulatory sections, finance reads pricing, legal reads the contract. Every page is read by someone. No pair of conflicting pages is read by the same person. That is the whole failure mode, and more reviewers makes it worse, not better, because responsibility fragments further.

Keyword tools do not help here either. A search for "delivery" returns forty hits; nothing in a keyword index knows that hit 12 and hit 31 state incompatible obligations. Conflict detection is a semantic problem: two passages, often in different vocabulary or different languages, asserting things that cannot both be true.

What systematic conflict detection looks like

Whether you do it with people or software, the method is the same. Extract every commitment-bearing statement, meaning anything with a number, a date, a unit, or an obligation verb, into one normalized list. Group statements that refer to the same subject. Compare within groups. Disagreements are your conflict list; take each one back to the buyer as a clarification question before the deadline.

Done by hand, this is days of work per tender, so it happens only on the biggest bids. Done by a system that reads every page and cross-references as it goes, it is hours, and it happens on every bid. Asking the buyer to resolve a contradiction before submission costs nothing. Discovering it during contract execution costs the margin on the deal, or the deal itself.

Three habits worth adopting this quarter

1. Keep a single "numbers and dates" sheet per tender. Every figure, from every document, with its source. Two entries for the same thing is a finding, not a formatting problem.
2. Treat buyer Q&A responses as amendments: re-check affected sections every time one lands.
3. Log every conflict you catch and what it would have cost. That log is how you justify fixing the process. It is usually a shockingly persuasive document.