CD Baby Metadata Guide: Best Practices to Ensure Accurate Royalty Reporting

When a track earns plays but the money never follows, the root cause is usually mismatched identifiers or incomplete writer splits. This CD Baby metadata guide lays out field-level mappings, preupload validation checks, and postrelease correction workflows so downstream royalty reporting is auditable and recoverable. Expect concrete validation rules, sample spreadsheet templates, and step-by-step procedures for fixing metadata errors and reclaiming lost royalties.

1. How CD Baby metadata flows into downstream royalty systems

Direct routing, split responsibilities. Metadata you enter in CD Baby does three different jobs: it builds DSP and storefront catalog records, it supplies recording-level identifiers for collecting agencies, and it feeds composition/publishing registration data used by PROs and mechanical societies. Each downstream system reads a subset of fields and applies its own matching rules — so a single inconsistent field breaks just one of the three revenue paths, not all of them.

Who consumes which fields

• DSPs and storefronts: consume releaseupc, trackisrc, track title, credited artist(s), and track artwork. These form the public catalog and the data used in usage reporting.
• SoundExchange and neighboring collecting societies: rely primarily on track_isrc, performer credits, and recording ownership metadata to allocate digital performance royalties for master recordings.
• PROs and mechanical collection agencies: use composition data — composer names, IPI/CAE numbers, publisher names, publisher IPI, writer split percentages, and ISWC when available — to assign publishing shares.

Key identifier roles and a practical tradeoff. ISRC is the operational glue for recording-level payouts; ISWC and IPI matter for composition payouts. Letting CD Baby assign ISRCs is convenient and sufficient for distribution, but if you plan to claim or reconcile across multiple distributors or long-term catalogs, owning your ISRCs avoids split or duplicate recording identities later. That ownership is the tradeoff: convenience now versus cleaner reconciliation later.

Common mismatch that causes lost or delayed money. Embedding featuring or remix credits inside the track title instead of using contributor fields commonly prevents automated matching at PROs and DSPs. DSPs will display the title how you submitted it, but matching systems often strip title variations and match on ISRC and contributor roles — wrong field placement breaks automated attribution.

Concrete example: A duo uploaded a single to CD Baby and accepted an auto-assigned ISRC. Months later they re-released a remastered cut with a different ISRC and the DSP split streams between two recordings. Their SoundExchange registration used the original ISRC, so one recording collected performance royalties while the new ISRC did not. The correct fix required consolidating ISRCs before release or filing a retroactive claim with SoundExchange after coordinating metadata updates in CD Baby and the PROs.

Propagation and limitation to plan for. CD Baby delivers metadata to DSPs and collection agencies via DDEX-style feeds and APIs, but updates do not uniformly retroactively remap past usage. Catalog corrections typically update future reports; recovering historical misallocations often requires separate claims to SoundExchange or manual PRO interventions. Expect different timelines and prepare documentation (original upload CSV, registration screenshots, contracts) before submitting claims.

For implementation details, see the CD Baby delivery guidelines and the DDEX specification: CD Baby metadata and delivery guidelines and DDEX.

2. Essential identifiers and contributor fields to always include

Must-have identifiers first. Always supply a releaseupc and a trackisrc for every release and track you control — these two are the primary keys downstream systems use to tie plays to payments. Submit ISWC and IPI numbers where available; omissions will routinely create unallocated publishing income that requires manual claims to recover.

Primary identifiers and what they actually protect

• UPC / GTIN (release_upc) — identifies the release package and groups revenue in statements; use a unique UPC per release variant (digital single, album, remaster).
• ISRC (track_isrc) — the recording-level identifier used by DSPs, SoundExchange, and mechanical reporting; verify ownership before accepting auto-assigned codes.
• ISWC — composition identifier that speeds PRO matching when the work is registered; get or request one from your PRO as early as possible.
• IPI / CAE numbers — essential for both writers and publishers; mismatched or missing IPI is the top cause of writer shares being left unallocated.
• Writer splits and publisher shares — explicit percentages that sum to 100; ambiguous or omitted splits force manual intervention at PROs.

Contributor fields and formatting rules that avoid downstream breaks

Credit fields, not titles. Put featured artists, remixers, and producers into their contributor roles rather than stuffing them into the track title. Use consistent artist name variants across releases and match the display name to your PRO registration or canonical database entry such as MusicBrainz to reduce identity collisions.

PRO affiliation must align. If a songwriter is registered to ASCAP, BMI, PRS, etc., make sure the PRO affiliation and IPI submitted to CD Baby mirror that registration. When the registry and upload differ, PROs do not automatically reconcile and those writer shares can sit unpaid until a claim is filed.

Trade-off to accept up front. Letting CD Baby assign ISRCs and skipping ISWC registration is faster, but it creates extra work later if you need consolidated reporting across distributors or want to combine tracking for remasters and reissues. Owning your codes is a small operational cost that saves a disproportionate amount of reconciliation time.

Concrete example: A songwriter uploaded three tracks under a stage name but registered with their PRO under a legal name tied to an IPI number. Because the upload used the stage name with no IPI, the PRO could not match the compositions and held publishing payments in suspense. The fix required updating CD Baby metadata, adding the IPI, re-registering the works with the PRO, and submitting a retrospective claim; the full recovery process took several weeks and required documentation of original splits.

• Quick validation checks before upload: confirm ISRC matches ^[A-Z]{2}-[A-Z0-9]{3}-d{2}-d{5}$ or your national format, ensure release_upc is 12 or 13 digits depending on provider, and validate that writer splits numerically total 100.
• Registration step: register works with your PRO and request ISWC where available before or immediately after release; keep registration screenshots or confirmation numbers with your upload records.

Next consideration: after you assemble these identifiers and contributor fields, prepare a single-source CSV that mirrors CD Baby field names and your PRO registrations so updates and claim evidence are immediate when you need them.

3. Mapping CD Baby upload fields to DDEX and society elements

Direct mapping matters. What you type into CD Baby becomes structured elements in DDEX ERN feeds and individual fields at PROs, mechanical societies, and SoundExchange. Treat the upload form as a schema: each CD Baby field must map to a specific DDEX element and to the corresponding society attribute, otherwise automated matching will fail and money will sit in suspense.

Practical field mapping matrix

Trade-off and limitation. DDEX can model complicated ownership (multiple publishers, territory-specific splits, medleys), but many DSPs and societies normalize or ignore nonstandard constructs. If your release has territory splits or a medley, expect that some recipients will flatten the data — you will then need PRO-side registrations and supplemental documentation to preserve accurate shares.

• Validation step: enforce presence of trackisrc, composeripi for each writer, and writersplitpercent totaling 100 before upload.
• Canonical names: match artist and publisher names to MusicBrainz or your PRO registration to reduce identity collisions; use consistent capitalization and punctuation.
• Backup evidence: attach or keep a split sheet and PRO registration confirmations; downstream claims will require these when mappings fail.

Concrete example: A band uploaded a cover and supplied the original composer names but left out the ISWC and publisher IPI. DSPs listed the track fine, but the mechanical society treated the work as unregistered and held back mechanicals. The fix required registering the work with the society to obtain an ISWC, updating the CD Baby upload with that ISWC and publisher IPI, and then filing a retroactive claim with the mechanical society.

Next consideration: automate a preupload validator that checks these mappings against DDEX ERN rules and your PRO registrations so you catch mismatches before distribution.

4. Preupload validation checklist with examples and machine readable checks

Straight to it: catch metadata problems before upload with automated gates that enforce identifier format, contributor identity, and numeric integrity. Manual eyeballing misses small deviations that break matching; build a short validation pass that runs on your CSV or master metadata source and reject rows that fail.

Machine-readable checks to run automatically

• ISRC format: accept only 12-character ISRCs without punctuation using the pattern ^[A-Z]{2}[A-Z0-9]{3}d{7}$. Reject lowercase or extra hyphens; normalize before you attempt to register or upload.
• UPC basic gate: require d{12,13} and verify the check digit for 12-digit UPC-A releases; flag any non-numeric values. If you use EAN-13, record the exact format in your release variant column.
• Writer splits sum: enforce =ROUND(SUM(writersplitrange),2)=100 in spreadsheets or equivalent numeric equality within a small epsilon (0.01) in scripts; do not allow empty split cells.
• Composer identity cross-check: require either a valid IPI number or a PRO-lookup confirmation URL for each credited writer. If no IPI, block upload and surface a manual review item.
• Artist name canonicalization: compare credited artist string to your canonical artist ID list (MusicBrainz ID or your internal key); mark mismatches and show the suggested canonical value.

Practical insight: automated checks should be strict on keys (ISRC, UPC, IPI) and permissive on display text (titles, liner notes). The trade-off is friction at upload versus fewer downstream exceptions; pushback from collaborators is normal, but it beats chasing suspended royalties.

Concrete example: a distributor CSV contained an ISRC with lowercase letters and a stray space. The pipeline normalized titles but not ISRCs, so the track created a second recording identity downstream. Running the ^[A-Z]{2}[A-Z0-9]{3}d{7}$ check would have caught it and forced correction before delivery, avoiding a retroactive SoundExchange claim.

Practical checks you can script or run in OpenRefine

• Trim and uppercase: apply a transform to remove leading/trailing whitespace and convert identifier columns to uppercase before validation.
• Split validation pipeline: stage 1 = syntactic checks (regex, numeric ranges), stage 2 = resolution checks (PRO API or MusicBrainz lookup), stage 3 = business rules (splits sum, publisher present).
• Evidence column: add proofurl and proregistration_id columns in your CSV so any flagged row immediately includes the registration evidence reviewers need.

Do not rely on a human-only review for ISRC and IPI consistency; those are the keys that programmatic reports use to match plays to payments.

Next step: tie these checks into your release checklist and store the validated CSV with timestamps and reviewer initials. When you need to file retro claims or correct metadata in CD Baby, that validated record is the fastest path to proof and recovery.

5. Tools and automation to detect and prevent metadata errors

Start with a gate, not a hope. Automate a preflight that rejects malformed identifiers, inconsistent contributor identities, and incomplete split data before anything reaches CD Baby. A short, repeatable pipeline saves far more time than retroactive claims.

Practical automation pipeline

1. Source of truth: keep one canonical CSV or a small Git repo with one JSON/CSV row per track and columns named to match CD Baby fields (releaseupc, trackisrc, composeripi, writersplit_percent).
2. Syntactic validation: run regex and checksum checks (uppercase normalization, numeric UPC length, ISRC format) and block rows that fail so human review is required before override.
3. Resolution checks: call MusicBrainz or an internal artist registry to verify canonical artist IDs and flag name mismatches; validate IPI against PRO APIs where available.
4. DDEX staging: transform your canonical record into a DDEX ERN and run it through a validator to catch structural problems early; store the ERN diff for audit.
5. Delivery policy: if an automated push to CD Baby is possible for your workflow, require a green report from both syntactic and resolution stages; otherwise export the validated CSV and attach the validation report to the upload ticket.

Practical limitation. Automation reliably catches format and identity mismatches, but it cannot prove legal ownership, territorial publishing splits, or resolve disputed credits. Those require human decisions and documentary evidence; plan for a manual review queue with escalation rules.

Integrations and tools to use

Use a combination of reconciliation and cleanup tools rather than a single silver bullet: OpenRefine for bulk normalization, MusicBrainz lookup for canonical IDs, the DDEX ERN validator for structural checks, IFPI ISRC guidance for code ownership checks, and SoundExchange guidance for performance metadata. Where possible record proof links (PRO registration URLs, ISWC receipts) into your metadata rows.

Concrete example: A small label built a pipeline that normalizes CSVs with OpenRefine, runs a MusicBrainz reconciliation step, converts the cleaned rows into an ERN and validates it with a DDEX validator, then produces a per-release PDF report saved in the release folder. When a DSP later reported an unmatched recording, the team used the PDF to show the exact pre-delivery values and resolved the split within three weeks instead of months.

• Monitoring signals to automate post-release: percentage of streams with no publisher match, sudden appearance of duplicate ISRCs for the same title, mismatch in expected vs actual ISRC count on DSP catalogs, and unexpected delta in publisher revenue by release.
• Practical alerting: wire these checks into a simple dashboard or Slack webhook so a human gets a prioritized triage item instead of a blind inbox full of errors.

6. Reconciliation and monitoring after distribution

Start with a canonical ledger. Keep one definitive spreadsheet or database row per track (matching CD Baby field names) that records releaseupc, trackisrc, credited artists, composeripi, publisheripi, writer_splits, and proof links to PRO registrations. That single source is the only thing you should trust when reconciling statements; everything else is transient.

Operational reconciliation steps

Follow a repeatable cycle: ingest statement files, match usage by identifier, surface mismatches, triage by error type, then execute correction or claim actions. Automate the first three steps so humans focus on exceptions, not routine row-matching.

1. Ingest: import DSP usage reports and CD Baby payout/statement CSVs into your ledger and normalize fields (uppercase, trim spaces).
2. Match: join DSP rows to your ledger on trackisrc and releaseupc. Count unmatched plays and list distinct unknown ISRCs.
3. Triage: classify mismatches into categories — missing ISRC, duplicate ISRC, wrong contributor data, or publisher/I PI mismatch — and assign owner and priority.
4. Resolve: for catalog errors push corrected metadata to CD Baby and, where plays already occurred, prepare retro claims for SoundExchange or your mechanical society with the canonical evidence.
5. Verify: after submission, track claim status and re-run the match weekly until the delta closes or the claim is denied.

Practical trade-off: automating weekly reconciliation catches drift early but costs developer time; doing it quarterly reduces overhead but multiplies retroactive claims and recovery time. Pick the cadence that matches your catalog size and revenue sensitivity.

Concrete example: A small indie label ran a weekly ingest and found 2.3% of streams on a new release did not map to any track_isrc. Triage showed a single row where an ISRC had a trailing character in the CD Baby upload. The team corrected the CD Baby record, submitted a SoundExchange retro claim with the original validated CSV and PRO receipts, and recovered most of the withheld performance royalties within two payout cycles.

Monitor three signals continuously: unmatched ISRC count, unexpected duplicate ISRCs for the same title, and publisher match rate (percent of streams with registered publisher IPIs).

What often gets misunderstood: many assume updating metadata in CD Baby will automatically remap historical plays. In practice, DSP catalogs update future metadata but historic statements rarely reassign past usage without a formal claim. Treat metadata updates and retro claims as two separate tracks.

Next consideration: link this pipeline to your PRO registration logs and keep evidence attached to each track row. When you file claims, agents will ask for the exact pre-delivery CSV and registration confirmations—having them in one place closes claims faster.

7. Correcting metadata and recovering lost royalties

Direct fact: fixing metadata and getting money back are two related but distinct workflows — one updates future delivery, the other pursues retroactive payments. Treat them separately and run them in parallel: correct the live record first, assemble the audit evidence second, and submit claims only after you have canonical proof.

Step-by-step correction workflow

1. Update the CD Baby record: correct fields that are wrong (for example track_isrc, credited artist role fields, composer IPI, publisher IPI, ISWC). Use the CD Baby dashboard or support channel and keep the ticket number. If the platform prevents the change (some ISRC edits are restricted), document that restriction in your evidence package.
2. Synchronize PRO registrations: immediately update or add the work on your PRO account so composer names, IPI, ISWC, and writer splits match the corrected CD Baby metadata. Save confirmation screenshots or registration IDs.
3. Prepare an evidence packet: assemble the validated preupload CSV, original upload receipt, PRO registration confirmations, split sheet, masters ownership proof (ISRC ownership or assignment), and any agreements showing writer percentages.
4. File retro claims with collecting societies: submit to SoundExchange for digital performance, and to the relevant mechanical societies/PROs for composition/mechanical income. Attach the evidence packet and reference the CD Baby support ticket where you corrected the public record.
5. Track and iterate: log claim IDs, expected review windows, and follow-up cadence. If a claim is rejected, request the specific reason and rectify the missing piece of evidence rather than re-filing bluntly.

Practical limitation: some DSPs and societies will not retroactively remap past usages simply because you edited the distributor record. Changing a recording's ISRC after plays have already been reported usually creates a new recording identity downstream. That means a metadata correction alone rarely recovers historical splits without formal claims to collecting agencies.

Evidence package and claim priorities

• Minimum evidence to include: validated pre-delivery CSV, CD Baby upload receipt or ticket, PRO registration confirmation (ID or screenshot), split sheet signed or timestamped, and proof of ISRC ownership (IFPI/issuing agency or internal assignment log).
• Priority decision rule: weigh the expected recovery against administrative cost. For small catalogs, set a dollar/time threshold (for example: pursue claims when expected net recovery exceeds three times projected admin cost). Escalate complex multi-territory or high-value claims to a specialist.
• When not to reissue: do not attempt to fix historical mapping by reissuing the same recording under a new ISRC and expecting systems to merge plays. Reissue only for new releases — pursue claims for past plays.

Concrete example: A songwriter was omitted from the composer list on a single. The team updated the CD Baby track to add the writer and corrected the writer split, then registered the corrected work with the PRO and saved the registration ID. They filed a SoundExchange retro claim attaching the original validated CSV, the CD Baby support ticket, and the PRO confirmation. The society requested an additional signed split sheet; after supplying it, most withheld performance royalties were released within two payout cycles.

Judgment and trade-off: recovery is possible but seldom instant or total. Many creators underestimate the administrative friction — expect requests for supplemental proof and multistep review. If your catalog is large or you foresee recurring corrections, invest in a repeatable claims pack template and a small workflow to assemble evidence quickly; that reduces friction far more than occasional manual attempts.

Key rule: never rely on a metadata edit alone to recover past revenue — always pair the edit with a documented claim to the appropriate collecting body and a clear evidence package.

For CD Baby-specific guidance on edits and support channels, see the distributor metadata guidelines at CD Baby metadata and delivery guidelines. For performance claim procedures consult SoundExchange and your mechanical society documentation when filing retroactive claims.

8. Appendix: Quick reference artifacts and templates

Practical rule: keep a single release folder with versioned artifacts that match the exact CD Baby field names. When you need to file a claim or answer a support ticket, the fastest path to recovery is a small, well-organized evidence bundle saved at the time of upload.

Core artifacts to store per release

• Canonical CSV: filename pattern RELEASEUPCartistrelease-datemaster.csv. Columns to include: releaseupc, trackisrc, tracktitle, recordingartist, creditedartists, composernames, composeripi, publishername, publisheripi, iswc, writersplitpercent, proofurl.
• Signed split sheet: a single-page PDF with contributor names, IPI numbers, exact split percentages, date, and signatures or timestamped digital consent.
• Evidence packet: compact ZIP containing the canonical CSV, CD Baby upload receipt or screenshot, PRO registration confirmations, ISRC ownership proof, and any publishing agreements.
• Validator report: an automated output (CSV or PDF) showing which rows passed syntactic and resolution checks and who approved the release.
• Triage log: a short plain-text file listing any known issues at upload (for example legacy artist variants or territory exceptions) and the support ticket numbers associated with follow-up.

Practical insight: include proof_url entries that point to immutable records - PRO confirmation pages, ISRC agency receipts, or DDEX ERN snapshots. Those links speed review, but store them on a secure internal server rather than exposing personal identifiers publicly.

Validation snippets and naming conventions

Filename convention: use UPCAupc>. for every exported artifact. Consistent names make automated scripts and claims forms deterministic and reduce human error during evidence assembly.

• ISWC placeholder validation: require any provided ISWC to match the shorter canonical pattern T-d{9}-d or include the PRO registration ID if no ISWC yet.
• Split sheet rule: splits must be stored as decimals with two digits (for example 33.33) and the CSV must include a checksum column split_sum that equals 100.00.

Trade-off to consider: more metadata in the artifact set reduces time to recover money but increases privacy and admin overhead. For small teams, restrict public-facing exports and keep the full evidence bundle behind passworded storage or a rights management system.

Concrete use case: a boutique label used this template set to resolve a disputed writer credit. They supplied the canonical CSV, the signed split sheet, and the DDEX ERN snapshot to SoundExchange and the PRO. Because the submission matched the stored upload evidence exactly, the society processed the retro claim in weeks rather than months.

Next step: add these templates to your release checklist and automate a single command that packages the release folder into a claim-ready ZIP.