Everything from an upload to a paid-out royalty.

The system of record. Releases and tracks carry the complete contributor and composer graph rather than a flat text field, so a credit is an entity you can query, correct once, and deliver consistently to every store.

• Releases, tracks, contributors, composers and recording versions as first-class records
• 193 metadata languages and 429 genre styles, held as stable lookups rather than free text
• ISRC, UPC/EAN, label, P-line and C-line, territory rules and sale dates
• Roles and role groups, primary versus featured, ordered credits per release and per track
• Corrections propagate — fix an artist once, every release carrying that credit follows
• An artist de-duplication tool for the near-identical roster entries every migrated catalogue arrives with
• A per-release status timeline, so "where is it" is a screen rather than a support ticket

The upload surface your artists actually touch. Release, Tracks and Distribution as three tabs over one record, saving as they type, with a live validation panel beside them. Submission unlocks only on a clean report — so a release does not reach your queue, or a store, in a state someone has to send back.

• Three tabs over one release — Release, Tracks, Distribution — with the tab held in the URL, so a reload or a Back lands where you were
• Autosave with a visible save state; nothing is lost to a closed laptop
• A validation panel listing every finding as blocking or advisory, and clicking one jumps to the exact field that raised it
• Submit is gated on a clean report rather than accepting the release and rejecting it later
• Contributor and composer pickers with roles, ordering and publishing shares — not free-text credit fields
• Artwork and per-track audio uploaded straight to storage, with metadata read from the file itself
• Per-track monetisation policy and distribution settings on their own tab

Quality control that exists now, rather than the automated engine described on the QC page. Releases arrive pre-validated by the builder, land in a review queue, and are approved, returned with a reason, or held. The automated checks being built plug into this queue rather than replacing it — the queue is where anything a machine should not decide alone ends up either way.

• Pre-submit validation in the builder, so most problems never reach the queue
• Findings carry a severity — blocking or advisory — rather than one undifferentiated list
• Approve, return with a reason, or hold, with the whole exchange recorded on the release
• Returned releases come back with the specific field named, drawn from a structured reason catalogue
• A hold with a reason that pauses the queue clock and is invisible to the uploader
• Audio recognition on every track beside the release — approval waits until each one is scanned
• Changes after go-live arrive as edit requests and are reviewed, never written straight through
• The queue the automated checks feed into, so adopting them changes the volume, not the workflow

For distributors whose labels, or whose sub-labels, want a say before anything goes out. A release submitted by an artist goes to their label's own review desk first — approve, reject, or ask for changes — and only an approved release reaches yours. Nothing is delivered on the first approval alone.

• Two review stages, each with approve, reject and request-changes
• The label's decision and reasons travel with the release to the second stage
• Switched on per account, so labels that want no desk of their own are not given one
• The same queue, reasons and audit trail at both stages

A release that is being reviewed or delivered cannot change under the reviewer, and a live release is never edited in place. Each state decides who may change what, and the answer is enforced on the server rather than hidden by a button.

• Drafts edited freely and deletable until first submitted
• Locked in review and in delivery, for every role including the reviewer
• After go-live, changes arrive as edit requests and go back through review
• A release date or as soon as possible — never neither, so a blank date is never a silent choice
• Every transition recorded on the release's own timeline

Moving a live catalogue is the single biggest reason a label stays on a platform it has outgrown. A release is identified by its barcode and a recording by its ISRC, and by nothing else — two labels can both release “Greatest Hits”. The import scans first and writes nothing; a person reads the report, then applies it.

• Barcode and ISRC matching, normalised first, so an export written with dashes is not a new catalogue
• Three verdicts per line — already here, ready to create, or unresolved with the reason named
• Scan and apply are separate steps; the report a person approved is exactly what is written
• One transaction per release, so one bad date never rolls back a nine-hundred-release migration
• Imported releases land as drafts — history, not new work in the review queue
• A catalogue already held by an upstream partner can be read across and linked, not re-uploaded
• Historical statement import so earnings history survives the move

Delivery orchestration with a per-account store catalogue on top. The reach is a function of the relationships you hold, not of the software: through aggregator and partner routes the addressable network runs past 400 platforms and sub-platforms, and the delivery layer is built to target any endpoint you have a deal with. Every client sees only the destinations you enabled for them.

• 400+ platforms and sub-platforms addressable through aggregator and partner routes
• Not bounded by one contract — deliver through your supply agreement, your partner's, or ours
• New destinations added as endpoints rather than as engineering projects
• Spotify, Apple Music, YouTube Music, Amazon, Deezer, TikTok, Tidal, JioSaavn, Boomplay, Anghami and more
• Per-account store catalogue — enable or disable destinations for each client
• Takedowns, redeliveries and per-store status tracked as release events
• Content ID and rights-management destinations handled alongside the audio stores

The delivery relationship and the software that drives it need not come from the same company, as every credible platform in this category now says. Here it is not a higher plan tier or a short endpoint allowlist, and the API you would automate it with is public. Where your upstream partner exposes an API, the whole system is built on it — artist dashboards, admin console, catalogue, analytics, royalties, payouts and support.

• Bring your own distribution agreement — your contract, your rates, your relationship
• Not a premium add-on and not a single-endpoint allowlist: every destination you hold a deal for
• Delivery orchestrated through your upstream partner rather than replacing it
• Where that partner exposes an API, the whole platform is built on it end to end
• Artist-facing dashboards, admin console, analytics and royalty reporting on your supply chain
• Or use ours — the same platform, with wavbee's own delivery relationships behind it
• The choice is commercial, not technical: nothing in the software assumes one answer

Where delivery runs through an upstream partner's API, a release is sent the moment it reaches your review — so the partner's own checks run while you review — and held there until you approve it. Approval releases exactly what was reviewed: if anything changed in between, it is withdrawn and re-sent first. Rejected releases are withdrawn and kept, so a corrected resubmission comes back under the same record.

• Sent at review, held at the partner, released only by your approval
• A content fingerprint proves the approved release is the one being released
• Codes the partner assigns — barcode and ISRCs — are read back into your catalogue
• Per-store status read back on a schedule, so the timeline shows what the stores did
• Separate sandbox and production connections per account, never mixed
• Existing artist accounts at the partner linked by exact email, never duplicated

If you hold an ISRC registrant code or a GS1 barcode range, codes are allocated from it at the right moment in the release's life — and a code the uploader supplied is never replaced. Without a range, the release goes out blank and the codes assigned downstream are copied back.

• ISRCs from your registrant range; barcodes from your GS1 prefix, 12 or 13 digits
• The GS1 check digit computed, the item width derived from the prefix
• One allocation per release, recorded, never reused
• Supplied codes kept as supplied

A takedown is a request with a stage, not a button. An artist asks, their label decides, then the distributor — and a self-distributing label's approval is the last word. Whole catalogues can be taken down in one decision, and distribution can be switched off for an account without closing it.

• Takedown requests decided in order — label first, then distributor
• Whole-catalogue takedowns: live releases taken down, in-flight ones taken down on arrival, drafts untouched
• Distribution off stops new releases and keeps the account, its statements and its payouts
• Taking the catalogue down is a separate choice from switching distribution off
• Artists told of every decision in your name

Masters, artwork and documents held in object storage behind signed, expiring URLs, with large uploads going straight from the browser to the bucket so a big master never has to squeeze through the application.

• Private bucket for masters, artwork, attachments and documents
• Signed, expiring delivery URLs — no public object is ever the default
• Direct-to-storage presigned uploads for large files
• A separate public bucket for the assets that are genuinely public
• Provider-agnostic — the storage layer is configuration, not code

Who owns what, who wrote what, and on what evidence — held against the release and track rather than in a spreadsheet somebody has to remember to update.

• Per-release and per-track ownership with an account boundary enforced in the database
• Contributor roles and role groups aligned to the standards stores expect
• Writer and publisher shares captured at track level and delivered with the release
• Monetisation policy per track and per destination
• Every change written to an audit trail with the actor and the timestamp

Statements arrive in as many shapes as there are reporting parties — your distributor's, a third party's, your own. Every one is normalised into one table, attributed to the recording it belongs to, and pushed out as per-artist statements, earnings views and API data. Imports are additive: a late or supplementary report adds to a month rather than overwriting it, and nothing is ever counted twice.

• One normalised store for both major reporting patterns — per-transaction and per-summary
• A byte-identical file is refused outright; a second file for a month already imported is asked about, with the overlap shown first
• Overlap counted row by row on one definition of a row, so “identical data” adds only what is new
• Your own and third-party reports imported alongside your distributor's, never mixed with them
• Attribution to ISRC, release, artist and account, then per-artist statements published from the same rows
• An import can be withdrawn while nothing built from it is final; after that a correction is an adjustment
• Replacing an import is restricted, needs a reason and is audited

Statements that have been signed off stay exactly as they were signed off. When a supplementary report lands for a closed month, the difference is carried forward — once for the label's payout and once for each affected artist, at that month's own rates — and the next month cannot close until someone has acknowledged it.

• Closed months never rewritten — differences carried, not edited in
• Calculated with the original month's rules, so an unchanged month carries exactly nothing
• Each artist's correction goes to whoever owned the release in that month
• A month cannot be finalised until its carried adjustments are acknowledged
• A negative balance carried against later earnings, never silently dropped

Reporting built on the ingested statements rather than on a separate analytics product, so the number an artist sees and the number you pay out are the same number from the same row.

• Trend charts over revenue and performance by release, track, artist and account
• Ranked lists — top releases, top tracks, top territories, top stores for a period
• An explorer for slicing the same data by dimension rather than only reading fixed reports
• Per-end-user analytics surfaced inside the account holder's own console, not only yours
• A per-account analytics switch, independent of anyone else's reporting
• Drill-down to the individual statement line behind any figure
• Exportable for finance, with the underlying royalty rows still addressable

The publishing side of a recording, held as records rather than a credits field: who wrote it, in what shares, which publisher and administrator act for them, and which society they belong to — validated in the builder and delivered with the release to every store that takes it.

• Writer shares per track, with composer and lyricist roles checked before submit
• ISWC, publisher, administrator, mechanical society and registration id per share
• Publisher records with IPI number and society, set up and audited centrally
• Writers with ISNI, mergeable when a migrated catalogue arrives with duplicates
• Self-published writers handled explicitly, never left as a blank

The rest of the publishing picture. Writer and publisher metadata already travels with every track; the work behind it — its own owners, registrations and money — is the next major expansion. It is partner-plural by design: publishing routes through whichever administrators and societies the client already works with, not through one we picked for them.

• Works as records in their own right, linked to the recordings that embody them
• Writer and publisher splits with controlled-composition handling
• Society and CMO registration workflows, through whichever partner the client works with
• Mechanical and performance royalty ingestion alongside the recording pipeline
• One statement view across recording and publishing income

Today a release's earnings go to the account that owns it. Splits divide a track's earnings between the people who made it, each paid into their own balance from the same statement line, without the owner re-distributing by hand.

• Shares per track, per collaborator, adding to one hundred percent
• Collaborators paid from the same statement line, into their own balance
• Invitations for collaborators who do not have an account yet

Earnings become payments without anyone maintaining a parallel spreadsheet. A monthly run picks up every account whose latest statement clears the threshold, and the amount actually paid is recorded in the account's own currency.

• Monthly automatic payout run driven by the latest settled statement, with a ticket trail
• Bank details held encrypted per end user, with a payout minimum you set
• Manual payout requests alongside the automatic run
• Balances stay right after a month closes — late corrections arrive as adjustments, never rewrites
• Multi-currency — the paid amount is recorded in the currency it was paid in
• A permanent payout log, queryable per account and per period

The money layer, including the parts nobody demos. Currency is derived from the account's country rather than trusted from the client, mandates are never charged before the account is approved, and every redirect flow is confirmed server-side.

• Three gateways — cards, UPI and wallet rails — behind one interface
• Subscription and one-off pay-per-use charges on the same billing stack
• Approval-gated mandates: nothing bills before an account is accepted
• GST tax invoices in their own numbered series, with credit and debit notes for corrections
• Returns built from the issued documents rather than from a payments export
• Reconciliation sweeps recover any payment whose browser callback never arrived

Every account is a hard boundary. Isolation is enforced in the query layer and asserted by a scoping matrix in the test suite, because 'we scope by account everywhere' is a claim that needs a machine checking it, not a convention.

• Account-scoped everything — catalogue, users, statements, tickets, assets
• Owners, and team members granted any of nine scoped capabilities — a section without one is absent, not read-only
• Fields filtered on the server where a screen mixes domains, so finance data never reaches a catalogue-only seat
• Per-account switches granted centrally — QC, escalation, store management, royalty import, analytics, API access and docs
• Cross-account isolation asserted by an automated scoping matrix, not by convention
• Impersonation for support behind its own grant, with a visible banner and a full audit record

A distribution platform is a support business wearing a technology coat. This is a full desk — inbound email parsed and threaded on message identity, shared and personal mailboxes, SLA clocks that stop and start with status.

• Inbound email threaded on Message-ID and reference code, never on subject resemblance alone
• Shared team mailboxes and personal mailboxes with per-member roles
• Kanban queue with statuses, internal notes, and a public reply visible to the requester
• SLA timers that pause and stop with ticket status
• Live chat and calls with wavbee's team from inside the dashboard, with the agent seeing the page you are on
• Spam learning, suppression filters, a knowledge base and dynamic intake forms