DDEX DSR Files Explained: Profiles, Records and Import Checks
By Qlero Team
Understand DDEX sales reports, distinguish DSR from ERN and CWR, and check profile-specific records, identifiers and import compatibility.
Open a DSR file for the first time and its record codes can look unfamiliar. The useful starting point is not a royalty rate: it is the exact profile and version the sender used.
DSR means Digital Sales Reporting, a DDEX message suite for reporting digital sales and usage. It is not a single universal spreadsheet layout, a catalog delivery message, or proof that an artist has been paid. This guide explains how to read its structure and what to check before relying on an import.
What is a DSR file?
DDEX's DSR overview describes reporting from licensees, such as digital music services, to licensors of recordings, musical works and music videos. The recipient and relevant profile depend on the reporting relationship; a label should not assume every source delivers the same kind of report.
The current flat-file suite replaced an earlier XML format. Its baseline format is plain text. Under the delimiter rules, records occupy lines, tabs separate cells, and files use the .tsv extension. There are also rules for multiple values and escaping special characters. Renaming a file .csv does not convert it correctly.
Profiles include Basic Audio, User-Generated Content, Audio-visual and Financial Reporting to Record Companies. A standard defines the exchange format; it does not establish that every DSP uses it or that every accounting product supports every profile.
DSR, ERN and CWR do different jobs
Keep three separate questions in mind:
- What is being made available? DDEX's Electronic Release Notification, or ERN, communicates releases, resources and availability terms from record companies or distributors to DSPs.
- What happened on the service? DSR communicates sales and usage under the relevant reporting arrangement.
- What work is being registered? Common Works Registration, or CWR, is a CISAC standard, not a DDEX message suite. It supports works registration between publishers and societies, as DDEX itself explains in its CWR comparison.
These are different exchanges, not three compulsory stages traversed by every royalty. When a report fails to match, identify whether you are investigating the source report, recording metadata, work information or your own catalog. Do not assume the report format is the cause.
For the distinction between a recording and a work identifier, see ISWC vs. ISRC.
Start with the profile, version and record definitions
DDEX's architecture guide separates the common framework in Part 1 from profile-specific layouts and the detailed record definitions in Part 8. Reading only a profile's diagram is not enough to implement its fields and validation rules.
Some profiles offer two variants. A Multi-Record Block Variant, or MRBV, separates related information across records. A Single-Record Block Variant, or SRBV, combines a block's information into one longer record. DDEX's variant guide says the Financial Reporting to Record Companies profile is SRBV-only. Its layout should not be treated as the layout of every DSR report.
A reading map for the record-company financial profile
For Part 9 version 1.2, the published structure identifies this sequence:
- HEAD: the opening record.
- SY10.02: summary records describing commercial model, use type and territory.
- SR08.02: detail about releases, resources and sales or usage. A detail record may be followed by a DE extension for information the existing DDEX records cannot carry.
- SRFO: the closing record for this profile.
There is an important source limitation. As checked on 28 September 2026, that page's prose requires at least one SR08.02, while its table permits zero. Do not silently choose one as a universal validation rule: confirm the applicable specification and no-activity requirements with the sender or DDEX. This reading map is not a parser specification.
Likewise, the footer's presence is not proof that the report's amounts, catalog matches or subsequent royalty calculations are correct.
What the identifiers do—and do not—tell you
A recording's ISRC has 12 characters; display hyphens are not part of the code. DDEX's identifier guidance also warns that barcode identifiers are strings: leading zeroes must survive transmission.
That guide includes XML examples for DDEX messages. Those examples do not mean the flat-file DSR profile described here is XML.
Keep the original value and document any normalization you apply. Removing display punctuation from a genuine ISRC is different from deciding that two recordings are the same. Do not merge versions on title similarity alone or treat a valid-looking identifier as proof of ownership, contractual entitlement or payment.
Checks before accepting a DSR import
The following is a recommended review sequence, not a claim about which failures occur most often:
- Confirm the exchange. Record the sender, recipient, profile, version and variant. Ask whether the file is an original DSR report or a distributor's transformed export.
- Check the syntax against that specification. Review record order, required cells, delimiters and escaping. Do not apply Part 9's record codes to a different profile.
- Understand optional extensions. An absent DE record is not automatically a defect. Confirm how any agreed extension is interpreted rather than inventing values for missing cells.
- Check identity separately. Compare recording and release identifiers with the relevant catalog records. Preserve leading zeroes and source identifiers for investigation.
- Reconcile within the same scope. Compare reported and imported totals for the same currency, territory, use and period. Do not add summary amounts to the detail they summarize or assume unlike amounts share a denominator.
- Test changes before routine use. Keep a sample and an agreed expected result when a sender changes its implementation. Log unresolved questions before including the data in royalty calculations.
DDEX's compatibility guidance allows exceptions even within a major version. A newer sender format is not automatically safe for an older reader. Version names alone do not replace a compatibility test.
For implementation work, DDEX also directs implementers to obtain an Implementation Licence and Party ID and to work with a specific exchange partner. Its implementation guidance is a starting point, not a substitute for the operative specifications.
What to confirm with Qlero
Qlero's current DDEX repertoire guide documents inbound ERN 3 and 4 NewReleaseMessage deliveries through a configured partner. This is catalog metadata ingestion, not evidence of DSR sales-report support. It requires Pro or Enterprise, a recordings licence and the documented settings/repertoire permissions. The guide also limits which metadata is stored and states that takedown and update message types do not change repertoire.
Separately, Qlero's sales-template guide documents mapping provider columns, importing sales files and reviewing processed lines. Its template editor accepts CSV, XLSX and XLS example files; creating custom templates requires Pro or Enterprise. Template and sales-file access depend on the relevant view/write permissions.
Neither guide establishes support for every DSR profile, version or extension. That documentation gap does not prove a capability is absent. Before planning a native DSR workflow, ask Qlero to confirm and demonstrate the exact source format, any conversion step, the applicable plan and the resulting totals and exceptions.
Once sales rows are imported, Qlero's status guide distinguishes data validation from contract processing. A Ready file can still contain Invalid rows. Valid data does not settle the contract checks, and Reported does not mean the payee has been paid.
Frequently asked questions
Do all DSPs send DSR files?
Do not assume so. Confirm the actual format and version with each reporting partner. A DDEX-based catalog delivery does not establish how that partner sends sales reports.
Can I read a DSR file in a text editor?
The flat-file format is plain text, so you can inspect it. Interpreting cells and validating relationships still requires the relevant profile, architecture and record definitions. A readable file is not necessarily a valid or correctly imported one.
Why can a valid file still leave unmatched income?
File conformance and catalog matching are separate checks. Investigate the specific identifier, catalog record and import mapping. In Qlero, even a matched row can remain invalid for another reason, such as a missing date or exchange rate; the invalid-lines guide explains those distinctions.
Is the DSP sales report the artist's royalty statement?
No. Source sales or usage information is an input to the label's accounting; the artist's statement reflects the applicable agreement and accounting process. Use the royalty statement field guide to examine that separate output.
Keep the format question separate from the accounting question
A useful DSR review establishes which specification the sender used, how the records relate, and whether the imported result preserves the report's meaning. It does not stop at recognizing an ISRC or finding a footer.
If you are evaluating Qlero, book a demo and identify the profile and version you need to handle. Ask for a demonstration of that workflow before treating general DDEX support as confirmation of DSR compatibility.
Further reading
Standards and product documentation checked on 28 September 2026. This is a source-based explanation, not a report of hands-on parser testing or a guarantee of compatibility with your files.