What is ERN? Electronic Release Notification, the Core DDEX Message Explained

ERN means Electronic Release Notification. It is the XML message inside the DDEX standard that one distributor sends to one DSP to say “here is a new release, here is the audio, here is when it goes live.”

If DDEX is the postal system, ERN is the letter. Every modern release on Spotify, Apple Music, Boomplay, or any other major streaming service arrived as an ERN message.

What is ERN?

ERN is a specification published by DDEX, the not-for-profit music industry standards body. It defines the exact structure of the XML file a distributor sends when releasing music. Every field, every tag, every allowed value is documented in the spec.

The ERN message bundles together everything a DSP needs to ingest a release in one go:

• Release identifiers: UPC for the release, ISRC for each track.
• Title and artist metadata: release title, primary artist, featured artists, contributors, language, genre.
• Asset references: file paths to the WAV/FLAC audio and the cover art image, plus their checksums.
• Rights and territories: where the release can stream, where it cannot, which commercial models apply.
• Dates: original release date, this-delivery release date, takedown date if any.
• Contributor roles: who produced, who wrote, who engineered, who featured, with role codes from the DDEX controlled vocabulary.

Why does ERN exist?

Before ERN, every DSP had its own format for receiving releases. iTunes wanted one CSV shape, Beatport wanted another, Deezer wanted a third. A distributor with ten DSP relationships maintained ten different ingestion templates.

ERN collapsed that into a single XML spec. A distributor builds against ERN once. Any DSP that supports ERN can accept the message. The economics of running an independent distributor are only possible because of this collapse.

How does ERN work in practice?

The delivery flow is mechanical:

1. The distributor’s CMS takes the artist’s submission and generates an ERN XML file.
2. The XML, the audio assets, and the cover image are packaged into a delivery folder.
3. The folder is shipped via SFTP or a private API to the DSP.
4. The DSP validates the message against the ERN schema.
5. If valid, the release goes into the ingestion queue and gets scheduled for its release date.
6. If invalid, the DSP returns an error code and the distributor must fix and resend.

This is silent and fast when it works. A clean ERN delivered today is on Spotify in 24 to 72 hours. A broken ERN sits in error state until someone notices.

ERN versions and why they matter

ERN has gone through multiple major versions:

• ERN 3.x (introduced around 2011): legacy, still accepted by some DSPs but increasingly deprecated.
• ERN 4.1 and 4.2: the workhorse of the late 2010s and early 2020s, still in heavy use at many distributors.
• ERN 4.3 (published December 2022, current general-availability version): now mandated or strongly preferred by Spotify, UMG, Beggars, and a growing list of others.

The version matters because newer ERN supports newer DSP features: cleaner contributor role mapping, better Dolby Atmos handling, more granular territory rights, expanded immersive-audio asset types. If your distributor only ships ERN 4.1, your releases on a 4.3-only DSP will silently fail or land without the newer attributes.

What this means for global indie artists and labels

Three things to know without becoming an XML engineer.

1. Ask your distributor which ERN version they ship. If the answer is “I don’t know” or anything below 4.2, your release coverage has invisible gaps. Modern distributors should be on 4.3.

2. Most artist-facing problems are ERN field problems. The producer credit that did not show up on Spotify? That is a Contributor element in the ERN that was either missing or mapped to the wrong role code. The featured artist who is in the title instead of the artist list? Same problem. These are not Spotify bugs. They are distributor metadata bugs.

3. Regional DSPs have stricter ERN validation than the majors. Boomplay, Audiomack, Anghami, and JioSaavn all run tight schema validation. A loosely-formed ERN that Spotify accepts may get rejected by Boomplay because Boomplay’s parser is stricter on territory codes. If you keep missing African or MENA DSPs, your distributor’s ERN hygiene is the most likely cause.

Common ERN mistakes and gotchas

• Wrong contributor role codes. DDEX uses controlled vocabulary (Producer, MainArtist, FeaturedArtist, Mixer, Engineer, etc.). Free-text “produced by” comments in the title do not populate the underlying ERN role.
• Missing or invalid ISO language code. Songs sung in Yoruba should declare yo. Songs in Mandarin should declare zh. Defaulting everything to English breaks lyric matching, recommendation, and editorial discovery.
• Territory list errors. “Worldwide excluding US” with a typo’d ISO code can silently drop entire continents from the release.
• Asset reference mismatch. The XML says audio.wav, the file in the folder is Audio.WAV. Some DSPs accept, some reject.
• Stale ERN version. A 2026 release shipped on ERN 3.x is silently degraded on every DSP that has moved on.
• Original release date confusion. ERN distinguishes original release date from this delivery’s go-live date. Get them backwards and your back-catalog reissue shows up as a 2026 debut.

How InterSpace Distribution handles this

InterSpace Distribution generates DDEX ERN 4.3 messages natively for every release. Contributor role mapping is enforced at upload, ISO language codes are validated, territory rights are explicit per ISO country, and the underlying XML is available on request for any artist who wants to inspect their own delivery. The same engine ships to 220+ DSPs including the African, MENA, South Asian, and Southeast Asian platforms majors-focused distributors deprioritise.