Skip to main content
DDEX is the XML format distributors and aggregators use to deliver release metadata. You do not upload anything yourself. Your delivery partner sends ERN messages to Qlero’s SFTP, Qlero matches them into your repertoire, and you check what landed in Data Files › DDEX.
DDEX is available on Pro and Enterprise plans, for record companies on a recordings licence. You need write access to record company settings to set your Party ID, and import access to Repertoire to see your deliveries.

​
Before your first delivery

Set your DDEX Party ID. Open organisation settings, then the record company’s General page, and fill in DDEX Party ID (DPID). It looks like PADPIDA0000000000A. This is how Qlero recognises a delivery as yours, so it has to match the Party ID your partner puts in the message. Until it is set, the DDEX tab under Data Files stays locked. Ask Qlero to set up your delivery partner. Every delivery arrives under a named partner, the distributor or aggregator your catalogue comes from. Qlero creates the partner and the SFTP account, then passes the credentials to them. There is nothing to configure in the app.

​
Deliver from your partner

Once your Party ID is set and Qlero confirms the partner is ready, your partner can start delivering. Three things they need to get right:
  • Your DDEX Party ID goes in the message header, as SentOnBehalfOf. A delivery carrying an unrecognised Party ID never reaches your repertoire.
  • Messages are ERN NewReleaseMessage, as unzipped .xml. Both ERN 3 and ERN 4 are supported.
  • One message describes one release and its tracks.
Nothing appears in your repertoire until a message finishes processing.

​
What Qlero reads from the message

An ERN message carries far more than Qlero stores. These are the only fields that reach your repertoire.

​
Tracks

​
Releases

​
Labels

​
What is ignored

Deals, territories and rights, prices, genres, parental warnings, C lines, contributors and writers, publishers, and technical file details do not reach your repertoire. Display artists are stored as names on the track and release, and a delivery never creates artist records.

​
Rules at a glance

A delivery changes a field only when the message says something about it. A field the message leaves out keeps the value you already have. A field the message carries but leaves empty is cleared, which is how your partner removes a value they no longer hold.

​
Tracks

Tracks are matched on ISRC alone, across your whole repertoire.

​
Releases

Releases are matched on barcode first, then catalogue number. The message states the tracklist, so the release ends up holding exactly what was delivered, in that order. Say a release holds tracks 1, 2 and 3, and your partner redelivers it with tracks 1, 2 and 4. The release ends up with 1, 2 and 4. Tracks 1 and 2 are updated if their details changed, track 4 is added, and track 3 comes off the release. Taking a track off a release does not delete it. It stays in your repertoire with its contracts intact, and you can add it back to the release by hand. Format type, version, variant and notes are yours, the same as on tracks.

​
Labels

Matching is on the label name and ignores capitalisation, so Qlero Records and qlero records are the same label. A label created by a delivery is an ordinary label and appears in Repertoire › Labels. A partner sending an unexpected label name creates an unexpected label, so it is worth checking the list after your first delivery. See Adding new labels.

​
Contracts

A delivery can fill a gap but never overwrites a deal. A missing sales contract can be filled. When a track or release has no sales contract and its label and artist auto-match one, the delivery attaches that contract at 100%. This applies whether the delivery created the track or updated one you already had. Everything else is left alone. An existing sales contract, its participation rate, your cost contracts and any participation rate override are never edited or removed by a delivery. A DDEX message carries no participation rates, so set those yourself unless auto-matching covered them. See Assigning contracts to tracks and releases.
A delivery is saved as one unit. If a single track in the message is unusable, nothing from that message is saved, including the tracks that were fine. Ask your partner to correct the file and redeliver.

​
Verify your delivery

Open Data Files › DDEX. Each delivery is one row:
  • Release Identifier shows the barcode with the catalogue number beneath it.
  • Outcome is Created, Updated or Unchanged, and it describes the release only: its own details and its tracklist.
  • Tracks counts what was in the message. Created, Updated and Reused split that into new tracks, tracks whose details changed, and existing tracks added to the release unchanged.
Read the two together. A delivery can land on Unchanged while the Updated count is not zero, which means the release record was already right but track details changed. Search by release identifier to find a specific delivery, or filter by Status to find the ones that failed.

​
Known limitations

Takedowns and updates do nothing. Qlero processes NewReleaseMessage only. A takedown or update message is recorded as a delivery and changes nothing in your repertoire, with no error to tell you so. Anything a takedown was meant to do has to be done by hand. A failed delivery is quiet. The table has no status column, so a delivery that failed appears as a row with dashes in place of its counts. Filter by Status to find them. The app does not show why a delivery failed. If a delivery is missing, or lands without changing what you expected, contact Qlero support with the release identifier.

​
Next steps

A DDEX delivery brings in metadata. Attach the new tracks and releases to contracts so Qlero can allocate income to them. See Assigning contracts to tracks and releases.