Distribution Management

Bring distribution onto one traceable path

From release configuration, DSP delivery, identifier allocation, and status tracking to takedown and redelivery, SEUNOR governs every step on one consistent path.

Delivery language preview

Release statusDelivering · 12 DSPs

Identifier statusAwaiting ISRC × 2

Delivery taskDDEX ERN 4.3.2 packaging

Sync status1 change pending sync

Business value

Govern every segment of the release path in one place

Value

One traceable release path

Drafts, releases, platforms, delivery tasks, and ERN packages live on the same trunk, so every segment can be traced back to the right owner and time.

Value

Identifiers, no manual numbering

UPC and ISRC are allocated from prefix pools, with sequences carrying over across years; existing prefix blocks can be loaded into the pool to avoid historical conflicts.

Value

Failures are retriable, changes can be synced

Failed deliveries keep error details and a retry entry; metadata or asset changes are detected and redelivered to live platforms as needed.

Core capabilities

Six control points along the release path

Capability · 01

Release wizard

A two-step wizard with autosaved drafts and cross-session recovery; supports multi-release batch creation and automatic merge against conflicts.

Capability · 02

DSP mapping

Onboard multiple DSPs per tenant configuration; one release config can be dispatched at once, with platform-level status maintained independently.

Capability · 03

DDEX ERN multi-version

Outbound coverage spans 3.8.2, 4.1, 4.1.1, 4.2, 4.3, 4.3.1, and 4.3.2; the version is picked per DSP requirement, no in-team translation needed.

Capability · 04

Observable delivery tasks

Underlying delivery tasks separate packaging, uploading, callback, and completion; failures keep error details and can be retried.

Capability · 05

Takedown and recovery, two lanes

Standard takedown is restorable, permanent removal is irreversible; takedown timezone is configurable, and restore stays independent from soft delete.

Capability · 06

Preset templates and reuse

Save a common DSP configuration as a preset and apply it in one click on the next release; occupied platforms are skipped automatically.

Workflow

A four-step loop from selection to DSP go-live

01Step

Pick the work

Choose one or a batch of works from the catalog; existing releases are detected to avoid duplicate go-lives.

02Step

Configure the release

Pick platforms, regions, release windows, commercial models, and pricing; request automatic identifier allocation if needed.

03Step

Deliver and track callbacks

The system generates DDEX ERN per DSP requirement, delivers via SFTP, and tracks callback results.

04Step

Govern post go-live

Track status, sync changes, redeliver as needed, take down safely, and restore with a clear audit trail.

Distribution backbone

The four capability areas SEUNOR covers along the release path

Distribution is more than "sending files to DSPs". It pulls release configuration, platform delivery, status tracking, and exception handling into a layer that humans and systems can operate together.

Release configuration and collaboration

Turn release work from a one-time event into a savable, recoverable, reusable, batchable collaboration.

Two-step wizard with autosaved drafts; resume from where you left off across sessions
Multi-release batch creation merges automatically into existing releases to avoid duplicate go-lives
Preset templates save common DSP configurations once and reuse them many times

DSP platforms and protocols

Tenants onboard DSPs on demand, with unified DDEX ERN multi-version delivery and SFTP transport.

Tenant-level DSP configuration; onboard via platform templates quickly
Outbound DDEX ERN covers 3.8.2 to 4.3.2, seven versions, picked per DSP requirement
Direct SFTP transport, files checksummed with SHA-256, host-key policy configurable

Delivery status and observability

Turn delivery from a black-box upload into something where every segment can be seen.

Release-level status and platform-level status are separated and never contaminate each other
Underlying delivery tasks split packaging, uploading, callback, and completion into four states
Timeline records every delivery batch, error detail, and retry history

Takedown, redelivery, and exception handling

Stable operations after go-live matter more than the first release.

Standard takedown is restorable, permanent removal is irreversible, and takedown timezone is configurable
Failed tasks can be retried, with a full audit trail for every redelivery
Metadata or asset changes are detected and redelivered to live platforms on demand

Who uses Distribution

Different teams, the same underlying problem

Distribution is not only for new releases. Whether you are launching a new version, redelivering long-tail catalog, or coordinating across regions, the same system handles all of it.

Label distribution operations

Dozens of new releases per month, with different release windows and commercial terms per region and per DSP, plus ad-hoc reschedules.

Capture common configurations as preset templates; manage multi-region, multi-window, multi-model deals with commercial cards; run pre-release conflict checks to avoid duplicate go-lives.

Independent labels and rights agencies

A growing third-party catalog needs to reach different DSPs gradually, with scattered identifiers and limited prefix blocks, and worries about year-over-year sequence conflicts.

UPC and ISRC are allocated from prefix pools, with sequences carrying over across years; existing prefix blocks load into the pool, so no manual numbering per track.

Aggregators and platform operations

Live tracks see continuous metadata or asset changes that must be synced to every delivered DSP, and failures need to be pinpointed to a specific step.

The system detects differences and redelivers to live platforms on demand; the underlying delivery task splits packaging, uploading, callback into four states, and failures keep error details for retry.

Standards and protocols

SEUNOR DDEX ERN version support matrix

Different DSPs require different DDEX ERN versions. SEUNOR supports seven outbound versions in parallel and picks the right one per DSP, so teams do not maintain multiple generation pipelines themselves.

01ERN version	02AVS version	03Outbound (to DSP)	04Inbound (receive ERN)
3.8.2	AVS 2016-10-06	Supported	Supported
4.1	AVS 4	Supported	Supported
4.1.1	AVS 4.1.1	Supported	Supported
4.2	AVS 2020-05-18	Supported	Supported
4.3	AVS V11	Supported	Supported
4.3.1	AVS V11	Supported	Supported
4.3.2	AVS V11	Supported	SupportedRecommended

3.8.2AVS 2016-10-06

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.1AVS 4

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.1.1AVS 4.1.1

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.2AVS 2020-05-18

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.3AVS V11

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.3.1AVS V11

Outbound (to DSP): Supported
Inbound (receive ERN): Supported

4.3.2AVS V11

Outbound (to DSP): Supported
Inbound (receive ERN): SupportedRecommended

The actual onboarding version follows each tenant's DSP agreement; newer DSPs usually recommend 4.3.2.

Identifier governance

How industry identifiers are governed inside the SEUNOR release path

UPC / EAN, ISRC, ISNI, IPI, GRid, and DPID decide whether a work can be correctly identified across the global supply chain. SEUNOR makes these identifiers pooled, allocated, and back-fillable so teams do not number every track by hand before release.

01Identifier	02Scope	03How SEUNOR handles it
UPC / EAN	Album-level product code	Managed as a prefix pool and allocated automatically at release; existing prefix blocks load into the pool with sequences continuing across years
ISRC	Track-level recording identifier	Pool + per-year sequence with automatic carry-over; can also be allocated by SEUNOR, with pre-allocation supported to unblock the release path
ISNI	Creator identity	Bound to the artist entity and injected into ERN automatically at delivery
IPI	Composition rights party	Bound to the artist entity for CMO reconciliation
GRid	Release batch identifier	Generated as the release lane progresses and attached at delivery
DPID	DDEX party identifier	Maintained in tenant configuration; sender and recipient DPIDs are injected into DDEX messages automatically

UPC / EAN

Scope: Album-level product code
How SEUNOR handles it: Managed as a prefix pool and allocated automatically at release; existing prefix blocks load into the pool with sequences continuing across years

ISRC

Scope: Track-level recording identifier
How SEUNOR handles it: Pool + per-year sequence with automatic carry-over; can also be allocated by SEUNOR, with pre-allocation supported to unblock the release path

ISNI

Scope: Creator identity
How SEUNOR handles it: Bound to the artist entity and injected into ERN automatically at delivery

IPI

Scope: Composition rights party
How SEUNOR handles it: Bound to the artist entity for CMO reconciliation

GRid

Scope: Release batch identifier
How SEUNOR handles it: Generated as the release lane progresses and attached at delivery

DPID

Scope: DDEX party identifier
How SEUNOR handles it: Maintained in tenant configuration; sender and recipient DPIDs are injected into DDEX messages automatically

Observable status

Turn delivery from a black box into something every segment can be seen

Distribution maintains two layers of state machines: release-level status tells you where the release sits overall, and platform-level status tells you what is happening on a specific DSP.

Covers the full lifecycle from creation to takedown; takedown and update paths are independent.

Happy path

PENDING

PROCESSING

DELIVERED

UPDATE_PENDING

TAKEDOWN_PENDING

TAKEN_DOWN

Failure branches

FromPENDINGPENDING_ALLOCATION
FromPROCESSINGFAILED
FromUPDATE_PENDINGUPDATE_FAILED
FromTAKEDOWN_PENDINGTAKEDOWN_FAILED

State dictionary

10 states

PENDINGPending deliveryCreated and waiting to enter delivery
PENDING_ALLOCATIONAwaiting ISRCRequested SEUNOR to allocate ISRC; resumes automatically once allocated
PROCESSINGDeliveringGenerating ERN and delivering via SFTP
DELIVEREDDeliveredDelivered and live; subsequent updates or takedown can be initiated
UPDATE_PENDINGUpdate in flightMetadata / asset changes are being redelivered to live platforms
UPDATE_FAILEDUpdate failedRedelivery failed; error detail preserved for retry
FAILEDDelivery failedFirst-time delivery failed; error detail preserved for retry
TAKEDOWN_PENDINGTaking downTakedown initiated; takedown ERN is being generated and delivered
TAKEN_DOWNTaken downTakedown complete; standard takedown is restorable
TAKEDOWN_FAILEDTakedown failedTakedown delivery failed; error detail preserved for retry

Governance moves

Stable operations after go-live matter more than the first release

Distribution is not only about "shipping content". A set of governance moves give post-release changes, failures, takedowns, and restores a clear path.

4Gates · Post-release

Gate · 01

Change diff detection

When metadata or asset of a live release changes, the system detects the diff and lets the user decide whether to sync to live platforms, instead of letting changes be forgotten.

Gate · 02

Retries with audit trail

Failed terminal states preserve error details; retries can be initiated, already-uploaded files are not re-uploaded, and every retry is logged in the redelivery audit log.

Gate · 03

Standard takedown vs permanent removal

Standard takedown is restorable, permanent removal is irreversible; takedown timezone is configurable to keep restorable content from being accidentally made irreversible.

Gate · 04

Conflict precheck and automatic merge

Release creation checks for window overlaps on the same DSP and asks the user to confirm; when a release is in flight for the same work set, new platforms are appended to the existing release instead of opening a new one.

Before vs after

From manual distribution to governed distribution

Same content, same DSPs, just a different way of working.

Before governance

Every release relies on spreadsheets, email, and shared drives; anything missing must be chased
Identifiers are numbered by hand, year-over-year conflicts appear, and mistakes surface only after release
Delivery failures are reconciled by humans in DSP backends; the failing step is hard to trace
Takedown and permanent removal share one lane; mistakes are irreversible
Changes to live content must be resubmitted DSP by DSP

With Distribution in place

Release configuration runs as a main-line workflow; drafts, platforms, deals, and pricing are all governable
UPC and ISRC are allocated from pools, with sequences continuing cleanly across years
A delivery state machine covers packaging, uploading, and callback; failures preserve error details and can be retried
Standard takedown is restorable, permanent removal needs its own path, and takedown timezone is configurable
The system detects diffs and redelivers to every live platform on demand

FAQ

The questions teams ask most often before adopting Distribution

These answers cover the highest-frequency topics; detailed boundaries live in the product documentation and contracts.

No starting from scratch. SEUNOR supports DDEX ERN 3.8.2 to 4.3.2, seven outbound versions, and can reuse existing metadata directly; missing fields are filled per asset-layer rules, and teams do not need to finish everything before starting.

Get started