Release through more than one distributor — or collect from a PRO and the MLC on top — and your income arrives as several files, each on its own timeline and in its own shape. Here is how to combine royalty statements from multiple distributors into one normalised, per-song view, and reconcile that merged total back to the money that actually reached your bank.
The situation is familiar to almost every working artist, manager or small label. A back catalogue sits on DistroKid, a newer record went out through TuneCore, an older one still earns on CD Baby, a PRO (ASCAP, BMI, PRS) pays performance royalties, and the MLC pays US mechanicals. Five income sources, five logins, five exports — and not one of them agrees on file format, currency, time period or even what a “track” is called. Ask a simple question — “how much did Midnight Drive actually earn last year, everywhere?” — and nothing answers it.
To combine royalty statements from multiple distributors you do three unglamorous things: get every file into the same shape, collapse the duplicates that hide your real per-song totals, and tie the merged figure back to your bank deposits so you trust the number. None of it is hard in principle. It is fiddly, and the fiddliness is where mistakes live.
Start with what each service actually hands you, because the differences change how you parse the file.
| Source | File you download | Money column | Units column | Currency |
|---|---|---|---|---|
| DistroKid | Tab-separated .tsv from “See Excruciating Detail” (CSV on request) | Earnings | Quantity | USD |
| TuneCore | Monthly sales report CSV | Total Earned | Not itemised per line | USD |
| CD Baby | Tab-delimited text (.txt) you paste into a sheet | Payable | QTY | USD |
DistroKid’s detailed export is genuinely tab-separated despite everyone calling it a CSV, and it itemises a Quantity against each line, so you can separate streams from downloads (you can request a CSV instead). TuneCore’s monthly sales report is built around stores and money — Sales Period, Posted Date, Store Name, Country of Sale, Net Sales, Exchange Rate, Total Earned, Currency — with no per-line stream count, so if you need unit counts the earnings CSV alone won’t give them to you. CD Baby hands you a tab-delimited text file with QTY, Unit and Payable columns. All three account in USD, but CD Baby converts to your local currency at payout when your bank sits outside the US, so the deposit won’t equal the statement — a wrinkle that belongs in reconciliation, not in the parse.
Sources: DistroKid Help Center · TuneCore Support · CD Baby Help Center
Even if the formats matched, the dates would not. Streaming platforms report to distributors roughly 45 to 60 days after a month closes, so a January stream typically lands in your distributor statement around March — a lag no distributor can remove, because it starts upstream at the DSP. Performance royalties are slower and run on quarterly cycles: BMI pays domestic performances around five to six months after the quarter they fall in, ASCAP roughly six to nine. The MLC, which collects US mechanicals, is different again — it issues statements and payments about 75 days after each usage month, so January usage is paid in mid-to-late April.
A single calendar quarter of your music being played is therefore scattered across statements that arrive months apart, from bodies that number their periods differently. That is why you cannot just stack the files: normalise to a usage period (when the play happened), not the posted date (when you were told about it), or your year-on-year comparisons are nonsense.
Sources: The MLC — payment timeline · ASCAP — payment · BMI Royalty Policy Manual
This is the error that quietly corrupts more merged catalogues than any other. Move a release between distributors — or re-upload the same master — without carrying the original ISRC across, and the new distributor mints a fresh one. The recording is identical, but every downstream system now treats it as two tracks. Earnings split across the two identifiers, and no report anywhere shows the combined figure. A song looks like it underperformed when its income was simply cut in half across two rows.
There is no fully automatic fix, because the identifiers genuinely differ. Keep a master list mapping every alternate ISRC (and UPC) for a recording to a single canonical track, then group on the canonical ID rather than the raw ISRC. Audio fingerprinting can flag suspected duplicates, but a human still confirms the mapping — merging two tracks that only look the same is its own kind of error.
Source: Curve Royalty Systems — Managing Duplicate ISRC Codes
The target is one flat table where every line, whatever its origin, carries the same six fields. Dashboards, per-song totals and tax summaries all build on top of it.
period — the usage month, not the posted date · store — Spotify, Apple, YouTube, a PRO, the MLC · territory — country of sale where reported · track — canonical track ID, with alternate ISRCs mapped to it · units — streams or downloads where available · amount — the payable figure, in one reporting currency.
Mapping each source into those columns is mostly renaming, with a few judgement calls:
| Common field | DistroKid | TuneCore | CD Baby |
|---|---|---|---|
| period | Sale Month | Sales Period | Sale month |
| store | Store | Store Name | Partner / store |
| territory | Country of Sale | Country of Sale | Often absent |
| track | Title + ISRC | Song Title | Track + ISRC |
| units | Quantity | — | QTY |
| amount | Earnings (USD) | Total Earned (USD) | Payable (USD) |
The gaps matter as much as the mappings. TuneCore’s standard export has no per-line unit count, so its units stays blank rather than being faked. CD Baby often omits territory, so don’t invent one. And any non-USD figure — a PRO payment, an overseas society — is converted at a documented rate before it sits in the same amount column as the rest; record the rate you used, because you will be asked.
A merged spreadsheet isn’t finished until its total agrees with reality, and on the first pass it almost never matches a single deposit — which is expected. The sum of your amount columns is a gross-ish accrual; a bank deposit is a net payout over a different window. Build a bridge for each source:
Opening balance + earnings accrued this period − amounts held below the payout threshold − FX and payout fees − withholding (US tax withheld from non-US payees; songwriter shares held back) = amount actually deposited.
Work source by source, period by period, and the residual after each bridge should be zero or a small, explainable rounding difference. When it isn’t, you’ve found something real — a missing statement, a duplicated line, an FX rate applied twice, a store that paid into a period you hadn’t imported. That tie-out is the point: it turns “roughly this much came in” into a figure you can put in front of an accountant, a co-writer or a buyer.
This is what the free Perpendis royalty converter automates. Drop your DistroKid, TuneCore and CD Baby files — plus PRO and MLC statements — into the browser; it normalises them to the schema above, links alternate ISRCs, and outputs one reconciled Excel earnings tape (Summary, Tie-Out, By Period, By DSP, Top Tracks and the underlying line items) plus a clean CSV. Everything is parsed locally in your browser — the files are never uploaded to a server. To see a single source first, the platform pages walk through DistroKid, TuneCore and CD Baby individually, and how to read a royalty statement covers the field-by-field basics.
A note on limits. Exact column headers drift as DistroKid, TuneCore and CD Baby revise their exports, so treat the mappings above as a durable pattern rather than a frozen spec, and sanity-check against your own latest download. ISRC de-duplication can’t be fully automatic — a tool can flag likely duplicates, but confirming that two identifiers really are the same recording is a human decision. And reconciliation only ever ties to the statements you actually have; a missing period will balance to itself and still be wrong.
You can, but the total will mislead. The columns don’t align, the periods are numbered differently, the bank deposits differ from the statements once payout FX and fees are applied, and any song sitting under two ISRCs is double-counted as two tracks. Normalise to a common schema and de-duplicate first, then sum.
A statement reports what you accrued in a usage period; a deposit is a net payout over a different window — after minimum-payout thresholds, FX and payout fees, and any tax or songwriter withholding. Build a per-source bridge from opening balance to deposit, and the leftover should be zero or a small rounding difference.
Bring them into the same schema, but map each line to its real usage period, not the pay date — your PRO pays five to nine months in arrears and the MLC about 75 days after each usage month. Tag every line with its store (PRO, MLC) so you can separate recording income from publishing income when you need to.
Drop your DistroKid, TuneCore and CD Baby files into the free converter and get one clean, reconciled earnings tape in a single session — parsed locally, never uploaded. For a whole catalogue, multiple entities or investor-grade diligence, we’ll do it for you.