An OFM agency monthly reporting workflow turns creator and agency operations into a traceable report. The report must reconcile source data and lead to approved actions.
Here, OFM means creator management operations, not a government office. A run is complete only when another person can reproduce it. That person must be able to trace the numbers, exceptions, decisions, delivery, and archived version.
This is an operational workflow. It is not a universal rule for accounting, tax, law, employment, or finance.
No authenticated platform account was tested for this guide. Exact export fields and platform behavior therefore remain unverified. Your agency must inspect its own accounts.
A polished dashboard is not proof of completion. Before a metric can support a decision, it needs six things.
Define the metric and its source. Set its period and owner. Record its completeness and reconciliation status.
What must be ready before the monthly close starts?
Start only when the period, scope, owners, source access, baseline, audience, and approval path are fixed. Pause collection when a material metric is undefined, an account identity is disputed, access is unsafe, or no one owns recovery.
Use a run header with a run ID and period start. Add the exclusive period end and reporting timezone.
Define the creator and account scope. Record the source cutoff, owner, reviewer, and approver.
Add the delivery date, report version, and reopen rule. Keep passwords and payment credentials out of reporting artifacts. Also exclude message bodies and personal data that the report does not need.
Assign distinct roles where practical. The reporting owner controls the close.
Source owners confirm extracts. Metric owners approve definitions.
An operator prepares the dataset. A narrative owner drafts decisions.
An approver accepts the version. A delivery owner confirms receipt. An independent verifier performs readback.
Choose the starting branch before work begins. A first report needs a clean baseline.
A recurring run needs the last approved version. A migration needs the legacy report. It also needs an old-to-new mapping and rollback point.
Metric dictionary: define the words before the numbers
A metric dictionary should record the metric name and decision use. State its formula and grain.
Name the numerator and denominator. List all inclusions and exclusions.
Define the timestamp basis, period, and currency. Record the source, owner, and confidence state. A label alone is not a definition.
| Metric | Operational definition | Required distinction |
|---|---|---|
| Gross creator sales | Completed in-scope customer sales before defined reversals and deductions | Not payout, cash received, or agency revenue |
| Net creator sales | Gross creator sales less declared discounts, refunds, chargebacks, and other sale reversals | State every deduction; do not silently subtract fees or costs |
| Platform net earnings | Platform-reported or reconstructed amount after platform-level deductions and adjustments | Separate official displayed totals from reconstructed totals |
| Cash payout | Settled cash reaching the designated bank or wallet in the period | Payout timing can differ from sale timing |
| Agency revenue | Amount earned by the agency under signed agreements and its adopted accounting policy | Never assume it equals creator gross sales |
| Conversion rate | A named qualifying outcome divided by a named eligible population | State the denominator, window, identity unit, and deduplication rule |
These are operational definitions. They are not universal accounting definitions.
Principal-versus-agent presentation depends on contracts and facts. So does gross-versus-net presentation. Both may require professional judgment.
For conversion, never report one generic rate. A visitor-to-paid rate uses eligible unique visitors.
A click-to-paid rate uses valid tracked clicks. A lead-to-paid rate uses qualified, deduplicated leads.
A chat-to-paid rate uses eligible conversations. Changing the denominator changes the metric.
Source-of-truth map
Give each metric one controlling source and one documented fallback. Record the creator ID and account ID. Name the source object or report.
Define the date field, timezone, and currency. Record the extraction method and time. Add the owner, control total, and fallback.
Use the OFM agency operations hub for the broader operating context. Use OFM analytics tools to select a measurement system.
See the OFM revenue attribution methodology for deeper attribution logic. This reporting page controls the close. It does not own full tool selection or attribution methods.
1. Open the run and lock the reporting contract
Action: Create one run record for the creator or portfolio. Lock the period and timezone.
Define the scope, audience, and owners. Set the close calendar and source cutoff. Record the materiality rule, delivery target, version, and reopen conditions.
Expected result: One run ID controls every extract and exception. It also controls each approval and delivered version.
Every contributor uses the same month boundary. Everyone also uses the same creator and account roster.
Failure signal: Teams use different dates, an approver is missing, or a scheduled report can change after approval without a reopen event.
Recovery: Stop collection and select the canonical run. Reconcile its scope and dates.
Assign missing roles. Retain earlier work as an unapproved draft.
Verification: A second person reads the header. That person must identify the same period, timezone, and scope. The owners, deadline, audience, version, and reopen rule must also match.
Close calendar
| Gate | Owner | Evidence required |
|---|---|---|
| Scope lock | Reporting owner | Approved run header and account roster |
| Source cutoff | Source owners | Extract timestamps and completeness checks |
| Reconciliation | Metric owners | Control totals and exception queue |
| Narrative review | Decision owners | Evidence-linked variance notes and actions |
| Approval | Approver | Versioned approval record |
| Delivery and archive | Delivery owner | Receipt, access check, and immutable reference |
Do not prescribe one universal close duration. Set dates from source availability and review capacity.
Account for delivery commitments. Allow time to resolve material exceptions.
2. Map identities, metrics, and source ownership
Action: Build a crosswalk for each canonical creator and managed account. Map every source key and required metric. Add the source owner, extraction method, and fallback.
Expected result: Every required metric has one canonical creator and account key. It has one declared controlling source and one responsible owner. Unmatched rows stay in quarantine, not in a report total.
Failure signal: Display names act as identifiers. One account maps to two creators.
Unknown historical accounts appear, or a required source has no owner.
Recovery: Quarantine unmatched records. Confirm canonical IDs with the responsible owner.
Merge only through a controlled change. Record unavailable sources as exceptions.
Verification: Join samples from every source to the crosswalk and require zero unexplained creator/account mismatches before aggregation.
The crosswalk should contain the canonical creator ID and account ID. Add the source system, source key, and display name.
Record the scope, owner, and mapping status. Name the verifier and verification time. Do not store login secrets in it.
3. Freeze definitions and extract source data with lineage
Action: Version the metric contract. Then collect source data through a manual export, connector, API, or mixed branch.
Preserve raw inputs. Record filters, timezone, and currency.
Add the extraction time, row count, and control total. Name the query version and collector.
Expected result: A dated source inventory can reproduce every reported value. It does not overwrite prior evidence. Raw files remain separate from transformed datasets.
Failure signal: An export is stale or partial. A connector refresh time is unknown.
Pagination is unchecked. A manual copy loses filters. Or transformed data replaces the raw input.
Recovery: Retain the failed extract. Diagnose access, filters, freshness, and pagination.
Switch to the approved fallback. Label incomplete coverage. Document the input state before the rerun.
Verification: Compare row counts and totals with a native source view or approved control total. Trace each sample report value to a preserved extract and metric-contract version.
Manual exports need saved filters and stable filenames. They also need immutable raw copies, timestamps, and row counts.
Connector or API pulls need object IDs and query versions. They also need pagination tests, refresh timestamps, retries, and completeness checks.
Mixed sources can coexist, but they must remain separate until normalization. A successful connector job proves execution, not completeness.
4. Normalize period, identity, currency, and event grain
Action: Transform copies of raw data into the metric contract. Standardize canonical IDs and timestamps.
Set month boundaries and currency labels. Define the conversion basis and event grain. Standardize null handling, signs, and duplicate rules.
Expected result: One derived dataset uses consistent keys and period logic while every transformed field remains traceable to raw evidence.
Failure signal: Events shift across the month. Duplicate rows inflate totals.
Currency units are absent. Nulls become zeros. Or creator totals do not equal account rollups.
Recovery: Isolate affected records. Correct the transformation rule, not individual outputs.
Rebuild from raw inputs. Version the rule. Retest upstream and downstream totals.
Verification: Run uniqueness, null, boundary, currency-label, sign, and rollup checks. Explain every dropped, merged, converted, or shifted record.
Use an inclusive start and exclusive end. First convert timestamps to the declared reporting timezone.
Preserve the original timestamp. Keep activity, sale, settlement, payout, and invoice dates distinct.
5. Reconcile totals and manage exceptions
Action: Compare source controls with normalized totals. Check creator and account rollups.
Review platform earnings, payouts, and prior-period continuity. Open an exception for every difference above the approved threshold.
Expected result: Every material difference is resolved. Otherwise, it remains a quantified, owned, and approved exception. Missing data is never silently converted to zero.
Failure signal: Rollups do not tie. Native and connector totals disagree.
Late records alter a closed period, or a definition change appears as operating performance.
Recovery: Contain the affected metric and classify the cause. Return to identity, definition, extraction, or normalization.
Rerun the affected path. Preserve both the original and corrected states.
Verification: The queue shows the metric and three totals: source, normalized, and reported. It shows the difference, cause class, and severity.
It also records the owner, status, retest, and closure evidence. An unresolved critical item blocks approval.
Use the core reconciliation equation:
control total - reconciled detail total = unreconciled difference
Do not force the residual into fees, refunds, revenue, or rounding. A zero residual does not prove that category mapping is correct. Offsetting errors can still exist.
For a sales bridge, show gross creator sales - discounts - refunds - chargebacks - other sale reversals = net creator sales. Reconcile platform earnings and cash payouts separately because they represent different stages.
Exceptions and restatement log
Record the report version and affected metric. Keep the original and corrected values.
State the reason, source, and decision impact. Record the owner, approver, affected recipients, and notification status. Never silently edit an archived report.
Late or missing data should make a metric provisional or blocked. State coverage, assign a recheck date, and use an estimate only when an approved method exists and the estimate is visibly labeled.
6. Analyze variances and create the action register
Action: Compare only compatible periods and definitions. Separate observed change from changes in source, coverage, or definition.
Also isolate timing, currency, and attribution changes. Then convert material findings into decisions.
Expected result: Each material variance has a bounded explanation. It has an evidence class and confidence state.
It names an owner and an action or explicit no-action decision. It also has a due date and observable completion test.
Failure signal: The narrative asserts causation from correlation. Changed definitions look like performance.
Actions lack owners. Or the report repeats numbers without a decision.
Recovery: Rewrite the narrative as an observed fact plus a bounded explanation. Disclose comparability limits.
Assign or reject an action explicitly. Move unresolved causation to investigation.
Verification: A reviewer traces every material statement to reconciled metrics or an operational record and identifies the owner, due date, and completion evidence.
The action register should include the finding, decision, and action. Name the owner, due date, and dependency.
Add the expected observable result, status, and closure evidence. The register does not promise ROI. It does not guarantee that an action will improve revenue.
Use explicit evidence labels in working notes:
public fact: supported public documentationvendor claim: untested provider statementseditorial assessment: this workflow’s operating rulesmissing/unverified: facts that require account, contract, invoice, or internal evidence
7. Build and approve the audience-specific report
Action: Build the internal operating pack first. Then derive the creator-facing version through an approved disclosure map.
Review the figures, definitions, and exceptions. Check the narrative, actions, access, and version.
Expected result: Each audience receives the metrics and decisions it may see. Restricted staff, security, cross-creator, and unneeded personal data stay hidden.
Failure signal: Internal notes leak. Two views show conflicting values.
An editor changes numbers outside the controlled dataset. Or approval lacks a version ID.
Recovery: Contain distribution. Correct the owning dataset or disclosure rule.
Regenerate every affected view. Rerun reconciliation. Obtain fresh approval.
Verification: Compare visible values with the approved dataset, test role-level access, confirm material caveats appear, and record approver, version, status, and time.
The internal pack can include source quality and exception details. It can also show workflow owners and operating actions.
The creator-facing version should use agreed metrics and plain definitions. It should state material caveats and actions. It must exclude restricted operational detail.
Aggregate a portfolio only after creator-level reconciliation. Prevent one creator or account from appearing in multiple rollups.
8. Deliver, archive, verify, and control restatements
Action: Deliver the approved version through an authorized channel. Confirm access.
Archive an immutable package and carry actions forward. Close or reopen the run under the declared rule.
Expected result: Recipients can access the approved report. The agency can reproduce it later.
Open actions persist. Corrections create traceable versions.
Failure signal: Delivery cannot be confirmed. The wrong recipient has access.
The archive lacks source links, or a late correction overwrites the approved report.
Recovery: Contain incorrect access. Restore the approved snapshot.
Open a restatement case and fix the upstream cause. Regenerate and reapprove the report. Then notify affected recipients when required.
Verification: Check the delivery log and role access. Check the archive checksum or stable reference.
Action carry-forward, approval, and close status must pass. An independent verifier reproduces one sample metric. The trace starts at archived input and runs through transformation to the report.
The final close gate records pass, fail, or not applicable. It covers identity, definitions, completeness, and reconciliation.
It also covers narrative, action ownership, and audience access. Finally, it checks approval, delivery, archive, and reopen controls. A successful email send or dashboard load is not enough.
Migration branch for an existing report or tool
Migrate through a controlled parallel run. Preserve the last approved legacy report.
List its sources and recipients. Map old fields and definitions to new ones. Classify each difference as expected, defective, missing, or unresolved.
Run old and new methods across a representative close cycle. Do not assume a universal duration.
Approve cutover only after all required tests pass. Test completeness, comparability, access, delivery, archive, and rollback.
If no usable legacy export exists, document the evidence gap. Preserve available approved reports.
Establish a clean baseline. Do not claim historical comparability. Decommission the old route only after retrieval and rollback are demonstrated.
Frequently Asked Questions
What should an OFM agency include in a monthly report?
Include declared scope, metric definitions, source and period status, reconciled creator/account metrics, material variances, caveats, decisions, owners, and next actions. Keep internal controls separate from the creator-facing view.
What is the difference between a monthly reporting workflow and a template?
The workflow controls how data is defined, collected, reconciled, approved, delivered, and restated; a template only structures the output. A good layout cannot repair weak lineage or unresolved totals.
Which data sources should feed the report?
Use only sources required by declared metrics and controls. Common categories include canonical creator/account records, platform transactions, CRM or chat events, content logs, cost records, contracts, invoices, and bank or payout evidence.
How do you reconcile different numbers across systems?
Align identity, period, timezone, formula, event date, currency, filters, attribution, and duplicate handling before selecting a controlling value. Keep unresolved differences in the exception queue.
How should late or missing monthly data be handled?
Mark the metric provisional or blocked, quantify coverage, assign a recheck owner and date, and do not treat missing data as zero. Restate a closed report only through its approved reopen rule.
Should every creator receive the same monthly report?
Use one controlled metric system, but tailor each creator-facing view to agreed scope and access. Do not expose cross-creator, staff, security, or unnecessary personal data.
Who should approve an OFM monthly report?
Name one accountable approver with authority over the reporting scope. Keep the preparer, source owners, metric owners, delivery owner, and independent verifier distinct where practical.
Is an OFM monthly report an accounting or tax report?
No; this workflow governs operational reporting and does not replace accounting, tax, legal, payroll, contract, or financial advice. Qualified professionals and authoritative source systems must resolve those matters.