1 min lesson
Tracing a break through upstream lineage
Tell someone how to act on this idea: "Explaining it means walking the data lineage."
Step 1 of 2
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.
Cursor's finance team described doing exactly this on a live reconciliation break.
We're actually able to trace back the reconciliation issues all the way back to the furthest upstream table using Cursor.
Learn more
Full explanation
Bridges leadership reads
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.
- From → To
- Bookings → Billings
- What the gap is
- Signed but not yet invoiced
- Common driver
- Future-dated or milestone billing
- From → To
- Billings → Revenue
- What the gap is
- Invoiced but not yet earned
- Common driver
- Deferred revenue on prepaid terms
- From → To
- Revenue → Cash
- What the gap is
- Earned but not yet collected
- Common driver
- Net-30 terms, AR aging
| From → To | What the gap is | Common driver |
|---|---|---|
| Bookings → Billings | Signed but not yet invoiced | Future-dated or milestone billing |
| Billings → Revenue | Invoiced but not yet earned | Deferred revenue on prepaid terms |
| Revenue → Cash | Earned but not yet collected | Net-30 terms, AR aging |
Each bridge is a query that attributes the delta to named, explainable buckets.
Learn more
Full explanation
Data-quality controls
Data-quality controlsthe breaks that corrupt the close
Rated usage with no matching contract or entitlement.
Anti-join usage against active contracts.
Means revenue can't be attributed.
An invoice exists but no revenue schedule was created.
Anti-join invoices against schedule lines.
Means recognized revenue will be understated.
Payments received but not matched to an invoice.
Anti-join payments against applications.
Distorts AR and the cash bridge.
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.
Without the right context, a model goes to the wrong table or invents one - the hallucination that quietly corrupts a reconciliation. Cursor's finance team fixed this with a custom skill they call the finance assistant: it holds predefined definitions of every internal term and, for each definition, the table that is its canonical source of truth. Reported as super helpful and used heavily. Once it knows the shape of the business - say, self-service customers billed via Stripe versus enterprise on ACH and wire - you stop re-explaining it on every query, and the model stops grounding itself on the wrong source.
If they let you use Cursor on the SQL exercise, use it - but apply judgment out loud. Generate a draft, then say what you're checking: the join grain, null handling on the left joins and whether the tolerance is right. Catching a model's silent inner-join-where-you-needed-a-left-join is exactly the AI authenticity signal this loop screens for.
QIn the three-way reconciliation, why is using LEFT JOINs from the usage view (rather than INNER JOINs) essential for it to work as a control?