DistroKid Metadata Requirements: Preparing Your Catalog for Accurate Rights and Payments

Getting metadata right separates paid royalties from errors and lost revenue. This guide lays out DistroKid metadata requirements and the exact fields, identifiers, and formatting that determine how recordings and works are matched and paid across stores, PROs, SoundExchange, and The MLC. You will get field-level rules, ISRC and UPC handling, songwriter and publisher split templates, a pre-release validation checklist, and step-by-step corrective workflows for covers, remixes, and sampled material.

1. How DistroKid fits into the rights and payments ecosystem

Direct point: DistroKid functions as a distribution conduit, not a publishing administrator. It moves recording assets and recording-level metadata to stores and streaming platforms, and that transmission determines how recordings are discovered, matched, and paid at the storefront level.

What DistroKid actually delivers downstream

• Recording identifiers and product identifiers: ISRCs for each master and UPC for the release product - these are the primary keys used by stores and collection systems to match recordings.
• Display metadata: artist display name, track title, version text, explicit flag and cover art which affect how a recording surfaces and who gets credited on platform reports.
• Contributor data: DistroKid can carry artist and writer fields to stores and via supply chains using DDEX mappings, but the level of detail consumed by each downstream system varies.
• Rights and territory flags: availability windows and territorial restrictions that determine where sales and streams are recognized.

Practical limitation: Supplying songwriter and publisher names to DistroKid helps attribution but does not equal registration with PROs or mechanical collection agencies. Payment flows for publishing require registration and matching at collection points like The MLC and PROs, which will ignore distributor-only metadata if it lacks proper identifiers such as IPI or publisher IDs.

Tradeoff to accept: Letting DistroKid auto-assign ISRCs is fast but increases risk of fragmented recording records if you later need to consolidate masters or prove prior uses. Assign your own ISRCs when you have an existing catalog or complex licensing to preserve continuity across releases.

Concrete Example: A four writer band uploads a single to DistroKid. They preserve preexisting ISRCs, populate each writer with legal name and IPI numbers, and submit the release two weeks before the release date. They also register the composition with each writer's PRO and with The MLC before release. Result - storefronts show correct credits and mechanical collection agents can match and begin claiming; missing any of those steps typically produces delayed or misallocated publishing payments.

Judgment: Many teams assume a distributor is a one stop solution for royalties. That belief fails in practice. Distribution guarantees delivery of recording metadata to platforms, but correct, timely payment for publishing hinges on separate registration and consistent identifiers across systems. Treat DistroKid as the pipeline, not the final arbiter of publishing rights.

2. Required and strongly recommended metadata fields and their payment implications

Direct point: Meeting the core DistroKid metadata requirements is the practical minimum for stores to correctly identify your recording and for collection systems to start matching money to the right account. Missing or inconsistent fields break matching at the storefront level and create a cascade of manual work to recover royalties downstream.

Required release-level fields: UPC, release title, release type, and release date.** The UPC is the product key used by retailers to aggregate sales and report units. If the UPC is wrong or duplicated you will split or lose revenue reporting. Release date and territories control market entitlement windows and feed downstream reports that affect time-limited licensing and promo payments.

Required track-level fields: track title, ISRC, primary artist name, and audio file that meets format rules.** ISRC is the recording identifier used by platforms and SoundExchange to link plays to a master. If you let DistroKid auto-assign an ISRC for a previously released master you risk fragmentation. Use WAV 44.1 kHz 16-bit or higher to avoid ingest rejection that delays reporting.

Strongly recommended contributor and rights fields: full songwriter legal names, IPI/CAE numbers, PRO affiliation, publisher names and publisher IPIs, exact percentage splits, and rights owner or label account.** DistroKid will carry contributor data into supply chains, but publishing payments depend on matching those identifiers at PROs and The MLC, so accurate IPI numbers and consistent publisher names are essential for payments to reach the correct collecting entity.

Field-to-payment implications at a glance

Practical trade-off: Letting DistroKid auto-assign ISRCs and UPCs is fast for single releases, but if you operate catalogs across retailers, labels, or sample clearances you will save far more time by assigning and tracking ISRC and UPC externally. The operational cost of later consolidating fragmented masters often exceeds the time saved at upload.

Concrete example: A producer releases a collaborative single with three writers. They supply a preexisting ISRC for the master, enter each writer with legal name, IPI, PRO, and exact percent splits in DistroKid, and register the composition with each writer's PRO and with The MLC before the release date. As a result, streaming platforms display correct credits and mechanical claims are matched quickly; if any IPI had been missing the mechanical claims would have required manual intervention to recover payments.

Key consideration: providing songwriter and publisher names in DistroKid helps attribution but does not replace registering those works with PROs or mechanical administrators. Use DistroKid for delivery, not for registration.

3. ISRC, UPC, ISWC and identifier handling best practices

Direct action: Treat identifiers as authoritative keys in your catalog. Mistakes with ISRC, UPC or work identifiers create long lived mismatches that require manual reconciliation across stores, PROs and mechanical agents.

ISRC: rules, limits, and what to do when masters change

Core rule: Assign one ISRC per unique audio master. If you create a new master file that changes timing, mix, or sonic character you must use a new ISRC.

Operational limitation: Correcting an ISRC after release often generates a new storefront record or requires support from each store. That can break playlists, reset play counts, and complicate royalty histories. Plan identifier changes before submitting to DistroKid rather than relying on post-release edits.

UPC and product lifecycle considerations

Principle: One UPC per distinct product. Repackages, deluxe editions, or bundles need separate UPCs; do not reuse a UPC to represent different tracklists or versions.

Tradeoff: Centralized UPC management costs time up front but prevents revenue fragmentation and simplifies retailer reconciliations. If you let a distributor mint UPCs randomly you lose control over release lineage and version history.

ISWC and composition matching

Why ISWC matters: ISWC links a composition across systems and accelerates publisher and PRO matching. Obtain or record ISWCs via PRO registration and include them in your publishing admin records even if some storefronts do not display them.

Practical caveat: Not every collection system uses ISWC at ingestion time, but when present it reduces ambiguity for works with common titles or multiple versions. Do not rely on ISWC alone; always pair it with legal names and IPI identifiers.

Concrete Example: A label remasters a back catalog track for an anniversary release. Because the remaster changes the master, the team assigns a new ISRC, reserves a new UPC for the anniversary product, and retains the original ISWC since the composition did not change. This preserved publisher matching while keeping streaming histories clean for each master.

1. Immediate steps for correct identifier handling: Map each master to a single ISRC in your source of truth and never let multiple ISRCs claim the same file.
2. UPC stewardship: Reserve UPCs in an external ledger and document which tracklist each UPC represents before uploading to DistroKid.
3. Composition linkage: Register compositions with PROs to obtain or confirm ISWC values and record IPI numbers for every writer and publisher.
4. Verification: Cross-check identifiers against public databases such as IFPI and MusicBrainz prior to submission.

Judgment: Many teams underestimate the downstream cost of inconsistent identifiers. The short term convenience of letting a distributor mint everything is tempting, but in practice it multiplies reconciliation work and reduces your leverage when negotiating splits or clearing samples. If you run multiple releases or work with outside licensors, assign and track identifiers centrally.

Next consideration: Before the next upload to DistroKid, confirm identifier consistency between your catalog, PRO registrations and any third party publishers. That single check prevents the most common causes of delayed or lost publishing payments.

4. Songwriter and publisher metadata, splits, and PRO affiliation

Essential reality: DistroKid accepts detailed songwriter and publisher fields, but those fields are only useful for payments when they match authoritative identifiers that PROs and mechanical administrators actually use. Entering names without IPIs, or providing inconsistent publisher details, creates noise for downstream matching and delays real money.

What you must capture for each writer and publisher

• Legal name — use the name registered at the writer's PRO, not a stage name or nickname.
• IPI/CAE number — this is the single most useful identifier for PRO matching; verify digits before upload.
• PRO affiliation — e.g., BMI, ASCAP, PRS; leave blank only if the writer truly has no affiliation (rare).
• Publisher name and publisher IPI — if a writer assigned rights to a publisher, include that publisher's IPI; otherwise the publisher side of mechanicals stalls.
• Exact percentage split — must sum to 100; use two decimal places if you need precision (e.g., 33.33%).

Practical limitation: DistroKid can carry split percentages into the supply chain, but most PROs and The MLC require separate registration of the exact same split and identifiers to effect payment. In practice that means you should treat the DistroKid entry as a delivery artifact, not as registration or proof of ownership.

Tradeoff to accept: If you need fast releases with collaborators who are difficult to reach, using DistroKid's split tools to pay distribution money can be a practical short-term fix. For durable publishing income, however, expect to register the composition with each writer's PRO and with The MLC (for US mechanicals). Paying now vs. capturing long-term publishing requires separate operational work and sometimes a publishing administrator.

Concrete example: Three writers co-write a song. In your source catalog you record: Jane Smith — IPI 987654321 — ASCAP — 40%; Marco Ruiz — IPI 123456789 — BMI — 35%; Publisher: Blue Oak Music — IPI 567890123 — 25% publisher share assigned. You enter the exact same lines into DistroKid, then immediately register the same split and IPI values on ASCAP and BMI portals and submit the composition to The MLC. This alignment prevents the common mismatch where streaming services credit a writer but the PRO cannot match the claim because IPIs differ.

Common operational mistakes I see: people upload writer credits with stage names or omit publisher IPIs; others round splits so they no longer total 100. These errors are simple but costly — they trigger manual interventions at PROs and often produce delayed or partially paid royalties. Verifying IPIs against your PRO accounts before submitting to DistroKid removes most downstream friction.

Next consideration: When collaborators live in different territories with multiple PROs, prepare written split agreements and register the composition in every jurisdiction or use a publishing administrator that can do cross-border registrations. Without that step, global collection will remain piecemeal even if DistroKid displays the credits correctly.

5. Special cases and required licensing workflows

Direct point: Covers, remixes, and samples are handled very differently from original recordings and require distinct licensing steps before you upload to DistroKid. Treat each special case as a mini project with its own paperwork, metadata checklist, and acceptance criteria.

Covers

What to do: For US mechanicals use a compulsory mechanical license route such as Songfile when available, or obtain a license from the publisher. Outside the US, you generally need publisher permission because compulsory rules vary by territory. Enter the original composer names, IPI numbers, and publisher names into your DistroKid metadata and keep the license receipt in your release dossier.

Practical limitation: Even with a mechanical license, some platforms require evidence of clearance on demand. Metadata alone rarely satisfies downstream copyright teams. Maintain a retrievable copy of the license and record the license ID or contract number in your internal catalog and in the DistroKid notes field if available.

Remixes and alternate masters

What to do: Treat a remix that creates a new master as an independent recording. Assign a new ISRC, set a new UPC if the product changes, and capture explicit contributor roles in DistroKid metadata such as remixer, producer, and featuring artists. Secure a written agreement with the original rights owner that spells out split percentages for both master and publishing.

1. Step 1: Get written permission from the master owner to create and distribute the remix, and record the contract identifier in your catalog.
2. Step 2: Negotiate and record split percentages for the remix contributors and the original writers; enter these splits into DistroKid and into PRO/MLC registrations.
3. Step 3: Assign a new ISRC for the remix master and update your UPC strategy if releasing as a separate product.

Tradeoff: Using DistroKid tools to publish a remix quickly gets music live, but rushing without a signed master license and clear split allocations often leads to later disputes that are harder to resolve and to recover past royalties from.

Samples and clearances

What to do: Samples require two clearances: master use clearance from the recording owner, and publishing clearance from the song owner. Collect both agreements before upload. In metadata, include licensor names, role tags, and an internal reference to the clearance files so rights teams can match quickly if a claim arises.

Real-world use case: A producer uses a one bar sample from a 1990s track. The team negotiates a master license with the label and a publishing split with the original writers. They assign a new ISRC for the new master, enter the original writers with their IPI numbers and newly negotiated percentage splits into DistroKid, and archive both signed licenses in their release folder. Because both clearances were documented and the metadata mirrored the split sheet, the claim was settled without stores removing the release.

Judgment: Many teams assume visible credits in stores are sufficient to avoid takedowns. They are not. Accurate metadata reduces friction, but only the license documents and the timing of registration with PROs and mechanical agencies will prevent blocked releases and lost payments.

Next consideration: For cross-border collaborations verify PRO registration rules early. If writers use different PROs, register the same splits in each PRO and with The MLC for US mechanical collection to avoid fragmented payouts.

6. Metadata validation, pre-release checklist, and testing

No surprises rule: run a validation and testing pass that treats DistroKid metadata requirements as a hard gate, not a best practice. Errors you tolerate before release become manual tickets, lost streaming history, and delayed publishing payouts after release.

Pre-release timeline and gating

Schedule: lock identifiers and metadata at least 14 days before release if you control ISRC/UPC, and 21 to 28 days when you must coordinate PRO registrations, mechanical claims, or cross-label clearances. Why: stores can take variable time to ingest, and PRO/MLC matching often requires propagation that is outside DistroKid.

• Metadata freeze (T-28 to T-21): finalize ISRCs, UPC, canonical artist string, and agreemented split sheet stored in your catalog.
• Upload window (T-21 to T-14): perform DistroKid upload with future release date; use internal staging fields or private territory to let platforms ingest without public promotion.
• Verification pass (T-14 to T-7): confirm credits in platform portals (Spotify for Artists, Apple Music for Artists), check SoundExchange/MLC registration status, and run automated schema checks.
• Final signoff (T-7 to T-0): archive license files and ensure no metadata edits are pending; any identifier changes after this point should be treated as a new release.

Validation checks to automate: do not rely on eyeballing CSVs. Run a script that asserts exact matches for ISRC format (12 characters), UPC length, IPI number structure, sum of writer percentages equals 100. Also verify artist name normalization against your PRO entries and canonical streaming artist IDs where available.

Testing strategies: stage a limited-territory upload or a private release date so you can inspect how stores display artist credits, track titles, version text, and cover art. Use a DDEX ERN validator to validate your export and cross-check recordings against MusicBrainz or other public registries to spot duplicate ISRCs before the release goes live. See DDEX and DistroKid support for format references.

Practical tradeoff: running a staging upload costs time and sometimes ties up a UPC slot, but it prevents the far more expensive work of reconciling split payments and chasing down stores after the release. For catalogs with many collaborators, staging pays off almost immediately.

Concrete example: An independent label uploaded an EP to DistroKid with a future release date two weeks out. During the verification pass they discovered one co-writer had no IPI in the CSV; the MLC would not match that share. The team added the IPI, re-exported the DDEX-like payload, and confirmed the composition was registered with The MLC before the release date. That prevented a months-long payback problem for that writer.

Next consideration: instrument the validation pass into your release pipeline (CSV/JSON schema checks, ERN validation, and a staging upload). That discipline converts DistroKid metadata requirements from a checklist into an operational control that saves time and preserves revenue.

7. Correcting metadata after release and dispute remediation

Direct action: When metadata is wrong on a live release, updating the DistroKid record is necessary but rarely sufficient. Changes you make in DistroKid will push downstream, but stores, PROs, SoundExchange and mechanical administrators use their own matching logic and timelines — you must coordinate fixes across every affected system.

Why a DistroKid edit alone often does not recover lost payments

Key limitation: Many collectors match on identifiers and registered composition splits, not on the distributor display. If a writer lacked an IPI when the recording first streamed, simply adding the IPI in DistroKid later does not retroactively make a PRO or The MLC reassign past receipts unless you trigger their dispute or claim process. Changing a ISRC after release can also create a new storefront record and fragment play history — sometimes worse than the original metadata error.

Practical remediation workflow

1. Stabilize the canonical record: Lock the corrected metadata in your catalog of record and push the same values into DistroKid so stores ingest a single authoritative version. Do this before you open disputes.
2. Collect evidence: Gather signed split sheets, registration receipts (PRO and The MLC), original ISRC assignment logs, and any license agreements. Screenshots of the mistaken storefront metadata plus server timestamps are useful.
3. Register and re-register: Ensure the composition is registered with each writer's PRO and with The MLC if US mechanicals apply. Include exact percent splits and IPIs in those registrations.
4. Open targeted disputes: File tickets with DistroKid support and with affected collectors (SoundExchange, PROs, The MLC). Attach the same evidence package to each claim and reference the DistroKid release URL and ISRC or UPC where relevant: DistroKid Help.
5. Decide on identifier changes: If the fix requires issuing a new ISRC (for a corrected master), weigh the tradeoff: reissuing preserves clean metadata going forward but may split historical streams and playlists; leaving the old ISRC and adjusting registrations may be preferable when historical plays are material.

Concrete Example: A songwriter was omitted from writer credits and therefore missed MLC mechanicals for three months. The team updated DistroKid, registered the composition with correct splits at the PRO and The MLC, then submitted identical evidence to The MLC and to DistroKid support. The MLC processed a retrospective claim after validating the split sheet and the registration receipts; recovery took three reporting cycles. The process worked because the team had preexisting signed split sheets and consistent IPIs across systems.

Judgment: Fixing metadata is not a one-click recovery. In practice, you will only recover past royalties when: (a) identifiers in all systems match, (b) you provide authoritative proof, and (c) you engage the correct collector. Time matters — the longer you wait, the harder the reconciliation and the lower the recovery rate.

Next consideration: Choose your remediation path based on materiality. For high-value catalog items, accept short-term disruption and reissue clean masters with new ISRCs if necessary. For long tails, prioritize registration fixes and evidence-backed claims to collectors rather than fragmenting historical play data.

8. Practical templates and appendix

Start here: keep a small, machine-readable set of templates that live next to your contracts. Treat these artifacts as operational controls - they stop avoidable mismatches when you upload to DistroKid and when you register with PROs or The MLC.

One-page metadata submission checklist (copy-paste)

What belongs on one line per track: use this minimal set to feed DistroKid and to validate against your catalog. Columns should be exact and machine-checked: UPC, ISRC, Track Title, Artist Display Name, Version Text, ISWC (if available), Primary Artist Spotify ID (optional), Explicit Flag, Audio File Path, Cover Art Path, Release Date, Territories.

Sample split sheet template (operational)

Use this row format in your publishing ledger and attach a signed PDF to the release folder. Required fields: Legal name, IPI/CAE, PRO, Publisher name, Publisher IPI (if applicable), Share percentage, Signed date, Contact email.

CSV and JSON ingestion recommendations

Prefer a DDEX-aligned JSON payload for automated pipelines, and keep a CSV fallback for manual reviews. JSON lets you preserve nested contributor objects (role, IPI, PRO, publisher object) which maps cleanly to ERN. CSVs are fine for humans, but they force denormalization that invites manual errors during merges.

Practical tradeoff: building a DDEX-capable export requires engineering time up front, but it eliminates repeated manual fixes and speeds dispute resolution. For small catalogs the CSV route is acceptable; for scale, invest in JSON exports aligned to Contributor objects and Work identifiers.

Concrete example: a distributor ingestion pipeline exported a JSON file where each track included isrc, title, and an array contributors with objects for each writer containing legalName, ipi, pro, and share. That export allowed automated registration scripts to push identical data to PRO portals and to DistroKid with zero manual retyping. When a late correction was needed, only one authoritative record required editing and re-deploying.

Appendix links: for identifier rules and registration, see ISRC and UPC guide, The MLC, and DistroKid support at support.distrokid.com.

Next consideration: assign a named owner for these templates and enforce a metadata freeze before upload. Ownership prevents the typical last-minute edits that create identifier drift and long term payment headaches.