A tender match decision compares two dated source records at an explicit level: representation, notice and version, procurement procedure, lot, or bid action. “same_publication_representation” means both records reproduce the same published notice and version, even if their URLs or formats differ. “same_notice_different_version” preserves two editorial versions under one notice identifier. “same_procedure_related_event” links competition, change, result, modification or completion events that share a procedure identifier without treating them as duplicates. A planning notice has no eForms procedure identifier; a later notice links back through a dedicated planning reference and remains a related publication. “same_procedure_different_lot” keeps separately biddable lots visible. “related_process” connects procurements such as a framework and call-off, renewal or replacement without merging their identities. “probable_match_review” records strong but incomplete evidence. “distinct_opportunity”, “identity_conflict” and “insufficient_identity” prevent unsafe grouping. A display can collapse verified representations, but the evidence records remain intact.
The same title can appear on an official journal, a buyer portal, an open-data feed and an aggregator. That looks like four opportunities when it may be one publication. The reverse error is more expensive: two records from the same buyer can share a title and procurement code while covering different years, lots or procedures. A correction, award notice or later version can also resemble the original competition. Simple deduplication based on title, buyer and deadline either floods a watchlist or hides an event that changes the bid. The decision needs scoped identifiers, source relationships and a clear statement of what is being grouped.
Match the strongest identifier at the narrowest relevant scope. In eForms, the procedure identifier groups notices in one procurement, the notice identifier groups versions of one notice, the notice version selects an editorial version, and the lot identifier selects part of the requirement. In OCDS, an OCID joins releases in one contracting process while each release ID identifies a publication event within that process. Find a Tender exposes both notice IDs and OCIDs. Preserve those values with their schemes and publisher. Use buyer, title, classification, place, value and dates as consistency checks, not substitute keys. An agent may compare public records and recommend a grouping state. It must not delete a source record, silence an unmatched notice, infer a replacement without a published relationship, or change a bid decision on similarity alone.
Direct answer
Two tender records can match and still require separate treatment
Start by naming what “same” means. Two URLs can be representations of one notice version. Two notice versions can belong to one notice. A competition notice and an award notice can belong to one procurement procedure. Several lots can sit inside that procedure. Each statement is compatible with the others, but each supports a different interface and bid action. A single duplicate flag loses those distinctions.
An exact representation match is the narrowest case. It requires the same publisher-defined notice identity and version, plus compatible content assertions such as buyer, notice type and lot coverage. HTML, PDF, XML and an official API object can all reproduce that publication. Grouping them in search results is reasonable. Deleting all but one is not, because each source may carry a different retrieval route or evidence format.
A procedure-level match is broader. It says the records belong to the same buying process. It does not say they ask suppliers to do the same thing now. Competition, change, result, modification and completion publications can share a procedure identifier. A planning notice is different: it carries no eForms procedure identifier and must be connected through the later notice’s explicit planning reference. Keep every notice identity, type, date and relationship. The lineage helps a bid team find the current action without erasing what came before.
Lot scope changes the practical answer. A notice may cover ten lots under one procedure and one deadline. A supplier might qualify for only two, need a partner for a third and ignore the rest. A grouped procedure page can reduce clutter, but every lot remains a separately addressable decision object. If the source does not expose lot identity clearly, the result is insufficient_identity, not “duplicate.”
| State | What matches | Display and action |
|---|---|---|
| same_publication_representation | Notice, version and represented scope | Group in the view; retain both sources |
| same_notice_different_version | Notice ID, but version differs | Keep a version lineage and compare changes |
| same_procedure_related_event | Procedure ID or OCID | Group under procedure; preserve each event |
| same_procedure_different_lot | Procedure, but lot differs | Keep separate qualification and response objects |
| related_process | Explicit inter-process relationship | Link without merging procurement identities |
| probable_match_review | Strong descriptive agreement, key absent | Keep visible and request review |
| identity_conflict | One or more strong identifiers disagree | Block grouping and investigate |
Identity evidence
A matching identifier proves only the scope it was designed to identify
eForms gives the comparison a useful hierarchy. BT-04 is the globally unique procedure identifier. BT-701 identifies a notice, and BT-757 identifies its version. The Publications Office adds the publication number when it publishes the representation. A change notice uses BT-758 to point to the notice and version it changes. Equal procedure UUIDs therefore prove common procedure membership, not equal notice type or publication.
The eForms documentation also says that versions sharing one notice ID are editorial versions and that only one version of that notice may be published. If a feed exposes versions 01 and 02 before publication, they are not two bid opportunities. They are not interchangeable evidence either. Preserve both observations and mark which version received a publication number. If two sources claim different published versions, open an identity conflict rather than choosing the larger number by habit.
OCDS separates process and publication in another way. The OCID is globally unique for a contracting process and joins information published at different times and places. A release ID is unique only inside that OCID and identifies one release. Releases are immutable events; a record compiles them into a current view. Matching OCIDs join the graph. Matching release IDs inside that OCID can support an exact release match. A release ID compared without its OCID has incomplete scope.
Find a Tender makes these distinctions available to reusers. Its API can filter by notice ID or OCID, and its publication model can list more than one OCID for a notice. This is an important warning against assuming one page equals one procedure. Store the array as published. Contracts Finder uses an internally assigned GUID to identify a published notice. Keep that GUID under the Contracts Finder scheme rather than comparing it directly with an FTS notice number or an OCID.
| Identifier | Supported conclusion | Unsupported conclusion |
|---|---|---|
| eForms procedure ID | Same procurement procedure | Same notice or lot |
| eForms notice ID | Same notice lineage | Same editorial version |
| Notice ID plus version | Same eForms notice edition | Same web representation |
| Publication number | Same published notice representation | Current bid action |
| OCID | Same OCDS contracting process | Same release or notice |
| OCID plus release ID | Same OCDS publication event | Identical transformed payload |
| Buyer reference | Possible match inside buyer namespace | Global identity |
| Lot ID | Same lot inside its procedure | Same lot in another procedure |
False merges
Mirrors can collapse in a list; versions, events and lots cannot
An official journal page and a buyer portal page may reproduce the same competition notice while serving different functions. If their strong identifiers and scope agree, mark a representation match. Choose the official publication or designated portal as the preferred display record according to the user’s task, but keep the companion source. A deadline or document link on the portal can change even while the journal publication remains fixed.
Notice versions need a lineage. Compare the version field, publication status, dispatch time and publication number. A draft feed replay and a published notice can share most content without being equivalent evidence. A corrected version can alter one field while retaining the same title and procedure. Hiding it behind an earlier match can leave the team with the wrong deadline or requirement. Version comparison belongs before any field-level acceptance.
Notice stages answer different questions. A planning notice signals intended procurement and reaches a later procedure through a planning reference, not a shared eForms procedure identifier. A competition notice asks for participation or tenders. A change notice modifies a named notice or version, and a result notice reports an outcome. The later events may share a procedure ID and much of the description. Group the linked lineage under one procedure page, but never let the result overwrite an active competition or let the planning entry count as another open tender.
Lots sit between procedure grouping and supplier action. The procedure may be one record for reporting while each lot has its own scope, value, eligibility or deadline. Compare the explicit lot ID first. When an aggregator flattens one notice into one row per lot, those rows are deliberate expansions, not duplicates. When it drops lot IDs and repeats the same title, preserve the rows as unresolved until the official notice restores the missing scope.
| Pair | Correct relationship | What stays separate |
|---|---|---|
| Official HTML and XML for one notice | Representation match | URLs and retrieval evidence |
| Buyer portal and journal notice | Possible representation match | Source roles and mutable fields |
| Notice version 01 and 02 | Same notice, different version | Content and publication status |
| Competition and result notice | Same procedure, related events | Notice type, date and action |
| Lot 1 and Lot 2 rows | Same procedure, different lots | Qualification and response scope |
| Framework and call-off | Related processes | OCIDs and deadlines |
| Same title in consecutive years | Unknown until identifiers checked | Procedure, buyer reference and period |
Agent contract
Store a relationship graph, not a destructive merged row
The match record should name candidate A and candidate B, their source roles, retrieval times and raw identifiers. It then records every asserted edge: same representation, same notice, different version, same procedure, lot relation or related process. Each edge cites the source field that supports it. Contradictions sit beside supporting evidence. This structure lets another system recompute a display group without reconstructing identity from prose.
A preferred record is a view choice, not the owner of all truth. Select it for a named use, such as showing the statutory publication in search results or opening the operational portal for documents. Keep field provenance. If the preferred record lacks a current deadline, do not fill it from a companion source without noting that source and its checked time. Group membership must never transfer authority automatically.
Use similarity only to create candidates. A normalized title, buyer name, CPV code, place, value band and date window can narrow the comparison set. Return the component agreements rather than one opaque percentage. Exact strong-identifier conflict blocks a match even when every descriptive field looks similar. Missing identifiers create a review state, not an invitation to lower the threshold until the rows merge.
An agent can read public representations, compare scoped fields and draft the graph. It may collapse verified mirrors in its answer if it also exposes the sources. It must keep uncertain candidates visible, preserve lots and stages, and abstain when strong fields conflict. Deleting records, changing monitoring rules, contacting the buyer, registering on a portal or making a bid decision requires separate authority.
| Field | Required content | Why it matters |
|---|---|---|
| candidates | Source IDs, URLs and retrieval times | Keeps the raw evidence recoverable |
| comparison_scope | Representation, notice, procedure, lot and action | Prevents an overbroad same claim |
| identifier_edges | Scheme, value, scope and source field | Makes matching inspectable |
| relationship_edges | Change, previous, framework, call-off or replacement | Preserves related but distinct processes |
| content_checks | Buyer, type, scope, place, dates and value | Tests identifier consistency |
| contradictions | Field, both values and source authority | Stops silent merge errors |
| decision | Controlled state, reason and reviewer | Governs grouping behavior |
| view_policy | Preferred record and retained companions | Separates presentation from evidence |
| recheck | Trigger and next permitted source | Reopens uncertain or changed groups |
Worked example
Resolve four listings for one fictional UK procurement
A fictional council procurement appears in four places. Find a Tender has a competition notice and later a result notice under OCID ocds-h6vhtk-0abc12. The council portal has a page for reference ICT-2026-041. An aggregator has copied the competition title twice, once for each lot, but omitted the lot labels from its cards. All four entries mention managed network services and the same council.
The competition notice and council page carry the same buyer reference, buyer identity and two lot IDs. Their notice and publication references align, so they receive same_publication_representation at the competition-notice level. The portal remains a companion source because it controls document access. The result notice shares the OCID but has its own notice ID, publication date and award stage. It is same_procedure_related_event, not a duplicate competition.
The two aggregator cards share a discovery URL pattern and title. The official notice shows that one card corresponds to Lot 1 and the other to Lot 2. They receive same_procedure_different_lot. Neither is suppressed from lot-level qualification. Their display labels are repaired from the official source, while the original aggregator text remains in the observation record so the mapping can be audited.
If the aggregator had omitted every lot clue, both cards would remain probable_match_review. A system could group them visually under the procedure with an uncertainty label, but it could not count one as redundant or discard it. The final graph contains one procedure, a competition and result event, two lots, two official representations of the competition and two secondary lot leads. No source record disappears.
| Record pair | Decision | Operational consequence |
|---|---|---|
| FTS competition and council page | same_publication_representation | One display group, two source roles |
| FTS competition and result | same_procedure_related_event | Keep separate stage events |
| Aggregator card A and B | same_procedure_different_lot | Keep both qualification rows |
| Council reference and OCID | Cross-scheme mapping | Retain both keys with evidence |
| Result notice and active bid list | Not an open bid action | Do not count as a second competition |
| Any pair with conflicting OCIDs | identity_conflict | Block automatic grouping |
What good looks like
Useful outcomes from duplicate tender notices
- Every candidate pair is compared at representation, notice, procedure, lot and bid-action levels instead of receiving one vague duplicate flag.
- Exact publisher identifiers and their schemes outweigh normalized titles, translated text and search similarity.
- Different versions and notice stages remain in a dated lineage even when one interface groups them under a procedure.
- Separately biddable lots are never suppressed merely because they share the same procedure and deadline.
- Cross-portal mirrors can share one display group while retaining their source URLs, retrieval times and field differences.
- Contradictory identifiers, buyers or scope fields stop automatic grouping and create a review case.
- Uncertain pairs stay visible until a stronger official identifier or relationship becomes available.
- Another person or agent can reproduce the decision from the match record without rerunning a fuzzy search.
Operating model
How to run the work
- 01
Choose the comparison level
State whether the question concerns one web representation, one published notice version, one procurement procedure, one lot or one response action. A pair can match at one level and differ at another.
- 02
Preserve both raw records
Store source, URL, retrieval time, original language, raw identifiers and source labels before normalization. Do not overwrite the weaker record with fields from the stronger one.
- 03
Match scheme-qualified identifiers
Compare notice, publication, procedure, OCID, buyer reference and lot identifiers only inside their stated schemes and scopes. Record exact matches, absences and conflicts.
- 04
Read explicit relationship fields
Look for changed-notice references, previous-notice references, related processes, notice type and release tags. A published relationship is stronger than a similar title.
- 05
Compare the bid object
Check lot, scope, geography, buyer, response type and deadline. Determine whether a supplier would make one response decision or several.
- 06
Use descriptive fields as checks
Normalize titles, buyer names, codes, dates and values for comparison, but keep the originals. Similarity can nominate a pair for review; it cannot prove identity.
- 07
Assign a controlled relationship
Choose the narrowest supported state, attach evidence for and against it, and name any unresolved fields. Do not reduce several relationships to a boolean duplicate value.
- 08
Group the view without deleting evidence
Select a preferred display record for verified mirrors, retain every source edge, and keep versions, stages and lots separately reachable. Set a recheck trigger when new official data arrives.
Evaluation
Questions that change the decision
- At which level do the records need to be the same for the intended action?
- Do both records carry the same notice identifier, version and publication number under the same scheme?
- Do they share only a procedure identifier or OCID, indicating related events rather than duplicate publications?
- Do lot identifiers or lot-specific requirements create separate bid objects?
- Does one record explicitly identify the other as changed, previous, replaced or related?
- Are buyer, notice type, scope, place, dates and response route consistent with the proposed relationship?
- Which source should be preferred for display, and which facts remain controlled by companion sources?
- What contradiction or missing identifier would require human review before suppression?
Failure modes
Where teams lose control
A title-based rule can merge annual competitions or separate procurements that use a standard buyer description.
A shared procedure identifier can cause a competition notice and its result notice to be treated as the same publication.
A later notice version can be discarded as a duplicate even though its fields changed before publication.
One procedure can contain several lots that need separate qualification, partners or submissions.
A publisher and an aggregator can disagree because the secondary record is stale, truncated or incorrectly mapped.
A local buyer reference can collide across years, departments or portals when its namespace is omitted.
A fuzzy score can appear precise while hiding which identifier or scope actually matched.
An agent can remove a record from monitoring before an official relationship or contradiction is resolved.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- candidate pairs with an explicit representation, notice, procedure, lot and action scope
- matches supported by a scheme-qualified notice, procedure, publication or OCID edge
- versions, stages and lots retained as separate nodes after display grouping
- probable matches kept visible pending review instead of automatically suppressed
- conflicts naming the exact identifier, buyer or scope field that disagrees
- preferred display records that retain links to every observed source representation
- merge decisions reproduced from stored evidence without title-similarity reruns
- groups reopened when a new notice, version, lot or source correction appears
Questions
Common questions
Does the same title mean two tender records are duplicates?
No. Buyers reuse standard titles, and annual or lot-level procurements can look alike. Treat the title as a comparison field and require scoped identifier evidence.
Does a matching OCID prove that two notices are the same?
It proves that the OCDS releases belong to the same contracting process. Compare release IDs, notice types, dates and lots before deciding whether they represent the same event.
Can an award notice be hidden as a duplicate of the tender notice?
No. It is a related event with a different purpose and date. Group it under the procedure, but preserve it as an award-stage record.
Should an official listing replace an aggregator record?
Use the official source as the preferred evidence and display route, but retain the aggregator observation and its mapping. It explains discovery and exposes stale or incorrect fields.
What if one record has no official identifier?
Use descriptive agreement to nominate a probable match, then recover the official source. Keep both records visible until a scoped identifier or explicit relationship resolves the pair.
Are two rows for different lots duplicates?
Not for qualification or response planning. They may share a procedure group, but each lot keeps its identifier, scope, eligibility and deadline.
Can a similarity score decide the merge automatically?
Use it to rank candidate pairs only. The decision should expose exact identifiers, relationships, scope checks and contradictions rather than rely on one opaque score.
When should a grouped record be reopened?
Reopen it when a new notice, version, lot, publication number, source correction or identifier conflict appears. Preserve the earlier decision and checked time.
Sources
Primary references
- eForms notice, version and procedure identifiers Publications Office of the European Union
- eForms guidance for linking notices in one procedure Publications Office of the European Union
- Find a Tender open contracting data UK Cabinet Office
- Find a Tender OCDS release package API UK Cabinet Office
- Find a Tender publication identifier model UK Cabinet Office
- Contracts Finder published notice identifiers UK Cabinet Office
- OCDS identifier scopes Open Contracting Partnership
- OCDS releases, lots and related processes Open Contracting Partnership
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.