Integrating your ERP system with HubSpot transfers financial data from the business system to the CRM. Recorded revenue, products, and customer IDs are added to the customer profile and updated automatically. Sales, marketing, and customer service can see what the customer actually buys without having to ask the finance department.
One thing determines what you can use the data for, and these two are almost always confused. The general ledger tells you what the customer buys. Accounts receivable tells you whether you’ve been paid. These are two separate questions, two separate sources, and two completely different sets of data.
An ERP integration with HubSpot is a connection that reads financial data from the business system and assigns it to the correct company in HubSpot. The most common type is one-way: the financial system is the source of truth, and HubSpot is where the data is used. Nothing is written back.
Most financial systems with an open API can be integrated. In Sweden, we most commonly encounter Visma in its various forms, namely, Visma Control Edge, Visma.net, and Business NXT—as well as Fortnox and Microsoft Dynamics 365 Business Central.
Here’s what’s typically transferred, and what it’s used for:
| Data from the accounting system | Where it ends up in HubSpot | What the team does with it |
| Recorded revenue per account, from the general ledger | A separate object for transaction lines, linked to the company | Revenue per product and customer |
| Product category | Checkboxes on the company card | Lists and segments based on purchasing behavior |
| First and most recent transaction dates | Date fields for the company | Active customer and alert when purchases cease |
| Invoices, due dates, and payments from the customer ledger | Dedicated field for invoices | Payment status as background information before a call |
| Customer number | Key fields for the company | Matching against existing companies, without duplicates |
The first thing that happens when purchase history is stored on the company profile is that list building becomes a matter of filtering rather than a question for the finance department.
If you have checkboxes for each product category, you can filter to find all customers who buy A but don’t buy B. That’s a ready-made call list for sales and a ready-made segment for marketing—all within the same CRM. The difference from a standard mailing is that the selection is based on a purchase that’s actually been recorded, not on what someone happened to enter manually two years ago.
Many companies want sales and marketing to be able to respond differently when a customer stops being a customer.
The solution is a “active customer” field for each product category. A customer is considered active if the most recent recorded revenue in that category falls within a predetermined time window. The window is set based on how often the product is billed or paid for: one month for a subscription billed monthly, or, for example, one year for something purchased individually. If purchases stop, nothing new is added to the field, and the customer is automatically unchecked.
“Active customer” thus indicates whether the customer is currently a customer. If you also want to know when the customer last made a purchase or renewed a subscription—that is, the pure purchase signal—the correct source is the order or invoice. A prepaid annual invoice can continue to be recorded for twelve months, so the accrued revenue is a good answer to the first question and a poor answer to the second. You can have both, but decide which question each field answers.
Without revenue data in the CRM, customers are prioritized based on number of employees, industry, size, or perhaps even gut feeling. With recorded revenue per customer, you can also prioritize them based on what they actually spend.
This gives the sales manager a basis for allocating accounts and makes the difference between a large customer and a well-known customer clear. Revenue data doesn’t replace the experience of the person who knows the customer—it simply provides a benchmark against which to assess them.
Think through the access permissions before the data goes live. Not everyone needs to see every amount. In HubSpot, access can be restricted by team or by attribute, so the sales team can see that a customer is buying a certain category without seeing the revenue generated by that category.
This is the second data source. Invoices, due dates, and payments are stored in the accounts receivable module, and they’re structured as a separate object in HubSpot.
The benefit is simple. The person making an upselling call knows if there are three overdue invoices at the root of the issue. The support agent knows if the case is linked to an invoice the customer is disputing. No one has to guess, and no one has to email the finance team in the middle of a call.
There’s one thing the payment status shouldn’t be used for: to diminish customer value. A late payer isn’t a less valuable customer. Keep these two issues separate in the model; otherwise, both answers become unclear.
The CRM knows what you sold. The accounting system knows what actually became revenue. As long as they’re separate, they’re compared once a quarter, in an Excel file, by a person.
If both are in HubSpot, you can include won deals and booked revenue in the same report. Then you can see when a deal is won but never materializes, and the forecast becomes something you can reconcile with the accounting records instead of against the previous forecast.
Start with a one-way integration, from the accounting system to HubSpot. This covers all five use cases above, and it’s the approach where nothing can go wrong with the accounting.
One-way means that the integration only reads data. If built correctly, it’s not a setting but a code-level block that stops any write request before it’s even sent. The financial data is mirrored in the CRM and cannot be modified from there.
Two-way sync, where a change in HubSpot creates or updates something in the financial system, is a different project with different requirements. It may be the right approach, but it’s not the same thing, and it shouldn’t creep into a scope that started with the sales team wanting to see what the customer is buying.
Three options, and they suit different situations.
A pre-built connection from a marketplace is the fastest and cheapest option when your use case fits the standard model. It becomes difficult as soon as the data model is your own or complex—for example, when the product must be derived from a dimension or the customer number from a free-text field. We’ve written more about where the line is drawn and why off-the-shelf integration solutions fail in complex B2B scenarios.
An integration platform gives you control over the flow without writing your own code. The trade-off is that the logic ends up in a platform that someone has to manage, and troubleshooting thousands of lines of code every night is rarely the platform’s strong suit.
A custom-built integration is the right choice when data needs to be interpreted, when the volume is high, and when the financial system lacks a straightforward entry point. In that case, you build a service with a queue between the systems, so that one side can be down without any data being lost.
Start with a preliminary study that answers four questions: which accounts represent sales, how the product is derived, what the matching key is, and what constitutes an active customer. This also sets the timeline, since the lead time in this type of project lies in access and the data model—not necessarily in the development phase.
Is your sales data stuck in the financial system while your salespeople work in the CRM? Book a 20-minute session, and we’ll show you exactly what that would look like for your business.