Reconciling Track Identifiers Across DSPs: A Report-Matching Checklist

Check ISRCs and provider codes across DSP reports, confirm recording identity and report scope, and distinguish a mapping fix from recovered royalties.

One recording can appear under different identifiers in reports from DSPs and distributors. Before combining the rows, a royalty team needs to establish two things: that they describe the same recording, and that the reported activity can be added without duplication.

An identifier mismatch is a reason to investigate. It is not, by itself, evidence that a service has underpaid, that money is permanently lost, or that correcting a catalog record will recover cash. This guide focuses on reconciling recording-level report rows across sources—not assigning new codes or rebuilding an entire import process.

Separate recording identity from report scope

An ISRC identifies a recording, while a UPC/EAN generally identifies a product or release. IFPI's guidance distinguishes those levels. A release total cannot simply be assigned to one track because the release and track have similar names. For the recording-versus-composition distinction, see ISWC vs. ISRC.

A provider's own track code is another identification system, not automatically an ISRC. Record which organization controls it. DDEX's proprietary-identifier guidance uses a namespace for that purpose: an identical-looking value from another system is not enough to establish a match.

Also distinguish usage dates, reporting periods, territories, use types and currencies. Keep source reports separate until you understand their definitions. Differences in artist spelling or row layout do not establish that a DSP has created a second recording or withheld income.

A worked example: two identifiers, one reporting view

Suppose a label re-uploads unchanged audio six months after release to correct a metadata typo, but a second ISRC is assigned. Use USAB12300001 and USAB12300099 as fictional example codes, not verified catalog assignments.

For the following year, assume the source data contains 550,000 streams under the first code and 250,000 under the second. The team has independently confirmed that both refer to the same audio, cover the intended reporting scope and contain no overlapping activity or duplicate summary rows.

• Combined usage in this model: 550,000 + 250,000 = 800,000 streams.
• A view filtered only to the first code omits 250,000 streams.
• That omission is 250,000 ÷ 800,000 = 31.25% of the modeled combined usage.

This is a reporting-view example, not a measured DSP incident. It does not establish how listeners reached either upload, whether either royalty amount was omitted from the distributor's payment, or whether an artist was underpaid. Reconcile the actual monetary rows and agreement separately. Spotify says it does not pay artists at a fixed per-stream rate, so the counts alone cannot support a dollar-loss estimate.

Do not apply this addition to arbitrary dashboard totals. In Spotify for Artists, a song appearing on multiple releases contributes its streams to each release's total. Adding those release totals can therefore count the same activity again.

A re-upload does not prove financial fragmentation

IFPI says to retain an existing ISRC for the same recording, including across releases or formats. Two codes in circulation should prompt an identity check, not an assumption that two distinct recordings exist.

Spotify's track-linking instructions concern retaining play counts when re-uploading with matching audio and metadata, including duration, title and artist name. That is a platform-specific check, not proof that historical royalty reports have been merged or corrected. Follow the provider's process for metadata updates rather than assuming another upload will repair the accounting.

Five steps to reconcile identifiers across sources

The following is a recommended control sequence, not a promise that every provider or accounting platform automates it.

1. Compare like-for-like rows as well as totals

Keep the original files. Record the sender, file reference, reporting scope and whether a file replaces an earlier report. Identify detail rows, summaries and adjustments before combining anything. Compare monetary totals in the same currency and on the same gross/net basis.

Then compare recording identifiers within that scope. A file total can be correct while rows are allocated to the wrong catalog record; conversely, a correctly identified recording can still have a missing report or amount. Both checks matter. For message-format questions, use the separate DDEX DSR reading guide.

2. Normalize a comparison key, preserving the original

DDEX's identifier rules specify a 12-character ISRC without display hyphens. They also require barcode leading zeroes to survive transmission.

For comparison, remove display separators only where the identifier's own rules allow it. Keep the raw source value alongside the normalized key. Do not apply a blanket punctuation-removal rule to every provider code, convert identifiers into numbers, or silently repair an unfamiliar code into a plausible-looking one. Formatting agreement is not evidence of recording identity.

3. Maintain a recording-to-source identifier register

Use one reviewed catalog record for each recording, with its release relationships kept separately. Record the source identifier, the proposed catalog match, supporting evidence, reviewer and decision date. This register is an operational recommendation, not a claim that Qlero automatically records all those fields or provides a complete audit log.

Check audio/version information, duration, delivery records and provider references where available. Names can help investigate but should not decide an ambiguous match. A live take or remix should not be merged with a studio recording just because their titles resemble each other. Equally, IFPI says an ordinary remaster generally keeps the ISRC unless significant new creative input changes the result; the word “remaster” alone does not settle the decision.

Keep the applicable rights, territory, dates and agreements available for the accounting check. Matching an identifier does not establish ownership or the royalty share to apply.

4. Keep unresolved exceptions visible

Separate confirmed matches from candidates and unresolved rows. If an ISRC is missing, request the missing detail or investigate other supplied references; do not force a match on title alone. If one code appears to identify different audio, stop and seek clarification rather than merging it into the first result.

Record the affected files and reported amounts where available, without labeling all unresolved amounts “lost royalties.” A match may solve the identity problem while leaving a contract, date, currency or reporting issue unresolved.

5. Escalate the specific discrepancy and verify the result

Send the appropriate provider the original file references, relevant rows, identifiers, supporting catalog evidence and the precise question. For example: should two codes identify the same recording, or is a report missing a separately identified version?

Ask what will change: source metadata, a future report, a corrected historical report or a financial adjustment. Preserve the response and reconcile any replacement before counting it. A catalog correction, a corrected statement and a bank receipt are different evidence. Neither a standard response time nor a recovery outcome can be inferred from an identifier mismatch.

Four exception patterns worth checking

• A second code after re-delivery: confirm the audio and existing assignment before deciding whether it is a duplicate identifier or a distinct recording.
• Different names or credits: treat them as investigation clues, not proof of different identity or unpaid income.
• Missing identifiers: obtain supporting references or corrected source data; an approximate title match is not the only possible response.
• Different reporting levels: establish whether a row describes a recording, release, summary or adjustment before attempting to compare or combine it.

These are useful categories for a review queue, not a ranked list of the industry's most frequent failures.

What Qlero documents—and what still needs checking

Qlero's alias guide documents additional identifiers used to match incoming sales. External ID is a reference/export field, not a sales-matching field. Aliases are case-insensitive and must be unique within their own type. Editing them requires Repertoire write access; edits in the Aliases tab take effect when saved.

The invalid-lines workflow is a separate route. Linking an incoming identifier to existing repertoire saves an alias immediately, and later files from any source in that record company can match it. Leaving the manager does not undo the link. This makes the recording-identity check important, especially for provider-specific codes that might collide.

That workflow requires the documented Sales Files and Repertoire & Agreements view/write access. Save And Revalidate applies to the current file; other affected files need their own revalidation. Review remaining invalid reasons afterwards. Matching a track does not supply a missing exchange rate or repair every other field.

Revalidation and re-import are different. Revalidation revisits invalid rows without rereading the source file; it leaves other rows and issued statements unchanged. Re-import rebuilds processed data and is blocked by a linked Published or Closed period. Neither action recalculates statements by itself. Do not use a newly saved alias as evidence that historical artist statements have been corrected.

If the source layout also needs work, custom templates require Pro or Enterprise and the relevant Template/Sales Files permissions. These documented workflows are not evidence of automatic cross-DSP identity resolution, upstream metadata correction or cash recovery. That documentation limit is not proof that another capability is absent: ask for a demonstration with your actual reports.

Finally, Reported is not a payment confirmation. Check the artist's statement and payment evidence separately from the status of an imported row.

Make reconciliation a repeatable review

As an operating policy, consider checking each reporting period, with extra review after re-deliveries or provider changes. This is a recommendation, not a universal contractual deadline.

1. Retain the reviewed recording register and reuse confirmed delivery metadata.
2. Keep normalization rules explicit and test them against representative source values.
3. Carry unresolved exceptions forward with an owner and supporting files, not an invented match.
4. Follow up confirmed discrepancies and verify the provider's actual correction.
5. Review re-uploaded tracks for identifier continuity without assuming streaming continuity or financial recovery.

For a distributor handover, see the separate catalog and royalty-history checklist.

Frequently asked questions

Why might one recording appear under two ISRCs?

A second code may have been assigned on re-delivery, or the records may describe different versions. Check the evidence. A change of distributor is not, by itself, a reason to replace an existing ISRC for unchanged audio.

Can income be recovered after a mismatch is identified?

Possibly, but first establish whether the issue concerns a reporting view, allocation, an omitted royalty or an actual payment. Ask the responsible party about its correction process and applicable agreement. Do not promise recovery or a fixed number of weeks.

Is comparing statement totals enough?

No. Review both source totals and recording-level allocations. Do not assume that an apparently reasonable total proves correct matches, or that a mismatch proves money was withheld.

How can a label reduce repeat mismatches?

Maintain reviewed recording records, preserve source identifiers and evidence, and reuse confirmed metadata. Resolve ambiguous versions before approving mappings. These controls reduce avoidable ambiguity; they cannot guarantee error-free reports from every partner.

How often should identifiers be reconciled?

Each reporting period is a useful proposed review point, with additional checks after catalog changes. Set the actual policy around report availability, materiality and contractual obligations.

Does this also resolve publishing royalties?

No. Recording reconciliation can provide useful evidence, but identifying a composition and its entitled parties requires separate work and rights information. A recording alias does not establish a work registration or a publisher's entitlement.

Resolve the mismatch before claiming a recovery

The useful output is a documented link from each source row to the correct recording, with the report's scope and unresolved questions preserved. Keep that result distinct from correcting the provider's records, recalculating royalties and confirming payment.

To assess the documented Qlero workflow, book a demo with representative source files and a real identifier exception. Ask which steps are supported, what requires manual review and how existing statements would be handled.

Primary documentation checked on 4 October 2026. The worked example is illustrative; this article is not a report of hands-on DSP or royalty-system testing.