The prices in HubSpot were wrong. The product records weren't updating. And after trying the obvious fixes, nothing worked. What we eventually found — buried deep in NetSuite's backend and hidden in a misconfigured field — explains why the standard approaches all failed.
100%
Data Accuracy
6,000+
Products Corrected
0
Manual Updates Needed
The Problem
This client runs a large product catalogue through NetSuite and uses HubSpot as their CRM. The two systems are connected — when a product is updated in NetSuite, those changes are supposed to flow through to HubSpot automatically.
The problem was that the prices in HubSpot were wrong. Not slightly off — wrong in a fundamental way. NetSuite holds two separate prices for products: a base price, which is the wholesale rate used for trade orders and internal purposes, and an online price, which is the actual retail price shown on the website.
The sync had always been pulling the base price — the wholesale rate — into HubSpot. So the entire product catalogue in the CRM was populated with prices that were never intended for retail. Sales teams using HubSpot were quoting incorrect figures. Reports based on product pricing were inaccurate. The problem had been there for a long time without anyone realising why.
On top of that: even when we tried to fix it, the products weren't updating at all. Records in HubSpot were staying stale no matter what changes were made in NetSuite. Something in the sync was silently failing — and failing completely.
"The standard fixes weren't working. The prices couldn't be found through normal means, and products weren't updating no matter what we tried. Both problems had the same root cause: the wrong data was being used as the reference point, and that reference point was invisible until we went looking in the right place."
The Investigation
Before we could fix anything, we needed to understand what was actually going wrong. What we found were two separate problems — each invisible unless you knew exactly where to look.
In NetSuite, product pricing is stored in what's called a pricing matrix — a table that can hold multiple price levels for different customer types, quantities, and currencies. The "Online Price" was in this matrix, but it wasn't accessible through the usual methods.
We tried the standard approaches — the typical scripts for pulling pricing data, the documented API fields, the visible configuration options. None of them returned the online price. It simply didn't appear through any of the normal routes.
We eventually found it by going into the browser's developer tools while on the product page in NetSuite and logging the underlying data structures directly from the console. The online price was sitting on a specific line in a hidden sublist — line 552 of the pricing table, to be precise — in a part of the system that isn't exposed through the standard interface. That was the only way to locate it. Once we had it, we could work with it.
The second problem explained why products were never updating — even when we pushed changes through. The HubSpot-NetSuite integration was configured to match products between the two systems using the SKU field. A product in NetSuite would look for its counterpart in HubSpot by comparing SKU codes.
The issue: the SKU field in their setup was empty. It had never been populated. So every time the sync ran, it tried to match products on a blank field — which matched nothing — and the update quietly failed. With over 6,000 products and variations, this had been silently broken the entire time.
When we looked at the product data more carefully, the answer was right there: in their NetSuite catalogue, the product's name was being used as the unique identifier that HubSpot actually expected. The integration just needed to be told to match by product name instead of SKU — a single configuration change that unlocked the entire sync.
The Solution
Once both problems were understood, the fixes were clear. We built a permanent, automated architecture so that neither issue could come back.
We wrote a custom NetSuite script (a SuiteScript User Event Script) that activates every time a product record is saved. The script goes directly to the correct location in the pricing matrix — the specific line where the online price lives — extracts the value, and copies it into a new, dedicated custom field we created called "HubSpot Online Price."
This means the correct retail price is always available in a clean, accessible field that the integration can read reliably. No manual steps. No complex formulas. Every time someone updates a product in NetSuite, the right price flows through automatically.
We updated the HubSpot-NetSuite connection to match products by Item Name instead of SKU. This single change meant that every product in the catalogue now had a reliable match point between the two systems — and the silent update failures stopped immediately.
We also updated the sync settings to cover the entire product catalogue rather than individual variations, so all 6,000+ products could be kept in sync — not just a subset.
Once the fixes were in place, all 6,000+ product records needed to be updated at once to populate the new pricing field for the first time. This created a short-lived issue: the product feed that picks up changes was designed to handle a few hundred records at a time. When thousands of changes suddenly arrived, it temporarily overwhelmed the system.
This looked alarming initially — the feed appeared to crash — but it was a one-time consequence of correcting years of missing data in a single pass. Once the system caught up and processed the backlog, everything settled. From that point on, only the products that have actually changed are updated on each cycle, keeping the volume well within normal limits.
The Results
100%
Data Accuracy
Every product in HubSpot now shows the correct online retail price, sourced directly from NetSuite.
6,000+
Products Corrected
The entire catalogue was updated and is now kept in sync automatically on every product save.
0
Manual Updates
The automation handles everything. Price changes in NetSuite flow through to HubSpot without any human intervention.
HubSpot-NetSuite integration issues like this are more common than most businesses realise — often because the problems fail silently. This project is relevant if any of the following sounds like your situation:
Prices in HubSpot don't match what's on your website or what your sales team expects
Product updates in NetSuite don't seem to be reaching HubSpot, or take a very long time
You have a HubSpot-NetSuite integration that was set up a while ago but has never worked quite right
You have multiple price levels in NetSuite (trade, retail, online) and the wrong one is being used
Your team manually corrects prices in HubSpot after NetSuite updates — a recurring, time-consuming task
You have a large product catalogue (hundreds or thousands of SKUs) and data quality is inconsistent
These problems are common because NetSuite is a powerful but complex system, and the default integration settings often don't account for how businesses actually structure their data. We've worked with NetSuite SuiteScript and HubSpot integrations across a range of industries — if your sync isn't behaving the way it should, we can find out why.
The integration was set up to pull a price from NetSuite — and it did, successfully. The problem was that it was pulling the wrong price field. From the integration's perspective, everything was working correctly. The base price was a valid number. No errors were logged. The only way to spot the problem was to compare the HubSpot prices to what was actually on the website — which is exactly how the client eventually noticed something was wrong. Silent data quality issues like this are common in integrations with complex pricing structures.
A SuiteScript User Event Script is a piece of custom code that runs automatically inside NetSuite when a specific action happens — in this case, whenever a product record is saved. It's the right tool because it means there's no scheduled job to worry about, no manual triggers, and no lag. The moment someone changes a price in NetSuite and saves the record, the script runs, extracts the correct value, and puts it in the right place. It becomes part of the product save process itself.
When we first activated the fix across all 6,000+ products, every record was updated at once to populate the new pricing field. The product feed that pushes changes to HubSpot was designed to handle a few hundred records per cycle — not thousands simultaneously. When the large batch hit, it temporarily overwhelmed the queue and the feed appeared to crash. This was a one-time event, not a recurring problem. Once the system processed the backlog, it returned to normal operation. Going forward, only products that actually change trigger updates, so the volume stays well within normal limits.
Yes. The same SuiteScript architecture can extract any field from NetSuite — inventory levels, product categories, B2B classifications, custom attributes — and make them available to HubSpot through the same sync. For this client, the immediate priority was pricing accuracy, but the framework we built can be extended to sync additional data without significant rework. If you need to bring customer categories, product types, or any other NetSuite data into HubSpot, the pattern is the same.
The quickest check: pick 10–20 products at random and compare the price, stock level, or any other synced field between NetSuite and HubSpot. If they match consistently, the sync is working. If they differ — even on just a few products — there's likely a matching or field-mapping issue. You should also check the sync logs in your HubSpot-NetSuite connection settings: a healthy sync shows recent timestamps on all object types. A sync that hasn't run recently, or that shows queued errors, is a sign something needs attention. We offer integration health audits for businesses that want a systematic check without the manual product-by-product comparison.
We'll review your integration and tell you exactly what's syncing correctly, what isn't, and what it would take to fix it. No jargon, no guesswork.