Why your Salesforce revenue field doesn't match finance (and how to fix it without breaking reports)

We watched this happen on a client team recently: a Series B SaaS company on Salesforce and HubSpot with 4,317 open opportunities. Their CRM calculates an estimated recurring-revenue figure the moment a deal is signed, meant to be compared later against the actual number once the customer goes live. Someone on the finance side didn't trust the estimate on a specific deal, so they pulled up the formula and recalculated it by hand. A second person did the same thing independently, using the same deal, the same inputs, and the same math. The two of them landed on different numbers. Neither matched what the system had stored.

Nobody had touched the formula recently. Nobody had made an obvious mistake. The field was doing exactly what years of incremental changes had told it to do, which was the actual problem. A metric like this doesn't break in one dramatic moment. It drifts, field by field and flow by flow, until the day someone checks it against reality and finds the gap.

If you're staring at a custom revenue field, an ARR-adjacent estimate, or a renewal-classification metric that finance, sales leadership, and operations each read differently, the instinct is to open the formula and start fixing. Resist that instinct until you've done three things in order. Skip the order and you risk rebuilding the same broken metric a few quarters from now, once the next round of "quick fixes" accumulates the same way the first round did.

Start by finding every input, every flow, and every override currently writing to the field. Not the ones documented in the original design. The ones actually running today.

In the case above, the estimate was built from formula fields layered on top of assumptions stored in backend custom settings that only one team could see or edit. One person on the receiving end of that number called it, plainly, a black box for everyone who couldn't access those settings. Several flows that had been "started to be deprecated" over the years were still quietly writing to the field's inputs, layered on top of each other as the system evolved and nobody fully retired the old logic. One specific input, a fit-tier value a sales rep sets at the moment of signing, could later be silently overwritten during onboarding by a completely different team's independent judgment call, with no flag anywhere in the record that a change had happened.

None of that shows up by reading the formula on its own. It shows up by tracing every process that currently touches the field, live, in the org you actually have, and writing down what you find. This step alone usually explains most of the drift, because most drift isn't a bad formula. It's a formula that quietly picked up more inputs over time than anyone remembers granting it.

A related audit, on a different metric at a different company, found something simpler and just as damaging. A renewal-classification field depended entirely on product line items being attached to the opportunity record. On inspection, [X]% of [N] renewal opportunities had no products attached at all. The formula was fine. The data underneath it had quietly stopped existing, and nobody noticed because the field kept returning a value either way, just the wrong one.

Once you know what's feeding the field, the first real fix isn't a smarter formula. Pick a specific moment in the business process, such as when the contract is sent or when it's signed, and decide that once a deal crosses that line, the number stops moving.

By the time a contract goes out, the business already has essentially everything it needs to know about that deal. Letting the estimate keep quietly recalculating after that point, sometimes for months, turns a clean snapshot into a moving target nobody can reconcile against anything else. It also makes the two-people-different-answers problem inevitable rather than occasional. If the inputs can still change after the fact, any two people checking the number at different times will get different results, and both will be technically correct.

This is the single change with the most impact you can make, and it's mostly a governance decision rather than an engineering one. It requires the business to agree, explicitly, on the one moment that counts, instead of leaving the field free to keep updating indefinitely by default.

Before you change the field's underlying logic, find out who and what already consumes its current output. A downstream commission calculation or a sales-intelligence dashboard built quietly on top of the existing number will break in its own way the moment that number starts behaving differently. Skip this step and you don't fix one broken metric. You trade it for two.

The wrong approach here is what one engineer we spoke with called the scream test: delete or change something you don't fully understand, then wait to see who complains loudly enough to tell you it mattered. It works, eventually, but only by breaking things in production and using the complaints as your documentation after the fact. Mapping dependencies first is slower. It's also the only version of this fix that doesn't create a second incident while you're in the middle of cleaning up the first one.

Yes. Once the inputs are frozen at a known point, you don't have to choose between a stable historical record and an accurate, evolving estimate. Keep the original, locked-at-signing number for audit and historical reporting, untouched from that point forward. Add a second field that continues to update as better information comes in: corrected assumptions, actuals gathered during onboarding, and whatever else would normally have kept quietly mutating the original number in the background.

The gap between the two fields, tracked over time, becomes a useful signal instead of an embarrassment to explain away. A locked estimate that consistently comes in low against the eventual actual is telling you something specific about how deals get sized at signing. That's worth knowing. It stops being worth knowing the moment the "locked" number is allowed to quietly drift along with everything else.

Yes, as an interim step. Sometimes the historical data is already too damaged to correct retroactively, and the honest move is a fix that only protects records going forward. In the renewal-classification example above, the interim fix was an automation that copies the missing product data from a prior renewal onto each new one, so future records self-heal even though the historical backlog stays wrong for now.

That's a legitimate first move, not a compromise to apologize for, as long as two conditions hold. Everyone involved agrees, out loud, that it's temporary. And the plan for the historical backlog gets written down somewhere, with an owner and a rough timeline, rather than quietly dropped once the future-facing fix ships and the pressure to finish the job disappears.

A small transparency step is worth adding here too, even before the underlying logic is fully trusted: a plain-language panel on the record itself, showing what's actually driving the number for that specific deal. Not the full formula. Just enough that someone looking at one record doesn't have to go ask a specific person on a specific team what a specific setting currently means.

The bar for success was never technical precision down to the decimal. It's whether a business leader, finance, and sales leadership all trust the same number, at the same time, for the same reason.

Progress toward that is visible well before the underlying accuracy fully catches up. The record recalculates far fewer times than it used to. In this case, [X] times per deal instead of [Y]. The number stops changing once the deal is signed. And a replay of old deals under the new logic shows what their numbers would have looked like restated, which gives everyone a concrete before-and-after instead of a promise.

If none of those things are true yet, the formula isn't the next thing worth fixing. The freeze point is.