Worked exampleRevenue operations

Three revenue numbers, three different questions

A signed agreement, an issued invoice and a received payment are different events. This worked example proposes a reporting model that keeps those differences visible and lets finance trace a number back to its source.

Worked example. This is a proposed solution for a fictional operating scenario, not a client engagement. No measured results are claimed.

By Ops AutomatorsUpdated September 7, 2026Get the practical worksheet

Conceptual editorial illustration. The workflow below describes a proposed solution.

The problem: Leadership receives conflicting figures because reports combine different events, dates and customer identifiers.
The approach: Keep bookings, invoice activity and cash receipts in separate datasets joined through an approved customer and contract crosswalk.
Intended outcome: The intended benefit is a report whose differences can be explained. This isn't an accounting policy or a verified reporting engagement.

Example system roles CRM opportunities · invoice ledger · payment records · reporting store

Agree the question before building the chart

Assume a SaaS business has a CRM bookings report, a billing export and a payments report. A weekly meeting calls each of them revenue. They disagree because a contract can be signed this month, invoiced next month and paid later.

Finance defines the reporting terms. In this example, bookings represent accepted contractual commitments under the business's policy; billings represent issued invoice activity; cash receipts represent recorded payments. Recognized revenue requires a separate accounting policy and is outside this design.

Use separate facts and a shared identity

Create a bookings dataset keyed by contract or opportunity version, an invoice dataset keyed by invoice ID and a payment dataset keyed by payment ID. Preserve each source's status and effective date. Join through customer and contract mappings that finance can review.

Do not join invoice lines directly to every payment line and then sum the result. That can multiply amounts when an invoice has several lines and several payments. Aggregate at the intended reporting grain first, or use an explicit allocation bridge.

A missing mapping enters a reconciliation queue. Excluding unmatched records silently may make the chart look tidy while removing actual activity from the business view.

Connect the revenue operations record model ↗

Proposed workflow

Keep the three ledgers separate

Extract source facts
Bookings, invoice activity and receipts retain their own IDs.
Integration owner
Resolve identity
Map customer and contract references explicitly.
Finance + RevOps
Reconcile totals
Compare by period, currency and reporting grain.
Finance analyst
Publish with context
Show definitions, freshness and exceptions.
Report owner

Exception & recovery

Missing mappings remain in a visible exception total. Failed extraction marks the affected source stale; it does not produce a new zero.

Proposed reporting model. Shared identity connects events without making them the same measure. Download the diagram (SVG)

A small fictional example shows the difference

Suppose a fictional contract is signed for 12,000 USD, an initial invoice is issued for 3,000 USD and the customer pays 2,000 USD against that invoice. Those figures answer different questions. The remaining invoice balance is 1,000 USD before any adjustments; the unbilled contract portion is not overdue cash.

These are teaching inputs, not Ops Automators results. They don't determine revenue recognition, tax or the treatment of amendments. The finance owner must specify those policies.

A credit, refund or cancellation should retain its source event and link to the affected record. Rewriting a historical total without retaining the adjustment makes prior reports impossible to explain.

Freshness belongs beside the number

Store source_updated_at, ingested_at and the last successful extraction watermark. A report should say when each source was current. If billing extraction fails, show the stale state instead of presenting yesterday's value as today's reconciliation.

Schedule a reconciliation that compares source control totals to the reporting store by period and currency. Investigate unmatched records, changed statuses and adjustments separately. The report owner approves corrections; the integration owner repairs extraction errors.

Pilot with one period that includes a partial payment, a credit and an amended agreement. Finance should be able to trace each figure to the underlying records and reproduce the calculation.

Use the report to explain a discrepancy before adding more charts. If the organization hasn't agreed what a booking means, a new dashboard will simply repeat the disagreement more neatly.

Keep this part

Fictional reconciliation example

Preserve the event, the date and the definition behind each number.

Example rules and teaching inputs. Adapt them to your process.
Measure	Teaching input	What it answers
Contract commitment	12,000 USD	What was agreed under the bookings policy?
Issued invoice	3,000 USD	What has been billed?
Applied payment	2,000 USD	What payment has been recorded?
Unpaid invoice balance	3,000 − 2,000 = 1,000 USD	What remains on this invoice before adjustments?
Unbilled contract portion	12,000 − 3,000 = 9,000 USD	What part of this example contract is not yet invoiced?

Use the example to agree the rules, then fill in the blank sheet with your own records and owners. Downloads are free; no email required.

Blank worksheet (CSV)Populated example (CSV)Editable brief (Markdown)

Evidence & limits

How to evaluate the proposal

Validate report completeness against dated source totals and document every definition. Track unresolved reconciliation differences and time to explain them. Do not describe improved visibility as attributable revenue.

All amounts in the table are fictional teaching inputs in one currency.
Revenue recognition and accounting policy require the finance team's own determination.
A reporting store adds extraction and reconciliation ownership. A reviewed export may be enough for an infrequent report.

Sources & implementation context

Stripe: payout reconciliation report
Explains settlement batches and balances; a payout is not the same as a sale or an invoice.

The design decisions and worksheets are original worked-example material. Vendor documentation supports specific platform behavior, not a claim that this implementation has been delivered.

How this page was prepared

AI assisted the research, drafting and conceptual artwork, helping compare source material and turn the workflow into a reusable worksheet. The scenario is fictional and the design is a proposal. The stated sources and limitations define the evidence available. No independent expert review or client result is implied.

About the team commissioning this collection

Continue with the useful detail