HubSpot + NCR Counterpoint integration

Counterpoint is where the money happens in a lot of specialty retail and wholesale businesses, and it is also where the money stays. The ticket history knows which accounts have slowed down, which ones pay late and which ones stopped buying a product line six months ago. None of that reaches the sales team, because the sales team does not have a Counterpoint licence and would not know which of seven hundred tables to look in if they did.

What the business gets instead is a report. Somebody in operations runs it, it lands as a spreadsheet, and by the time a rep reads it the number that mattered has changed. Accounts receivable aging is the clearest case: a rep who can see that an account is ninety days overdue has a different conversation from one who does not, and that information has a shelf life of about a week.

The second driver is the pipeline itself. A wholesale business with an open order book wants those orders visible as deals, moving through stages as they get fulfilled and paid, so that forecasting is based on what customers actually ordered rather than what a rep remembered to log. Both drivers point at the same thing: the transaction history needs to live beside the relationship, on a schedule people can rely on, without anyone opening the point of sale system.

Six things. Customers become companies, ship to addresses become a custom object, tickets become deals, ticket lines become line items, items become products, and accounts receivable transactions move the deal to a paid stage.

Two of those keys are compound. A ship to address is identified by the customer number and the address id together, because the address id repeats under every customer. A ticket line is identified by the ticket number and the line sequence number for the same reason. Getting either one wrong produces silent overwrites rather than errors, which is the worst kind of bug to find later.

Customers map to companies, not contacts. A Counterpoint customer number is an account, and in this kind of business the account is a firm with several people attached. The data has one owner and one direction. Counterpoint is the system of record for everything here, HubSpot never writes back, and nobody edits a ticket in the portal.

The pattern is a managed SQL sync. Scheduled packages read the shipped views over a read only login, map columns to HubSpot properties, and load in dependency order: companies first, then shipping locations, deals, line items and products, then the associations that tie them together. HubSpot API paths are pinned to version 2026-03.

The connection goes through an on premises agent rather than an open port. Skyvia documents a direct connection that needs the SQL Server reachable over the internet, and an agent connection that does not. Retailers take the agent, because exposing a point of sale database to the internet is not a trade anybody wants to make.

Change detection is per view rather than global. Where a view exposes a creation or modification timestamp, the package runs incrementally. Where it does not, the package reloads the whole view, which stays cheap at these record counts. The packages run in a chain, one after another, rather than on independent schedules, so a parent record always exists before a child tries to associate to it.

The decision here is unusually clear. There is no app to install, so it is a managed sync against a custom service. A service buys you real time reaction and arbitrary logic, and this data has neither requirement: the source is a nightly posting cycle, the mapping is a column list, and nothing needs to happen in the second after a sale. What a managed sync gives you instead is somebody watching the run history and fixing the package when the retailer adds a column, which is what the retailer is still paying for in five years. Pick the service only when a rule cannot be expressed as a mapping.

The Counterpoint failures worth designing against are the quiet ones.

1. Scope. We profile the database first: which views exist, which columns are populated, how many records each one holds, and which fields carry a usable timestamp.
2. Architect. We agree the object model, the compound keys and the exclusion rules before any package is built, and we confirm the connection style with the retailer’s network team.
3. Build. Packages chained in dependency order, keyed on the source identifiers, with the association fields carried through rather than added later.
4. Validate. Everything runs against a sandbox portal behind a fail closed portal allowlist, and the production cutover is a credential swap.
5. Operate. We watch the run history, reconcile counts against the source, and adjust the mapping when the retailer’s system changes, which it does.