We would rather under-claim than mislead. This page explains where the data comes from, how each figure is computed, what is robust, what is only directional, and what we are still verifying against the source.
Source chain: CPPP (eprocure.gov.in) and state procurement portals → an open, public scrape published at tender.sarthaksidhant.com → our frozen copy. We hold ~3.9M tenders and ~4.9M award records - ~3.17M unique awards after deduplication (see the audit below), 2011-2026.
We downloaded the source databases and compared them byte-for-byte (SHA-256) against our copy: identical. Whatever is in the public release is exactly what we analyse - no rows dropped or altered in the handoff.
It is not an official government dataset, and we did not build the scraper. The underlying records are public, but their completeness and accuracy are the source's, not ours - see the limits below.
We work with two separate CPPP datasets - ~3.95M tender notices and ~4.92M award records, which deduplicate to ~3.17M unique awards. They are not a one-to-one set, and the difference is structural, not an error.
Only about 23% of award records map to a tender in the notices file - the rest come from buyers, portals or years the notices dataset does not cover. So you cannot expect the two counts to line up.
Awards are recorded at line-item/winner level - one tender can legitimately produce several award rows (multiple lots or winners; framework and rate contracts, far more). That is one reason award records outnumber tender notices. The other reason was duplication - see the audit.
A content-level audit found that 30.3% of award records were exact duplicates: identical tender reference, buyer, winner, value and dates, differing only in which scrape partition captured them. The cause is upstream - the source scrape ran in overlapping partitions, and the same award was collected more than once (each copy under its own record ID, which is why an earlier ID-level check correctly reported "zero duplicate IDs" and still missed this). The tender-notice dataset had only ~0.5% duplication.
Every figure on this site is now computed on the deduplicated set (first occurrence kept). Effects: counts fell ~30% (4.92M award records → 3.17M unique awards); headline rates barely moved - single-bid 13.2% → 12.6%, short bidding windows 19.3% (unchanged), March-rush share 10.9% (unchanged) - because duplication was roughly proportional across categories. We publish this correction rather than hide it: auditing our own data is the point of the site.
In short: "3.17M awards" means unique award records at line-item/winner level. Per-record rates on this site (single-bid, etc.) are computed at the award-record level on the deduplicated set.
Anything built on bid counts and dates: single-bid rates, the state-vs-central gap, bid-window tightness, the fiscal-year rhythm, and contract counts. These fields are well-populated and clean.
Anything built on contract value: rupee totals, value leaderboards and sector concentration. Buyers publish values inconsistently (mixed units, and notional amounts for things like bank empanelment), so we cap outliers and report these as indicative, not audited.
~20% of tenders and ~8% of awards lack a full detail record in the source scrape (a uniform gap across all years, i.e. the scraper, not our copy). Those records are still counted, but with less field detail.
Published values mix units and include notional figures. We bound and cap them, but value-based numbers remain directional. Reconciling values against source records is ongoing.
A few state portals record the "number of bids" field in ways that produce implausible single-bid rates (e.g. West Bengal below 1%). We flag these and are cross-checking against the source portals.
A single bid can mean a thin market, a proprietary item, or a restrictive specification. It is a flag worth investigating - not evidence of wrongdoing. We present it as a signal, never an accusation.
One gap we cannot fully close yet: independently auditing the source scrape against the live government portals. Those portals gate search behind CAPTCHAs and expose mostly current records, so historical verification is hard. We are building a forward-capture process to check future source releases against our own snapshots.
Nothing here is investment, legal, or policy advice.
When a number or a claim on this site turns out to be wrong or overstated, we correct it, log it here with the date, and never silently edit it away. An analysis you cannot see being corrected is an analysis you cannot trust.
2026-07-03 — "March rush" retired as a red flag. We had presented the concentration of awards in March (10.9% of the year) as a warning sign. A value-weighted test did not support that: March carries only 10.0% of awarded value (an even calendar would give 8.5%; January carries more), the median March award is identical to the rest of the year, and Jan–Mar sits inside the government's own 33% year-end norm. The pattern is the mechanical rhythm of a fiscal year ending 31 March, so we now present it as a calendar effect, not an integrity signal. Full test on the Spending page →
2026-07-02 — Counts restated after a duplication audit. A content-level audit found 30.3% of award records were exact duplicates from overlapping scrape partitions. All counts were restated (4.92M award records → 3.17M unique awards; ~580k single-bid → ~395k); headline rates moved by less than one percentage point (single-bid 13.2% → 12.6%). Details in the duplication audit above.
If you work with the
Open Contracting Data Standard, this is how NITI Scope's fields map onto its vocabulary. It is a
crosswalk, not an OCDS publication - the underlying scrape predates any OCDS structure, there are no
registered ocids, and vendors have no stable party identifiers (we match names to the MCA company
registry ourselves).
| NITI Scope field | Nearest OCDS path | Notes |
|---|---|---|
| Tender title / description | tender/title, tender/description | Free text from the portal |
| Tender reference no. | tender/id | Portal-scoped, not a registered ocid |
| Buying organisation | buyer/name | Free text; no stable buyer ID |
| Published date | tender/tenderPeriod/startDate | |
| Bid-submission closing date | tender/tenderPeriod/endDate | Basis of our bidding-window figures |
| Number of bids received | tender/numberOfTenderers | Basis of our single-bid rate |
| Selected bidder(s) | awards/suppliers/name | Name only; we link to MCA CINs where an exact match exists |
| Award date | awards/date | |
| Contract value | awards/value/amount | INR; directional (see above). Site shows Rs crore or US$ at an indicative rate |
| Bidder address | parties/address (supplier) | Free text; basis of shared-address flags |
| Competed vs sole-source | tender/procurementMethod | Not published in the source - we infer from bid counts |
Aggregate tables are downloadable as CSV on the Data & API page, with a suggested citation. For questions about mapping specifics, email np@dendrons.ai.