Why Connectors are Iceberg Problems

Almost every sales-led SaaS team we talk to opens with the same set of symptoms: my MRR / ARR data isn't tying together or contracts say something different from CRM fields. Someone then has to go in and clean data by hand.

That's a real problem, and on its surface it looks like a missing integration between systems. But the more time we've spent with RevOps and Finance teams over the past year, the more we've realized that the connector is the visible peak of a much larger iceberg. Below the surface sits a stack of problems that a connector doesn't touch — and that have to be addressed in their own right before any automation can actually deliver on its promise.

Here's what we keep seeing under the waterline, with a few example painpoints.

The Contract Often Says One Thing, and the CRM Says Another

One of the things teams notice when they try to automate the deal-to-billing handoff is that the two ends don't agree with each other.

A finance lead at one small SaaS team we spoke to had built her own automation: it reads contracts from PandaDoc and creates subscriptions in Stripe. It works around 85% of the time. The other 15% — the part she still has to clean up by hand — is almost always traceable to the contract itself. Her phrasing was that typing in a fields in a hurry by overworked sales teams often leads to "really illogical contracts." On Monday someone will write "quarterly" on a line item but attach the annual price. On Tuesday, someone types in that a deal started on February 30th.

Look only at the CRM record of those deals (e.g. products, amounts, cadence) and everything appears clean. But the contract that the customer actually signed says something else, and the contract is the legal source of truth. Until those two artifacts agree, no connector can sync anything reliably, because there's no single right answer to sync.

This is the pattern that shows up over and over again: there is always something upstream of whatever you're trying to automate, and the upstream data is where errors get introduced, no matter how fancy your new downstream billing tool. Automating a data handoff doesn't fix this issue; it just moves bad data faster.

Missing Contracts

Connectors can only connect data that exists. We spoke recently to a finance lead at a Series A startup who came to use asking for a connection between this contract and billing system. Over time, as he was leading the financial due diligence portion of their fundraise, he discovered the team was missing ~40 contracts. Teams assume there's data somewhere to begin with and it consistently lives in the same spot. But a lot of the time, there isn't.

The finance lead spent a full night going through inboxes trying to track them down. Even today, there are customers his company doesn't have a signed contract for, because the contracts live wherever they happened to land: Google Drive, an inbox, a HubSpot deal attachment nobody remembered to download.

For him, "we need a connector" turned into a need for a place to centralize our data — contracts, quotes, and traces to signatures. The connector was real. It just wasn't the hair on fire problem. The bottleneck was that there was no system of record for the artifact that's supposed to drive billing in the first place.

If your contracts are scattered across email, slack and google drive, the first you need to do is centralize your information in one system.

A Connector Moves Data. It Doesn't Remember It.

This is the observation worth naming explicitly, because it confuses a lot of teams when they shop for tools.

A connector is a pipe. It fires when something happens — a deal stage flips to closed-won, a customer's status changes — and it pushes data from one system to the next. It is designed for the moment of the handoff. It is not designed to be your archive.

If you want to know what was agreed to, when, by whom, and how it has changed over time, what you actually need is a system of record. This is especially true if you have clear pricing guidelines and an exceptions process that requires approvals from multiple stakeholders.

Even a perfect connector can't help you see the evolution of a quote over time, who approved or pushed back on pricing terms and the justification papertrail.

No source of truth

Another conversation — this time with a commercial lead at a Stockholm-based startup. She came in convinced she needed a HubSpot-to-Stripe connector. She'd already tried Chargebee and found it clunky. She'd tried the native HubSpot–Stripe integration and found it wasn't helpful because it didn't sync billing operations in Stripe from HubSpot records.

Eventually, she reframed the whole problem: "We have not set up our products in a standardized way in HubSpot." Whatever connector she picked would just be syncing chaos.

Her own conclusion was the right one: "What I would do personally is first define the source of truth (in our case, HubSpot). And once we have that cleaned up, then sync."

A connector assumes both sides have clean, well-modeled data. If the products in your CRM don't map cleanly to the prices in your billing system — or worse, if your CRM doesn't have a real product catalog yet — you're not ready for a connector. You're ready to do the upstream work of deciding where your data lives.

Are these process problems or product problems?

Here's the uncomfortable observation underneath all of the above.

Every layer of the iceberg can, in principle, be fixed with the right tool. There are CPQ products. There are contract repositories. There are pricing approval workflows. There are connectors (we make one). The market is not short on software.

The harder problem is that even after you buy the tool, somebody still has to use it consistently. The CPQ doesn't work if reps bypass it and send contracts from their own Google Docs. The contract repository doesn't work if half the team still attaches signed PDFs to an email thread and never uploads them. The standardized product catalog doesn't work if someone adds a new SKU directly in Stripe without updating HubSpot. Each tool depends on a behavior change, and behavior changes don't ship with software.

This is the part of the conversation that almost nobody enjoys, because the tool can't solve it on its own. It requires alignment — someone senior saying "this is how we do quotes now," and meaning it. It requires training. It requires a small amount of ongoing friction when a rep tries to work around the system and someone has to say no.

The tool is necessary. It is not sufficient. The teams that get the most out of any of this software are the ones that treat the rollout as a process change first and a deployment second.

So What's Actually Under the Waterline?

The "connector problem," summarized, is usually a quote-to-cash problem that's been compressed into its most visible symptom. The full iceberg, top to bottom:

• At the surface: deals closed in the CRM aren't syncing to the billing system.
• Just under: the contract data and the CRM data don't agree.
• Deeper: there's no central place where contracts and quotes are stored.
• Deeper still: it's unclear what the source of truth is.
• At the bottom: even with the process and tooling defined, the team has to actually use them consistently.

Each layer needs a different kind of solution. A connector fixes the surface. A repository fixes records. A standardized product catalog and a CPQ layer fix the layers under that. Approval workflows fix pricing logic. And nothing fixes the bottom layer except deliberate process design.

The mistake we see most often is teams buying one tool that solves one layer and assuming it will fix the others. It won't.

How to Tell Where You Actually Are on the Iceberg

A few honest diagnostic questions, in roughly the order we'd ask them:

• Have you defined your source of truth for different types of data?
• Do you know where every signed contract for every active customer lives, today?
• If you opened your CRM right now, would the product catalog match what's in billing?
• Could a new RevOps hire look at any closed deal and unambiguously rebuild it as a subscription, without asking the AE what they meant?
• Is there a single source of truth for what an existing customer is currently paying, currently using, and currently entitled to?
• If you bought the perfect tool tomorrow, would your sales team actually use it the same way every time?

If you have a lot of nos to the question above, you have work to do before you jump into a tool as a point solution.

Frequently Asked Questions

Why does my CRM-to-billing connector keep breaking?

Connectors only move data between systems. If the data going in is wrong — a contract that disagrees with the CRM, missing line items, or no defined source of truth — the connector just propagates the errors faster. The fix is upstream: clean up the data model before automating the handoff.

What is a system of record for sales-led billing?

A system of record is the canonical place where a piece of data lives. For sales-led SaaS, the signed contract is usually the legal source of truth for what was agreed to — but it's often scattered across email, Drive, and CRM attachments, which is exactly the iceberg problem.

Do I need a connector or a CPQ?

It depends which layer of the iceberg you're trying to fix. A connector fixes the surface-level CRM-to-billing sync. A CPQ fixes the upstream data quality problem — what gets sold, at what price, with what approvals, with structured data attached.

How do I know if my team is ready for a connector?

Three diagnostic questions. Is there one defined source of truth for each data type? Do all signed contracts live in one place? Does your CRM's product catalog match the prices in your billing system? If you answered no to any, that's the work you should do before a connector.

Related reading: what is CPQ? · the best HubSpot to Stripe connectors, compared · HubSpot Billing vs. Stripe Billing