Why AI gives the wrong revenue number from Salesforce and the order to fix it

AI reports a wrong revenue total from Salesforce because it adds up whatever the fields hold, and the fields are often stale. Fix the upstream data first. Then give the assistant approved sources and explicit rules, make it show its arithmetic, add an independent reviewer, and keep someone who knows the business as the last check.

An executive asks an assistant for total active recurring revenue. The assistant sums the account-level revenue field and returns one clean number. It does not match the contracts actually in force.

The model did nothing wrong. That account field adds up contract values, and the contracts behind it were renewed by editing the start date in place, so the end dates on a share of them were stale. The assistant summed accurately and reported what the data said. Nobody reading a fluent paragraph sees the gap. A spreadsheet with a bad total gets questioned because you can see the cells, and a sentence rarely gets the same treatment.

A second failure looks different. A deep-research connector in HubSpot produced a polished statistical analysis, regression results included. When the consultant asked it to show the math, it admitted it had not done the work. One answer rested on bad inputs and the other on no work at all. In both, nothing sat between the question and the answer to check anything. The rest of this piece is that missing layer, in the order we build it.

Start with the handful of figures an executive is most likely to ask about, such as active recurring revenue and renewals due this quarter. For each one, trace the field back to what feeds it. Is it a roll-up, a formula, or a value written by an automation? Which dates drive it? When something changes, are the underlying records replaced or edited in place?

Then total a small sample by hand and compare it with the field. If they disagree, you have found a defect that no prompt will repair. Every control later in this sequence catches errors. None of them removes one. That is why the data comes first, even though it is the least exciting step and the one most teams want to skip.

Check the definitions too. Ask what "active" means in your org and who decided it. A contract that is past its end date and still marked Activated counts as active to a roll-up and to an assistant, and it will count as active to the executive reading the answer. If finance and sales leadership would give two different definitions, the assistant will pick one without telling you which.

Some fixes take weeks. In the meantime, keep a short list of fields known to be wrong and tell the assistant not to use them, so the gap is visible and not silent.

Write the operating rules down and give them to the assistant every time. Use only these objects and fields. Validate your assumptions and double-check your arithmetic. Say so when data is missing instead of filling the gap. The consultant who runs this setup put it plainly: you would not think you have to tell an agent not to guess, but you do, and you have to say it in several different ways.

Keep the rules in one shared document that a non-technical owner can edit, so a change to how revenue is defined does not require touching anything built. The rules should name the fields you vetted in the previous step. Constraints that point at an unreviewed roll-up only make a wrong answer more consistent.

Ask every figure to arrive with its working: the object and field it summed, the filters it applied, the date range, how many records it counted, and the arithmetic line by line.

With that in hand, a person can check the answer in minutes by pulling the same records. Without it you are reading a confident paragraph and guessing. The cheapest test we know is the one that exposed the connector: ask it to show the math. An assistant that cannot produce the work should not be trusted with the conclusion.

Showing the math does not prove the answer is right. It makes it possible to find out.

A reviewer is a second assistant instructed to assume the first answer is wrong. It checks each claim against the source and sends the analysis back with what failed. We have seen one analysis go back several rounds, and another keep failing validation over a weekend.

That sounds like waste. It is the reason to do it: the failures showed up in a review loop and not in front of leadership. The cost is more runs and more time, so reserve it for numbers that reach an executive or feed a compensation calculation. A quick lookup does not need it.

The order matters here. A reviewer can only check what the first assistant shows. If you skipped the previous step, it is reviewing a conclusion with no working behind it.

Someone who knows the business still has to read it. Volume is cheap, and a long, well-formatted analysis can be wrong for the business in ways a reviewing agent will not catch: a renewal figure that ignores how your contracts actually roll over, or a quarter that cannot plausibly be that much higher than the last.

Name an owner. Give that person the shown math and the reviewer's notes along with the narrative, and make clear that sending the work back is a normal outcome.

Ask for a number you already know, such as the revenue finance reported for the last closed quarter. If the answer matches and the working is there, ask for one you do not know and review that. If it does not match, find which layer failed. A data defect and a rule gap have different owners, and the fix is different for each.

Keep a handful of known-answer questions and rerun them after any change to the fields they depend on. It is a small regression test, and it is how you find out a roll-up changed before an executive does.

Ask your assistant for last quarter's closed revenue today. If it cannot show where the number came from, you know where to start.