HubSpot + SAP S/4HANA integration

In a company that runs SAP, the ERP usually arrived years before HubSpot and is guarded by a team whose job is to keep it stable. The business partner, the sales order and the billing document live there, beside the credit limits and delivery blocks that decide whether an order ships at all. HubSpot tends to arrive later, bought by a sales or marketing team that wanted a CRM its people would actually open, and within a month somebody asks why the portal cannot see what a customer has ordered.

The requests that follow are specific. Sellers want open orders, delivery status and billed revenue on the company record before a call. Account managers want to know which customers are blocked before promising anything. Finance wants a new customer created once, in SAP, with the right sales area and payment terms, instead of typed twice by two teams who disagree about the spelling.

Timing shapes the design as much as the mapping does. SAP has committed mainstream maintenance for SAP ERP 6.0, the release most buyers call ECC, only to the end of 2027, with optional extended maintenance to the end of 2030. An integration built against ECC’s interfaces today gets rebuilt when that system moves to S/4HANA, so the part worth protecting is the HubSpot side: objects, keys and history that do not care which SAP release feeds them.

Five objects carry the account view. Business partners with the customer role become HubSpot companies, their contact persons become contacts, sales orders become deals, billing documents land on a custom object, and products become HubSpot products.

S/4HANA makes the business partner the leading object, and the customer is a role that partner holds, with a customer number of its own. Sales orders name the customer as the sold-to party, so we store both numbers on the company and associate each document on the number it carries. Older SAP ERP systems can hold customers with no business partner at all, which SAP’s own IDoc guidance allows for, and that is one more reason to check the key again after a conversion.

A customer also has one sales area row for every sales organization, distribution channel and division it trades in. Those rows describe a single company and never become companies of their own.

Data flows into HubSpot only. Pricing, credit, delivery blocks and billing belong to S/4HANA, and a CRM that edits them creates work for the people who run the ledger. A won deal can create a sales order through the Sales Order API, and we keep that for a second phase with a review step in front of it.

S/4HANA gets a watermark sync, with events in front of it where the client runs SAP Event Mesh. A service signs in as the communication user of a communication arrangement and reads each released OData API on a schedule. It filters on the change fields SAP publishes: LastChangeDateTime on sales orders and billing documents, and LastChangeDate with LastChangeTime on business partners. Each entity keeps its own watermark inside the service, and a restart picks up from it.

Where S/4HANA publishes business events, business partner and sales order events land on an Event Mesh queue, and a webhook subscription pushes them to our endpoint. The events carry keys, not records, so each one queues a read of the full record. The scheduled read keeps running behind the events and catches anything they miss.

The HubSpot writer upserts in batches on the SAP numbers, then a second pass links orders to companies through the sold-to party and billing documents to their orders. Either pass can be rerun over the same window with no effect, so replaying a bad day costs time and nothing else.

Two facts pick the route on SAP: the release you run, and what your SAP team already operates. Object count matters less.

On S/4HANA, in the cloud or on premise, a custom API integration against the released OData APIs is the route we recommend. The APIs are documented on the SAP Business Accelerator Hub, each belongs to a communication scenario the SAP team already governs, and events can sit in front of them later.

Where the client already licenses SAP Integration Suite, its flows can do the SAP-side work, including reading ECC through OData Provisioning, and hand clean records to the HubSpot writer. That keeps SAP logic with the people who own it.

The generic connector from the marketplace is the third option, and a fair one for a simple mapping, but it does not change what the SAP side has to expose. On ECC without Integration Suite, the interfaces are BAPIs over RFC and IDocs, usually through middleware the client already runs, and the work moves into the enterprise band.

1. Scope. We start with the SAP team: release and edition, which communication scenarios are in place, whether Event Mesh or Integration Suite already runs, and how many sales areas trade.
2. Architect. We fix the keys, the watermark per entity, the event path and the association order, and write them up as the communication arrangement request.
3. Build. We write the service against the quality or test system, and it refuses any SAP host or HubSpot portal that is not on its allowlist.
4. Validate. We reconcile customers, open orders and billed totals against SAP reports, including a same-day partner edit and a deleted order.
5. Operate. Cutover changes the host and the communication user. After that we watch run history and queue depth, and re-test in the test system before each SAP release reaches production.