Order-to-Cash, Deep

Order-to-Cash is the named beachhead in this charter. The job description starts you on O2C before Record-to-Report, so you should be able to draw the whole flow from memory and say which system owns each stage and where the hand-offs leak.

O2C is the path a dollar travels from the moment a customer wants to buy to the moment the cash is reconciled in the bank and recognized in the books. At Cursor, where pricing is consumption-heavy, the metering and rating stages in the middle carry more weight than they do in a flat-subscription business.

Here is the canonical lifecycle. Walk it left to right when an interviewer hands you a whiteboard.

1. 1Lead / opportunity (CRM). A prospect becomes a tracked deal in the CRM (Salesforce-class). Owns the commercial intent: who, how much, expected close.
2. 2Quote / CPQ. Configure-price-quote turns intent into priced line items: products, tiers, discounts, ramps, commitments. This is where commercial terms first become structured data.
3. 3Order / contract. The signed order is the legal commitment. It creates the contract and subscription records that everything downstream references.
4. 4Provisioning & entitlement. The product grants access and writes entitlements - the seats, usage caps and feature flags the customer is allowed to consume.
5. 5Usage metering. The product emits usage events (requests, tokens, compute) into a metering pipeline. For a consumption business this stage is the revenue engine.
6. 6Rating / invoicing. Metered usage is priced against the contract and rolled into an invoice for the period: base fees, usage charges, overages, true-ups.
7. 7Payment. The customer pays via card, ACH or wire through a payment processor.
8. 8Cash application. The payment is matched to the invoice it settles, including partials and overpayments.
9. 9Collections / dunning. Unpaid invoices trigger reminders, retries and escalation until they are paid or written off.

Two things flow through this pipe in opposite directions and saying so out loud is a fast way to show you think in systems.

System of record per stagename the owner, not just the box

Every stage has one system that is authoritative and the integrations between owners are where defects and revenue leakage concentrate. A vague answer names boxes. A senior answer names the system of record and the hand-off contract between each pair.

Bookings, billings, revenue, cash: four clocks, not onethe distinction juniors blur

These four numbers describe the same deal at different moments and they move on different timelines. Confusing them is the fastest way to lose credibility with a finance interviewer.

The data model is where the lifecycle becomes something you can build. Get the spine right - contract, subscription, entitlement, usage, invoice, payment - and modifications, true-ups and reconciliation fall out cleanly. Get it wrong and you will be patching one-off configuration for years.

Start with the contract as the spine. Everything downstream references it and it has to survive change without losing history.

Contract and subscription: versioned, never overwrittenthe spine

A subscription that gets upgraded mid-term, co-termed with another product or amended on price is not a single mutable row. It is a sequence of versions. You model line items as versioned so you can answer "what were the terms on March 14" for an auditor without reconstructing it from memory.

Entitlements: the gate between contract and productwhere the deal becomes enforceable

Entitlements translate the contract into what the product is allowed to grant: seats, usage caps, feature access, included credits. They are the join between commercial terms and runtime enforcement and they feed the overage logic. If the contract says "500K requests included, then $X per 1K," the entitlement is what the product and the rater both read.

Usage events: append-only, idempotent, replayablethe high-volume stream

Usage is the highest-volume table in a consumption business and the one most likely to corrupt revenue if you get it wrong. Three properties are non-negotiable.

-- raw usage: append-only, dedup on event_id
CREATE TABLE usage_event (
  event_id     text PRIMARY KEY,        -- idempotency key from the producer
  account_id   text NOT NULL,
  meter        text NOT NULL,           -- e.g. 'requests', 'input_tokens'
  quantity     numeric NOT NULL,
  occurred_at  timestamptz NOT NULL,    -- when it happened (for the usage period)
  received_at  timestamptz NOT NULL,    -- when we ingested it (for late-arrival)
  contract_id  text NOT NULL
);

-- a duplicate delivery is a no-op, not a double charge
INSERT INTO usage_event (...) VALUES (...)
ON CONFLICT (event_id) DO NOTHING;

Invoices and cash applicationwhere money meets the ledger

Invoices and their line items link back to the order, the usage period and the revenue treatment so every charge is traceable. Cash application is the inverse: it links a payment to the invoice it settles. Real life is messier than one-payment-one-invoice.

Cursor's own pricing is consumption-heavy, which makes usage-based billing the single most relevant domain in this loop. If you can design the path from a raw token event to a correct invoice line - and defend the corrections after a period closes - you are speaking directly to the work.

The metering pipeline is the assembly line. Each step has a failure mode and the interviewer will probe the seams.

1. 1Capture. The product emits a usage event per billable action - a request, input/output tokens, a compute-second - tagged with account, meter and a unique id.
2. 2Deduplicate. Drop replays on the event id so retries and at-least-once delivery cannot inflate usage.
3. 3Aggregate. Roll raw events into period totals per account and meter. High-volume streams get pre-aggregated to keep rating tractable.
4. 4Rate. Apply the pricing model to the aggregate: tiers, included credits, overage rates, minimums. This produces the priced charge.
5. 5Invoice. Assemble rated charges into invoice lines for the period and post them to billing.

Pricing constructs you must be able to modelthe vocabulary of consumption deals

Enterprise consumption contracts stack several of these at once. Know what each one means for the rater and the revenue treatment.

Idempotency and late-arriving eventsthe corrections problem

Two failure modes cause most consumption-billing pain. Double-billing comes from re-ingesting the same event and you defend against it with the unique event id and dedup. Late-arriving events are subtler: a usage event with an occurred_at inside a period that arrives after you have already invoiced or closed that period.

You cannot rewrite a closed invoice. You issue a correction.

Reconciliation across the three views of usageraw vs rated vs invoiced

Usage exists in three forms and they must agree. Raw is what the product emitted, rated is what the pricing engine charged and invoiced is what actually hit the customer's bill. Drift between any two is revenue leakage or an overcharge and you want an automated job that alerts on it rather than discovering it in an audit.

O2C is a distributed system that happens to move money. The hard part is not any single service, it is keeping billing, the payment processor, the revenue subledger and the GL consistent when the network is flaky and services retry. The patterns below are the ones a finance-systems engineer is expected to reach for by name.

Idempotency and exactly-once effectthe foundation under everything

Across the billing, payment and ERP boundaries you assume at-least-once delivery and make every operation safe to retry. An idempotency key on each request lets the receiver recognize a replay and return the original result instead of charging twice. You cannot get exactly-once delivery over a network, so you engineer exactly-once effect at the receiver.

# Same idempotency_key on a retry returns the original charge,
# it does not create a second one.
stripe.PaymentIntent.create(
    amount=invoice.amount_due,
    currency="usd",
    customer=invoice.customer_id,
    idempotency_key=f"invoice:{invoice.id}:attempt",  # stable per invoice
)

Eventual consistency and reconciliation as the safety nettrust, then verify

Distributed financial state is eventually consistent: for a window, billing thinks one thing and the GL thinks another. Reconciliation jobs are how you make that safe. They re-derive each system's view from a common source and assert they match, so a missed webhook or a half-applied payment surfaces as an alert within hours instead of an audit finding months later.

Failure handling that preserves controlsDLQ, replay, manual correction

Events will fail to process. The question is whether a failure quietly drops a dollar or lands somewhere recoverable. In finance, manual correction is legitimate, but it must keep segregation of duties and leave evidence.

• Dead-letter queue. When an event exhausts its retries, route it to a DLQ for isolation and alerting - never drop it. A DLQ that is filling up is a P1 because it is unrecognized revenue or unapplied cash.
• Replay. Because raw events are append-only and idempotent, you can re-run processing over a window once the bug is fixed and the idempotency keys prevent the replay from double-counting.
• Manual-correction workflow. When a human must intervene, do it through a tracked workflow with maker-checker approval and an immutable record of who changed what and why - not a direct edit to a production table.

Choosing the integration style per hopwebhooks vs batch vs CDC

There is no single right transport. You pick per system based on latency needs, volume and what the source can emit.

Interviewers test depth by asking where O2C breaks, because naming failure modes proves you have lived through them. Each one below maps to a stage you just walked and each has a detection mechanism you should be able to name in the same breath.

The translation gap, in detailthe one that catches CPQ teams

Sales and Legal can write any term they can imagine into a contract. The billing engine can only enforce the constructs it actually supports. When a quote promises a pricing structure the rater cannot model - a bespoke tier curve, a cross-product discount, a custom true-up cadence - someone ends up hand-billing it in a spreadsheet and that is exactly where leakage and audit findings breed.

Why period close is where it all comes duethe deadline that makes everything urgent

Close is the moment the four clocks have to agree for a period. Late usage, a mid-period upgrade, a missed webhook, an unapplied payment - any of them surfaces here under a deadline. The mature posture is to expect lateness and design for it rather than to pretend the period is truly frozen.

• Accrue for known-late usage. If you know events routinely arrive a few days late, estimate and accrue rather than under-stating revenue, then true up to actuals.
• Correct forward. A modification or late event after close is booked in the current period via credit memo or true-up; you do not reopen closed books.
• Make reconciliation a pre-close gate. The raw-to-rated-to-invoiced and cash-application checks should be green before you close, not discovered after.

Knowing the lifecycle is half the charter. The other half is doing the work fast, and a finance team running this exact pipeline at Cursor uses the editor in two distinct modes. Mode one is AI-as-analyst: a throwaway investigation you run once. Mode two is AI-as-builder: a durable tool the team uses every day. The same surface, two different jobs.

Mode one: drop a Slack thread into a fresh agentthe billing investigation that took a day

A finance teammate flagged a self-serve account with ten stacked unpaid invoices - the product should have blocked the account after the first non-payment, and didn't. The whole investigation was one move: open a new agent, paste the raw Slack thread, hit go. Nothing else. With the GitHub repo open and Databricks, Slack and Notion wired in over MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs., the agent reasoned across every system, built its own to-do list, and worked the problem end to end.

1. 1Paste the raw thread. Open a fresh agent and drop the unedited Slack thread in as the prompt. No cleanup, no framing.
2. 2Let it discover the code. The agent searches the repo live and locates the exact function that should have gated the account after the first unpaid invoice. You don't need to know the codebase yourself.
3. 3Validate against the customer. It checks the failure against that specific account in the warehouse, confirming the bug reproduced for them.
4. 4Quantify the blast radiusHow much breaks if a change goes wrong; the scope of potential damage.. It summarizes every impacted team - open invoice counts, total exposure, and the top ten customers by open value.
5. 5Propose the fix and file it. It drafts the code fix and a Linear bug report so eng can pick it up.

Mode one, deeper: a structured prompt for processing-cost analysisinterchange-plus, in one chat

The same mode handles heavier analysis. Cursor's self-service volume runs roughly $200M/month through Stripe on interchange-plus (IC+) pricing, which passes through the underlying card-network and issuing-bank costs with a markup. That gives full visibility into the real cost of each transaction, unlike a blended sticker rate like 2.9% + 30c. The analytical leverage is in the prompt structure, not in any one clever question.

• Persona. Open with who's asking and what decision the analysis feeds, so the output lands at the right altitude.
• Data. Point at the tables: the auths history, the balance-transaction file, and per-transaction cost data - card, card type, country, interchange and scheme fees. If the financial warehouse is wired in, Cursor queries it directly instead of needing files.
• Optimization categories. Name the specific levers to investigate - notably L2/L3 data-quality eligibility, where US transactions can qualify for cheaper interchange when you pass the right metadata.

Mode two: the contract-provisioning queueclosed-won to provisioned, on a cron

Enterprise provisioning used to be fully manual. Someone ran a daily closed-won report from Salesforce, hand-copied data between spreadsheets, downloaded each order form, validated it against Salesforce, then Slacked "ready to provision." It cost one to three hours a day, it was error-prone, and it did not survive 10x growth. Deal volume went from about 100 a month to 700-800 a month. The team replaced the whole thing with a built application.