How to build HubSpot reports you can trust (and the mistakes that quietly break them)
Most teams don't have a HubSpot data problem. They have a HubSpot reporting problem.
The numbers going in are usually fine. What breaks is the build: the wrong object at the centre of the report, a property quietly measuring something you never asked for, a chart that flattens the one trend you needed to see. The result is a dashboard nobody fully believes, which is worse than no dashboard at all, because now every meeting opens with an argument about whether the figures are right.
Here is how we build reporting at Uspeh, and the mistakes that cost teams the most trust.
Build custom from the start
HubSpot's out-of-the-box reports are tempting. A few clicks and you are roughly 80% of the way there. The problem is always the last 20%, and the last 20% is usually the exact thing that made the report worth building. Retrofit a built-in report to reach it and you tend to create more problems than you solve.
So we build custom by default. A custom report grows with the business. A built-in one hits a wall the moment your question changes, and your questions always change.
There are a few specific visualisations HubSpot only offers as pre-built report types, and no custom report will reproduce them. When you need one of those, reach for the pre-built type. Everywhere else, custom wins.
Point the report at the right object
When you build a custom report, the primary source should be the thing you actually want to count. Want contacts broken down by lifecycle stage? Contacts are your primary source. Want deals created per month? Deals are.
Obvious, until it isn't. Getting this one wrong sits behind the most alarming reporting bug we see.
When 100k shows up as 300k
Picture a single deal worth 100k with three contacts attached. Build the report with contacts as the primary source, pull in deal amount, and HubSpot will cheerfully show you 300k.
Nothing is broken. The report answered the question you accidentally asked, which was "show me the deal value sitting against each of these contacts." It counted the same deal once per contact because nothing told it not to.
The fix lives in the setup, not the data. Choose the object you truly want to measure, and slow down the moment you start combining objects. When you need genuinely layered filtering, a list or segment is usually more flexible than a report: build the segment first, then report on membership.
The property that measures the wrong thing
Native properties like Create Date live on contacts, deals, and companies, all under the same name. Pick the wrong object's version and your report measures something you never intended. Everything looks correct. It is simply answering a different question.
This is the most common reason a report looks broken, and it catches experienced builders reworking old reports as often as it catches clients. The fix takes seconds: click the pencil on the field and confirm which object the property belongs to. Then name the report and label the fields clearly, so the next person doesn't fall into the same hole.
A report can be accurate and still useless
A report can be technically perfect and tell you nothing, and usually the chart is to blame. Match the visual to the decision it is meant to support:
- KPI for the single headline number
- Column or bar for grouped data, like records created per month
- Line for trends over time
- Horizontal bars for funnels and deal-stage breakdowns
- Pivot tables for the breakdown-of-a-breakdown clients love to ask for
- Tables for sanity checks, with Record ID so rows stay clickable
- Combination charts to test whether more deals actually means more revenue
One trap worth naming: when large and small numbers share an axis, the small series flattens into a line that looks like nothing is happening. Fix the aspect ratio, or split it across two reports.
Never read a number in isolation
Say most of your contacts land on a Monday. The instinct is to staff the weekend to catch the rush. Drill into original source, though, and the story can collapse. Some of those Monday contacts were an import. Others were weekend emails that synced first thing and got stamped Monday.
The number was real. The conclusion would have cost you a rota change for nothing. Validate as you build, especially once filters and nested breakdowns start stacking, because one shaky assumption early gets inherited by every layer above it.
The details that make people trust the whole thing
Reliability earns trust. Polish signals it. Set the report colours to the client's brand. Format currency properly. Put the legend where the eye already goes. Show percentages next to charts so proportions read at a glance. None of this changes the maths. All of it changes whether the person looking at the dashboard believes it was built for them.
The real test
A dashboard is doing its job when someone can act on it without ringing you first to check the figures. That is the bar, and most reports that almost work miss it for one of the reasons above, not because the underlying data is wrong.
If you have quietly stopped trusting a dashboard you rely on, that is a build problem, and build problems are fixable. As a HubSpot Platinum Solutions Partner, that is the work we do at Uspeh.
Frequently asked questions
Why is my HubSpot report showing the wrong total?
The usual cause is the wrong primary object. If contacts are the report's primary source and you pull in deal amount, HubSpot counts the same deal once for every associated contact, so a single 100k deal linked to three contacts reads as 300k. Rebuild the report with the object you actually want to measure as the primary source.
Should I use custom or default HubSpot reports?
Default reports get you most of the way in a few clicks, but they hit a wall the moment your requirements change. Build custom by default so the report can grow with the business. The exception is a small set of visualisations HubSpot only offers as pre-built types, where you use those instead.
Why does my HubSpot report look broken when the data is fine?
Most often you have picked the wrong object's version of a shared property such as Create Date, which exists on contacts, deals, and companies under the same name. The report then measures something you never intended. Click the pencil on the field and confirm which object the property belongs to.
How do I build HubSpot reports my team actually trusts?
Choose the right primary source, confirm each property sits on the object you mean, validate as you build rather than at the end, and pick a chart that serves the decision. The test is simple: a dashboard is working when someone can act on it without ringing you to check the numbers.
Got questions
Others frequently ask…-
Usually the report is built on the wrong primary object. If contacts are the primary source and you pull in deal amount, HubSpot counts the same deal once for every associated contact, so a single 100k deal linked to three contacts reads as 300k. Rebuild the report with the object you actually want to measure as the primary source.
-
Default reports get you most of the way in a few clicks, but they hit a wall the moment your requirements change. Build custom by default so the report can grow with the business. The exception is a small set of visualisations HubSpot only offers as pre-built types.
-
Most often you have picked the wrong object's version of a shared property such as Create Date, which exists on contacts, deals and companies under the same name. The report then measures something you never intended. Confirm which object the property belongs to.
-
Choose the right primary source, confirm each property sits on the object you mean, validate as you build rather than at the end, and pick a chart that serves the decision. A dashboard is working when someone can act on it without checking the numbers with you first.
