Building a creator payout process that survives an audit
When finance asks how a creator payment was calculated eight months later, the answer must be reproducible. The data and records that make it so.
Creator payoutsPublished · 3 min read
Eight months after a campaign, someone in finance asks why a creator was paid $2,340. The campaign manager has left. The spreadsheet has been edited. The video's view count has moved. If the answer depends on anyone's memory, you have a problem — and if creator payments are a material line, an auditor will eventually ask.
An auditable process is not bureaucracy. It is four properties.
Property 1 — the number is reproducible
Reproducible means: given the stored record, anyone can recompute the same amount without access to a live counter or a person.
That requires storing the inputs, not just the output:
- which payout rule applied, with its parameters (rate, threshold, cap),
- the metric value used, and the exact timestamp of the reading it came from,
- the resulting amount, and any cap that bound it.
A row that says "CPM payout: $2,340" is not reproducible. A row that says "CPM $6.00 per 1,000 · 390,000 views read 2026-03-31T00:04Z · uncapped · $2,340" is.
Property 2 — the metric is frozen at settlement
Public view counts keep climbing. If your system recalculates from a live counter every time someone opens the payout screen, the historical amount changes, and reconciliation against what was actually paid becomes impossible.
The fix is a settlement date written into the agreement and enforced in the system: the reading taken at settlement is stored on the payout record and never re-read. Later readings continue for reporting, but they do not touch a settled payment.
Property 3 — the calculation is deterministic
Integer arithmetic, explicit rounding, no floating-point currency. Two rules that prevent most reconciliation pain:
- Store amounts in minor units (cents), computed with integer maths. Rounding halfway through a CPM calculation on floats produces amounts that differ by a cent between runs and systems.
- Apply caps explicitly and record them. "Would have been $1,800; capped at $1,200" is a materially different fact from "$1,200", and the difference matters when a creator asks.
The same discipline makes a recalculation safe: running the payout job twice must produce the same numbers, or the job is not a calculation but a lottery.
Property 4 — approvals and status are recorded
A payout moves through states: calculated → approved → paid, or failed. Each transition needs a timestamp and an actor. This is what lets you answer "who authorised this" and "why is this creator unpaid" without archaeology.
Keep failures visible rather than silently retrying. A transfer that failed six weeks ago because of a bad payout account is a creator who has not been paid — and they will remember it far longer than the campaign.
The record, in one table
| Field | Why it exists |
|---|---|
| Campaign, creator, video | Scope of the payment |
| Rule type and parameters | What was promised |
| Metric value + reading timestamp | The input, frozen |
| Computed amount, cap applied | The output and its constraint |
| Status and status timestamps | Approval and payment trail |
| Payment provider reference | Reconciliation against the bank |
Where processes usually break
- Screenshots as evidence. Unverifiable, editable, and gone when the post is deleted. Readings taken by a system with a timestamp survive.
- Manual spreadsheets. Every recalculation is a fresh chance to use a different window. The formula lives in someone's head, and leaves with them.
- No cap policy. A per-view rule without caps eventually produces a payment nobody budgeted for and finance refuses to release, which damages the creator relationship far more than a cap ever would.
- Deleted videos. If a creator removes a post before settlement, the public counter is gone. Your stored history is the only remaining evidence of what it earned — another reason to track continuously rather than measure once at the end.
What good looks like day to day
The campaign manager selects a campaign, runs a payout calculation, and sees a line per creator with the rule, the inputs and the amount. They approve. Payments execute and record their references. Nothing recalculates afterwards.
That is the whole process. It is unremarkable when it works — which is the point. ViewTracker's payout runs follow this shape: rules are applied to tracked view history with integer arithmetic and explicit caps, each payout stores the calculation that produced it, and settled runs do not silently change when the underlying videos keep earning.
Frequently asked questions
- What does an auditable creator payout record contain?
- The rule applied, the input metric and where it was read, the timestamp of the reading, the computed amount, any caps applied, who approved it and when, and the payment reference. Enough to reproduce the number without asking anyone.
- Should payouts be recalculated if views change after settlement?
- No. That is the purpose of a settlement date. The reading taken on the settlement date is final, and the record stores that reading — not a live counter that keeps moving.
- How long should payout records be kept?
- As long as your tax and contractual obligations require, which is usually several years. The tracking snapshots behind them should be kept for the same period, because without the readings the calculation cannot be reproduced.