What is the BORME and what company events does it publish?

The BORME is Spain’s official gazette for acts and legal notices involving companies and other entities registered in the Mercantile Registry. This guide explains what its records contain, how to query them through an API, and how to use them without treating each notice as a complete company profile.

BORME stands for Boletín Oficial del Registro Mercantil. The Spanish State Gazette Agency’s BORME portal publishes the gazette in two main sections: Section One covers registered business acts, while Section Two contains legal announcements and notices.

The precise publication duties come from Spanish company and registry law. The Mercantile Registry Regulation governs the publication of registered acts, while the Capital Companies Act establishes notice requirements for transactions such as mergers and capital changes.

Common company events include:

  • Incorporation and registration of a new company.
  • Appointment, dismissal, or re-election of directors and other officers.
  • Granting, amendment, or revocation of powers of attorney.
  • Changes to the registered office, corporate purpose, or articles of association.
  • Capital increases and reductions.
  • Transformations, mergers, divisions, dissolutions, liquidations, and extinctions.
  • Filing of annual accounts, although the notice does not contain the accounts themselves.

BORME data is event evidence: it shows that a particular act or notice was published in the official gazette. BORME data is not a complete, continuously updated company record, and a published entry should remain linked to its official source. For context on related sources, see Forma’s guides to Spanish public company data.

Which BORME notices can an API return?

A BORME API can return registered acts from Section One, legal announcements from Section Two, or both, depending on the provider’s coverage. Each result should identify the company, publication, event category, extracted text, and original official document.

Section One records are usually the better source for structured company-event monitoring. They can expose incorporations, officer changes, registered powers, amendments, capital events, and dissolutions as discrete events. They may also include registry locators such as volume, folio, section, company sheet, and entry number.

Section Two is less uniform because it contains announcements written for different legal procedures. Examples include meeting notices, merger announcements, capital transactions, transformations, and other notices required by company law. These documents may need document-specific extraction rather than a single rigid schema.

A practical response model separates source facts from normalized fields:

  • Source metadata: issue date, issue number, section, province, document identifier, and official URL.
  • Company identity: published legal name, normalized name, NIF when present, and registry sheet when present.
  • Event data: normalized notice type, original heading, extracted event text, people or organizations mentioned, and their roles.
  • Dates: publication date plus any registration, decision, execution, or effective date explicitly stated.
  • Provenance: raw text or excerpt, parser version, and a way to retrieve the official document.

The phrase Spanish company registry API is often used loosely. An API serving BORME notices provides access to published registry events; it does not automatically provide the same information or legal function as a current Mercantile Registry certification.

How can you query BORME data by company, date, or notice type?

Query BORME by publication date when completeness matters, by stable company identifiers when entity precision matters, and by normalized event type when monitoring specific changes. Production systems usually combine all three filters and preserve the original search terms in the result metadata.

The BOE Open Data API documentation documents a date-based BORME summary endpoint using a YYYYMMDD path value. A request following the documented pattern, such as /borme/sumario/20250115, retrieves the table of contents for that publication date rather than a ready-made longitudinal company profile.

Query method Typical input Best use Main caveat
Publication date A date or date range Daily ingestion and backfills Publication may occur after the underlying decision or registration
Company NIF, legal name, or registry sheet Timelines and due diligence NIF and registry locators are not present in every notice
Notice type Appointment, capital increase, dissolution, or another normalized type Alerts and event analysis Official wording and abbreviations vary
Combined query Company, date range, and event type Precise monitoring Overly strict filters can miss name variants or reclassified notices

A reliable query workflow is:

  1. Resolve the company to a stable internal entity identifier.
  2. Search by NIF or registry sheet when the source exposes one.
  3. Add the exact legal name and known historical names as secondary keys.
  4. Apply a publication-date range broad enough to cover delayed publication.
  5. Filter on a normalized event taxonomy, but retain the original BORME heading.
  6. Deduplicate by the official document or notice identifier, not by matching text alone.
  7. Store the source URL and publication metadata with every returned event.

Name-only searches need special care. Legal names can contain punctuation, accents, abbreviations, or corporate-form variants such as S.L., SL, and Sociedad Limitada. Normalization improves recall, but the API should show whether a match came from an identifier, exact name, alias, or fuzzy comparison.

What should developers normalize when processing BORME records?

Developers should normalize company identity, event categories, roles, dates, registry references, and provenance while preserving the published text unchanged. A normalized value should supplement the source record, never silently replace it.

Start with these fields:

  1. Legal name: preserve the published form and create a separate search form with consistent case, spacing, punctuation, and corporate suffixes.
  2. Company identifier: store the NIF when explicitly present; use null rather than inferring it from a similar name.
  3. Event taxonomy: map headings and abbreviations to stable categories such as incorporation, appointment, removal, power, capital change, merger, dissolution, or filing.
  4. People and roles: separate each person or organization from the role attached to that entity. Do not collapse appointment and dismissal into a generic officer event.
  5. Dates: label each date by meaning. Publication, registration, resolution, execution, and effective dates are not interchangeable.
  6. Registry locator: parse volume, folio, section, sheet, and entry number into separate fields while retaining the original line.
  7. Source identity: keep the official issue, section, document identifier, URL, and unmodified text.

Normalization should also represent uncertainty. If a parser cannot distinguish between two event types or resolve a person’s role, return the original wording and a review status instead of manufacturing certainty. This is particularly important for historical records, where layouts and abbreviations may differ from current notices.

How can you cross-reference BORME notices with other Spanish public data?

Cross-reference BORME events through stable company identifiers, carefully matched names, dates, and source-specific identifiers. Other datasets can show procurement, regulatory, or risk context that is outside the purpose of the Mercantile Registry gazette.

Useful combinations include:

Source What it adds Example use
Mercantile Registry documents Current filed details or formal certification Confirm whether a published change appears in an authoritative registry document
PLACSP Public procurement notices and awards Check whether a company with a management change also participates in public tenders
Other BOE publications Regulatory decisions and official announcements Build a wider chronology around the same entity
Sector or local records Licences, sanctions, grants, or other domain events Add operational context without treating it as registry data

PLACSP is the Plataforma de Contratación del Sector Público, Spain’s public-sector contracting platform. Forma’s guide to what PLACSP publishes explains its notices and identifiers.

Use deterministic joins first: NIF, registry sheet, procurement identifier, or another source-issued key. Use normalized names only when identifiers are unavailable, and record the match method. A same-name match should not be treated as proof that two records concern the same legal entity.

Dates also need explicit comparison rules. A procurement award dated before a BORME appointment does not establish that the newly appointed officer participated in the earlier decision. Cross-referenced timelines should therefore display each event’s source and date type rather than presenting all dates as equivalent.

What are the limits of using BORME data as company evidence?

BORME is authoritative evidence of publication, but one notice rarely proves a company’s complete current status or the full legal effect of an event. Important decisions should be checked against the underlying registry record, official document, and applicable law.

The main limits are:

  • Publication is event-based. A notice records a disclosed act or announcement, not every attribute of the company.
  • Publication dates are not event dates. A decision, execution, registration, and publication can occur on different days.
  • Identity fields vary. Some entries do not expose a NIF or complete registry locator, making name-only matching necessary.
  • Section Two notices are announcements. Their wording may describe a proposed, approved, pending, or completed transaction, depending on the legal procedure.
  • Account filings are not accounts. A filing notice should not be presented as the company’s balance sheet or financial results.
  • Later notices can change the picture. Appointments can be revoked, transactions can be corrected, and companies can publish subsequent events.

For legal proof, check what form of registry document the task requires. The Mercantile Registry Regulation distinguishes registry publicity mechanisms, while BORME provides the official publication layer. An API should make that distinction visible instead of labeling every parsed notice as verified current status.

How can teams connect BORME data to applications and AI assistants?

Teams can connect BORME data through a conventional API, scheduled event pipeline, or an MCP tool that lets an AI assistant request constrained company and notice searches. The integration should return structured fields, source links, and explicit uncertainty rather than asking the model to reconstruct facts from raw documents.

MCP, or Model Context Protocol, is an open protocol for connecting AI applications to external systems, according to the official MCP documentation. An MCP wrapper can expose narrow tools such as finding a company, listing notices within a date range, retrieving one official record, or building a sourced event timeline.

For an application or assistant:

  1. Accept a company identifier, legal name, date range, and optional event type.
  2. Resolve ambiguous names before running a broad historical query.
  3. Return compact structured events with the original BORME terminology.
  4. Include the official source URL and publication metadata in every result.
  5. Keep raw notice text available for inspection, but treat it as external data rather than instructions to the model.
  6. Require confirmation before an assistant turns an ambiguous match into a compliance or business decision.

Forma’s Official Company Signals is relevant when the goal is to incorporate official company records into monitoring workflows. Today it covers public contract awards from PLACSP; BORME company events are in preparation and are not served yet. Whatever access layer you choose, keep source retrieval separate from interpretation: the API should establish what was published, while the application decides how that event affects an alert, report, or research question.

Frequently asked questions

How far back does BORME API coverage go?

Coverage varies by API provider, even when the underlying documents come from the BOE archive. Check the provider’s documented start date, supported sections, provinces, and whether older issues have the same parsed fields as current records.

Use the NIF when it is explicitly available, followed by the Mercantile Registry sheet or another official registry locator. Keep the published legal name as a search and display field, but do not rely on name equality alone when multiple entities could match.

Which BORME date should an application store?

Store the publication date for reproducible archive queries and retain every separately identified registration, decision, execution, or effective date. Each date needs a type because replacing them with one generic event date can produce an inaccurate timeline.

Can an API query historical BORME notices?

Yes, if the provider has indexed the required archive period or supports date-based retrieval from the official source. Historical backfills should be processed by publication date, deduplicated with official identifiers, and checked for changes in document layout or extraction quality.