RevRule by Payload, problem guide

The totals add up. The money still went to the wrong people.

Spreadsheet reconciliation checks that outputs sum to inputs. Split errors pass that check perfectly, because the money all goes somewhere. Here are the failure modes that actually cost labels, publishers, distributors, and agencies money and trust.

Try the free sandbox RevRule overview and pricing

The failure modes

Five places spreadsheet reconciliation breaks

Overwritten rates

A renegotiated split replaces the old number in the cell. History is gone, and everything already computed under the old rate is now unverifiable. The $414.11 version of this error.

Side-tab balances

Recoupment lives in a separate tab updated from memory. One busy month and the balance, the clearing point, and the post-recoupment rate all drift. How recoupment should compute.

Wrong-column formulas

A formula copied across a row points at a neighboring participant's rate. The row total is still right. Three artists are underpaid and two are overpaid until someone recomputes a line by hand.

Source mixing

Distributor, direct, licensing, and sync income land in different sheets with different rates and cadences. Consolidation day is copy-and-paste day, and each paste is a chance to apply the wrong deal to the wrong revenue.

No audit trail

The output is a number per participant with no record of the events, rules, or intermediate steps behind it. The first detailed question from a participant turns into a reconstruction project.

One-person dependency

The sheet encodes one person's memory of every deal. When that person is away, the quarter waits. When they leave, the knowledge leaves with them.

The check that catches it

Recompute lines, not totals

Synthetic demonstration, fictional figures

In a published synthetic fixture run on the RevRule engine, a fictional label quarter (40 tracks, 5,000 statement lines, $219,518.20 synthetic gross) produced 21,000 entitlement entries in a hash-chained ledger. A random sample of 25 entries was recomputed independently: 25 of 25 matched the recorded amount, and every sampled entry carried its event id, rule id, participant id, and a written reason. A separate re-implementation of the rule math reproduced every participant total on every graph with a maximum difference of zero. That is the standard a reconciliation should be held to: any line, recomputed from the deal terms, matches. Synthetic data; not a customer result.

You can apply the same test to a spreadsheet today: pick ten paid lines at random and recompute them from the signed deal terms, by hand, without looking at the sheet's formulas. If all ten match, your process is healthier than most. If any line cannot be recomputed because the rate history or the balance history is missing, the process has the audit-trail failure, even if the numbers happen to be right this quarter.

How RevRule handles it

Rules and state, kept by the engine

RevRule replaces the spreadsheet's memory with defined rules. Each deal is a Revenue Graph: participants, splits, recoupment terms, and effective-dated rule versions. Revenue events are recorded as money arrives, each event is computed under the rules in force on its date, balances are engine state rather than side tabs, and every computation lands in a hash-chained ledger that can be queried by event, participant, or entry type and returned in full as JSON for your own systems.

Simulation previews a run with zero side effects before it counts. RevRule does not hold funds, execute payments, or collect royalties. It establishes what is owed under your rules and keeps the evidence, alongside whatever payment process you already use.

Get a free API key Integration reference Buy for $99 or start a managed plan

Pricing: $99 one-time perpetual license (uncapped operations, unlimited Revenue Graphs, 1 API key), or managed plans at $29, $79, and $199 per month with higher operation, graph, and key allowances. Evaluation accounts are limited to 1,000 operations per month and 3 Revenue Graphs. Seven-day refunds. Support by email, best effort.

Questions

Reconciliation, answered plainly

What are the most common spreadsheet royalty errors?

The recurring ones: a renegotiated split applied from the wrong date because the old rate was overwritten; a recoupment balance in a side tab that was not updated; a formula copied across a row that points at the wrong participant's column; a territory or format included at the wrong rate; and rounding handled inconsistently between the summary and the detail. None of them announce themselves, because the totals still add up.

Why do spreadsheet royalty errors survive checking?

Because reconciliation usually checks that the outputs sum to the input, and split errors conserve the total. The money all goes somewhere; it just goes to the wrong participant. Catching that requires recomputing individual lines from the deal terms, which is exactly the step manual processes skip under time pressure.

When should royalty accounting move out of a spreadsheet?

When any of these become normal: multiple participants per item with different splits, mid-period deal changes, recoupment balances across periods, more than one revenue source feeding the same participants, or a participant asking how a specific line was computed. Those are rule and state problems, and they are what a rules engine is for.