Extracting Party Roles From a Multi-Party Agreement

In a two-party contract, “the parties” is a useful field. Add a guarantor, an escrow agent and a servicer and it stops being one: the obligations in the operative clauses are addressed to roles, and a list of company names does not tell you which company is on the hook for which promise.

Why a party list is not enough

Multi-party agreements — licensing arrangements with a guarantor, three-party escrow, syndicated facilities, reseller agreements with an end customer joined in — are written in two registers. The preamble binds legal entities to defined terms. Every clause after that uses only the defined terms. So the operative text says “the Guarantor shall, on demand, pay any amount not paid by the Licensee when due”, and nowhere in that sentence is there a company name.

A downstream system almost always needs the pairing. Counterparty risk reporting needs to know which legal entity guarantees what. An obligation register needs to know who owes each covenant. A KYC or sanctions screen needs entity names, but the exposure calculation needs roles. Extracting a flat parties: [...] array satisfies none of them, and it is the default output of an unstructured prompt because it is the thing the document makes easiest to see.

The role vocabulary is also not free text. Licensor and licensee, lessor and lessee, assignor and assignee, guarantor, borrower and lender, obligor, servicer, escrow agent, trustee, disclosing and receiving party: these are pairs and triples with defined relationships, and a schema that constrains role to an enumeration with an other escape hatch plus the verbatim label is far more useful than one that stores whatever the document said. Constrained enumerations are exactly what provider-side structured output is good at enforcing.

The preamble is an alias table

The bindings almost always appear in a recognisable form near the front of the document:

THIS AGREEMENT is made on 4 February 2025

BETWEEN:

(1) NORTHSIDE SYSTEMS LIMITED, a company incorporated in England
    and Wales with registered number 00000000, whose registered
    office is at 1 Example Street, London (the "Licensor");

(2) ORCHARD DATA B.V., a private limited company incorporated in
    the Netherlands, whose registered office is at Voorbeeldweg 2,
    Amsterdam (the "Licensee"); and

(3) ORCHARD HOLDINGS N.V., a public limited company incorporated
    in the Netherlands (the "Guarantor", and together with the
    Licensee, the "Orchard Parties"),

each a "Party" and together the "Parties".

Three things in that block are easy to miss and each one breaks a naive extraction. The numbering (1), (2), (3) is the party index used elsewhere in the document, including in the execution blocks. The composite definition “the Orchard Parties” creates a fourth alias that resolves to two entities, and clauses will use it. And the registered numbers and jurisdictions are the only reliable identity keys — the names are not unique.

So the first pass should produce an alias table, not a party list: each alias mapped to one or more entities, each entity carrying its full legal name, jurisdiction, registration number and registered address where stated. Aliases that resolve to sets are first-class, and the table needs to include the collective aliases “Party” and “Parties” explicitly, because agreements sometimes define “Parties” to exclude the guarantor and then use it in clauses that a reader assumes are universal.

Two-pass resolution

With the alias table built, the second pass reads the operative clauses and emits obligations against aliases, which are then resolved to entities. Splitting it in two is not stylistic. A single pass asking for “obligations by party” forces the model to hold the alias table in working memory across a fifty-page document and resolve on the fly, which is where invented attributions come from. The resulting shape — entities, aliases, roles and obligations as four related collections — is the ordinary multi-entity document schema.

{
  "entities": [
    { "id": "e1", "name": "Northside Systems Limited",
      "jurisdiction": "England and Wales", "reg_no": "00000000" },
    { "id": "e2", "name": "Orchard Data B.V.",
      "jurisdiction": "Netherlands", "reg_no": null },
    { "id": "e3", "name": "Orchard Holdings N.V.",
      "jurisdiction": "Netherlands", "reg_no": null }
  ],
  "aliases": [
    { "alias": "Licensor",       "entities": ["e1"], "party_index": 1 },
    { "alias": "Licensee",       "entities": ["e2"], "party_index": 2 },
    { "alias": "Guarantor",      "entities": ["e3"], "party_index": 3 },
    { "alias": "Orchard Parties","entities": ["e2", "e3"] },
    { "alias": "Parties",        "entities": ["e1", "e2", "e3"] }
  ],
  "roles": [
    { "entity": "e1", "role": "licensor", "label": "Licensor" },
    { "entity": "e2", "role": "licensee", "label": "Licensee" },
    { "entity": "e3", "role": "guarantor", "label": "Guarantor" }
  ],
  "obligations": [
    { "clause": "11.1", "obligor_alias": "Guarantor",
      "obligor_entities": ["e3"],
      "summary": "pay on demand any amount unpaid by the Licensee",
      "quote": "The Guarantor shall, on demand, pay any amount not paid
                by the Licensee when due." }
  ]
}

The resolution step is then plain code: look up the alias, attach the entity ids, and fail loudly on an alias that is not in the table. That failure is the valuable part. An obligation addressed to “the Sub-Licensee” when no such alias was defined means either the preamble extraction missed a party, or the drafter used an undefined term — which is itself a finding worth showing a lawyer. A single-pass extraction would have quietly assigned it to whichever party seemed to fit.

Keep the verbatim quote on every obligation. Role attribution is the kind of claim a reviewer will want to check against the source sentence, and a summary that inverted an obligor is invisible without it. The same argument applies to any extraction where the output is a relationship rather than a value.

Entity collisions inside one group

The hardest real-world failure is not linguistic, it is corporate. A group with entities named “Orchard Data B.V.”, “Orchard Data Holdings B.V.” and “Orchard Data UK Ltd” will have all three appear somewhere in a contract bundle, and only one is bound. String matching on names merges them; so does an embedding-based match, which is worse because it merges them confidently.

Resolve on the identity keys the document gives you: registration number, jurisdiction, and registered address. Where a registration number is present, treat it as authoritative and treat a name mismatch against your master data as a flag rather than a correction — companies rename more often than they re-register. Where no number is present, do not merge; keep the entity distinct with a needs_identity_review flag and let a human bind it.

Two related traps. First, “together with its Affiliates” expands an obligation to a set that is defined by a control test in the definitions section and enumerated nowhere; the extraction should capture the scope expansion as a property of the obligation rather than attempting to enumerate the affiliates. Second, an entity can hold two roles: “the Seller, which shall also act as Servicer”. The schema must allow it — roles are a many-to-many relation between entities and role labels, and any schema with one role field per entity will drop the second.

Roles that change after signature

A multi-party agreement is rarely static. Three mechanisms change the party set after execution and each produces a document your pipeline will see separately:

• Joinder or accession deeds. A short instrument in which a new entity agrees to be bound as if an original party, in a named role. It refers to the main agreement by date and title, and it will not repeat the preamble. Extraction has to link it back and add to the alias table rather than creating a standalone record.
• Assignment and novation. Assignment moves benefits; novation replaces a party entirely, transferring obligations too. The distinction is legally significant and is stated in the instrument. An assignment leaves the original obligor liable; a novation does not.
• Change of control. The entity is unchanged and its owner is not, which may trigger a consent requirement or a termination right without producing any amendment to the party list at all.

The practical consequence is that the party-role record needs an effective-from date on each role, not just a role. “Who is the guarantor?” is a question with a different answer depending on the date it is asked about, and a record that cannot represent that will answer today’s question with 2023’s data. Where several documents contribute to one agreement, the same amendment-chain discipline described for a master agreement applies here, with the alias table as the thing being amended.