Royalties & commercial terms

Every Contract carries a commercial side: whether money changes hands for the content it governs, and if so, on what basis and at what rate. This page explains how those terms are modelled — the shapes the platform records so that a royalty rate is a precise, machine-actionable rule rather than a sentence buried in a PDF. It is a data-model page: it tells you what a commercial term is, not how a payment is eventually made.

The commercial terms sit on the same contract as the rights terms, but they answer a different question. The rights terms say what may be done with a Work — which territories, which formats, whether an AI may retrieve it. The commercial terms say what is owed when those permitted things are sold. Keeping the two apart matters, because most people who need to read rights have no business seeing money: the commercial block is private, returned only to callers whose token is explicitly allowed to see it.

A commercial term is deliberately structured. "10% of net receipts on the ebook, rising to 15% after the first £50,000, but only 12% through third-party stores" is not free text on this platform — it is a small set of typed rules, each naming the dimensions it applies to and the rate it charges. That structure is what lets the platform price a sale without a human reading the contract, and lets a rights manager see at a glance how two contracts on the same Work differ.

Throughout, two conventions hold, matching the rest of the platform: money is integer micros (1,000,000 micros = £1.00 in the contract's currency) and rates are basis points (100 bps = 1%, so 2,500 bps = 25%). Neither ever appears as a floating-point number.

flowchart TD
    C["Contract<br/>(governs a Work)"] --> R["Royalty block<br/>type · currency · basis"]
    R --> T["FREE<br/>no money"]
    R --> F["FIXED_FEE<br/>one flat amount"]
    R --> RY["ROYALTY<br/>rate rules"]
    RY --> RR["Rate rules<br/>dimensioned, most-specific-wins"]
    RY --> A["Advance<br/>recouped first"]
    R --> S["Splits<br/>divide the payout"]

Three kinds of commercial term

The royalty block always states a type, and the type decides which other fields are meaningful. There are exactly four:

Most default open-licence contracts (MIT, the Creative Commons family) are FREE. A typical author agreement is ROYALTY. A permissions deal that pays a lump sum regardless of volume is FIXED_FEE. A reviewer paid twelve ebook credits and a year's subscription is IN_KIND — deliberately not FREE, which means no consideration at all. In-kind elements can also ride alongside cash (FIXED_FEE or ROYALTY) for the cash-plus-copies hybrids real letters use, and a FIXED_FEE may be a unit fee instead of a lump sum — a price per page reviewed or per training session delivered, multiplied by the delivered quantity.

Every monetary amount on the contract is denominated in a single currency (an ISO 4217 code such as GBP), and — for a ROYALTY — priced on a single basis, which is the subject of the next section.

Basis: what the rate is applied to

A royalty rate is a percentage, so the platform has to know a percentage of what. That is the basis, and for retail sales it takes one of two values:

• NET_RECEIPTS (the default) — what Packt actually receives after the channel has taken its discount and after tax. This is the usual basis for modern digital contracts.
• LIST_PRICE — the headline price the customer sees, before any channel discount. Rarer, but common in older print agreements.

The difference is not academic. The same headline rate produces very different payouts depending on the basis, because a channel discount sits between the list price and what Packt banks.

Subscription and other pooled revenue is always priced on the revenue attributed to the Work, never on a list price — a consumption event has no headline price to take a percentage of. How that attributed share is computed belongs to a future service, not to the contract model (see the status note below).

Rate dimensioning: most-specific-wins

A single flat rate is rare. Real contracts pay different rates for different formats, channels, and markets: hardback and paperback carry different percentages; a direct sale pays more than one through a third-party store; a translated edition pays a reduced rate. The model captures this as a list of rate rules, each of which may narrow itself along up to six optional dimensions:

When a sale happens, it carries a value on every one of these dimensions — an ebook, sold direct, in the US, in French. The platform matches that sale against the rate rules and picks the most specific rule that applies. The Works dimension carries per-title commercial variance inside one deal — a catalogue at 50% with one title at 25% is a work-scoped rule beside the default; if rights (not money) differ per title, the deal splits into linked contracts instead. Specificity is simply the number of dimensions a rule pins: a rule that names the format and the channel beats one that names only the format.

Consider a contract with four rate rules:

Now price three sales:

A paperback sale, or an audiobook, matches nothing more specific than rule A and so is priced at the 10% default. That default is mandatory: a ROYALTY must include exactly one dimensionless rule, so every possible sale prices against at least one rule and nothing silently earns zero. Two rules may never match the same sale at equal specificity — an ambiguous rule set is rejected when the contract is written, rather than tie-broken at pricing time.

Advances, installments, and splits

A handful of further fields shape who is paid, and when.

An advance (advance_amount_micros) is money paid up front against future royalties. It is cross-collateralised across the whole contract: royalties from every format, channel, and territory accrue against the single advance pot, and the payees only begin receiving money once the advance has been fully recouped. There are no per-format advance pots — one advance, one contract-wide balance to earn out.

An installment plan (installments[]) records how the pot is actually paid — real advances arrive as 3–5 tranches, not one cheque. Each installment is a share or amount of the pot with a trigger: signing, a named milestone, acceptance, publication, a date. Shares must reconcile to the whole pot, with one deliberate exception: an EARLY_DELIVERY installment is a bonus on top — a reward for delivering early — and sits outside the sum. The contract records the plan only; deciding when a milestone is met and tracking what has been paid belongs to the Royalty service, fed by production facts.

Two boilerplate clauses also get structured homes because the Royalty service must enforce them: a minimum payment threshold (a period's payment below it carries forward rather than paying out) and a cross-contract netting flag (overpayments may be recovered from sums due under the party's other agreements).

Splits (splits[]) divide the computed royalty between the contract's parties — the everyday case being co-authors. Each split names an agent_id that must be a party on the contract, and a share_bps. The shares must sum to exactly 10,000 basis points (100%): a 60/40 co-author split is 6000 and 4000. Splits apply after the rate is computed and after the advance is recouped. With no splits declared, the whole royalty accrues to the contract's granting party.

Paying someone who is not a party is never a split. When an author signs a deed directing their royalties to a company, that is a payee redirect — a standalone instrument that re-routes where a party's money is sent without touching who earns it or any contract term (overview; the licensing example shows a full redirect record).

{
  "type": "ROYALTY",
  "currency": "GBP",
  "basis": "NET_RECEIPTS",
  "payment_frequency": "QUARTERLY",
  "advance_amount_micros": 5000000000,
  "rates": [
    { "rate_bps": 1000 },
    { "manifestation_type": "EBOOK", "rate_bps": 2500 },
    {
      "manifestation_type": "EBOOK",
      "channel_class": "THIRD_PARTY",
      "rate_bps": 1500
    }
  ],
  "splits": [
    { "agent_id": "agt_chandra", "share_bps": 6000 },
    { "agent_id": "agt_okafor", "share_bps": 4000 }
  ]
}

Commercial terms are private

The commercial block is the most sensitive part of a contract, and the platform treats it that way. Commercial terms never appear unless your token carries the contracts.commercial.read scope. Without it, a read of a contract — or of the rights projected onto a Resource — returns the usage and territorial terms only, with the royalty block simply absent.

The behaviour is consistent across every service:

• A caller without the scope who does not ask for commercial terms gets the resource with the royalty block omitted — exactly as if it were never there.
• A caller without the scope who explicitly names a commercial field (in a field mask, say) gets a 403, never a silent empty value. This fails loud: finance reading royalty can never mistake "you are not allowed to see this" for "there is nothing here".

Holding the scope lets an application ask to see commercial terms; it does not, on its own, grant sight of any particular contract — that is a separate access check — nor does it change what the content may be used for. It is one of the three independent layers of authorisation the platform applies. See the OAuth scope registry for how the scope is defined.

Related pages

• The contract model — the full contract record, of which the royalty block is one section (§7 has the complete field set).
• AI & your content — how AI use is priced as royalty events, and the default posture on AI.
• Standard licences — the default contracts, most of which carry a FREE royalty.
• Contracts & Rights — the overview: how contracts govern Works and how rights resolve.
• Worked examples — end-to-end contracts, including commercial shapes.
• Glossary — one-line definitions for royalty, basis, and the other commercial terms.
• Explorer — Chapter III — contracts and rights, visualised.