HubSpot integration with your ERP and accounting

Your sales team works in HubSpot, your invoices come from your accounting software and your deliveries sit in your ERP. Between those three there is usually a person with a second screen. That person is also the first to notice when a customer is in the system twice.

Why connect HubSpot?

For three reasons, and it helps to know which one applies to you. The first is time: nobody has to re-key a won deal any more. The second is reliability: sales sees what has actually been invoiced and paid. The third is follow-up: you can only automate follow-up once the data is right.

Whichever weighs most decides what you connect first. If it is about time, start with the won deal. If it is about reliability, start with the invoice status coming back.

Which data goes which way?

• Companies and contacts: from HubSpot to your accounting system, or the other way round if your accounts are the source.
• Won deals: to an order or a sales invoice in your ERP or accounting software.
• Invoice and payment status: back to HubSpot, so sales can see what is outstanding.
• Products and prices: from your ERP to the quotes module, so no outdated price ends up in a quote.
• Subscriptions and renewals: both ways, with a clear source for the contract term.

What each combination involves is covered under HubSpot integration, and per package under HubSpot and Exact Online, HubSpot and AFAS and HubSpot and Twinfield.

How does the integration work technically?

HubSpot has a REST API for its CRM objects, with custom properties, pipelines and associations between objects. You can retrieve data, but you can also have a webhook notify you as soon as something changes. There are limits on the number of calls; check HubSpot's own documentation for the current values.

Choose deliberately between polling and being notified. Polling is simple and predictable, but always lags slightly. Notifications are fresher, but need a queue, because a spike in changes must never cost a message.

Step 1: pick one flow to start with

Take the flow that is re-keyed most often. In most companies, that is the won deal that needs to become an order or an invoice. That flow is easy to scope, and the result is visible straight away.

An integration that tries five flows at once breaks five times in the first month, and you won't know why. Put the rest on a list and work through it once the first one runs reliably.

Agree who manages that first flow, too. Someone has to make decisions about the mapping tables and be the one called when something gets stuck. Without that person, every change to a pipeline becomes a small project.

Step 2: line up the fields

Make a table showing, for each field, its name in HubSpot, its name in the other system, the direction and what happens in a conflict. Where data flows both ways, decide which side wins, usually based on when the change was made.

Watch the fields that fail quietly: VAT numbers, country codes, currencies, payment terms and whether an amount includes VAT or not. Keep the mapping in a table an administrator can edit, not in code.

Agree what happens to a deleted or merged record as well. A company merged in HubSpot shouldn't quietly leave a second contact behind in your accounts.

Step 3: make duplicates a design decision

Duplicate companies and contacts are the biggest risk in a CRM integration. Decide up front what makes two records the same: a Dutch Chamber of Commerce (KvK) number, a VAT number or an email domain. A name is not a key.

Clean your existing data before the first sync, too. Otherwise the mess doubles in both systems. Much of the clean-up itself can be handed off; see automatic CRM data clean-up.

Step 4: decide what happens when something fails

Put every message in a queue with its own status. If it fails, the system retries at growing intervals. If it still fails, it lands on a list someone reviews, with the reason in plain language.

Make it visible when a flow goes silent, too. Sales won't notice a missing invoice status: they simply see nothing and assume nothing has happened.

Where does it go wrong in HubSpot itself?

Usually not in the technology, but in the set-up. Pipelines nobody tidies, custom properties that exist twice under different names, and deals marked as won as an intention rather than a fact.

So tidy up what you are about to connect first. Remove properties nobody fills in, cut the pipelines back to what really exists, and record which fields are required before a deal can be marked as won.

Agree what won actually means and who ticks that box. Once that status triggers an invoice, it is no longer an admin detail. For the follow-up after that, see automated quote follow-up.

When is a standard connector enough?

Often, and that is the first thing to find out. If a ready-made connection between your packages carries the fields you use, take it. Do check what happens when there is an error and whether you can access the log yourself.

Building your own makes sense when you need to combine several systems, need your own logic in the mapping, or when the standard connector lacks exactly the fields you care about. What that costs is set out under having an integration built and in what an integration costs.