The same recording, a different code every time
A single recording earns royalties through at least three completely different reporting pipelines — streaming and download income through a distributor, performance income through a PRO, mechanical income through a collection society — and each one was built around its own identifier, at a different point in the music industry's history, for its own purpose.
This page describes exactly that mechanic — the logic that sits underneath royalty statement to Excel, spelled out on its own because it's the part worth understanding in detail before trusting it with a real catalog's reconciliation.
Why code matching alone isn't enough
In the ideal case, every statement carries a clean ISRC, every recording has one and only one ISRC for its entire life, and matching is a simple lookup. What makes matching genuinely hard is everything short of that ideal — and in a catalog of any age, that's most of it.
A sub-publisher statement might list only a song title, spelled with a translated or transliterated title in a foreign market. A PRO statement keys to ISWC, a code many independent releases never formally registered. A remaster or a regional release variant sometimes gets an entirely new ISRC for what is, functionally, the same recording a catalog considers one earning stream. None of these are exotic edge cases — they're what a royalty pipeline built from several independent systems, never designed to be read together, produces routinely.
What gets checked
| Field | Where it's checked |
|---|---|
| ISRC | Read exactly as printed on the statement line, compared to every other statement's ISRC field |
| ISWC | Compared where present, most reliably on PRO and sub-publisher statements |
| UPC / catalog number | Used to group lines from the same release when a track-level code is missing |
| Title and artist / writer | Fuzzy-compared as a fallback when no code resolves a match |
The matching hierarchy
Rather than trying every field at once and picking whichever combination looks most likely, matching checks a fixed hierarchy in order — the same sequence, applied the same way, every time.
ISRC matches exactly
The strongest signal available for recording-level income — streaming, downloads, mechanicals. Matched with high confidence.
ISWC matches exactly
The strongest signal for composition-level income — performance royalties, sub-publisher statements that never carry an ISRC at all.
UPC matches, plus title and artist agree
Used when neither track-level nor composition-level code resolves the match on its own, grouping by release and confirming with title.
Title and artist match, no code present or usable
Matched with a flag for a quick human confirm — the weakest signal, kept visible rather than silently trusted.
None of the signals resolve to a single line
Left unmatched, visible as its own group, never guessed from whichever recording is currently short on reported income.
ISRC and ISWC aren't interchangeable
The single most common confusion in royalty reconciliation is treating ISRC and ISWC as two names for the same thing. They're not. An ISRC identifies a specific recording — one particular performance, captured once, released as audio. An ISWC identifies the underlying composition — the song itself, independent of who recorded it or how many versions exist.
A single composition can have dozens of ISRCs against it — the original recording, a live version, a remix, a cover by another artist — each earning mechanical and neighboring-rights income separately, while all of them feed performance royalties back to the same ISWC and the same songwriters. Matching keeps these two identifiers, and the two different income streams they represent, distinct rather than merging them into one undifferentiated total.
Where UPC fits in
A UPC (or EAN, its international equivalent) identifies a release — an album, an EP, a single — not an individual track. It's the weakest of the three codes for pinpointing one specific recording, but it's useful for a different job: grouping every track that belongs to the same release when a statement reports at the release level, or when a track-level code is missing but the release-level one is present.
Where a distributor statement lists a UPC alongside a per-track breakdown, that release-level context also helps disambiguate two tracks with similar titles on the same release — a common case for deluxe editions and reissues that carry both an original and a bonus version of a similarly named song.
How title-and-artist fallback matching works
When neither a recording code nor a composition code resolves a match, the fallback compares track title and artist or writer name — normalized for common variation like punctuation, featured-artist notation and capitalization, but not aggressively rewritten in a way that could quietly merge two genuinely different songs that happen to share a common title.
A fallback match is always flagged at a lower confidence than a code match, specifically because a title is the weakest available signal — two entirely different works can share an identical title, and matching treats that possibility as real rather than assuming a title match is automatically correct.
Three confidence levels
Not every match is equally certain, and treating them all the same wastes review effort in one direction or risks a silent error in the other. Three levels keep that distinction visible.
| Level | When |
|---|---|
| High | An exact ISRC or ISWC match, with amounts and period consistent with the rest of the catalog's reporting pattern |
| Medium | A UPC-plus-title match, or a title-and-artist match with no code present at all |
| Low / unmatched | No combination of identifiers resolves to a single confident line |
When a line genuinely doesn't match anything
Some lines were never going to match cleanly — a one-off adjustment credit, a black-box distribution payment covering many unidentified recordings at once, or a correction from an earlier period folded into the current statement. Forcing those into a match would misrepresent an unusual line as routine per-track income.
Those lines stay in their own visible group rather than being pushed onto whichever recording happens to look under-reported. What happens to them next is a decision for the catalog owner, not the matching logic.
How it works
Upload the statements
Whatever each source exports, in whatever identifier structure it uses.
Each line is read
ISRC, ISWC, UPC, title and artist, for every line found, kept linked to its source statement.
The hierarchy check runs
ISRC, then ISWC, then UPC-plus-title, then title alone, evaluated in a fixed order.
Export
Excel, CSV or JSON, with confidence levels and source documents kept per line.
When the same recording gets a new ISRC
A remaster, an anniversary reissue, or a region-specific release sometimes registers an entirely new ISRC for what a catalog owner considers, functionally, the same recording and the same earning stream. Treated as strictly separate recordings, that split makes a track's income look smaller than it really is on any single reconciliation.
Where the UPC, title and artist all line up strongly enough alongside the ISRC mismatch, those variants are matched together into one combined earning stream rather than left artificially fragmented — flagged for a quick confirm the first time it happens for a given catalog, since merging two genuinely separate recordings by mistake is the failure mode worth being careful about here.
A catalog reconciliation, matched
A 40-track catalog, one quarter, statements from a distributor, a domestic PRO and a mechanical collection society run through the matching hierarchy together.
| Result | Lines |
|---|---|
| Matched with high confidence (ISRC or ISWC) | 104 |
| Matched, flagged for a quick confirm (title fallback) | 9 |
| Unmatched — investigated separately | 3 |
The three unmatched lines turned out to be two older tracks the catalog had never registered an ISWC for, plus one genuinely new synchronization payment that didn't belong to any of the statement types otherwise expected that quarter — each a concrete, specific next step once surfaced, rather than three anonymous discrepancies buried in a larger total.
What accuracy actually looks like
A useful way to think about matching accuracy isn't a single percentage — it's the shape of the distribution across the three confidence levels. A catalog with clean, consistently registered codes across its releases sees most lines land at high confidence, with only a small tail needing review. A catalog with older or under-registered releases sees a larger medium-confidence tail, which means more review time, not necessarily more errors.
That distinction matters because it's tempting to read a larger review queue as a sign the matching is working poorly, when it's often an honest reflection of how incomplete the underlying registration actually is. The alternative — resolving every ambiguous line silently and reporting everything matched — isn't more accurate, it's hiding the uncertainty instead of surfacing it.
Improving match rates over time
The match rate on a catalog's first reconciliation is rarely its best one. Registering a missing ISWC for an older release, correcting a typo in a distributor's ISRC field, and keeping title and artist spelling consistent across every platform a catalog is registered with are the three changes that improve match rates the most — and none of them require a change to the matching logic itself, only to the underlying metadata it reads.
A catalog that fixes its registration gaps once tends to see every subsequent reconciliation match at a consistently higher confidence, since the underlying identifiers rarely change again once corrected.
How a compilation or a various-artists release complicates matching
A various-artists compilation shares one UPC across tracks from many different rights holders, which means the release-level code alone can't distinguish which specific track's income belongs to which catalog. Matching in that case relies more heavily on the track-level ISRC, since it's the only identifier on a compilation statement that reliably narrows a line down to one specific recording rather than the whole release.
A catalog with tracks that regularly appear on third-party compilations — a licensed placement, a various-artists soundtrack — benefits disproportionately from having a clean, registered ISRC on every recording, precisely because that's the one signal a compilation statement can't confuse with another artist's contribution to the same release.
Featured artists and split-credit recordings
A track credited to “Artist A featuring Artist B” is registered as one recording with one ISRC, but statements from different sources sometimes list the artist field differently — full billing on one, primary artist only on another, initials or a stage-name variant on a third. Matched purely on artist-name text, those variants would look like different recordings.
Because the primary match runs on ISRC first, artist-field variation across statements for the same recording doesn't break the match — the artist field only matters at all for the weaker, code-absent fallback case, where featured-artist notation is normalized before comparison specifically to avoid this kind of false split.
What you get back
One row per matched line
Identifier, source statement, amount and confidence level, each in its own column.
Unmatched lines kept separate
Visible as their own group, not folded into whichever recording was under-reported.
Traceable to source
Every row linked back to the exact statement it came from.
Who this is for
Mostly useful for any catalog earning from more than one type of royalty source at once, where checking identifiers by hand across statements has stopped being a quick task: independent labels, music publishers and sub-publishers, self-releasing artists working with more than one distributor, and royalty accountants matching income across several clients' catalogs at once.
Matching across several catalogs at once
A royalty accountant or a small label group handling more than one catalog often has statements that mix recordings from several different rights holders in a single distributor export. Matching keeps each catalog's recordings distinct by their own ISRCs even when several catalogs' lines appear together in the same uploaded file, rather than requiring the file to be pre-split by catalog before it can be read.
Where this stops
ISRC and UPC matching confirms that a statement's own lines are correctly linked to the right recording or composition — it doesn't decide whether a royalty rate was correct, register a missing ISWC on your behalf, or file a black-box claim with a collection society. Those decisions, and the full picture of how matched lines become a reconciled catalog report, are covered in royalty statement to Excel.
That boundary is worth restating plainly, because it's easy to conflate “every line is correctly matched to its recording” with “every recording is being paid what it's owed.” A perfectly matched reconciliation can still reveal a rate a catalog never agreed to, or a territory that was never registered at all — matching surfaces that possibility clearly, but resolving it is a separate step outside what this feature does.