Multi-Label Royalty Accounting: How to Run One Platform With Separate Permissions

How label groups, distributors, and business-management firms run royalty accounting for many labels on one platform: organisation structures, sub-label separation, scoped roles, client visibility, payment controls, and a recommended permission matrix.

A label group acquires its third imprint and inherits a third royalty system. Finance now closes the quarter three times, in three logins, with three different ideas of what a distribution fee is, then rebuilds a group-level view in a spreadsheet that nobody fully trusts. Meanwhile the operations manager at the newest imprint has a login to the group's main system that lets her see every contract in the building, including deals for artists she has never worked with. Both situations are common, and both are avoidable.

This article is for the people who run royalties across more than one label: group finance teams, distributors administering royalties for the labels they distribute, and business-management firms accounting to clients who never share a roster. The question is the same in each case: how to get the efficiency of one platform without giving everyone the keys to everything.

Why separate systems and open systems both fail

Running one system per label feels safe because the walls are physical. Nobody at Northlight Records can see Harrow Street's contracts because they are in a different database. The cost shows up in the work. Every DSP delivers one report covering every label in the group, so the same file has to be split, loaded, and reconciled three times, with three chances to mis-split a line. Every currency rate, every catalog correction, every template update is applied three times. Group reporting means exporting from each system and joining the results by hand, which is where numbers quietly drift.

The opposite approach, one system where every staff member has a full administrator account, removes the processing overhead and creates a different problem. Royalty data holds contract terms, unrecouped balances, bank details, and tax identifiers. An administrator at one imprint who can open another imprint's payee record can see an account number they have no reason to see. A member of staff who can both edit a contract rate and release a payment can, with no second pair of eyes, change what an artist is owed and pay it. Auditors notice this, and so do artists' lawyers.

The workable middle is a single platform whose organisation structure defines what each person can reach, with roles that define what they can do once they get there.

The organisation structure that does the work

Permissions are only as good as the structure they attach to. A platform built for groups models at least four layers: the group, the legal entity, the label or imprint, and the payee.

The group is the top of the tree and owns shared configuration: ingestion templates, exchange-rate sources, and the statement calendar. The legal entity sits below it and matters because it is the thing that actually contracts with artists and pays them. A group often has several: a UK limited company, a US LLC, and a publishing arm that must never share a bank run with the recorded-music side. Statements carry the entity's name and registration details, and payment batches are generated per entity because each has its own bank account and tax reporting obligations.

Below the entity sits the label or imprint, the operational unit where catalog, contracts, and statements live day to day. Then comes the payee: the artist, producer, mixer, or licensor who receives statements and money. A producer with points on releases at two imprints should be one payee record with two contract assignments, not two records with two sets of bank details that may not match.

Every contract, recording, product, sales line, and statement should belong to exactly one node in that tree. When that is true, "who can see this" becomes a question about which nodes a user has been granted, which the software can answer precisely.

Sub-label separation in practice

Separation between sub-labels is not just about hiding data. It is about keeping each imprint's operational footprint self-contained while the group shares the machinery.

Take a group with Northlight Records and its dance imprint, Harrow Street. Both receive revenue through the same distributor, which sends one monthly CSV. On ingestion, the platform reads the label field or the UPC and routes each line to the correct imprint. Lines that match no catalog go to a quarantine, and Northlight's catalog staff see only Northlight's unmatched lines while Harrow Street's team resolve their own. A line coded to a UPC that both labels believe is theirs surfaces as a conflict at group level, which is where someone with group-wide visibility should resolve it.

Contracts follow the same pattern. A deal signed by Harrow Street is visible to Harrow Street staff and to group finance, and invisible to Northlight. Statement templates and portal branding are set per imprint, so a Harrow Street artist logging in sees Harrow Street's logo and statement layout, not the parent company's. Group finance runs one unrecouped-balance report across every entity and imprint; Northlight's general manager runs the same report and sees only Northlight.

Role-based access scoped by structure

A role describes what a person can do. A scope describes where they can do it. Combining the two is what makes a single platform safe.

Most groups need a small number of roles. Finance sits at group or entity level and owns money: finalising statements, approving and releasing payments, and holding the only routine access to bank details. Operations runs the royalty cycle: ingestion, matching, calculation, and draft statements, usually across the whole group because the cycle is shared. Catalog staff maintain recordings, products, and identifiers, scoped to their own imprint. Artists and other payees use the portal and see their own statements, balances, and payment history. External clients, the label or artist that a business-management firm or distributor accounts to, see their own data and nobody else's.

A user can hold different roles at different scopes. The general manager of Harrow Street might be Operations for Harrow Street and hold nothing at Northlight. A group financial controller is Finance at group level, which cascades to every entity and imprint beneath it. When Harrow Street is sold, the platform should let you remove the imprint's scope from every user in one operation and produce a log of who had access on the day of sale.

Client visibility for firms and distributors

Business-management firms and distributors face a stricter version of the same problem. Their "labels" are clients who are, in some cases, competitors of one another, and each client wants to log in and see their own position.

The client role should be read-only over its own subtree: finalised statements, earnings by source and territory, recoupment position, and the payments made against those statements. It should never expose the firm's other clients or the ingestion detail showing which other clients appeared in the same distributor file. A useful test during evaluation is to log in as a client, open a statement, and try to trace a line back to its source file. You should reach the client's own row and no further.

Client access also needs a clean exit. When a client leaves the firm, the platform should export their contracts, catalog, sales history, and statements as a package, then close the scope, without the firm handing over anything belonging to another client.

Payment controls and separation of duties

Money leaving the building deserves the tightest controls in the system. The pattern that satisfies most auditors is a three-step chain with different people at each step.

Operations produces the payment run from finalised statements, applying thresholds and holds (no payment under the configured minimum, none where a tax form is missing or a bank-detail change is pending). Finance approves the run, checking the batch total against the finalised statements and spot-checking any payee whose amount moved sharply from the prior period. A second Finance user releases it, generating the bank file or triggering the payout provider. The platform should refuse to let the approving user also release, even though both hold the same role, and it should record all three actions with timestamps and user identities against the batch.

Bank details are the other pressure point. Payees update their own details through the portal, and a Finance user approves the change before it is used. Until then, the old details remain in force and the payee's payments are held. A change approved within minutes of a login from a new device is the kind of thing your activity log should make easy to find.

Recommended permission matrix

The matrix below is a defensible starting point for a group or firm with five roles. Adjust it to your headcount, but change the payment rows only with your auditor in the room.

Three notes on reading it. "Approve only" means the role cannot make the change directly but signs off a change proposed by someone else, which is how contract edits, bank-detail updates, and user changes gain a second pair of eyes. Finance holds both payment approval and release, but the platform should enforce that two different Finance users perform them. Operations manages users because someone has to, and Finance approves any change granting payment or bank-detail rights so that Operations cannot escalate its own access.

One template library, one statement cycle, one team

The reason to accept the discipline of structure and roles is what it buys on the other side.

Ingestion templates are defined once at group level. When a distributor changes its column layout, one person updates one mapping and every imprint's next import uses it. Exchange rates and conversion dates are loaded once. The unmatched-lines queue is one queue, filtered by scope, rather than three queues checked by three people on three schedules.

The statement cycle becomes a single calendar. Quarterly statements for every imprint are calculated in one run, reviewed by operations, finalised by finance, and published to portals on the same day. Adjustments and retroactive corrections follow the same process everywhere, so an auditor sampling Harrow Street's statements finds the same paper trail as at Northlight.

Most importantly, one team can run it. A group with four imprints does not need four royalty administrators; it needs one team with group scope and a catalog contact at each label who handles their own metadata and unmatched lines. Qlero's Enterprise tier is built for this model — multi-entity operations on one platform, with role-based access, white-labelled portals per imprint, and payment approval workflows.

Ready to consolidate without losing control?

Book a demo at qlero.io/book and bring your organisation chart, your list of entities and imprints, and the permissions your current systems actually grant. We will map them onto a single structure, show you where the separation-of-duties gaps are today, and walk through what one platform with proper scoping looks like.