Adding Income Terms to Your Contracts

Via the Terms tab of your Contract, you set the royalty rates for revenues generated in specific scenarios. For example, you may apply a different rate on Performance income versus Mechanical income. Or Online income might be treated differently depending on the country of sale.

Dissection of an Income Term

The first line of a term can be read as an “ if” & the second line can be read as a “ then”. ie if revenue matches the set criteria, then apply this royalty rate.
If Variables
The following types of if variables are for you to specify the conditions under which to apple a royalty rate. You can configure the menu options available for each type via the Settings area.
Cat Type – Do you need to apply a different rate for income mapped to a Work versus income mapped directly to a Contract but not a Work?
Cat Group – Works can be combined in groups for rates applying. For more information on how to assign products to groups see the Catalogue Group article.
Territory – Rates can be dependent on the territory where the income is generated. It is possible to create Territory Groups in Settings, so you can combine multiple territories as required
Channel – The list of Channels can be customised via your Settings. As a default, we provide Channels such as Performance, Mechanical and Sync. Channels can be grouped via Contract Term Groups.
Config – The list of Configurations can be customised via your Settings. As a default we provide Configurations such as Stream, Download, Television, Radio etc. Configurations can be grouped via Contract Term Groups.
Source – Do you need to treat revenue generated by particular sources in certain ways? Perhaps income generated by a Society have a rate that diffes from income generated by a sub-publisher. Sources can be created via your Settings. And can be grouped via Contract Term Groups.

Then Variables

The following then variables state the royalty rate to be applied to revenues meeting the conditions above.
Deal Type – Select what type of revenue to use as the base to calculate your royalty rate on. The different types of deals work in the following ways:
  • Gross Receipts – The value stored in the Gross Amount field will be taken as the calculation input. This field is generally used to store the revenue before any 3rd party takes a commission. 
  • Net Receipts – The value stored in the Net Amount field will be taken as the calculation input. This field is generally used to store the revenue earned by you.
Whichever deal type you select, be sure your Sales Templates always captures the relevant values when inputting sales data onto Curve. For example if you work with Gross Receipts deals, make sure you capture the Gross Amount. Sometimes this data may not be shown explicitly in your sales statement, and you may need a Copy Field (eg to copy data from the Net Amount to Gross Amount column) or a Calculation (eg to multiply the Gross Amount by a percentage to get your Net Amount) to make sure the correct base is stored in the correct field.
Rate % – The royalty rate to be applied in these circumstances. This is the payee’s share. So if you have an 80/20 Royalty deal in your favour, the value to enter is 20.
Reduction % (✪) – This field further reduces the royalty amount. A reduction percentage of 50 would halve the royalty. A reduction percentage of 75 would turn $10 into a $7.5 royalty. This field is only available to Curve Pro clients as part of the Complex Sales Terms add-on ✪.

If Multiple Terms Match the Revenue, Which Term Will Be Applied?

To any given sales line, the contract will always apply the Income term that is most specific. The order in which the terms are created on the Contract does not make a difference. The term that is deemed most specific is decided by three rules.
1. Which term has at least one condition that is highest up in the hierarchy. The hierarchy goes from left to right, so from Cat Type > Cat Group > Territory > Channel > Configuration > Source.
2. If two terms both have a condition that is equally high up in the hierarchy, which of these is a direct condition rather than a Contract Term Group? A Configuration condition for Stream will be deemed more specific than a configuration condition for an Online Contract Term Group. Similarly, a Territory condition for the US will be deemed more specific than a Territory condition for a Territory Group US & CA for example.
3. If two terms both have a condition that is equally high up in the hierarchy, and they both are direct conditions or both are group conditions, then Curve will look at the first following condition to verify which Term is deemed most specific.
As an example, below, we are displaying six terms which are ordered from most specific to least specific. The first term is most specific, because it has a Cat Type condition. The 2nd and 3rd term both have a Territory condition, but the 2nd term is deemed more specific because it is a specific Territory rather than a Territory Group. The 4th and 5th term both have a Channel condition, but the 4th term is deemed more specific because it also has a Configuration condition. Finally, our 6th term is least specific because it does not have any conditions set.
Let's have a look at a real-life scenario. The following example contains a common pitfall. We have specified a term for Performance revenue, and a term for Streaming revenue. Our first term is more specific, which means that any royalty lines with a Performance - Streaming combination will be applied the top term of 70%. If that is what you were aiming to achieve, excellent. But you may have been aiming for all Streaming revenue to be applied an 80% royalty rate.

This discrepancy can be resolved as shown in the below example. By creating an additional term that specifies an 80% royalty for Performance - Streaming income, this term now becomes more specific than the first term. Income mapped to the Channel “Performance” and Configuration “Streaming” will now be applied an 80% of Net Receipts rate.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.