OnlyFans Earnings Tracker Template: Record Gross, Fees and Payouts

This OnlyFans Earnings Tracker is a creator operations record. It answers: what did the chosen platform statement show, what changed between its components, and which payout records were later matched? It does not forecast income, track expenses, calculate profit or tell a creator what they should earn.

Keep performance calculations elsewhere. The PPV break-even calculator tests a bounded offer assumption, while this tracker preserves reported statement and payout evidence after activity occurs.

Choose the statement as the source of truth

Start with the creator's current platform statement or earnings report, not a remembered dashboard total. Record the source screen, export name or file ID, selected dates, account currency, statement generation time and capture owner.

Copy labels exactly because platform terminology and available fields can change. If the live interface says gross earnings, creator earnings, pending balance or available balance, store that label beside the value. Do not rename different fields into one generic “revenue” column.

A screenshot can support a row, but a dated export or platform record is easier to trace when available. Store evidence under the creator's existing access rules. The tracker needs a locator, not fan-level purchase details.

Define the period and currency boundary

Every row needs a start date, end date, time zone if known, currency and period status. Mark a period complete only when the platform has finished processing it according to the creator's normal review rule.

Do not combine currencies in one numeric total. If an account or transfer record exposes more than one currency, keep separate rows and preserve the original amounts. Currency conversion belongs in another workflow using a named rate and date.

Partial or overlapping statement periods should remain visible. A custom five-day check can help resolve a discrepancy, but it cannot be compared casually with a calendar week. Include the coverage rule so a later reviewer understands why the row exists.

Map the statement components before doing arithmetic

Create a field map for the account: displayed label, plain meaning, sign convention, source location and whether the amount is gross, deducted, pending or available. This prevents a fee from being added twice or an available balance from being mistaken for a period total.

Use the platform's displayed relationship when it is clear. When it is not, preserve the components and mark the bridge unresolved. A tracker should surface uncertainty rather than make the columns balance by adding a vague adjustment.

If the platform revises a statement, add a new capture version with the revision time. Keep the earlier value connected to any decision already made. Silent replacement breaks the evidence chain between the original review and the later correction.

Copy the Statement Reconciliation Row

Use one row per selected statement period with these fields:

• Identity: row ID, account alias, period, source label, source timestamp and currency.
• Statement values: gross displayed amount, fee amount, adjustments, pending amount and available amount, only when those fields exist.
• Bridge: expected relationship, calculated difference, difference status and reviewer note.
• Evidence: export or screenshot locator, capture owner, version and quality state.
• Handoff: payout status, payout IDs, unresolved question, owner and next check date.

Use null states such as field not shown, not captured, processing and not applicable. A true zero should be entered only when the source displays or clearly supports zero. This distinction stops missing data from producing false balances.

Reconcile gross, fees and available amounts

Write the expected relationship in words before applying a formula. For example: gross displayed amount minus the separately displayed platform fee, plus or minus named adjustments, should connect to the period's creator amount when those fields share the same scope.

Then calculate a difference using the source values. If it is zero within the source's displayed precision, mark reconciled. If not, mark open and list possible evidence gaps rather than choosing a cause. Pending transactions, refunds, timing boundaries or differently scoped fields can all affect the bridge.

Do not compare a lifetime dashboard total with a weekly statement or a pending balance with a completed-period amount. Matching names are not enough; period, scope, state and currency must also match.

Create a separate Payout Match

A Payout Match connects one platform payout record to one or more eligible statement rows. Record payout ID, request date, processing date, displayed amount, currency, platform status, external receipt date, external reference and match state.

Use match states such as unmatched, partially matched, matched, returned, cancelled and investigation needed. Several statement periods may fund one payout, or one period may be covered by several payouts. Use a small allocation table instead of hiding this many-to-many relationship in a comment.

Match by documented identifiers and amounts, not timing alone. A transfer arriving near the expected date can still belong to another request. If the external record uses a different descriptor, note it and preserve both references.

Open a discrepancy queue instead of guessing

Every unexplained difference gets a discrepancy ID, affected row, amount, currency, first observed date, current evidence, missing evidence, owner, next action and status. Keep questions narrow enough to resolve.

Examples include a payout status that changed without a matched receipt, a statement revision after capture, or components that use different date boundaries. Avoid labels such as “platform error” until the supporting evidence establishes that conclusion.

Set a review cadence for open items and record each contact or evidence update. Close the item with a resolution category and link to the corrected row version. Do not delete the original discrepancy merely because the final totals now match.

Review a bounded worked example

Imagine a completed statement period displays gross activity, a separately labelled platform fee and a creator amount. The copied fields reconcile at the displayed precision, but the amount remains pending. The row is statement reconciled and payout not yet eligible; it is not fully closed.

Later, the creator requests a payout that combines that period with part of the next one. The Payout Match allocates the displayed transfer amount across both statement rows and preserves the payout ID. Each allocation can be checked without changing the original statement values.

If the external receipt differs, the queue records the difference and missing evidence. The tracker does not invent a conversion, fee or timing explanation. It remains open until a source supports the resolution.

Keep operating effort separate from earnings records

A creator may want to compare earnings evidence with the content or promotion work completed during the same period. Keep those inputs linked but separate. The content library coverage calculator measures usable asset coverage, not earnings.

Likewise, the promotion time-budget calculator allocates available working time. Linking its period ID can provide context, but dividing earnings by incomplete time records can create a misleading efficiency figure.

Only add a derived measure when its question, numerator, denominator, period and decision owner are defined. The base tracker should remain readable even when no derived analysis is performed.

Run a monthly quality check

Select a sample of statement rows and trace every displayed value to its source. Confirm dates, currency, sign, label and source version. Then trace matched payouts to their platform record and external receipt reference.

Check for duplicate imports, overwritten revisions, zeros standing in for missing values and payouts linked by date alone. Resolve access problems before the evidence becomes difficult to retrieve.

Archive completed months without flattening the row history. A durable tracker keeps the original captures, later revisions and discrepancy resolutions connected. It should be possible to reconstruct what the creator knew at each review point.

Separate statement close from payout close

A statement row can be internally reconciled before its value becomes available for transfer. Mark statement reconciliation and payout matching as two different gates. This prevents an accurate platform period from remaining falsely “open” merely because its transfer has not arrived.

Conversely, an external receipt does not prove every statement component was classified correctly. Close the Payout Match when identifiers and allocated amounts agree, then keep any unrelated statement discrepancy open under its own ID. Independent statuses make the tracker easier to audit and stop one resolved step from hiding another unanswered question.

Limitations and sources

Limitations: this template depends on the fields, timing and precision available in the creator's own platform and payout records. A matched amount does not explain performance, predict future earnings or replace a full bookkeeping system. Platform labels and payout processes can change, so verify the live source before each capture.

OnlyFans publishes its current platform terms, including the platform relationship among fan payments, creator earnings, fees and payouts. Google Analytics and GOV.UK measurement guidance also emphasise scope and evidence limitations across reports. The Statement Reconciliation Row, Payout Match and discrepancy queue are original SirenCY editorial artifacts designed for narrow creator operations.