The deal's headline number is one someone typed

The last piece left two full line item records behind one sale, one on the quote and one on the deal, made in the same transaction on purpose. The deal's copy now has to answer a question the quote's copy is never asked: what is this deal worth? And the field most people open a deal to check isn't computing an answer at all.

The number that's just typed in

Every deal has a property labelled Amount. It's distinct from the amount field on each line item underneath it, though the two share a name, and that's most of what makes this confusing. HubSpot's description of the deal's version is plain: "the total value of the deal in the deal's currency." Nothing in that sentence says how the value got there, and the schema is the reason. amount is calculated: false, readOnlyValue: false. It's an ordinary writable number, the same kind of field as the deal's name or its close date. Nobody computes it. Somebody, or something, writes it.

HubSpot will write it for you, at exactly one moment, and only if you let it. Save a change to a deal's line items in the UI and HubSpot asks you to "select whether you want to update the deal amount to reflect your new line items, or save the deal without updating its amount." Decline that prompt, or skip the UI entirely, and the field stops moving. HubSpot's own documentation names one path that skips the prompt outright: "When importing line items, the associated deal amount will not be updated." Import line items against deals that already exist and every one of those amounts stays where it was. The same documentation gives the remedy in its next sentence, which is to associate the line item to the deal by hand afterwards.

On the deal I've been tracing, the $9,995-a-month six-month sale, amount reads $59,970, the full six-month value, and it happens to match the deal's own hs_tcv, the property that holds Total Contract Value, to the cent. I'd caution against reading that as a formula working, because there's no formula. Something wrote the contract value into that field once and nothing underneath it has moved since. Which write, and when, the record doesn't say.

Which sum it lands on

There are two obvious candidates for what a deal's amount should equal: the sum of every line item's own amount, which is its net price for one billing period, or the sum of every line item's hs_tcv, its value across the whole term. On a one-time sale the two sums are identical, so most deals in a portal can't tell you which one HubSpot uses. Across the 89 deals in this portal with at least one line item and a populated amount, 84 match the sum of hs_tcv and 66 match the sum of amount, and the two groups overlap heavily for that reason. Narrow to the 20 deals where the two sums genuinely diverge and the ambiguity goes away: 18 land on the sum of hs_tcv, none land on the sum of amount, two land on neither. When HubSpot writes the field for you, it writes the whole contract rather than one billing period, on every deal in this portal where the two could be told apart.

"Neither" is the part I'd pay attention to. Widen back to all 89 deals and five of them agree with neither candidate sum, in both directions:

Nothing on any of the five flags the gap. The last row is the most dramatic case I found: a deal reading $95,000 against a single associated line item whose own hs_tcv says $495. Somebody typed the amount by hand before a line item was attached, or edited it after declining the prompt, or wrote it over the API with no line items in the request. I can't tell you which from the record, and I'd rather say that than guess. What the record does show is two numbers that disagree, with nothing on it resolving the disagreement either way.

What actually rolls up

Set that against the deal's other revenue properties, alongside hs_tcv itself: hs_acv for Annual Contract Value, hs_arr for Annual Recurring Revenue, and hs_mrr for Monthly Recurring Revenue. All four are calculated: true, readOnlyValue: true. HubSpot publishes no formula for them, where most calculated fields carry one, because they're backend rollups summed straight from the matching property on every line item attached to the deal. Across every deal in this portal that carries a line item, all four match that sum exactly. Ninety-two deals, four properties, zero mismatches.

They don't drift because nobody can write to them. There's no prompt to decline and no import path that skips them. Report on any of the four and the number moves the moment a line item changes underneath it. Report on amount and it moves when someone remembers to move it. I think this is the most common reporting mistake in the whole chain, and it's an easy one to make, because amount sits right beside the other four and reads as the fifth member of the group when it's the only one with nothing computing it.

One number is missing from the deal entirely, and it's the one a margin-minded reader would actually want. The Deal object carries 515 native properties, and a name scan across all of them for anything containing "margin" or "cost" returns zero. Margin lives only on the line item, one billing period at a time or across the whole term, and neither version rolls up to the deal the way revenue does. A deal-level margin figure is either read off the line items directly or built on a custom property someone feeds by hand. That's a real gap, and I don't have an explanation for why revenue rolls up here and cost doesn't.

What to check this week

Pull a handful of your own deals with recurring line items and set amount next to hs_tcv on each. Where they match, you're probably looking at a deal nobody has touched since its line items were last saved. Where they don't, the gap is the size of the problem amount is hiding on that deal, and it won't show up anywhere else on the record. Then move whatever report currently reads amount over to hs_tcv, hs_arr or hs_mrr, depending on what the report is trying to say, knowing that all three are reading the line items live and amount is not.

The deal now has its own line item copy and its own number, four-fifths of which can be trusted without checking. Every hop so far has minted a fresh copy of the line item. The next one doesn't, and the next piece is about the one place in the chain where that's true.