> ## Documentation Index
> Fetch the complete documentation index at: https://docs.royaltyport.com/llms.txt
> Use this file to discover all available pages before exploring further.

# IP Groups

> Understanding how contracts are grouped by shared intellectual property

## Overview

IP Groups connect contracts that relate to the same intellectual property. When multiple agreements involve the same recordings, compositions, or rights chain, they're automatically grouped together to give you a complete picture of the rights, obligations, and revenue flow surrounding those assets.

<Info>
  A single contract can belong to **multiple IP groups**. For example, an Exclusive Recording Agreement (ERA) might be part of several groups - one for each track where collaborators (producers, featured artists, remixers) have their own agreements.
</Info>

***

## Core Concepts

### Siblings

Sibling contracts are agreements that share the same IP group because they:

* Cover the same recordings or compositions
* Share the same assignee (the party receiving rights)
* Directly reference or impact each other

<AccordionGroup>
  <Accordion title="Multiple collaborators">
    Different agreements with various contributors (artist, producer, featured artist) for the same track.
  </Accordion>

  <Accordion title="Modifying agreements">
    Amendments or addendums that modify an original agreement's terms.
  </Accordion>

  <Accordion title="Option commitments">
    Agreements linked because one triggers or references commitments in another.
  </Accordion>
</AccordionGroup>

**Example IP Groups:**

<AccordionGroup>
  <Accordion title="Track collaboration group">
    **Contracts in this group:**

    | Contract                  | Why it's in this group                            |
    | ------------------------- | ------------------------------------------------- |
    | Artist ERA                | Main artist agreement covering the track          |
    | Producer Agreement        | Producer hired to produce the track under the ERA |
    | Featured Artist Agreement | Guest vocalist on the track                       |

    All three contracts relate to the same track. The producer and featured artist were brought in specifically for this recording under the main artist's deal.
  </Accordion>

  <Accordion title="Remix group">
    **Contracts in this group:**

    | Contract        | Why it's in this group                       |
    | --------------- | -------------------------------------------- |
    | Artist ERA      | Original artist agreement covering the track |
    | Remix Agreement | Remix of the track created by another artist |

    The remix agreement is a sibling because it creates a derivative work of the same underlying IP - the remix couldn't exist without the original track.
  </Accordion>

  <Accordion title="Amendment group">
    **Contracts in this group:**

    | Contract                    | Why it's in this group               |
    | --------------------------- | ------------------------------------ |
    | Publishing Agreement (2019) | Original songwriter agreement        |
    | Amendment #1 (2021)         | Modifies royalty rates for streaming |
    | Amendment #2 (2023)         | Extends territory to include Asia    |

    The amendments directly modify the original agreement's terms, so they're grouped together as siblings.
  </Accordion>
</AccordionGroup>

### IP Origin (Parents)

The parent chain shows where the IP originated - the "umbrella" agreements under which work was created or commissioned.

<CardGroup cols={2}>
  <Card title="Exclusive Recording Agreement (ERA)">
    Covers all recordings an artist makes during the term. Parent to any specific track agreements or collaborator deals.
  </Card>

  <Card title="Exclusive Songwriter Agreement (ESA)">
    Covers all compositions a writer creates during the term. Parent to co-writer agreements and specific song assignments.
  </Card>
</CardGroup>

**Examples of parent relationships:**

<AccordionGroup>
  <Accordion title="Sample clearance">
    An artist clears a sample from another recording. The sample clearance agreement's parent is the original master owner's agreement - tracing rights back to the source.
  </Accordion>

  <Accordion title="Producer under ERA">
    An artist hires a producer for tracks under their recording deal. The producer agreement is a sibling, with the artist's ERA as the parent umbrella.
  </Accordion>
</AccordionGroup>

### Downstream Licenses (Children)

Child contracts are agreements that derive from or sublicense rights from the current contract. These represent rights flowing **downstream** from an originating agreement.

<CardGroup cols={2}>
  <Card title="Distribution Agreement">
    A label with master rights grants distribution rights to a distributor.
  </Card>

  <Card title="Territory License">
    A publisher grants rights to a sub-publisher in another region.
  </Card>

  <Card title="Sync License">
    A master owner issues a license for use in film, TV, or advertising.
  </Card>
</CardGroup>

<Warning>
  License and distribution agreements are NOT siblings of originating agreements - they're children. A distribution deal doesn't create new IP alongside an artist agreement; it exploits rights that were already created.
</Warning>

***

## The IP Groups View

Each IP Group displays three sections in a visual hierarchy:

| Section                 | Description                                     |
| ----------------------- | ----------------------------------------------- |
| **IP Origin**           | Contracts this group's rights derive from       |
| **Siblings**            | Contracts in the same group sharing the same IP |
| **Downstream Licenses** | Contracts that sublicense from this group       |

### Group Header

The header shows:

* **Group name** - Named after the shared assignee or a descriptive title
* **Group type** - Whether it's a sibling group or standalone
* **Contract count** - Number of siblings in the group
* **Relationship count** - Number of IP origin and downstream license connections

### Reasoning

Each group has a **Thinking** badge that shows the AI's reasoning for why these contracts were grouped together. Hover over it to see the explanation.

***

## Revenue Allocation

For sibling groups, the system shows how revenue flows between related contracts.

### Understanding Participation Rates

The **participation rate** determines what portion of revenue flows to each contract for royalty calculation. This is NOT the same as the royalty rate - it's the input to the calculation.

<AccordionGroup>
  <Accordion title="100% participation with own rules">
    When a contract calculates directly from net receipts (e.g., "Artist gets 50% of net receipts"), it receives **100% participation** with its **own rules**. The 50% rate is in the contract's royalty rules, not the participation.
  </Accordion>

  <Accordion title="Derived share with inherited rules">
    When a contract takes a share of another contract (e.g., "Featured artist gets 20% of artist share"), it receives **20% participation** and **inherits rules** from the main artist's contract. The main artist's participation is reduced to 80%.
  </Accordion>

  <Accordion title="Multiple contracts with 100%">
    When you see multiple contracts each with 100% participation, they each calculate directly from net receipts using their own royalty rules. The actual percentages are defined in each contract's rules, not split at the allocation level.
  </Accordion>
</AccordionGroup>

**Example: Main artist with featured artist**

| Contract        | Participation | Rules                  | Explanation                                                    |
| --------------- | ------------- | ---------------------- | -------------------------------------------------------------- |
| Main Artist ERA | 80%           | Own rules (50% of net) | Keeps 80% of the pool after featured artist takes their share  |
| Featured Artist | 20%           | Inherits from ERA      | Gets 20% of artist share, calculated using same rate structure |

The featured artist inherits rules because their contract says "20% of artist share" - their payout is derived from the main artist's terms.

**Example: Two direct participants**

| Contract           | Participation | Rules                  | Explanation                           |
| ------------------ | ------------- | ---------------------- | ------------------------------------- |
| Artist A Agreement | 100%          | Own rules (30% of net) | Calculates directly from net receipts |
| Artist B Agreement | 100%          | Own rules (20% of net) | Calculates directly from net receipts |

Both show 100% because each contract has its own rate defined. The 30% and 20% are in their respective royalty rules - no split happens at the allocation level.

### Rule Inheritance

The "Rules" column shows whether a contract uses its own royalty terms or inherits from another:

* **Own rules** - This contract defines its own royalty calculation
* **from #123** - This contract uses the same rules as contract #123

Inheritance typically occurs when one contract's share is defined relative to another (e.g., "X% of artist royalty").

### Beneficiaries

When a contract represents multiple parties, beneficiaries show how that contract's revenue is further split:

| Contract          | Participation | Beneficiaries                  |
| ----------------- | ------------- | ------------------------------ |
| Artist ERA (#501) | 80%           | Artist A (75%), Artist B (25%) |
| Producer (#502)   | 20%           | Producer (100%)                |

The beneficiaries within contract #501 split the 80% among themselves. This is common when explicit splits are defined in the contract.

***

## Reversion Dates

For sibling groups, the **Reversion Dates** section consolidates the key end-of-term and reversion dates across all contracts in the group. This gives you a single place to see when rights, agreements, or collection windows expire for the assets covered by the group — without having to open each contract individually.

Click **Show Reversion Dates** under a sibling group to expand the section. A **Thinking** badge next to the heading shows the AI's reasoning for how these dates were consolidated.

### Date Kinds

Dates are grouped into tabs by kind. A group only shows tabs for the kinds that apply.

| Date Kind          | Meaning                                                                  |
| ------------------ | ------------------------------------------------------------------------ |
| **Rights End**     | When the underlying rights revert from the assignee back to the assignor |
| **Agreement End**  | When the agreement's term expires                                        |
| **Option Window**  | When an option to extend or renew the agreement closes                   |
| **Collection End** | When the assignee's right to collect revenue stops                       |
| **Retention End**  | When the assignee's right to retain previously collected revenue ends    |

<Info>
  A single sibling group can have multiple reversion dates of the same kind when different assets in the group revert on different dates — for example, two tracks under the same artist deal may have different rights end dates.
</Info>

### What Each Card Shows

Each reversion date appears as a card with:

* **Date** — the effective date when this end or reversion takes place
* **End type** — when applicable, the nature of the end (e.g. perpetual, conditional). Fixed dates are shown without a label.
* **Estimated** — shown when the date was inferred rather than stated explicitly in a contract
* **Thinking badge** — hover to see the AI's reasoning for that specific date
* **Description** — a short plain-language summary of what is ending
* **Applies to** — the recordings and/or compositions in the group this date covers. When omitted, the date applies to the whole group.
* **Linked contracts** — clickable contract IDs that source or trigger this reversion. Click a `#ID` to jump straight to that contract.

<Tip>
  Use the Reversion Dates section together with the [Agreement Timeline](/projects/crm/agreement-timeline) when reviewing renewal or acquisition decisions. The IP Groups view tells you when rights to specific assets revert; the timeline shows how those agreements fit into the broader party history.
</Tip>

***

## How Groups Are Created

IP Groups are created automatically through different types of relationship detection:

### Link Types

<AccordionGroup>
  <Accordion title="Umbrella links">
    Connects contracts to their originating "umbrella" agreement. When a producer agreement or featured artist deal is created for work under an ERA, the system identifies that ERA as the umbrella and links them together. The umbrella becomes the IP origin for the group.
  </Accordion>

  <Accordion title="Modification links">
    Connects amendments, addendums, and other modifying documents to their original agreement. When a contract explicitly references or modifies another agreement, they're linked as siblings within the same group.
  </Accordion>

  <Accordion title="Shared asset links">
    Connects contracts that cover the same recordings or compositions. When multiple agreements reference the same ISRC, track title, or composition, they're grouped together based on that shared IP.
  </Accordion>
</AccordionGroup>

Groups update automatically as you upload new contracts that relate to existing ones.

***

## Best Practices

<AccordionGroup>
  <Accordion title="Link contracts to recordings and compositions">
    Matching works best when agreements are properly linked to their recordings and compositions. Verify that catalog data is complete in each contract's [Catalog tab](/projects/contracts/contract-details/structured-data/catalog) to ensure accurate grouping.
  </Accordion>

  <Accordion title="Add all legal aliases">
    If you operate under different legal entity names, make sure all aliases are added in your [Project Settings](/projects/settings/general). The system uses these to match contracts where your organization appears under different names.
  </Accordion>

  <Accordion title="Review group reasoning">
    Check the "Thinking" badge to understand why contracts were grouped. This helps validate that the AI correctly identified relationships.
  </Accordion>

  <Accordion title="Use allocations for revenue analysis">
    When analyzing deal economics, start with the allocation view to understand which contracts handle which revenue streams.
  </Accordion>

  <Accordion title="Check for multiple group membership">
    Remember that umbrella agreements (like ERAs) can appear in multiple groups. Review all groups an agreement belongs to for the complete picture.
  </Accordion>
</AccordionGroup>

***

## How This Relates to Agreement Timeline

Royaltyport offers two different views of contracts and agreements over time; they answer different questions:

| Feature                                                    | What it shows                                                                                                                                                                        | Where                                                                 |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| **[Agreement Timeline](/projects/crm/agreement-timeline)** | Chronological agreement history **per CRM party** (entity, artist, writer). "What agreements has this label/artist/writer had over time?"                                            | CRM → Entity, Artist, or Writer → **Timeline** tab                    |
| **IP Groups** (this page)                                  | Contracts **grouped by shared IP** (same recordings, compositions, rights chain). Parent/child and sibling relationships. "Which contracts touch this asset and how do they relate?" | **Contracts** → **IP Groups**; or contract detail → **IP Groups** tab |

Use **IP Groups** to see which contracts share the same IP. Use the **Agreement Timeline** for a party-centric deal history.

***

## Related Documentation

<CardGroup cols={2}>
  <Card title="Agreement Timeline" icon="calendar-clock" href="/projects/crm/agreement-timeline">
    Agreement history per entity, artist, or writer.
  </Card>

  <Card title="Contracts overview" icon="folder" href="/projects/contracts/overview">
    Explore the contracts area of a project.
  </Card>
</CardGroup>