Record Label Management Software: When the Release Calendar and the Recoupment Ledger Stop Agreeing

Why the release calendar and the recoupment ledger stop agreeing

Here is the scene we walk into at label services groups and independents. There is a shared calendar with 11 releases in the next 90 days, colour coded by artist. There is a spreadsheet called MARKETING_SPEND_Q3 that the digital manager updates when she remembers. There is a distributor dashboard that knows what has been delivered and nothing about what was promised. There is an inbox where artwork approvals, mix revisions and clearance confirmations arrive as attachments. And there is one person, usually in finance, who maintains the artist balances in a separate workbook with a tab per deal.

None of those four things talk to each other, and the cost is not abstract. Across label projects we have delivered, the pattern is 8 to 12 hours a week of senior time spent assembling information that should already exist, one or two releases a year that miss editorial consideration because assets went out late, and an annual statement run that takes three weeks because the marketing recharges have to be reconstructed from invoices and memory. The bigger risk is the trust one. An artist who cannot get a straight answer about their unrecouped balance will eventually get a lawyer to ask, and by then the cost is the relationship.

Problem 1: a release is a project with hard external deadlines, and no label tool models it

A release is not a row in a catalogue. It is a project with a critical path that runs backwards from the street date. Audio has to be mastered and ISRCs assigned before delivery. Delivery to distribution has to clear the DDEX ERN validation before it reaches the stores, and a rejected message on artwork dimensions or a missing contributor role costs days you do not have. Playlist pitching has its own window, and Spotify publicly advises pitching at least seven days before release, which in practice means your final masters and metadata have to be locked well before that.

Reprtoir handles catalogue and asset management well and gives you somewhere sane to keep audio and metadata. Revelator is distribution first and knows how to get a release into the stores. Neither of them models your release as a dependency graph with owners and dates, because they are not project systems. So the label runs the project in Asana or Monday or a calendar, disconnected from the catalogue record, and the two drift within a week of the date moving.

What a custom build does: one release object that owns the date, and every task hangs off it with an offset. Move the street date and the mastering deadline, the delivery date, the pitch window, the embargo and the asset approvals all move with it, and the people responsible get told. Delivery status comes back from the distributor by API so the calendar knows what actually shipped, not what someone believes shipped. This is the feature label ops staff notice in week one.

Problem 2: your deals are bespoke and they live in PDFs nobody reads twice

Every deal on your roster is different, and the differences are exactly the parts that determine money. A distribution deal at 80 or 85 net. A licence with a 60 month term and a reversion. A profit share where recording costs come off the top. An artist where marketing is recharged at 50 per cent and another where it is 100 per cent. Cross collateralisation across two albums but not the EP. Producer points paid from the artist share, a featured artist paid from the master, tour support that is recoupable but not returnable.

Curve Royalty Systems is genuinely good at what it is built for, which is processing royalty statements and calculating splits. What it is not built to be is the place your deal terms live as executable rules alongside the release project and the marketing budget, so recoupment pools that span specific projects and specific cost categories usually end up modelled by hand outside it. That hand modelling is where labels lose money quietly, because a marketing invoice coded to the wrong recoupment pool is invisible until an artist manager audits you.

What a custom build does: the deal becomes a set of machine readable terms attached to the artist and to the specific projects it covers. Every cost that enters the system, a mastering invoice, a video payment, an ad spend line, gets coded at entry to a recoupment pool or to label overhead, and the person coding it sees the deal term on screen while they do it. The unrecouped balance is then a live number, not an annual reconstruction.

Problem 3: income arrives in thirty shapes and none of them are yours

Monthly statements come from the distributor, sometimes from Merlin, sometimes direct from a DSP, sometimes from a sub distributor in a territory, sometimes from a sync agent as a PDF. Every one has a different column layout, a different territory naming convention, different currency handling, and a different lag. Physical adds returns reserves. Sync adds one off payments that need splitting against a different set of terms. Neighbouring rights come in annually from somewhere else entirely.

The manual version is a person spending the first week of every month reshaping CSVs so they can be pasted into a master workbook, matching on ISRC and hoping the ISRC is right, then hand keying the odd PDF. Errors here are silent. A misparsed territory column does not throw an error, it just produces a slightly wrong statement that nobody catches for a year.

What a custom build does: an ingestion layer with a saved mapping profile per source, so a new statement file from a known payer is parsed, validated against expected ranges and posted without a human reshaping anything. Unmatched ISRCs go to an exception queue rather than being dropped. Foreign currency is converted at a rate you record and can defend later. This is unglamorous and it is the single most valuable piece of plumbing a label of any size can own, because it turns three weeks of statement season into two days of reviewing exceptions.

Problem 4: you cannot see whether a release made money until it no longer matters

Ask most independent labels for the contribution of a specific release 12 months after street date and you will get a project. The costs are spread across an accounting system that knows suppliers but not releases, a marketing sheet that knows campaigns but not invoices, and the statement workbook that knows income but not spend. So decisions about which artist to reinvest in are made on instinct and on how the last conversation went.

What a custom build does: every cost carries a release identifier from the moment it is committed, not when it is paid. That distinction matters, because a label commits to a video budget weeks before the invoice arrives, and the useful number is committed spend against the plan, not cash out. Then the release view shows plan, committed, actual, income to date and contribution, and the roster view rolls it up. Labels that get this running usually change how they allocate marketing within two quarters, because for the first time they can see that the catalogue track quietly earning every month is outperforming the campaign everyone was excited about.

Problem 5: the artist balance question, and why a portal pays for itself

The most expensive recurring conversation at a label is an artist manager asking where the money is, and every one of those emails pulls a senior person into a manual dig. An artist facing portal showing statements, the unrecouped balance and what has been charged to it removes most of that traffic and changes the tone of renegotiations. One hard rule: do not build the portal until the recoupment engine is trusted internally, because publishing a wrong balance to an artist is worse than publishing nothing.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape for label operations is this. A first release covering the release project plan with date driven dependencies, artist deal terms as executable recoupment rules, and cost capture against releases runs $55,000 to $120,000 and ships in 10 to 14 weeks. A full platform adding multi source statement ingestion, splits and payee calculation, per release and roster profit and loss, marketing budget control and an artist portal runs $140,000 to $350,000 phased over 5 to 10 months.

What drives the price up in this category specifically: the number of distinct deal shapes on your roster, because each one is rules work, and a group that has acquired catalogues will have inherited terms nobody can explain. Publishing, if you administer it, is a separate data model from recordings and effectively a second project. Physical, because returns reserves and manufacturing costs bring in inventory. Neighbouring rights and sync, each of which has its own income shape. Direct DDEX delivery, if you want to deliver to stores yourself rather than through a distributor, which is a specialist build measured in months not weeks.

What keeps it down: starting with your active roster and the last two years of releases rather than a full catalogue migration on day one. Historic catalogue can be loaded later, once the model has proven itself on live releases.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you release fewer than about 20 titles a year with a small roster on broadly similar deals. Curve for royalties, your distributor's dashboard for delivery, and a well kept spreadsheet is genuinely enough, and a custom build at that size is a distraction from signing better artists. Buy also if royalty accounting is the only thing that hurts, because that is a solved problem and Curve solves it.

Build when two or more of these are true. Your deal terms differ meaningfully artist by artist and the differences drive real money. You are running enough concurrent releases that the calendar and the delivery reality drift. You are a label services business where clients expect visibility into their own release, which no packaged tool will give them under your brand. You have acquired catalogue and inherited terms that need to be encoded before the people who remember them leave. Or your annual statement run has become a three week hostage situation.

How to choose a developer for label operations software

Ask them to model recoupment on a whiteboard before you sign anything. A developer who has done this asks immediately about cross collateralisation scope, whether marketing is recharged at 50 or 100 per cent, and whether producer points come off the artist share or the master. One who draws an artist table with a balance column has never seen a real deal and is about to learn on your money.

Ask what they know about DDEX. You do not need them to be a delivery specialist unless you are building delivery, but they should know that ERN is the message standard, that ISRC and UPC identify different things, and why a delivery gets rejected. If DDEX is a new acronym in the meeting, the integration estimate they give you is a guess.

Ask how they will handle statement ingestion when a payer changes their file format without telling you, because they will. The right answer involves versioned mapping profiles and a validation step that fails loudly, not a parser someone edits each time.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and we would tell you to walk away from any developer who hedges on that, because in a business built on ownership of rights you should not be renting your own operating system.