DDEX Explained: The Complete Guide to Digital Music Delivery in 2026
Updated October 2026
When an artist uploads a release to a music distributor, the process can look deceptively simple.
Upload the audio. Add artwork. Enter metadata. Select stores. Submit.
Behind that interface, however, the music industry needs structured ways for record companies, distributors, digital service providers, rights organizations and other businesses to exchange enormous amounts of information accurately.
That is where DDEX comes in.
DDEX standards help organizations exchange information about releases, recordings, rights, commercial availability, sales, usage and other parts of the digital music supply chain.
If you’re building a distributor, record-label platform or music technology company, understanding DDEX helps you understand what actually happens beneath the dashboard.
This guide explains the fundamentals without assuming you are already a DDEX engineer.
What is DDEX?
DDEX stands for Digital Data Exchange.
It develops standards for exchanging data across the digital music industry.
Rather than every company inventing completely different ways to describe a recording, release, deal or usage report, DDEX provides standardized structures and terminology that companies can implement.
DDEX currently maintains standards covering areas including:
- release delivery;
- sales and usage reporting;
- claims;
- recording information;
- musical works and rights;
- party information;
- catalog transfers;
- and enriched metadata.
DDEX is therefore not simply “a file format.”
It is an ecosystem of standards designed around different music-industry business processes.
Why does the music industry need DDEX?
Imagine a distributor sending releases to multiple services.
Without standardization, the distributor might need completely different data models for every recipient:
DISTRIBUTOR
├── Custom Format A → DSP A
├── Custom Format B → DSP B
├── Custom Format C → DSP C
├── Custom Format D → DSP D
└── Custom Format E → DSP ENow multiply that across thousands of labels, distributors, publishers, DSPs and rights organizations.
The complexity becomes enormous.
Standards allow businesses to share a common vocabulary and structure.
Conceptually:
LABEL / DISTRIBUTOR
│
▼
STRUCTURED INDUSTRY DATA
│
▼
DIGITAL SERVICE PROVIDERThe parties may still have bilateral technical and commercial requirements, but standardization reduces unnecessary incompatibility.
The most important DDEX standard for music distributors: ERN
If you operate a record company or music distributor, one of the first DDEX acronyms you are likely to encounter is:
ERN
That stands for:
Electronic Release Notification Message Suite
DDEX describes ERN as the standard that enables record companies and distributors to send DSPs information describing releases and resources they are making available, together with the terms under which those releases can be made available to consumers.
In simplified terms:
RECORD LABEL / DISTRIBUTOR
│
▼
ERN
│
▼
DSPERN can communicate much more than:
Here is an MP3.
A commercial music release needs context.
What information can an ERN delivery describe?
An ERN communication can represent information about the product and the resources contained within it.
Conceptually, that includes:
RELEASE
│
├── Release metadata
│
├── Resources
│ ├── Sound Recording 1
│ ├── Sound Recording 2
│ └── ...
│
├── Artists / Contributors
│
├── Identifiers
│
├── Rights-related information
│
└── Deals
├── When
├── Where
└── How the release may be made availableDDEX specifically describes the release-delivery standard as carrying complete metadata about the release and its resources plus “deals” describing when, where and how the product can be made available.
This is why digital distribution is fundamentally a structured-data problem as much as an audio-delivery problem.
What is the current ERN version?
As of October 2026, DDEX lists:
Electronic Release Notification — Part 1 Baseline XML Schema: Version 4.3.2
as the current baseline version.
The wider ERN suite also contains separate parts covering release profiles and delivery choreographies.
DDEX currently lists, among other components:
- ERN Part 1 — Baseline XML Schema 4.3.2;
- Release Profiles for ERN 4.3.1+ — 2.3.1;
- Cloud-based Storage Choreography — 1.8.1;
- Web Services Exchange Choreography — 1.8.
This distinction matters.
Saying “we support DDEX” is not precise enough for technical procurement.
A serious implementation discussion should identify the relevant standard, version, profile and choreography.
ERN is not just one giant XML template
DDEX describes ERN as having multiple parts.
Part 1 defines the core messages.
Part 2 defines release profiles describing how metadata should be constructed for different release types.
Parts 3 and 4 define choreographies for exchanging ERN information using cloud-based storage or web services.
This means an implementation involves more than generating valid XML.
You also need to understand:
- what business process is occurring;
- which profile applies;
- how assets are transferred;
- how the recipient expects the exchange to work;
- and what bilateral requirements exist.
Releases and resources are different things
This distinction is fundamental.
A Release is the commercial product or package.
A Resource is content contained within or associated with that release.
For a simple album:
ALBUM — RELEASE
│
├── TRACK 1 — SOUND RECORDING
├── TRACK 2 — SOUND RECORDING
├── TRACK 3 — SOUND RECORDING
└── TRACK 4 — SOUND RECORDINGThe album and each sound recording can have different identifiers and metadata.
Confusing those entities causes catalog problems.
ISRC vs UPC/EAN vs other identifiers
Identifiers are critical to music metadata.
ISRC
An ISRC identifies a sound recording or music video recording.
Think:
ISRC
↓
RECORDINGUPC / EAN
UPC and EAN identifiers can identify releases/products.
Think:
UPC / EAN
↓
RELEASEDDEX’s identifier guidance lists ISRC for sound recordings and identifiers including GRid, UPC and EAN for releases. It specifically warns against using an ISRC as the release identifier merely because a single-track release contains one primary recording.
That distinction should also exist in your own database.
Don’t design:
song_code = everythingDesign explicit entities.
Parties also need identifiers
Music metadata isn’t only about tracks.
The ecosystem contains:
- record companies;
- distributors;
- artists;
- composers;
- publishers;
- DSPs;
- rights organizations;
- and other parties.
DDEX supports multiple identifiers depending on the entity and business process. Its guidance includes identifiers such as DPID, ISNI, IPI and IPN for relevant parties.
Not every identifier belongs everywhere.
Good music-data architecture preserves those distinctions.
What is a DPID?
A DDEX Party Identifier, or DPID, identifies organizations participating in DDEX exchanges.
It is particularly relevant when implementing DDEX standards and communicating between business partners.
DDEX’s implementation guidance for DSR, for example, directs implementers to obtain an implementation licence and a DPID before going live.
A DPID should not be confused with an artist identifier, ISRC or UPC.
Each identifies a different kind of entity.
What is a Deal in DDEX?
This is one of the concepts developers coming from ordinary web APIs often underestimate.
Delivering metadata describing a release does not automatically mean:
Make this available everywhere forever.
The recipient also needs to know the commercial conditions governing availability.
Conceptually:
RELEASE
│
▼
DEAL
│
├── Territory
├── Start
├── End
├── Commercial model
└── Permitted useDDEX describes deals as carrying information about when, where and how releases may be made available.
That makes deals fundamental to release delivery.
Territories matter
Suppose a rights holder controls a release in:
Ghana
Nigeria
Kenya
United Kingdombut not in:
United States
CanadaYour system cannot safely reduce that to:
available = trueRights and availability are territorial.
DDEX ERN supports territory-specific release/resource information as well as territorial scope within deals. DDEX recommends keeping the territory information communicated about releases/resources aligned with territories for which relevant deals exist.
This is one reason distribution databases need proper territory models.
Release date is not the only date
Music delivery workflows can involve multiple dates and times.
For example:
Original release date
Pre-order date
Street date
Deal start
Deal end
Visibility date
Takedown dateThese are not interchangeable.
A DSP might need metadata before a release becomes publicly available.
Your internal data model should therefore avoid treating every date as one generic:
release_dateunless the workflow genuinely requires only that concept.
Contributors matter
A recording can involve many people.
Examples:
- primary artist;
- featured artist;
- composer;
- lyricist;
- arranger;
- producer;
- remixer;
- translator;
- and other contributors.
Current ERN profile rules specify that available contributor information for several writer-related roles—including composers, lyricists, arrangers and translators—should be supplied when the sender has that data.
This illustrates why modern distribution forms increasingly request detailed credits.
Those fields are not merely decorative.
They participate in a much larger metadata ecosystem.
What happens to the audio and artwork?
Metadata alone is not the entire delivery.
A DSP also needs relevant binary assets.
Depending on the release and workflow, these may include:
- audio masters;
- cover artwork;
- music videos;
- clips;
- or other resources.
ERN includes choreographies for communicating release information alongside mechanisms for exchanging assets, including cloud-storage and web-service approaches.
A real delivery pipeline therefore has at least two major concerns:
STRUCTURED METADATA
+
BINARY ASSETSBoth must remain correctly associated.
A simplified release-delivery architecture
At a high level:
ARTIST / LABEL
│
▼
DISTRIBUTOR
│
├── Catalog
├── Metadata
├── Rights
├── Assets
└── Deals
│
▼
VALIDATION
│
▼
DELIVERY LAYER
│
▼
DSP
│
▼
CONSUMER AVAILABILITYThe distributor’s dashboard may make this look easy.
The infrastructure underneath is doing the difficult work.
What happens when metadata changes?
Music releases are not immutable.
After delivery, a distributor may need to communicate changes such as:
- corrected metadata;
- contributor changes;
- asset updates;
- territorial changes;
- deal changes;
- or takedowns.
That means your catalog should be treated as a living stateful system rather than a one-time export.
A poor architecture thinks:
upload → finishedA better architecture thinks:
catalog state
↓
delivery state
↓
DSP state
↓
future updatesThat distinction becomes extremely important at scale.
What is a takedown?
A takedown tells a service that content should no longer be commercially available according to the applicable rights/deal instructions.
Reasons might include:
- rights expiration;
- customer request;
- copyright dispute;
- contract termination;
- incorrect delivery;
- or catalog transfer.
Takedowns can also have territorial implications.
DDEX maintains specific ERN implementation guidance for takedowns and territorial takedowns.
Your distribution platform should therefore model takedowns as controlled operations—not simply a database delete button.
Delivery is only half the cycle
Getting music onto DSPs is the outbound side.
Eventually, information needs to come back.
Conceptually:
LABEL / DISTRIBUTOR
│
│ Release delivery
▼
DSP
│
│ Sales / usage reporting
▼
LABEL / DISTRIBUTORThis leads us to another major DDEX standard:
DSR
Digital Sales Reporting Message Suite
What is DSR?
DDEX describes DSR as the standard that allows digital music services/licensees to report sales and usage information about music, music videos and other content to rights owners/licensors.
In simplified terms:
DSP
│
│ Sales / Usage Data
▼
DSR
│
▼
RIGHTS OWNER / DISTRIBUTORThe recipient can use that information as part of downstream processes such as reconciliation and royalty accounting.
ERN and DSR solve different problems
This distinction is extremely useful.
Think:
RELEASE DELIVERY
LABEL ------------------------------> DSP
ERN
SALES / USAGE
LABEL <------------------------------ DSP
DSR
ERN communicates releases and commercial availability.
DSR communicates information about how content was used or sold.
They are different standards serving different directions in the music supply chain.
DSR is no longer an XML reporting standard
This is an important 2026 detail.
Older DDEX DSR implementations included XML variants.
DDEX announced the sunset of those older XML DSR standards, and its current documentation describes DSR as a flat-file reporting standard.
So an article that simply says:
DDEX is XML.
is incomplete.
ERN remains XML-based, while current DSR reporting uses its own flat-file architecture.
Standards evolve.
That is why implementations need version awareness.
DSR has different profiles
Different music businesses generate different reporting requirements.
Current DDEX DSR specifications include profiles for areas such as:
- basic audio;
- user-generated content;
- audiovisual content;
- royalty reporting;
- radio broadcast;
- financial reporting to record companies;
- and other processes.
This means “supporting DSR” should again prompt the question:
Which profile and version?
Precision matters.
From DSR to royalties
Receiving a usage report does not magically produce an artist balance.
A distributor may need to perform additional processing:
DSP REPORT
↓
INGEST
↓
NORMALIZE
↓
MATCH
↓
ISRC / RELEASE
↓
CUSTOMER
↓
CONTRACT
↓
REVENUE SHARE
↓
SPLITS
↓
ADJUSTMENTS / RECOUPMENTS
↓
STATEMENT
↓
BALANCE
↓
PAYOUTThis is why royalty accounting becomes a major infrastructure product in its own right.
DDEX standardizes important data exchanges.
Your business logic still has to turn those exchanges into correct accounting.
What is CDM?
Another standard worth understanding is:
Claim Detail Message Suite — CDM
DDEX describes DSR and CDM as complementary parts of a communication cycle.
DSR communicates sales/usage information from licensee to licensor.
CDM can then communicate claims and invoice-detail information from licensor to licensee and support discrepancy communication back from the licensee.
This demonstrates the broader point:
DDEX is not one “music upload standard.”
It covers multiple stages of industry data exchange.
Other DDEX standards
As your infrastructure becomes more sophisticated, you may encounter additional standards.
Examples currently listed by DDEX include:
MEAD — Media Enrichment and Description.
PIE — Party Identification and Enrichment.
Catalogue Transfer standards.
RIN — Recording Information Notification.
Recording Data and Rights standards.
Musical Work Data and Rights communication standards.
Entity Cluster and other specialized standards.
You do not need to implement everything simply because it exists.
Implement standards based on actual business requirements.
Do you need to be a DDEX member?
Not necessarily.
DDEX states that organizations do not have to become DDEX members merely to implement its standards.
However, implementers need the appropriate DDEX Implementation Licence before implementing/going live according to DDEX’s licensing requirements.
Always consult the current DDEX licensing information before implementation.
Do not assume that publicly accessible documentation means there are no implementation requirements.
Does DDEX automatically give you access to Spotify or Apple Music?
No.
This is a critical misconception.
Implementing an industry standard is not the same as obtaining a commercial relationship with every DSP.
DDEX defines standardized ways of communicating data.
It does not automatically give your company:
- a Spotify distribution agreement;
- an Apple Music distribution agreement;
- delivery credentials;
- commercial approval;
- or guaranteed ingestion by a DSP.
Think of the distinction as:
DDEX
=
HOW DATA CAN BE COMMUNICATED
not
AUTOMATIC DSP ACCESSYou still need the relevant business relationships or an infrastructure provider that has an appropriate delivery arrangement.
Does valid DDEX guarantee DSP acceptance?
No.
A message can be technically valid and the underlying release can still have problems.
For example:
- incorrect rights;
- unacceptable artwork;
- bad metadata;
- invalid dates;
- unsupported content;
- policy violations;
- or recipient-specific requirements.
Think:
SCHEMA VALID
≠
BUSINESS VALID
≠
RIGHTS VALID
≠
DSP ACCEPTEDAll four layers matter.
Why validation is so important
Before distribution, a good platform should validate information at multiple levels.
Technical validation
Is the data structurally correct?
Metadata validation
Are required fields present and correctly formatted?
Business-rule validation
Does the release satisfy the selected destination’s requirements?
Rights validation
Does the customer have the authority to distribute the content?
Operational QC
Does anything require human review?
This is why a professional distribution system needs more than an XML generator.
DDEX vs API: are they competitors?
No.
This is another important misconception.
A developer-friendly REST API and DDEX can exist at different layers of the same architecture.
For example:
YOUR APPLICATION
│
│ REST / JSON
▼
DISTRIBUTION API
│
▼
CATALOG + VALIDATION
│
▼
INDUSTRY DELIVERY LAYER
│
│ Appropriate delivery format/workflow
▼
DSPYour application’s developers may work with simple resources such as:
Artist
Release
Track
Store
Deliverywhile the infrastructure layer handles more specialized industry exchange requirements.
That abstraction can be extremely valuable.
Why API abstraction matters
Imagine forcing every developer building a music app to understand:
- ERN XML;
- release profiles;
- choreography;
- DPID;
- resource references;
- allowed-value sets;
- territory structures;
- deal structures;
- asset transfer;
- recipient-specific requirements;
- acknowledgements;
- and every future standard update.
That creates a huge barrier.
A higher-level API can expose something easier:
{
"title": "Midnight Drive",
"artist_id": "art_123",
"release_date": "2026-11-20",
"territories": ["GH", "NG", "GB"]
}while specialized infrastructure handles deeper transformation and delivery logic.
This is one reason API-based music infrastructure is increasingly important.
But abstraction must not hide important concepts
A simple API should not make the underlying business model incorrect.
For example, an API might expose:
territoriesinstead of making developers construct a DDEX Deal.
That’s useful.
But the system still needs to understand that territories represent rights and commercial availability.
Good abstraction makes complexity manageable.
Bad abstraction simply ignores complexity.
A strong internal data model
If you are building a distributor, your database should model real music entities explicitly.
A simplified structure might look like:
ORGANIZATION
│
├── USERS
│
├── LABELS
│
├── ARTISTS / PARTIES
│
└── CATALOG
│
└── RELEASE
│
├── IDENTIFIERS
├── ARTWORK
├── TERRITORIES
├── DEALS / AVAILABILITY
└── RESOURCES
│
└── SOUND RECORDING
├── ISRC
├── AUDIO ASSET
└── CONTRIBUTORSThen separately:
DISTRIBUTION
│
├── SUBMISSION
├── DESTINATION
├── DELIVERY
├── STATUS
├── ERRORS
└── TAKEDOWNAnd later:
FINANCE
│
├── USAGE
├── REVENUE
├── ROYALTIES
├── SPLITS
├── STATEMENTS
└── PAYOUTSThis is much more scalable than one giant releases table containing everything.
Why versioning matters
Standards change.
DDEX has already sunset older versions of standards, including older ERN versions and XML DSR variants.
Your architecture therefore needs to distinguish:
your canonical internal catalog
from
a specific outbound standard/version
A good design looks like:
CANONICAL CATALOG MODEL
│
├── Transform → Format / Version A
├── Transform → Format / Version B
└── Transform → API / Workflow Cnot:
DATABASE = ONE EXTERNAL XML VERSIONThat gives your infrastructure room to evolve.
What should a distributor store internally?
At minimum, consider maintaining structured records for:
- organizations;
- users;
- artists;
- labels;
- releases;
- recordings;
- identifiers;
- contributors;
- assets;
- rights;
- territories;
- availability;
- DSP selections;
- validations;
- submissions;
- deliveries;
- status changes;
- errors;
- takedowns;
- reports;
- royalties;
- and audit events.
The exact schema depends on your business.
But avoid throwing away information simply because your current UI doesn’t display it.
Catalog data becomes increasingly valuable over time.
Auditability matters
Music infrastructure deals with rights and money.
You should be able to answer questions such as:
Who changed this release?
When did they change it?
What was the previous value?
Which territories were selected?
Which stores received it?
When was it submitted?
What validation passed?
Why was it rejected?
When was the takedown requested?
This requires event history and audit logs.
A mature system does not simply overwrite critical information without traceability.
A complete digital music supply-chain view
Putting the pieces together:
ARTIST / LABEL
│
▼
CATALOG INGESTION
│
├── Audio
├── Artwork
├── Metadata
├── Identifiers
├── Contributors
└── Rights
│
▼
VALIDATION + QC
│
▼
DISTRIBUTION SYSTEM
│
▼
RELEASE DELIVERY
│
│ ERN / applicable workflow
▼
DSP
│
▼
CONSUMER USAGE
│
▼
SALES / USAGE REPORTING
│
│ DSR / applicable reporting
▼
REPORT INGESTION
│
▼
CATALOG MATCHING
│
▼
ROYALTY ACCOUNTING
│
▼
STATEMENTS
│
▼
PAYOUTSThat is much closer to the real meaning of music distribution infrastructure.
Where Sonentra fits
Sonentra’s goal is to give businesses a simpler application layer for operating music distribution workflows.
From the developer’s perspective, the interaction should revolve around understandable product concepts:
Authenticate
↓
Discover Stores
↓
Create Artist
↓
Create Release
↓
Add Tracks & Assets
↓
Select Destinations
↓
Validate
↓
Submit
↓
Monitor Delivery
↓
Receive WebhooksThis allows a business to build its own customer experience without requiring every application developer to become an expert in every underlying music-industry standard.
However, an important distinction must be made:
This article explains DDEX industry architecture. It should not be interpreted as a claim that every Sonentra workflow, DSP connection or API endpoint currently uses DDEX, or that Sonentra holds a particular DDEX certification or direct DSP relationship, unless explicitly documented elsewhere.
Infrastructure capabilities should always be verified individually.
That transparency matters.
Frequently asked questions
What does DDEX stand for?
DDEX stands for Digital Data Exchange.
It develops standards used for exchanging data across the digital music industry.
What is DDEX ERN?
ERN is the Electronic Release Notification Message Suite. It enables record companies and distributors to communicate releases, resources and commercial availability information to DSPs.
What is the latest ERN version?
As of October 2026, DDEX lists ERN Part 1 Baseline XML Schema version 4.3.2 as current.
Is DDEX an API?
Not in the ordinary sense of a REST API product.
DDEX defines standards and exchange structures/choreographies for music-industry business processes. APIs can sit above or alongside DDEX-based infrastructure.
Is DDEX XML?
Some DDEX standards use XML. ERN is XML-based. Current DSR reporting, however, uses flat-file structures rather than the older XML DSR variants.
What is DSR?
DSR is the Digital Sales Reporting Message Suite. It supports reporting of sales and usage information from digital services/licensees to rights owners/licensors.
Does DDEX give me direct access to Spotify?
No. Implementing DDEX does not itself establish a commercial or delivery relationship with Spotify or another DSP.
Do I need DDEX to start a music distribution company?
Not necessarily as a direct implementation. If you use an infrastructure provider, parts of the industry delivery complexity may be abstracted behind its software or API. Companies building direct supply-chain integrations may need deeper DDEX expertise and appropriate licensing.
Do I need a DDEX licence?
DDEX states that you do not have to become a member to implement its standards, but an Implementation Licence is required for implementation under its current rules. Check DDEX’s current licensing requirements before going live.
The important lesson for developers
DDEX teaches us something bigger than XML schemas.
Digital music is structured infrastructure.
A release is not just:
song.mp3It is a network of:
Recording
+
Release
+
Artists
+
Contributors
+
Identifiers
+
Rights
+
Territories
+
Deals
+
Assets
+
Delivery
+
Usage
+
RevenueOnce you understand that, the architecture of a serious distribution platform makes much more sense.
Build on a simpler application layer
If you’re building a music business, you may not want your engineering team spending its first year implementing every layer of the distribution supply chain.
Sonentra is building white-label and API infrastructure around a simpler workflow for music businesses.
Building your own application?
Explore the Sonentra Developer API →
Launching a branded distributor?
Explore Sonentra White Label →
Need the developer-level introduction first?
Read: Music Distribution API — The Complete Developer Guide →
Starting the business itself?
Read: How to Start a Music Distribution Company in 2026 →
Technical disclaimer: DDEX standards evolve. Version numbers and implementation requirements in this article were checked against official DDEX materials in October 2026. Always consult the current DDEX specifications and your specific trading partner’s implementation requirements before developing a production implementation.
