Subsidiary Rights and Permissions Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the rights grid get scoped as a spreadsheet replacement so often?

Because that is how it is described in the first meeting. The rights director says we keep it all in a grid, here is the grid, we want that but searchable. A supplier looks at a spreadsheet with titles down the side and languages across the top and quotes a database with a filter.

What the grid actually encodes is combinatorial and mostly invisible. For one title you may control world rights in all languages, or English language rights in specified territories with another publisher holding rest of world. Within that sit volume rights, translation rights per language, audio, dramatic, first and second serial, book club, large print, anthology and quotation, digital, and now audio adaptation and machine learning uses that older contracts never contemplated. Each has a term, a territory and a reversion condition, and each of those comes from a clause.

The fix is to separate the right from the clause that governs it and to say so before anyone estimates. Each title links to a contract, each contract belongs to a template generation, and each right record carries the clause reference defining its scope, its reversion trigger and its split. The grid then becomes derived rather than maintained. That single structural decision is what turns which titles have free German translation rights from an archaeology project into a query, and it is the difference between a fair list taking an afternoon and taking a fortnight.

What goes wrong when an inherited rights database is migrated?

Houses that grew by acquisition carry a rights database from the acquired publisher that nobody can query, and the temptation is to import it wholesale into the new system so the backlist looks complete on day one. That is how you convert an unreliable record into an authoritative looking one.

The failure shows up commercially rather than technically. Somebody sells a right on the strength of a migrated row that was populated inconsistently by a team that no longer exists, or a right that reverted before the acquisition and was never marked. Selling a right you no longer hold is the error in this field that costs both money and a relationship with an agent who will remember it.

The fix is to profile before promising. Sample the inherited data against original contracts, work out which fields were maintained and which were aspirational, and import with explicit confidence markers so an unverified record is visibly different from a verified one. Prioritise verification on the titles that actually earn, because verifying an entire backlist at once is rarely affordable and rarely necessary. Any supplier who proposes a clean migration before looking at the data is proposing to import errors faster.

Why do royalty and title management integrations break after launch?

Because the boundary between systems was never drawn precisely, and subrights income does not behave like sales income. Three patterns recur.

• Money arrives in the wrong shape. A translation advance comes from a foreign publisher, is subject to withholding tax in that country, splits with the author at a contract rate, may split again with a co agent, and has to land on a statement in the correct period against the correct title, possibly recouping against the original advance.
• Splits vary per deal and per territory, so an integration built around one split rule quietly misallocates a whole season of licences.
• Title data disagrees. Your title management system holds one version of an identifier or an imprint and the rights platform holds another, so reconciliation becomes manual again, which was the problem you were solving.

The fix is to attach the money to the deal and let the rights platform own deal truth while your existing royalty system continues to own royalty accounting. Advance, terms, split percentages, co agent share, currency and withholding position all sit on the licence record, and allocated income feeds the royalty run rather than being retyped from a spreadsheet. Replacing royalty accounting outright is a much larger project than the return justifies for most houses, and it is where budgets in this category most often go.

What happens when reversion and option deadlines are not covered?

They get answered reactively, days late, and inconsistently across a list. Modern contracts define reversion by conditions rather than by a date: the work being out of print under a definition the contract specifies, sales falling below a threshold over consecutive royalty periods, or the publisher failing to exploit a right within a defined window. Older contracts define out of print in terms that predate print on demand entirely, which is precisely why the answer differs by contract generation.

So when an agent writes asking for reversion, somebody finds the contract, reads the clause, pulls the sales history, computes and replies. It takes days, the answers vary between titles, and the house is always responding rather than deciding. Options behave the same way in the other direction: an option lapses, nobody notices, and a title sits blocked for two years after it stopped being blocked.

The fix is to encode the reversion test as an evaluable rule attached to the contract and run it continuously against sales data. Titles approaching a trigger surface before the agent writes, which changes the conversation entirely, because you can decide deliberately whether to promote, reissue or let the right go. Rights that have reverted must be marked unsellable everywhere immediately, not noted somewhere.

Should you build custom or configure what you already own?

A good number of houses should configure and we would say so before quoting. If you publish under roughly fifty titles a year on a consistent contract template, a rights module in Virtusales Biblio or a well maintained grid is proportionate, and the money is better spent on acquisitions and marketing. If your primary need is title and product data rather than rights, Klopotek and Biblio are strong there and the rights layer arrives with them. Ingenta handles content distribution and the commercial side competently, and none of that is worth rebuilding.

Where those products strain is the clause library problem described above, because their rights taxonomies are fixed and variation between contract generations ends up recorded as free text. That is a real limitation for a large backlist and not a criticism of the products for the houses they were designed around.

Build when two or more of these hold. Your backlist runs to thousands of titles across multiple contract generations and nobody can produce the availability picture without opening PDFs. You have acquired another house and inherited a rights database you cannot query. Your reversion answers take days and vary between titles. Permissions volume is high enough that handling cost eats the fee, which is where university presses usually arrive first. Or you are being asked new licensing questions and cannot report on where the backlist stands.

How do hidden costs get into the quote?

Through the parts of publishing that are historical rather than functional.

• Contract generations counted as one. Each generation needs its clause behaviour modelled and then verified against real contracts by someone who knows them, which is discovery time from your rights director rather than engineering time.
• Imprint and territory structure. Several imprints with different practices means several sets of defaults, approvals and reporting cuts.
• Inherited data from an acquisition, which is profiling and reconciliation work, not an import.
• Multi currency and withholding tax, if you licence widely. Currency alone is manageable; withholding rules and the paperwork behind them are not.
• Author and agent portals, which look simple and carry real access control and data protection obligations.
• Permissions policy authoring. Somebody has to write the fee schedule and the rules for what auto approves before any of it can be automated.

Ask for the quote broken down by contract generation, by imprint and by integration, and ask how many hours of your rights director's time the discovery phase assumes.

What separates a build that works from one that fails here?

Scope discipline in the first phase. Model your last two contract generations properly and treat the older ones as exceptions, start with translation and audio rights rather than the whole grid, and leave royalty integration to a later phase once deal data is trustworthy. Houses that try to encode thirty years of clause variation before shipping anything spend a year in discovery and never reach a fair list.

The second marker is how the system handles categories that did not exist when the contracts were signed. Podcast adaptation, audio abridgement, interactive formats and text and data mining are live commercial questions, and what a contract from 2009 says about them is usually nothing. Whether silence favours the publisher or the author is a matter for your counsel, not your software. What the software must do is make the taxonomy extensible and treat unaddressed as a first class state alongside granted and reserved, so you can produce the list of titles where the position is clear and the list that needs legal review.

When vetting a developer, ask them to model a reversion clause. Someone who has worked in publishing asks what the out of print definition says and whether print on demand availability counts, because that is the crux. Someone who has not proposes a date field, and you will be back to reading contracts within a year. Then ask what they would do with the inherited database from your acquisition, and listen for profiling and confidence markers rather than a promised clean migration.

Settle ownership before kickoff: repository, database and cloud accounts. At Digital Heroes the client owns everything from the first commit. A rights grid is a register of assets accumulated over decades, and it should live somewhere you control absolutely.