Getting two systems to exchange records is a week of work. Keeping them agreeing eighteen months later — through duplicate companies, renamed products, timeouts mid-write, an edit made in both places at once — is a design problem. Twopir Consulting decides system of record field by field, makes identity deterministic and writes idempotently. So a retry never creates a second order.
Trusted by 500+ organizations — including distributors, manufacturers and field-service businesses running HubSpot in front of an ERP with Twopir Consulting.
Synchronization Coverage
None of these break on day one. They accumulate, and the first person to notice is usually a customer or a finance lead at month-end. Every one is a design decision that was never made.
Someone corrects a billing address in HubSpot, someone else corrects it in SAP Business One, and the next sync overwrites one with the other. Nobody knows which version is right, so people stop trusting both.
“ABC Manufacturing” and “ABC Manufacturing Pvt Ltd” are the same customer to a human and two customers to a matcher. The duplicates only surface when the statement of account does not add up.
The request timed out, so the integration retried. But the first call had already created the document, and now there are two sales orders for one deal. The ERP is correct; the integration was not.
A record was rejected by SAP, logged, and forgotten. There is no queue anyone reviews, no alert with the record's name on it, and no procedure for replaying it once the underlying data is fixed.
Every field is configured to sync immediately. Under load, the queue backs up, genuinely urgent updates sit behind stock counts that nobody needed to the second, and the whole thing slows down.
There is no reconciliation. The first evidence of drift is a customer question, a finance month-end, or a report that two people read differently in the same meeting.
An integration is a connection. Synchronization is a set of guarantees about what that connection does to your data over time.
SAP Business One HubSpot data synchronization is the design that keeps shared records consistent across a CRM and an ERP over time: which system owns each field, which direction each record moves, how the two systems recognise the same entity, how often data moves, what happens when a write fails, and how you prove afterwards that the two still agree.
It is not the same as an integration. An integration is a connection; synchronization is a set of guarantees about what that connection does to your data. The three that matter are identity, ownership and idempotency. Identity means each system can find the other's record deterministically. Ownership means exactly one system decides each field. Idempotency means processing the same event twice produces the same result as processing it once.
There is also a structural difference worth naming early, because it shapes the design: SAP Business One is company-first and HubSpot is contact-first. SAP hangs Contact Persons off a Business Partner; HubSpot treats Contacts as first-class records that may be associated with a Company, or with none. A sync model that ignores that asymmetry produces orphaned contacts in one system and unreachable ones in the other.
The starting matrix for a first build. Yours will differ, and the differences are the interesting part — particularly the row where ownership switches from sales to finance.
| Data | System of record | Direction | Cadence | Why |
|---|---|---|---|---|
| Customer identity — CardCode | SAP Business One | SAP → HubSpot | On creation, then on change | Created by SAP when the Business Partner is first written; stored on the HubSpot Company so the link is readable from either side. |
| Company name, address, tax ID | Usually HubSpot until first order, then SAP | Switches | On change | A common and deliberate switch: sales owns the prospect record; finance owns the customer record. The switch point is a business rule, written down. |
| Contact details | HubSpot | HubSpot → SAP | On change | Sales and marketing maintain these. SAP receives them as Contact Persons under the correct Business Partner. |
| Product catalogue — ItemCode | SAP Business One | SAP → HubSpot | Scheduled, typically daily | The ERP defines what exists and what it is called. HubSpot Products mirror it. |
| Price lists | SAP Business One | SAP → HubSpot | Scheduled | Pricing rules, currency and customer-specific lists stay in the ERP. Sending a price back the other way invites disagreement no CRM can settle. |
| Stock availability by warehouse | SAP Business One | SAP → HubSpot | Scheduled, hourly or better | Rarely needs to be accurate to the second. Decide how stale is acceptable, and what a rep should do when the number is wrong. |
| Deal / opportunity state | HubSpot | HubSpot → SAP on trigger only | Event-driven | The ERP does not need the pipeline. It needs the one event where a deal becomes a committed order. |
| Sales order — DocEntry DocNum | SAP Business One | Created by HubSpot event | Event-driven | HubSpot triggers creation; SAP owns the resulting document and its number. The DocNum is written back so the deal can be traced to it. |
| Delivery and A/R Invoice status | SAP Business One | SAP → HubSpot | Event-driven or frequent schedule | What sales and customer success need to see without opening the ERP. |
| Payment status and balance | SAP Business One | SAP → HubSpot | Scheduled, typically daily | Enough for an account manager to know before a renewal call that an invoice is overdue. |
Scroll the table sideways to see every column
Each side stores the other's identifier. Everything else on this page depends on these five rows being right. Name matching is not an acceptable substitute.
| Record | Native key | Cross-reference stored | What it makes possible |
|---|---|---|---|
| SAP Business Partner | CardCode | HubSpot Company ID, held in a user-defined field such as U_HubSpotId | Both sides can resolve the other without searching on name. |
| HubSpot Company | Record ID | CardCode, held in a dedicated HubSpot property | Makes the ERP customer number visible to the people talking to the customer. |
| SAP Item | ItemCode | HubSpot Product SKU or a dedicated mapping property | Product-name matching is the second most common source of silent duplicates. |
| HubSpot Deal | Record ID | Stored on the SAP sales document in a user-defined field | This is what makes the write idempotent: before creating, check whether a document already carries this Deal ID. |
| SAP Sales Order | DocEntry internal, DocNum human-facing | Written back to a HubSpot Deal property | Gives support and finance a shared reference. The two are not interchangeable and should not be stored in one field. |
Scroll the table sideways to see every column
Real-time is not free and it is rarely necessary. Choosing cadence per field group is what keeps a queue from backing up under load.
| Mode | How it works | Use it for | Trade-off |
|---|---|---|---|
| Event-driven | A HubSpot webhook, or a change detected on the SAP side, pushes the record immediately. | The one event that must not wait: a deal becoming a committed order. | Every event-driven field adds load and a failure path. Reserve it for what genuinely cannot wait. |
| Near-real-time polling | A frequent cycle — every few minutes — picking up what changed. | Document status that people watch, such as delivery and invoice state. | Simpler and more forgiving than webhooks, at the cost of a small, predictable lag. |
| Scheduled batch | A daily or hourly run over a defined set. | Catalogue, price lists, stock levels, payment balances. | The right default. Ask what breaks if this is an hour stale; usually the honest answer is nothing. |
| On-demand | A user or an operator triggers the sync for one record. | Re-syncing a corrected record, or resolving a support question without waiting for the next cycle. | Needs a permission model. Not everyone should be able to push a record into the ERP. |
| Reconciliation sweep | A periodic comparison that reports differences rather than writing. | Proving the two systems still agree, and catching drift the error queue never saw. | Read-only by design. It reports; a human decides what to do about a difference. |
Scroll the table sideways to see every column
Identity, idempotency and provable agreement. Every other data problem on this page is downstream of one of the three.
Every synced record carries an explicit cross-reference in both directions, so neither system ever has to guess which record is which.
Processing the same event twice produces the same result as processing it once — which is what makes a retry safe.
Not “it seems fine” but a periodic comparison you can show a finance lead.
Five steps, all before build. The last one — designing the failure path — is the one most often skipped and most often regretted.
Every field both systems hold in common, listed. Including the ones people maintain in spreadsheets because neither system was trusted.
Exactly one system owns each field. Where ownership switches — prospect to customer — the switch point is written down.
The cross-reference strategy: which key, stored where, and what happens when no match is found.
Per field group: event-driven, near-real-time, scheduled or on-demand. Defaulting to real-time everywhere is how queues back up.
Error classification, retry policy, replay authority, alerting and the reconciliation sweep — before build, not after the first incident.
These are the questions that surface in month six if they are not answered in week two, usually in the form of a record nobody can explain.
SAP hangs Contact Persons off a Business Partner; HubSpot treats Contacts as first-class. The sync model has to decide what happens to a HubSpot contact with no company, and to a SAP contact whose partner is merged.
Marketing engagement data has no place in an ERP, and journal detail has no place in a CRM. A smaller, deliberate field set is more reliable than a large accidental one.
A deleted HubSpot company must not delete a Business Partner with posted documents against it. Deletes are usually handled as deactivation and flagged for a human.
An integration with no errors and no traffic looks identical to one that stopped running. Monitoring watches for absence, not only for failure.
These are design patterns, not client metrics — we publish numbers only where a specific engagement has measured them. The case study beside them is real and linked.
The integration looks up the SAP Business Partner by the stored cross-reference, not by name. If there is no match, the rule says whether to create, queue for review, or stop — and that rule was decided in design.
Before creating a sales order, the engine checks whether a SAP document already carries this Deal ID. If it does, the existing DocEntry is reused and logged. A timeout stops being dangerous.
The company record is HubSpot's while it is a prospect and SAP's once it is a customer with posted documents. One system owns it at any moment, and everybody knows which.
A scheduled read-only sweep compares the two systems and reports differences. It never auto-resolves: a difference is information for a person, not an excuse to overwrite.
Quote and order data kept consistent across CPQ and the systems around it. Different platform pair, the same data discipline this page describes: one owner per field, deterministic identity, and writes that can be repeated safely.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. A sync that drifts costs more in lost trust than in lost records, because people stop believing either system.
Not system by system. Most real designs switch owner partway through a record's life, and pretending otherwise is what produces the overwrite arguments.
Deterministic cross-references in both directions. This is the single most common reason a CRM-ERP sync degrades after the first few months.
Existence checks before create on every financially significant document. It is much cheaper than the reconciliation project that follows a week of duplicates.
Real-time where it earns its cost, scheduled everywhere else. A queue that never backs up is worth more than a dashboard that claims to be live.
A read-only reconciliation sweep you can show a finance lead. We help growing and mid-market companies solve complex CRM, integration, and business system challenges.
Directionality, duplicates, idempotency, cadence and reconciliation — the five that decide whether the sync holds.
Per field, yes — per system, almost never. Two-way at the record level, with one owner per field, is the design that holds up. Two-way at the field level, where either system may overwrite the other, is what produces the arguments about whose address is correct.
In practice the split settles quickly: HubSpot owns contact and engagement data, SAP Business One owns catalogue, pricing, documents and financial state, and the company record switches owner when a prospect becomes a customer. The matrix above is where that gets written down.
By never matching on name. Each side stores the other's identifier — CardCode on the HubSpot Company, the HubSpot ID in a SAP user-defined field — so resolution is a lookup rather than a guess.
Where no cross-reference exists yet, matching falls back to an agreed deterministic key such as a tax identifier, and if that fails the record is queued for a human rather than created speculatively. Creating on a weak match is how you get two Business Partners for one customer and a statement of account that does not add up.
That processing the same event twice produces the same result as processing it once. Concretely: before the integration creates a sales order, it checks whether a SAP document already carries that HubSpot Deal ID. If one does, the existing reference is reused; if not, the document is created and its DocEntry is logged against the deal.
This matters because a timeout is not proof that nothing was written. The request may have succeeded and the response been lost. Any integration that retries without an existence check will eventually create a duplicate order, invoice or payment — and those are not cosmetic.
No, and designing it that way is usually a mistake. Real-time costs load, adds failure paths and puts urgent updates behind unimportant ones when the queue backs up.
The useful question is not “how fast” but “how stale is acceptable, and what does someone do when the number is wrong”. Order creation is genuinely event-driven. Stock, price lists and payment balances are almost always fine on a schedule, and saying so out loud in design saves a lot of infrastructure.
It goes to an error queue with the reason classified — transient, data, or configuration — because those want different responses. Transient errors retry under policy. Data errors alert with the record named, so someone can fix the underlying problem. Configuration errors escalate, because retrying will not help.
Then there is a replay procedure with a named owner and a permission model. A failure that sits in a log nobody reads is the same as data loss, just slower to discover.
Explicitly, in the mapping. SAP Business One hangs Contact Persons off a Business Partner, so a contact without a partner has nowhere to live. HubSpot treats Contacts as first-class records that may have no associated Company at all.
The design decides what happens to a HubSpot contact with no company — usually it does not sync until it has one — and what happens to SAP contacts when Business Partners are merged. Skipping this produces orphaned records on one side and unreachable ones on the other.
A scheduled reconciliation sweep: a read-only comparison across an agreed set — record counts, key financial totals, identifiers present on both sides — that reports differences without changing anything.
It is deliberately read-only. A difference is information for a person to act on, not a licence for the integration to overwrite one system with the other. It also catches the class of drift the error queue never sees, because nothing failed — it simply never ran.
Usually, and it is a common starting point. The work is in two parts: stop the production of new duplicates by fixing the identity and idempotency design, then merge what already exists.
The merge is the careful half, because SAP Business Partners with posted documents against them cannot simply be deleted. That part is planned with your SAP partner and sequenced so financial history stays intact.
Four companion pages. This one covers the data model; the others cover architecture, delivery, commercial scope and custom work.
The fastest way to improve a CRM-ERP sync is usually not more automation — it is settling ownership, identity and cadence explicitly. Bring your current setup and we will work through the matrix with you.
Talk through ownership, identity and reconciliation with an architect
