Contracted revenue says one thing. Billing says another.
The CRM records what was sold. Stripe records what is being invoiced. When those diverge, the gap is usually a real event nobody logged.

Pull the ARR for a customer out of the CRM. Pull the same customer's recurring invoice total out of billing. Subtract.
For most accounts the answer is zero. For the ones where it isn't, something happened: a mid-term expansion, a negotiated credit, a downgrade that never made it back into the opportunity record, a seat count that drifted after the contract was signed. The number is not the interesting part. The event behind it is.
Finance reconciles this on a schedule. Sales usually doesn't reconcile it at all, because from the CRM's point of view nothing looks wrong. The opportunity closed. The number is right there.
The forecast is built on the wrong number
If you forecast from contracted ARR, you are forecasting from a value that was true on the day a rep clicked Closed Won. Everything that happened afterward lives somewhere else.
That is fine when nothing changes after signature. It stops being fine the moment your pricing has usage components, mid-term adjustments, or any expansion motion, because those are exactly the accounts where the two numbers separate. The accounts that diverge most are usually your most active ones.
Why a report doesn't settle it
You can build the report. Most finance teams have. It takes an export from each side, a join on whatever identifier the two systems happen to share, and a human deciding which mismatches are real.
The join is the hard part. The customer is an Account ID in the CRM and a Customer object in billing, and the only thing connecting them is often a name that someone typed twice. Get that wrong and the report shows a $200K discrepancy that is actually two different companies with similar names.
The report is also a snapshot. It is accurate the afternoon it is built, and it starts drifting immediately.
Resolve the customer first
The reconciliation is only hard because the customer is not a single thing. Once the CRM account, the billing customer, the support organization, and the product tenant are recognized as one entity, "contracted versus billed" is a property of that entity rather than a join you re-derive every quarter.
Both numbers stay. Neither overwrites the other. What you gain is the ability to ask which accounts diverge, by how much, and since when, and to get an answer that reflects today rather than the last time someone ran the export.
Questions this makes ordinary
- Which accounts bill less than they contracted, and when did that start?
- Which expansions are invoiced but never made it into an opportunity?
- Which renewals are being forecast at a number billing has not seen in two quarters?
- Where does a usage-based line item exceed what the contract anticipated?
Those are not exotic. They are the questions a finance and revenue team already asks, answered without an export.
Frequently Asked Questions
Why is contracted ARR different from billed revenue?
Contracted ARR reflects the agreement at signature. Billed revenue reflects what is actually being invoiced now, including mid-term expansions, downgrades, credits, proration, and usage-based components. A gap between them is normally a real commercial event rather than a data error, which is why flattening the two into one number loses information.
How do you reconcile Salesforce and Stripe revenue?
The reconciliation depends entirely on being able to identify the same customer in both systems, which is the part that usually breaks. Salesforce holds an Account, Stripe holds a Customer, and the link between them is often a name or an email domain rather than a shared identifier. Resolving that identity once, rather than re-joining exports each quarter, is what turns the reconciliation from a recurring project into a question you can ask.
Which number should the forecast use?
It depends on what the forecast is for. Contracted value is the right basis for bookings and quota. Billed recurring revenue is closer to what will actually be collected. The failure mode is not choosing the wrong one, it is not knowing which one a given report used, or discovering the two disagree only at quarter end.
See the gap on your own accounts.
Your CRM, billing, support, and product systems keep saying what they know. SixDegree recognizes the customer underneath them, so contracted and billed become two properties of one account rather than two exports to join. Works today for RevOps teams.