Contracting Process Identifier

In any structured data system, the ability to link related records is fundamental. The Open Contracting Data Standard (OCDS) achieves this linkage through the contracting process identifier, known as the OCID. Every release and every record that relates to the same procurement process shares the same OCID, making it possible to trace an opportunity from its earliest planning release through to final payment without losing the thread.

What is a Contracting Process Identifier?

An OCID is a string identifier that uniquely identifies a single contracting process within the global OCDS ecosystem. It is composed of two parts:

1. A publisher prefix: a short string registered with the Open Contracting Partnership that uniquely identifies the publishing organisation (for example, "ocds-xxxx-" for a specific national procurement platform). The OCP maintains the registry of registered prefixes to ensure global uniqueness.
2. A local process identifier: a string generated by the publisher to uniquely identify this specific contracting process within their own system (for example, a tender reference number or an internal database identifier).

Together, these form an OCID such as "ocds-a1b2c3-GB-2024-001234." This identifier is used consistently across every release for that process: the tender-stage release, the award-stage release, any contract or amendment releases, and implementation releases all carry the same OCID. When an analytical platform merges these releases into an OCDS record, it does so by grouping all releases that share the same OCID.

OCIDs are designed to be persistent. Once assigned to a contracting process, an OCID should not change, even if the buyer's internal reference number changes or the contract is transferred to a different administrative unit. This persistence is what makes longitudinal analysis possible: you can track the full lifecycle of a contract across years using a single identifier.

Why the contracting process identifier matters for bidders

The OCID is the pivot around which all contract intelligence is organised. When a supplier research platform displays a "full contract history" for a buyer, it is aggregating all releases linked by a shared OCID. Without the OCID, each stage of the procurement (the notice, the award, the contract, the amendments) would appear as disconnected documents requiring manual matching.

For a bidder, the practical implication is that OCID-based data allows platforms to show the complete story of a contract: what was the original estimated value, how did it change at award, were there amendments that increased the final value, and was the contract delivered on time? This depth of analysis is only possible when releases are consistently linked by a stable OCID across the full lifecycle.

OCIDs also enable cross-referencing between platforms. If two separate systems (for example, a national procurement portal and a European open data aggregator) both publish OCDS data for the same contract, they should both use the same OCID, making it straightforward to reconcile and de-duplicate records.

Example

A Norwegian municipality assigns the OCID "ocds-nor123-2024-HEAL-0088" to a healthcare supplies procurement. A planning release, a tender release, an award release, a contract release, and two contractAmendment releases are all published with this OCID over 18 months. A procurement intelligence platform indexes all six releases under a single entry linked by the OCID, presenting the user with a complete timeline of the procurement in a single view.

Frequently Asked Questions

How do I find the OCID for a specific contract?

If you are accessing OCDS data through a publisher's API or data download, the OCID is a top-level field in every release JSON object. Procurement platforms that ingest OCDS data typically expose the OCID as a reference field, allowing direct lookup. If you have a national tender reference number, you may be able to search by that number and retrieve the associated OCID from the publisher's portal.

Can an OCID be reused for a different contract?

No. OCIDs are intended to be globally unique and permanently tied to a single contracting process. A publisher should never assign the same OCID to two different processes. If you encounter duplicate OCIDs in a publisher's data, it is a data quality issue that undermines the integrity of the records.

Do all EU member states use OCIDs?

Not all EU member states publish OCDS data or register publisher prefixes with the OCP. Where a country does publish OCDS data (either natively or through a mapping of their existing notice formats), OCIDs are assigned by the publisher. TED (Tenders Electronic Daily) uses its own notice identifiers, and alignment between TED identifiers and OCIDs is an active area of work between the European Commission and the OCP.