Short answer
Yes. A Latvian registration number is a much stronger matching key than a legal-entity name alone. The selected Latvijas Vēstnesis notice 2026/125.KM1 identifies biedrība “Mamskie budni” by registration number 40008253671. The Enterprise Register's open-data catalogue says its daily register resource contains a regcode field alongside the current name, registration date, termination or reorganisation date, closure information and address. The intended join is therefore the notice's registration number to the register row's regcode.
That match must still be verified against the actual register row and dated source snapshots. A shared number links the legal subject; it does not make every statement in the notice a current register fact or prove that liquidation has finished. The notice date, OP number and event type should remain separate from the register snapshot date and status fields.
Production Legalcode can retrieve the notice by its registration number, but it currently indexes only Enterprise Register catalogue pages, not the underlying entity rows. It can explain the join but cannot complete it. A zero Enterprise Register result therefore means missing entity-level coverage, not that the entity is absent from Latvia's official register.
The representative notice
The production MCP retrieved the Vēstnesis notice using its exact official-publication number, 2026/125.KM1. The fetched record gives a publication date of 3 July 2026, registration number 40008253671, and the legal-subject name Biedrība "Mamskie budni".
The source text states:
Biedrība "Mamskie budni", reģ. Nr. 40008253671 ... paziņo par darbības izbeigšanu un likvidācijas procesa uzsākšanu.
—
In substance, the association announces the termination of its activities and commencement of liquidation. It invites creditors to submit claims within three months after publication.
This is an official-notice event. It is not itself a current Enterprise Register extract, a court judgment, or proof that the liquidation was later completed. The publication records what was announced on that date.
The Enterprise Register's matching field
The fetched Enterprise Register catalogue describes a daily open-data resource for registered legal subjects. Its notes list the registration number, current name, legal address, registration date, and the date of removal or reorganisation among the supplied information.
The schema makes the intended identifier explicit:
regcode (numeric)—
The same catalogue lists name, registered, terminated, closed and address. This supports an identifier-first matching method: look for 40008253671 in regcode, then compare the name and lifecycle fields as corroboration.
The example concerns a biedrība, an association, rather than necessarily a commercial company. The matching principle is broader than the question's shorthand: it applies to legal subjects represented in the register resource, subject to the relevant dataset's scope.
Why a name-only match is weaker
Names are valuable evidence, but poor primary keys. A name may:
- change before or during liquidation or reorganisation;
- include quotation marks, entity-form prefixes or transliteration differences;
- vary in spacing, punctuation or capitalisation;
- be reused or resemble another subject's name; or
- reflect a historical name in one source and the current name in another.
An identifier-first join avoids many of those ambiguities. The name should then be checked as a consistency signal. If the identifier matches but the names differ, the researcher should inspect historical-name and reorganisation data before declaring an error.
A name-only fallback may be necessary for a damaged or older record that omits the number, but it should be treated as probabilistic. It calls for additional fields such as entity type, address, historical names, predecessor/successor links and event dates.
The join should preserve two separate timelines
Matching the subject does not collapse the sources into a single timeless fact. A defensible record keeps at least two dates:
The OP number 2026/125.KM1 should also be retained as the notice identifier. It is not a substitute for the entity registration number. One identifies the publication; the other identifies the registered subject.
This distinction matters in credit-risk reporting. “A liquidation notice was published” is an event with a date and provenance. “The entity is currently in liquidation” is a current-status proposition requiring up-to-date register evidence. “The entity has been removed” requires a removal or closure field and its effective date. Those statements should not be inferred from one another without evidence.
A reliable matching workflow
A practical cross-source workflow is:
- Extract the registration number, legal-subject name, OP number, notice type and publication date from the Vēstnesis notice.
- Validate the identifier's format and preserve it as a string so leading zeros or formatting are not lost.
- Look up the same identifier in the relevant Enterprise Register row-level resource.
- Compare the current and historical names, entity form, registration date, address and lifecycle fields.
- Preserve the register resource's snapshot or effective date and do not back-project a current row into the past.
- Record any reorganisation, predecessor or successor relationship instead of treating changed identifiers or names as the same subject by assumption.
- Keep the notice and register provenance separately so another reviewer can reproduce both sides.
If the identifier does not match, stop. Similar names are not enough to override a conflicting registration number. If the identifier matches but another field conflicts, investigate the timing or historical record before using the event in a score or report.
What production Legalcode can and cannot do
The question-specific production tests produced a clear split.
Search for 40008253671 within LV_VESTNESIS returned exactly the representative notice with a literal-text match. Search for Mamskie budni also returned it. This is an improvement over the registration-number recall problem first recorded in the existing Vēstnesis issue.
The same registration-number and name searches within LV_ENTERPRISE_REGISTER returned zero results. Fetching the master catalogue explained the result: Legalcode has the catalogue document describing a 485,729-row CSV and its regcode field, but not those entity rows as searchable records.
The zero is therefore a coverage result, not an official-register result. It must not be translated into “no such entity” or “no register match.” Completing the join currently requires consulting the underlying official resource outside the indexed MCP corpus.
There are other metadata cautions. The MCP's status: ACTIVE refers to the indexed document, not the legal subject. The catalogue's metadata-update date is not necessarily the effective date of any entity fact. On the notice side, the registration number is searchable body text but is not yet exposed as a dedicated exact-match entity-identifier field.
MCP source-quality findings
The Enterprise Register limitation remains tracked in . The question provides a concrete consequence: an official notice supplies the correct join key, yet the MCP cannot return the corresponding register row.
The Vēstnesis modeling gaps remain tracked in . The fresh test also records a positive regression result: keyword search now retrieves the representative notice by registration number. No duplicate issue was opened.
Conclusion
Registration number is the correct starting point for matching a Latvian Enterprise Register subject to a Vēstnesis notice. It is more reliable than a name and lets the researcher use names, addresses and lifecycle fields as validation rather than guesswork.
But identity and legal state are different questions. Preserve the notice event and date, verify the actual row-level register record and its as-of date, and avoid turning publication of a liquidation notice into an unsupported statement that the entity is currently liquidated or closed.
Production Legalcode successfully finds the notice by identifier. Until Enterprise Register entity rows are ingested or the limitation is made machine-readable, it cannot finish the join, and an empty result must be reported as a corpus gap rather than negative official evidence.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.