Publishing Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the royalty engine keep getting scoped as a rate field?

Ask a developer to build royalties and you will usually get a rate on a title, a units count and a multiplication. That model matches how the requirement gets described in a meeting and it does not survive contact with a single real contract.

A mid list title might carry 10 percent of list on the first 5,000 hardcover, 12.5 percent to 10,000, 15 percent thereafter, 7.5 percent of net receipts on trade paper, 25 percent of net receipts on ebook, a 50/50 audio licence split, 50/50 on translation and 90/10 on first serial, a joint account across three titles by the same author, an advance earned against all of it, an agent of record taking 15 percent, a co author split, and a high discount clause that flips the basis whenever the discount to an account exceeds 55 percent. This is specific to publishing because each of those terms was negotiated separately, by different people, sometimes years apart, and amended afterwards.

The fix is to model the contract as a versioned rules object rather than a set of fields. A term set attaches to a work with an effective date, a format scope, a territory scope, a channel scope and a calculation basis. Escalators are threshold rows. Joint accounts are explicit links with an earn out order. Every statement line then stores the exact term version and threshold row that produced it, so an agent query in November resolves by clicking the line rather than by reopening the workbook. If a developer's answer to your ugliest contract mentions a rate field, they have never built this.

What goes wrong when you onboard a contract backlog?

Contract onboarding is the largest variable in a publishing project and it is routinely priced as data entry. A publisher with 400 structured contract records is a different engagement from one with 3,000 scanned agreements going back to 1994, and the second is where schedules die.

Three traps recur. The first is amendments: the head contract says one thing and amendment three changes the territory, filed as a separate scan under a different name, so any process reading only the primary agreement produces confidently wrong terms. The second is that older agreements predate formats they now earn on, meaning audio and ebook rates were added by letter agreement or never addressed, and someone has to decide what governs. That is a legal decision, not a data one. The third is that reverted titles sit in the pile alongside live ones.

The approach that works uses document extraction to draft rather than to write. Run the corpus through an extraction pass that pulls candidate territory, language, format, term and reversion clauses, present each side by side with the highlighted clause text, and require a rights or contracts person to confirm every one. The model never writes to the terms table directly, and each approval is logged with the clause it came from. On a 900 contract backlog that turns a project nobody would fund into a few weeks of part time review. Sequence it by earning titles first, because the tail is long and mostly dormant.

Why do the earnings feed integrations break after launch?

Every sales channel reports differently and each one has a quirk that only appears after you depend on it. Amazon Vendor Central, Ingram, Audible, Findaway, Draft2Digital, OverDrive and direct sales use different unit definitions, different currency handling and different reporting calendars, and normalising them is real integration work rather than a mapping table.

The failure that actually damages a close is restatement. A channel reissues a prior period with corrected figures after you have paid on the original, so the period now has two truths and your engine must decide which one the current statement reflects and how the difference is disclosed. Systems that overwrite the earlier figures produce statements that no longer reconcile to what the author was told, and the first person to notice is the agent. Currency is the second recurring break: a feed reporting in the account's currency needs a stated conversion policy with the rate and date recorded per line.

Build for restatement from the first release. Store earnings as immutable period records with a source and a load identifier, treat a correction as a new record superseding the old rather than replacing it, and show adjustments to prior periods as explicit lines on the current statement. Ask any developer which of those named feeds they have normalised before, because a general claim of integration experience usually means none of them.

What happens when returns reserves and rights availability are not covered?

Two gaps sit here and both cost money quietly. The first is the returns reserve. A reserve is a liability with a release schedule tied to a returns curve, not a percentage field. Publishers who model it as a flat percentage either hold too much, which authors and agents notice and resent, or too little, which turns into a negative balance when a returns wave lands and produces a statement conversation nobody enjoys. Store a returns curve per account per format from your own history, then release reserves on a schedule the author can see, with the balance and release dates shown on the statement.

The second gap is rights availability, where revenue leaks without anyone recording a loss. A Spanish house asks about world Spanish for a 2023 title. Answering requires checking whether the head contract granted translation rights or reserved them, whether a Latin American deal carved out territories, whether a prior option period has expired and whether the audio licence conflicts. That is four sources and a folder of scans, and the answer arrives conservative because nobody wants to grant something twice.

Model rights as a graph rather than a grid. Each grant record carries territory as a country list rather than free text, plus language, format, channel, term start and end, exclusivity, option windows and reversion triggers. Availability then becomes a query. The connection to metadata matters too: when rights and ONIX output come from the same record, you stop listing titles for sale in markets you do not control, which is a legal problem rather than a metadata one.

Should you build custom or configure what you already own?

Buy, genuinely, if you are under roughly $8M in net sales, single imprint, with mostly straightforward contracts, under about 300 royalty payees, and ONIX distribution as your loudest pain. Firebrand Title Management and Bookmaster will serve you better than a custom build and the money is better spent on marketing. Klopotek and Virtusales BiblioSuite model far more deal complexity than a generic system and do it well for the shapes they were designed around. Rightsline and IPR License handle rights inventory reasonably.

Before commissioning anything, check whether the spreadsheet exists out of necessity or habit. Take your ten most complicated contracts to your incumbent vendor and ask them to model each one. If eight come back clean, your problem is training and configuration, and finding that out costs a week.

Build when the signals stack, and they usually arrive together: the royalty close depends on one person's workbook, you have reissued statements more than once in the last two cycles, a rights availability question takes more than an hour, you cannot separate a reprint decision from a returns wave, or you pay for a system of record plus a rights tool plus an ERP (Enterprise Resource Planning) and still do the work in Excel. The middle path we recommend often is keeping the incumbent for ONIX and title metadata, where it is genuinely good, and building the royalty and rights core around your actual contract logic. Integration is cheaper than replacement and it avoids the migration that kills these projects.

How do hidden costs get into the quote?

A focused first release, almost always the title and contract data model plus the royalty engine, runs $60,000 to $130,000 and ships in 12 to 16 weeks in Digital Heroes delivery experience. A full platform covering rights availability, subrights, print and returns intelligence, an author portal, an ONIX pipeline and ERP integration runs $150,000 to $400,000 phased over 6 to 12 months. Five things inflate that and all five are knowable in advance.

• Contract backlog size and quality. The biggest single variable. Scanned agreements with separately filed amendments cost several times what structured records cost.
• Earnings feed count. Each named channel is its own integration with its own restatement, currency and timing behaviour, not a line item called sales import.
• Parallel running. At least one full close cycle alongside the old process, and the labour of running both belongs in the plan.
• Historical statement replay. Reproducing five years of past statements exactly is a meaningful share of the budget, and it is usually worth buying because it is the only thing that makes anyone trust the new number.
• Withholding and tax handling. W-8BEN collection and treaty based withholding for foreign authors is a real exposure that most developers discover during your first close rather than during scoping.

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

Four things. The first is that the first release does one thing completely. That thing is the contract model and the royalty engine, run in parallel for a full close cycle. Not rights, not print, not ONIX. Projects that attempt the whole platform in release one arrive at the close date with everything half working, which is worse than the spreadsheet.

The second is that the term logic is testable. Rules that only a developer can read produce arguments nobody can settle, so build a test harness where your royalty manager can enter a scenario, meaning units, channel, discount and period, and see which term version and threshold row fires. That harness is also how you validate against historical statements and how disagreements about interpretation get resolved without an engineer in the room.

The third is that the author portal drills down rather than displaying a PDF behind a login. A statement line should expand into units, channel, rate applied, term version and the reserve calculation, with the contract clause reference visible, and the reserve balance shown with its release schedule. In our publishing work this is the piece that pays for itself in support hours, and it does something less measurable that matters more: agents stop treating your statements as suspect.

The fourth is ownership. Own the repository, the schema and the deployment, agreed before kickoff. At Digital Heroes the client owns the code from the first commit. This system encodes your author contracts, your rights inventory and your payment obligations, so a supplier holding the code holds your ability to pay authors, and no commercial term makes that acceptable.