Revenue Recognition & R2R

Order-to-Cash moves money. Record-to-Report decides what that money means on the income statement and the rulebook is ASC 606The US revenue-recognition standard; cited as the canonical judgment-heavy accounting work to keep human-led rather than hand to an agent, because facts and circumstances vary deal to deal..

For this role the domain screen will probe whether you actually understand recognition mechanics or just bill correctly and hope the GL sorts itself out. Cursor sells a usage-heavy product where cash and revenue diverge constantly, so the five-step model is not trivia. It is the contract you implement in code and configuration every day.

1. 1Identify the contract. A real, approved agreement with enforceable rights, commercial substance and a probable collection. An order in CPQ becomes a contract when both sides commit, which is the event your O2C pipeline has to capture cleanly.
2. 2Identify the performance obligations. The distinct promises inside the contract - the subscription, a usage entitlement, onboarding services, a discounted add-on. Each distinct obligation gets recognized on its own pattern.
3. 3Determine the transaction price. The total consideration you expect to be entitled to, including discounts, credits and any variable amount such as usage above a commitment.
4. 4Allocate the transaction price. Spread that total across the obligations by their standalone selling price (SSP), so a bundled discount lands proportionally rather than all on one line.
5. 5Recognize revenue. Book revenue as each obligation is satisfied - over time for a subscription, point-in-time for a one-off or in line with metered consumption for usage.

Allocating with SSPwhere bundles get interesting

SSP is the price you would charge for an item sold on its own. When a deal bundles a platform subscription with discounted onboarding, you do not honor the line-item prices on the quote. You allocate the total contract price across obligations in proportion to their standalone values, which can move revenue between lines.

Modifications, upgrades and co-termingcontracts rarely sit still

Mid-term changes are the part candidates fumble. The treatment depends on whether the change adds distinct goods or services at their SSP or alters the existing arrangement.

Co-terming, where a mid-year upsell is aligned to expire with the original contract, usually falls into the prospective bucket: you reset the schedule for the combined remaining term. Get the classification wrong and the timing of recognized revenue is wrong, which is exactly the kind of error an auditor catches.

Why legacy ERPs break on SaaSthe one-to-many problem

Older ERP revenue logic assumes one invoice produces one revenue event. SaaS violates that on the first deal. A single annual invoice spawns twelve monthly recognition entries, an upgrade splits a schedule mid-stream and a usage line generates a recognition pattern that does not match any invoice at all.

Cursor's own pricing is consumption-heavy, which makes usage-based revenue the single most relevant accounting topic for this seat.

Subscription revenue is the easy case: equal slices over time. Usage breaks the tidiness because the amount is not known until customers consume and the standard has specific machinery for amounts you cannot yet pin down.

Variable consideration and the constraintestimate, but only so far

Variable consideration is any part of the price that depends on a future outcome - overage above a commitment, volume tiers, service credits. ASC 606The US revenue-recognition standard; cited as the canonical judgment-heavy accounting work to keep human-led rather than hand to an agent, because facts and circumstances vary deal to deal. says you estimate it, then apply the constraint: you only include an estimate to the extent it is probable a significant reversal will not occur once the uncertainty resolves.

That expedient is why most metered usage is straightforward to recognize. The complications arrive the moment a customer prepays.

Prepaid credits and commitmentsdeferred revenue with a meter

A committed-spend deal - customer promises $600k over the year, drawing it down by usage - combines both worlds. The commitment is recognized as it is consumed and any minimum that goes unused at period end is a true-up you have to book.

True-ups and breakagethe unused portion

• True-up: when actual usage exceeds a committed minimum, you bill and recognize the overage for the period it occurred.
• Breakage: the portion of prepaid credits a customer is not expected to use. You estimate it and recognize it in proportion to the pattern of actual redemptions, rather than waiting for expiry.
• Re-estimation: breakage is an estimate that you revisit each period as redemption behavior becomes clearer, which can move recognized revenue up or down.

From rated event to recognized revenuethe audit trail that has to survive

The piece that separates a finance systems engineer from an accountant is owning the data path. Every rated usage event has to map to a recognition entry that an auditor can trace back to the metered fact.

1. 1Metering captures the raw consumption event with a timestamp, customer and quantity.
2. 2Rating applies the price book to produce a dollar amount and a rated-event id.
3. 3Recognition ties that rated amount to the contract, draws down any prepaid balance and writes a revenue schedule line for the period.
4. 4Reconciliation confirms that rated usage, drawn-down deferred revenue and recognized revenue tie out for every contract.

The single most important architectural call in R2R is where the revenue subledger lives and what it owns.

Billing knows how to charge. The GL knows balances. Neither is built to carry contract-level revenue logic - SSP allocations, deferral schedules, modification true-ups. The subledger is the system in between that does.

The three-layer picturebilling → subledger → GL

The subledger holds detail the GL is deliberately too coarse to track: every obligation, its schedule, its deferred balance and the history of any modification. It posts summarized journal entries up to the GL - a single deferred-revenue and recognized-revenue movement per period - while retaining the line-level traceability an auditor will ask for.

Build vs. buythe judgment they're testing

This role explicitly tests when to write code versus configure a platform. Native rev-rec inside a billing tool is enough for some businesses and a liability for others.

The close is where systems either earn their keep or bury the team in manual reconciliation for a week every month.

A finance systems engineer is judged on how short, repeatable and defensible the close is. The goal is a close that runs on rails and still gives an auditor everything they need.

The close sequencein order, every period

1. 1Subledger cutoff. Freeze the period - usage events after the cutoff belong to next month or get accrued.
2. 2Accruals. Book amounts earned but not yet invoiced, including late-arriving usage.
3. 3Reconciliations. Tie subledger to billing, deferred-revenue roll-forward, cash to bank, intercompany balances.
4. 4Journal posting. Push summarized subledger entries into the GL.
5. 5Consolidation. Roll up entities, translate currencies, eliminate intercompany.
6. 6Reporting. Produce management and statutory reports plus the flux explanations leadership reads.

Multi-entity and multi-currencywhat scaling to global looks like

A company heading toward multi-billion ARR will carry several legal entities and currencies. Consolidation rolls those entities into one set of financials and a NetSuite OneWorld-class capability handles the mechanics: currency translation at the right rates and elimination of transactions between your own entities.

Automating the closewhere the time goes

Shortening the close comes from automating the two slowest steps: reconciliations and flux analysis. Reconciliations that auto-match and flag only exceptions turn a day of tie-outs into a review of the handful that didn't match. Automated flux compares this period to last and to budget, surfacing the variances worth a human explanation.

Roll-forwards finance lives bythe four that come up constantly

Controls in an automated closespeed without losing the audit

• Evidence by default: every automated journal carries the inputs, the rule version and a timestamp, so the run is its own audit trail.
• Segregation of duties: the person who configures a recognition rule is not the person who approves the posting, enforced in the system.
• Exception review: automation handles the clean cases and routes only mismatches to a human, who signs off on record.
• Change management: rule changes go through review and are versioned, so an auditor can see what logic produced any past close.

Trusting the data you close onproducers, consumers and a contract

A close is only as defensible as the data feeding it, and that data is owned by other teams. The mental model Cursor's finance team uses is data producers versus data consumers: finance is a consumer; the analytics, engineering and partner teams upstream are producers. Ownership becomes workable when you negotiate an explicit data contract with those producers - and back it with snapshots and diffs as the data changes.

The technical screen will hand you finance data and watch you reconcile it in SQL - this is where engineering and accounting meet on the keyboard.

Reconciliation queries are the load-bearing skill. They prove the deferred-revenue roll-forward holds, that usage ties to revenue and that no rows fell through a join. Strong candidates write queries that are also controls: they return zero rows when the books are clean and the exact offenders when they aren't.

Deferred-revenue roll-forwardthe identity, in SQL

with movements as (
  select
    contract_id,
    period_month,
    sum(billed_amount)      as billings,
    sum(recognized_amount)  as recognized
  from revenue_schedule_line
  group by contract_id, period_month
),
rolled as (
  select
    contract_id,
    period_month,
    billings,
    recognized,
    -- opening = prior period's closing, via running balance
    coalesce(sum(billings - recognized)
      over (partition by contract_id
            order by period_month
            rows between unbounded preceding and 1 preceding), 0) as opening_deferred
  from movements
)
select
  contract_id,
  period_month,
  opening_deferred,
  billings,
  recognized,
  opening_deferred + billings - recognized as closing_deferred
from rolled
order by contract_id, period_month;

Three-way reconciliation with drift detectionusage → invoiced → recognized

The query finance trusts is the one that finds the breaks itself. Join the three views by contract and period, then return only the rows where the amounts don't agree within tolerance.

select
  u.contract_id,
  u.period_month,
  u.rated_usage,
  i.invoiced,
  r.recognized,
  i.invoiced  - u.rated_usage  as bill_drift,
  r.recognized - i.invoiced    as recog_drift
from usage_rated   u
left join invoiced_amt i
  on i.contract_id = u.contract_id and i.period_month = u.period_month
left join recognized_amt r
  on r.contract_id = u.contract_id and r.period_month = u.period_month
where abs(coalesce(i.invoiced, 0)   - u.rated_usage)  > 0.01
   or abs(coalesce(r.recognized, 0) - coalesce(i.invoiced, 0)) > 0.01
order by abs(i.invoiced - u.rated_usage) desc;

Tracing a break through upstream lineagethe row drifts; where did it come from?

Finding a break is half the work. Explaining it means walking the data lineage. A rev-rec booking table rarely sits alone - at Cursor it lands downstream of five or six upstream tables plus the jobs that run between them. When a discrepancy shows up in the rev-rec table, the question is which upstream table introduced it and which change did so.

This is where an agent earns its keep on a deep monolith. Point Cursor at the discrepancy and it can trace the reconciliation issue back to the furthest upstream table: inspecting which tables feed which, which jobs produce which outputs, whether a snapshot existed at the time and which PRs changed how those tables are built - walking the whole history rather than guessing.

Bridges leadership readsexplaining the movement

Bookings, billings, revenue and cash never equal each other in a given period and explaining the gaps is half the job. A bridge query walks from one to the next so finance leadership sees what drove the difference.

Data-quality controlsthe breaks that corrupt the close

Performance on high-volume usagebillions of metered events

• Partition by period: range-partition usage tables on event date so a monthly reconciliation prunes to one partition instead of scanning history.
• Pre-aggregate: roll raw events into a rated-by-contract-and-period summary table the close queries hit, leaving the firehose untouched.
• Incremental over full-refresh: recompute only the open period plus a short late-arrival window, not the entire fact table every run.
• Push filters down: filter on the partition key before joining, so the planner never materializes the full cross-product.