Two HubSpot reports in the same meeting can both be "right" and still disagree. One chart is closed revenue this quarter. The other is new pipeline this quarter. Leadership wants one number. You have two, plus a story about filters. The story is usually wrong. The objects underneath are doing different jobs: create date versus close date, deal amount versus line items, deals as the primary data source versus contacts, two dashboards that never agreed what a deal is.
This post is the diagnosis for marketing and RevOps leads at small and mid-size B2B companies running HubSpot who cannot defend the number on the slide. It is not a 20-tip dashboard list, not a Knowledge Base recap, and not a promise that HubSpot will match finance to the dollar. HubSpot reports what you stored. If the stored objects disagree, the charts will too.
In scope: why two reports disagree, the date and amount fields, imports that restamp create dates, deals with no line items, primary data source, and two dashboards built on two definitions. Out of scope: a full teardown of the portal (that is a HubSpot portal audit), a net-new implementation, and making HubSpot equal the general ledger. If the fight is one date property and one amount field, stay here. If the objects themselves do not match how you sell, stop decorating dashboards.
People say the report is wrong when they mean the number does not match the number they brought into the room. That is a human problem, not a HubSpot bug. HubSpot will add the records that match the filters you gave it. If those filters point at different dates, different amount fields, or a different object as the primary data source, you did not build two views of one truth. You built two truths.
What good looks like is boring. Both reports can be rebuilt from a sample of records. You can open five deals, see the create date, the close date, the amount, the line items, and the associations, and explain why one chart counted a deal and the other did not. What failure looks like is a priest in the meeting: one person who "knows how the dashboard works" and cannot show you the records. I do not start by cloning a nicer chart. I start by naming the object: deal or contact, create date or close date, amount or line item. If we cannot name those, another report will disagree in a new color.
HubSpot stores both. Create date is when the deal record was created in HubSpot. Close date is when the deal is expected to close, or when it closed. HubSpot will set or update close date when you create a deal in an open stage without one, and again when the deal moves into a closed-won or closed-lost stage, unless you turned that automation off in pipeline settings. They are not interchangeable. A report that uses one will never match a report that uses the other, even when both are filtered to "this quarter."
A create-date report answers when the record showed up in HubSpot. A close-date report answers when you say the money happened, or will happen. Pipeline created this month is usually create date. Revenue this month is usually close date, plus a closed-won filter, plus an amount field. If marketing's chart is create date on contacts who later associated to a deal, and sales is close date on deals, you are not looking at the same event. You are looking at two clocks.
Open five deals that appear in one report and not the other. Write down create date, close date, stage, and amount. If the miss is the date property, we change the report. If every create date in a cohort is the same week as an import, that is the next section.
This is the version that makes a lead-source-by-create-date report look like everything was born last month. You imported historical contacts, companies, or deals. HubSpot stamped Create date as the day the record arrived in HubSpot, which is the import day. The report is not wrong in HubSpot's logic. The data is. Cleanup first, then backfill. Skip that, and every Create date dashboard is a guess.
The object matters. HubSpot documents that a deal Create date is set automatically and can be edited by users. Contact and company Create date are treated as when the record landed in HubSpot, so an import often stamps today. Export the original dates, store them on a property you control, upsert on a unique identifier, and report on the date that means history, not the CSV load. If the create dates were overwritten on a Salesforce move, that is a mapping problem, not a dashboard problem. Map the date, then rebuild. That work is a Salesforce to HubSpot migration, not another report. I will not promise zero data loss on a move. We plan it. We do not sell a guarantee.
If the deal has no line items, the revenue report is a story you tell yourselves. HubSpot will still let you type an Amount on the deal. Sales can close it. A dashboard can sum Amount and look finished. Finance then asks what sold, and there is no product, no SKU, no quantity, no term.
HubSpot is explicit about the split. Amount is the total value typed on the deal. Annual recurring revenue, monthly recurring revenue, and total contract value are calculated from the recurring line items on the deal, and HubSpot says those calculations do not take Amount into account. Two reports, both titled revenue, one summing Amount and one summing TCV or net price on line items, will disagree whenever reps typed a round number that does not match the products.
Imports make this worse. HubSpot's import file rules say that importing line items with deals will not update the deal amount. You can land line items on the deal and still have an Amount that belongs to a previous story. I will not treat those two fields as the same number until someone owns the definition: we report Amount, or we report line items, and we write that down. Pick five Closed Won deals from last month. If any have an Amount and no line items, the revenue dashboard is not ready for executives. If they have line items and Amount still does not match, pick a canonical field before you build another chart.
In the custom report builder you pick a primary data source, then you may add more. That choice is the join. A report whose primary source is deals, with contacts added, is not the same as a report whose primary source is contacts, with deals added. One row per deal versus one row per contact. If a deal has three contacts, the contact-primary version can triple the amount unless you aggregate with your eyes open. If a contact has no deal, the deal-primary version will not see them at all.
Associations are the rest of the join. Which contact is on the deal. Which company owns the relationship. If those are fuzzy, HubSpot will still produce a chart. It will just be a chart of the associations you happened to have, including leftover ones from an old import. Two reports can filter Closed Won this quarter and still disagree because one is counting deals and the other is counting contacts associated to deals. What good looks like is that you can say the primary object in one sentence, and you can open a record and see the associations the report is using. What failure looks like is a cross-object report nobody can rebuild, because the join was a guess.
This is the quiet version. Marketing's dashboard uses lifecycle Customer and a contact create date. Sales uses Closed Won and deal close date. Finance uses line items, or a spreadsheet that never lived in HubSpot. All three are titled revenue. None of them agreed what a deal is before the widgets got built. Pretty reporting on a property with no owner is how a team argues about the number instead of the work. A dashboard is not a definition. If closed amount and backlog use two different deal definitions, I would not put that in front of executives yet. Write the definition first: amount with or without line items, closed versus backlog, create date versus close date, primary object. Then the widget. Two dashboards that were never given the same definition will never reconcile.
Do this in the portal, on records, not in a slide. Open the two reports and write down, for each: primary data source, date property, amount field, and filters (pipeline, stage, closed won, owner). Then open five records that appear in one and not the other. Create date, close date, amount, line items, associations. If you cannot rebuild the miss from those five, you do not have a reporting problem you can fix with a chart. You have a data problem.
If the miss is create date versus close date, pick one clock for that question and change the report. If the miss is an import week where every create date is the same, stop using Create date for history until the original dates live on a property you own. If the miss is Amount versus line items, pick the canonical field. If the miss is contact-primary versus deal-primary, pick the object that matches the question. Revenue is usually deals. People added this month is usually contacts. I will not approve a new dashboard on dirty dates and two amount fields because the chart looks finished.
If the disagreement is one date property, one amount field, or one primary source, fix the report. If you keep finding unowned properties, stages reps skip, workflows that fight, leftover Super Admins, and integrations still writing junk, another dashboard will encode the mess. That is a HubSpot portal audit: what is broken, what to fix first, what not to rebuild.
Do not hire an audit to settle a create-date-versus-close-date argument you have not written down. Do not hire a dashboard project to paper over a portal that cannot rebuild the number from records. Implementation is later, after the audit, and only if the finding is rebuild: how to evaluate a HubSpot implementation partner. Most "two reports disagree" jobs never get there.
Which date should we use, create date or close date?
Use the date that matches the question. When the record showed up in HubSpot is create date. When we say the deal closed, or will close, is close date. Pipeline created this quarter is almost never the same as revenue this quarter. If two reports use different dates and the same "this quarter" filter, they will disagree on purpose. Write the question on the dashboard title so the next person does not mix them.
Why did every contact look new after we imported?
Create date is when the record was created in HubSpot. An import of historical people often stamps today, so a lead-source-by-create-date report looks like a miracle month. The report followed the property. Export original dates and legacy IDs, store them, upsert, and report on the date that means history. If this happened on a Salesforce move, treat it as a mapping job.
Should deal amount match the sum of line items?
Only if you made it match. Amount is a field on the deal. Line items are a different object. HubSpot's ARR, MRR, and TCV calculations use line items and ignore Amount. Importing line items does not update deal amount. Pick one canonical field, write it down, and stop summing both in the same meeting.
Can HubSpot match finance to the dollar?
Not as a promise. HubSpot reports what you stored. Finance reports what they recognized. Those are different jobs. If line items, close dates, and associations are clean, the two can be close enough to talk. If they are not, I will not put a HubSpot dashboard in the room and call it the ledger.
Do we need a new dashboard or an audit?
If you can name the miss in one sentence (create date versus close date, Amount versus line items, deals versus contacts) you need a definition and a report change. If you cannot rebuild the number from records, or the portal is full of unowned properties and fighting workflows, you need an audit.
Write the two report definitions down: object, date, amount field, filters. Open five records. If the miss is a date, an amount field, or a primary source, change the report and stop. If the miss is an import that restamped history, fix the dates before you chart them. If you cannot rebuild from records, do not order another dashboard. Start with a HubSpot portal audit.
I do the work myself. All Gusto is a HubSpot Solutions Partner, est. 2014. Senior only.