The feeling I want to talk about isn't the moment you find an error. It's the quieter one underneath all the months where you didn't. You pulled the reports, updated the sheet, generated the statements, sent the payments, and on paper everything looks fine. And still, if someone asked you — right now, no warning — to swear the numbers you sent last quarter were correct, you'd hesitate. You might add a word like basically. You'd promise yourself that one of these months you really should sit down and go through it properly.
It doesn't wake you up at night. It just sits there, in the back of your head, every time you close the spreadsheet.
If that's where you are, I want to say something I think almost nobody says out loud: that feeling is not neurosis and it is not a character flaw. It's the most common emotional state in indie publishing accounting, and the reason it feels like yours alone is that nobody admits to it at a conference. Voice it out loud and half of it already starts to dissolve. The other half, we can work on.
The doubt is rational, not paranoid
Here's what's actually happening. A spreadsheet has no integrity check. There's no receipt at the end that says verified. There's no second system comparing your totals to a source of truth and flagging the mismatches. You are the entire audit trail, from the download folder to the bank transfer, and some part of you knows that, which is exactly why the uncertainty lingers. The doubt is your professional instincts working correctly on a system that has no built-in verification.
Once you see it that way, the anxiety stops being a referendum on you. It's a signal about the architecture. And it's the same anxiety a royalty holder would feel if they could see how their statement got made — which is its own separate problem, and one I'll come back to in a post soon. For today, let's stay with the part that's yours.
Where the doubt actually comes from
Vague doubt is the worst kind. Specific doubt is fixable. Almost every unease I've had about my own royalty numbers — and that I've heard from other publishers — traces back to one of three things.
A data entry error that went downstream and stayed there. You typed 1,249.00 when the report said 1,429.00. Three months ago, a Tuesday, you were tired, and nothing broke. The total still looked plausible. Every statement since has quietly inherited that $180 error, and the sheet can't tell you, because the sheet has no memory of what the source report said. Only going back to the original report will surface it.
Mismatched time periods masquerading as a quarter. You pulled KDP on the 7th and ACX on the 22nd and, because both happened "this month," you filed both under March. But the KDP report you downloaded in March is mostly January earnings on a 60-day delay, and ACX is on its own schedule. Your "Q1 total" is a bag of three or four different time slices glued together and called one thing. The number isn't wrong in any cell. The label on it is — which is almost worse, because nothing in the sheet will ever flag it.
Rounding and currency drift compounding line by line. You round GBP to two decimals, convert at yesterday's rate because that's what you had open, round again on the way out. One line, that's fine. Three hundred lines across a year, it isn't. The drift on any single row is too small to catch; the drift on the full year is large enough to matter. You only ever notice it if you go looking.
The audit protocol
Here's the thing that took me too long to learn: you don't audit the whole system. You can't. It's too big, and by the time you're done the business has moved. What you do instead is audit one thread, end to end, and you let that one thread either hold or not hold. The protocol takes an hour the first time, closer to twenty minutes after that.
1. Pick one title, one distributor, one quarter. Smallest possible trace. Don't pick your biggest earner or your most confusing distributor — pick something boring. The goal is to prove the chain, not to stress-test it.
2. Go back to the original downloaded report. The actual CSV or XLSX you pulled that quarter, untouched. Not the dashboard, not a summary cell in your sheet, not a number you remember typing in. The source file.
3. Trace one number, hop by hop. Source report → the row in your spreadsheet → the monthly total → the quarterly total → the statement line → the payment you sent. At each hop, write the number down. Do they match?
4. Mark the breakpoint, if there is one. If every hop matches, you now know — with a certainty you didn't have an hour ago — that for this title, at this distributor, for this quarter, your chain holds. One confirmed yes is worth a thousand vague reassurances. If a hop doesn't match, you know the exact stage it breaks — not "somewhere in the spreadsheet," but between these two specific steps. That's something you can fix.
5. Do one more thread before you generalise. Different title, or different distributor, or different quarter. Two confirmations is enough to trust the process. Two failures is enough to know it isn't a one-off.
That's the whole audit. It's tedious. It also only needs to happen once to change what you know about your own books. The outcome is either grounded confidence — not vibes, not "I think it's fine" — or specific clarity about where the leak is. Both beat the doubt.
What the audit can't fix
I want to be honest about the limits, because if you run this and everything passes, you might still feel the anxiety again in two months, and I don't want you to think the protocol failed. It didn't.
The audit catches traceability failures on the thread you audited. It doesn't catch errors you haven't introduced yet, it doesn't catch drift you haven't thought to look for, and it doesn't scale — you can't reasonably audit every title at every distributor every quarter, and if you try to, you'll stop. It's a spot-check, not a system. If your audit holds, keep your rhythm and run the check again next quarter. If it doesn't hold, the real question isn't "how do I fix this one thread." It's "what would a system with traceability built into it actually look like?"
How Royaltally handles this part
I built Royaltally because I lived with this exact doubt for years, audited my own sheets the way I just described, and got tired of knowing that a confirmed thread today said nothing about a confirmed thread next quarter.
Numbers flow directly from the parsed distributor report into the calculations. There's no manual entry step where a wrong digit can enter. Every line on a statement traces back to the source row in the original report, with the currency conversion rate and date recorded against it. The doubt doesn't have anywhere to hide, because there's no intermediate stage where it could have entered. (Currency drift specifically — the third source of doubt above — gets its own post in a couple of weeks, because it's the place traceability saves you the most money.)
As of this week, Royaltally is in beta. If the feeling in this post is one that's been sitting with you, this is the week you can actually try the thing. You can track up to 3 titles free, no credit card, with your own reports. Come take a look.
And if you'd rather run the audit yourself and stay with the sheet — that's a completely reasonable choice. The protocol above is genuinely useful whether you ever touch Royaltally or not.
You've got this
The doubt you've been carrying was rational. It was your instincts telling you, correctly, that a system without verification hasn't been verified. Running an audit — on your own sheet, or inside a tool — doesn't make you paranoid. It's the only thing that converts vague anxiety into a specific answer, which is the only thing anxiety is ever actually asking for.
You don't need perfect numbers. You need numbers you can trace. A working system has nothing to hide, and by the end of this week, you can know whether yours is one.
You're not bad at this. You're not behind. And next quarter, when you send those statements out, you're going to send them knowing.