One counterparty, nine records, and never the whole relationship

Someone asks what the business has with a supplier group and the repository returns 6 agreements out of 14. The other 8 are filed under a trading name, an abbreviation, a subsidiary and a spelling with the legal suffix left off. The instinct is to deduplicate. That instinct is half right and, applied wholesale, does damage that is expensive to reverse.

Some of those records are one legal person typed several ways. Others are different legal persons that happen to share a brand, and the difference matters because obligations, liability caps and governing law attach to the entity that signed, not to the group it belongs to.

Count the records, then count the legal persons

The confirming check produces two numbers whose ratio tells you what you are dealing with.

1. Export every distinct counterparty string in the repository with its contract count and, where you hold it, contract value.
2. Normalise hard for clustering only: fold case, strip punctuation and legal suffixes, collapse whitespace, and transliterate. Cluster on the normalised form. Never write the normalised string back to the record.
3. Take the 20 largest clusters by contract count. For each, establish the actual group structure from the counterparty, from a national company register, or from the signature blocks on the executed agreements themselves.
4. Record 2 counts per cluster: distinct strings, and distinct legal persons. Then classify each string against a person.
5. Read the ratio. Many strings resolving to 1 person is a data hygiene problem with a mechanical fix. Many strings resolving to many persons is a modelling problem, and no cleanup will solve it.

Most repositories show both at once, in different proportions per counterparty. Doing this on 20 clusters takes a day and prevents a merge programme that would otherwise run for a month in the wrong direction.

Five reasons one relationship becomes nine records

1. The party name is free text at the point of filing. No picker, no register, no validation — so every filer types what is in front of them, and 9 filers produce 9 strings.
2. Trading names sit beside registered names. A company registered as one thing trades as another, and the contract may name either or both. Neither string is wrong; they are just not the same string.
3. Group companies are separate legal persons. The supplier's UK entity, its German entity and its holding company are 3 parties, not 3 spellings, and each has signed different things.
4. Entities are renamed or reorganised mid-term. The party that signed 4 years ago may not exist under that name today, and nothing in the repository connects the old name to the new one.
5. Assignment or novation moved the contract. The counterparty legitimately changed part-way through the term, so the same agreement correctly names 2 different parties at 2 different dates.

The last two are why a counterparty record needs dates. A name is true for a period, not forever, and a contract's party is true as at a date. Anything that flattens both into one current value will misreport history.

The merge that destroys the thing you needed the record for

Merging is not a tidying operation. Collapse a subsidiary into its parent and the indemnity, the liability cap and the jurisdiction clause of an agreement now appear to belong to a party that never agreed them — and a parent company guarantee becomes meaningless, because the guarantor and the obligor have become one record. Establishing who owes what to whom is already the hardest part of clause extraction, as the indemnity extraction that returns only half the obligation sets out; a wrong merge removes the answer entirely.

Registered identifiers do most of the work, and then they stop

Name matching should be the fallback, not the method. Where a counterparty is a registered company, key the entity on its registration in a national register — Companies House in the UK, the relevant state registry in the United States, the corporate registry in India — and store the jurisdiction alongside, because numbers are only unique within their register.

For counterparties active in financial markets there is also the Legal Entity Identifier, a 20-character alphanumeric code issued under the ISO 17442 standard and published free by GLEIF. Where an LEI exists it is the cleanest key available, and the reference data behind it includes group relationships you would otherwise assemble by hand.

• Where identifiers stop. Sole traders, partnerships, unincorporated bodies, foreign branches and individuals frequently have nothing to key on, and a large share of small counterparties will never carry an LEI.
• Where identifiers move. Re-registrations, cross-border migrations and statutory mergers can change or retire an identifier, so store it with a validity period rather than as a permanent truth.
• Where the document is the source. The signature block and the parties clause on the executed copy state the entity precisely, which is another reason a filing gap is expensive — if the executed version never arrives, you are naming the party from a draft, the failure in the signed envelope that never lands back in the file.

Group hierarchy, not deduplication

The shape that survives has 3 tables rather than 1. An entity table holds one row per legal person with its identifier, jurisdiction, status and dated former names. An alias table maps every observed string to an entity, with provenance and a confirmation state. A group table holds dated edges between entities — parent of, subsidiary of, controlled by — so a question about the group is answered by walking edges rather than by pretending the group is a company.

Contracts then reference entity identifiers, never strings, which is the same discipline the document relationships need in contract families and the amendment on both. Roll-up reporting becomes a traversal, and a user can ask for one entity or for everything beneath a group node without anything being merged.

Deduplication asks which of these records is wrong. Entity resolution asks which legal person each record is talking about — and accepts that the honest answer is often several different ones.

Fix the capture path, or the backlog refills behind you

A resolution exercise that does not change how records are created buys you a clean repository for about a quarter. The point of capture is the contract request, where the counterparty should be selected from the entity register rather than typed, with an explicit add a new entity path that captures the identifier and jurisdiction and routes to review — a question the form has to earn its place with, as in designing the contract request form people will fill in.

• Block the free-text fallback. If a filer can type a name, they will, and the register stops being authoritative within weeks.
• Reconcile against the executed document. Where the party named in the signature block differs from the entity selected at request, raise it as an exception rather than trusting either one silently.
• Queue unresolved aliases by exposure. Resolve the counterparties carrying the most contract value first; the long tail can wait without costing anything.
• Measure it. Track the share of contracts pointing at a confirmed entity, and watch the trend rather than the absolute number.

One boundary is worth naming: fragmented party data also degrades retrieval, but that has its own distinct causes and its own repairs, set out in search that cannot find a contract everyone knows exists. Fixing entities improves one facet of search; it does not fix search. Building the entity register, the alias store and the review queue around them is internal tools and ops work. This page sits in the contract lifecycle: request to renewal, part of our legal technology practice.

• counterparty data
• entity resolution
• contract repository
• master data