Search "convert royalty statement to Excel" and you are pointed at generic PDF- and CSV-to-Excel converters that know nothing about music. They flatten the statement's structure, round the tiny per-stream amounts that make up most of a catalogue's income, and turn long barcodes into scientific notation, leaving a tidy-looking sheet you still cannot total by DSP or reconcile. Here is what actually goes wrong, and what a music-aware conversion produces instead.
You export the statement from your distributor, open the CSV or PDF, and something is off. The headline payout was, say, £3,412.88, but the rows will not add up to it; the artist names have sprouted odd symbols; and a column that should hold a release barcode now reads 9.79E+11. That is the usual result of converting a royalty statement to Excel with a general-purpose tool: the file looks like a spreadsheet, but the numbers underneath have already been altered on the way in.
Music earnings statements are not ordinary tabular data. They carry very small numbers to many decimal places, long numeric identifiers that are not really numbers, non-ASCII text, and a nested shape — period × store × territory × track. Generic converters are built for none of that, and they fail in four specific, repeatable ways.
These are not exotic edge cases. They happen on the first open, usually with no warning, and once the file is saved they are hard to undo.
| What a music statement holds | What a generic converter does | What it costs you |
|---|---|---|
| High-precision line earnings, e.g. 0.002642885330 | Stores to 2 decimals, or as a binary float | Totals drift by pounds across thousands of rows; the tie-out fails |
| 12–14 digit UPC / EAN / GTIN, longer catalogue IDs | Displays 9.79E+11, drops leading zeros, zeroes any digit past the 15th | The code no longer validates; you cannot group by release |
| Accented artist & track names (é, ñ, ü, ö) | Reads UTF-8 bytes as Windows-1252 → é | Names garble; they no longer match your catalogue |
| Nested period / DSP / territory structure | Flattens to one undifferentiated grid | No by-DSP, by-period or by-territory totals |
A statement from DistroKid, TuneCore, CD Baby or the MLC is really several reports stacked together: earnings per sale month, per store, per territory, per ISRC. The MLC alone issues two layouts — a work summary with one line per DSP per work, and a royalty detail with a line for every reported usage — both as tab-separated files. A generic converter has no concept of any of this. It reads the delimiter, drops every row into one flat grid, and discards the grouping that answered the only questions that matter: how much came from each DSP, in each period, from each track.
Source: The MLC — What do the different statement layouts mean?
This is the expensive one. Streaming has no fixed per-stream rate: a service pays out a share of a revenue pool, which lands at very roughly £0.002–£0.004 a stream on the larger platforms, and far less on ad-supported tiers or in lower-income territories. So the atomic unit of a music statement is a fraction of a penny, reported to six, nine, sometimes twelve decimal places. A converter that keeps only two decimals turns those micro-amounts into 0.00. And one that keeps them as ordinary numbers hands them to Excel's binary floating-point engine, which cannot store most decimal fractions exactly and lets tiny errors compound as you sum thousands of rows.
Source: Royalty Exchange — How streaming platforms calculate payouts per stream
A UPC is 12 digits, an EAN 13, a GTIN 14. Excel treats every one as a number, and two things go wrong. Any code of 12 or more digits is displayed in scientific notation, so a barcode shows up as 9.79E+11. And a code that begins with a zero silently loses it: 012345678905 becomes an 11-digit number that no longer validates. Longer identifiers fare worse. Excel keeps only 15 significant digits, so from the 16th digit on the value is permanently rewritten to zero, and reformatting the cell afterwards will not bring the original back. Once any of that happens, you can no longer join a track to its release.
Source: Microsoft Support — Keeping leading zeros and large numbers
Statements are full of names such as Beyoncé, Rosalía, Sigur Rós and Änglagård. When a file saved as UTF-8 is opened as Windows-1252 (Excel's default on Windows), those characters turn into mojibake: é for é, ñ for ñ. The earnings may survive, but the labels you match, split and report on do not.
Source: DataLion — How to fix mojibake in your data
A single floored micro-amount looks like nothing, and that is the trap. Take one real per-stream line of £0.002642885330. Rounded to two decimals it is £0.00. But a catalogue is tens of thousands of such lines, and the drift is the sum of every one you dropped.
Excel stores numbers as binary floating point per IEEE 754, and most decimal fractions have no exact binary form — it keeps 0.1 with a tiny built-in error. Add such values repeatedly and those errors accumulate: sum 0.0001 ten thousand times in Excel and you get 0.999999999999996, not 1. Invisible on screen, fatal to an equality check. A correct conversion does its arithmetic in exact decimal (fixed-point) form, so a sum of a hundred thousand micro-amounts is exact, not merely close.
Source: Microsoft — Floating-point arithmetic may give inaccurate results in Excel
Converting a royalty statement to Excel properly is not "open the CSV". It is: recognise the source format, map every column onto one normalised schema, keep every value as exact text or exact decimal, then rebuild the structure the flat file threw away. The output is not a single blob but a small workbook — an earnings tape — where each tab answers a real question and the numbers are guaranteed to agree.
| Tab | What it holds |
|---|---|
| Summary | Net earnings, period covered, count of DSPs, territories and line items |
| Tie-Out | Sum of line items vs. the statement's stated total, and the difference (should be 0.00) |
| By Period | Net by reporting / sale month |
| By DSP | Net by store: Spotify, Apple Music, Amazon, YouTube, and the rest |
| Top Tracks | Net by ISRC and title, ranked |
| Line items | Every normalised row: date, store, country, ISRC, UPC, quantity, gross, net |
The tie-out is the part a generic converter can never give you, because it depends on understanding what the total is meant to be. It re-sums every line item in exact decimal and compares the result to the figure the distributor printed. If they match to the penny, you can trust every split and tax calculation built on the file. If they do not, the difference tells you precisely how much precision the pipeline lost — the same £105.72-shaped hole a rounded import leaves behind. For the anatomy of these fields, our guide on how to read a royalty statement walks through them column by column.
Earnings statements are commercially sensitive: they reveal your income, your splits and your catalogue's performance. Our free royalty converter parses the file entirely in your browser using local JavaScript. The contents are read, normalised and reconciled on your own machine and never sent to a server, so nothing about your earnings leaves your laptop. Drop in the DistroKid TSV, TuneCore or CD Baby CSV, or a publisher or MLC export, and download the reconciled Excel tape and a normalised CSV — without uploading anything.
A conversion is only ever as complete as the file you give it. Because streaming pays a share of a pool rather than a fixed rate, the tie-out reconciles line items against the statement's own stated total — not against a per-stream rate you can recompute from first principles. Currency conversion introduces its own rounding; splits, advances and recoupments are frequently handled outside the statement entirely; and a distributor can change its export layout without notice. When a format is unusual or brand-new, we may still need a sample to map the columns correctly — and for messy multi-source catalogues, matching identity across statements is genuine work, not a one-click job.
For a quick glance, yes. The trouble is that Excel applies its own rules on the way in — 15 significant digits, scientific notation past 12 digits, Windows-1252 decoding — so long IDs and micro-amounts are altered before you ever see them, and reformatting the cells afterwards will not restore what was lost. If you only ever read the file, that may be fine. If you total, split or reconcile it, the quiet edits become real errors.
The headline figure is usually right; what you cannot see from it is how it was built. A tie-out proves the individual line items actually sum to that total, and the by-DSP and by-period views show where the money came from. That is what you need for accurate co-writer splits, for tax, and for any catalogue diligence — and it is the first thing that breaks when a naive import drops precision.
With this one, yes, because there is no upload: the parsing happens locally in your browser and the file's contents never reach a server. That is a deliberate design choice for exactly this kind of sensitive data. If a converter asks you to upload the file in order to process it, treat your income data accordingly.
Turn a messy DistroKid, TuneCore, CD Baby, ASCAP or MLC statement into one clean, reconciled Excel earnings tape — Summary, Tie-Out, By Period, By DSP and Top Tracks — parsed locally, with a tie-out that proves the totals. It is free, and nothing is uploaded. For a multi-source catalogue that needs custom reconciliation or diligence, we do that as done-for-you work.