HubSpot + Oracle Fusion Cloud ERP integration

Oracle Fusion Cloud ERP usually arrives as part of a finance programme: ledgers consolidated onto one cloud suite, receivables and order management standardized, and access held tightly by the people who run the close. Sales and marketing often chose HubSpot on a separate track, and the two programmes meet the first time a seller asks why a customer with a stack of unpaid invoices is still on the renewal list.

What sellers need from Fusion is narrow. They want the customer and its account numbers, the orders in flight, and which invoices are open or past due, on the company record where they already work. Finance is right to want that flow in one direction, so Fusion stays the record of what was ordered and billed and HubSpot only reads it. Nobody in sales needs a Fusion login for that, and nobody in finance wants to issue one.

An Oracle estate is not always Fusion. Some customers still run E-Business Suite or JD Edwards EnterpriseOne, sometimes beside Fusion during a phased move, and those expose different interfaces, covered in the questions below. The HubSpot side of the design does not change with them: the same objects, the same keys on Oracle’s own ids, and the same reconciliation, which is what lets a later move to Fusion swap the reader without touching HubSpot.

Four objects carry what sellers ask for. Customer accounts become HubSpot companies, sales orders become deals, receivables invoices land on a custom object with their open balance and due date, and items become HubSpot products.

The key needs the most care. Fusion keeps a customer party with one or more customer accounts under it. A sales order names the party as its buying party, while a receivables invoice carries the bill-to account number. So each HubSpot company is keyed on the party id and holds every account number beneath it; orders associate on the party and invoices on the account number. Keying the company on the account instead leaves orders with nowhere to land as soon as a party holds two accounts.

Invoices move one way and only once complete. Fusion marks an invoice as Complete, Incomplete or Frozen, and a seller should never see a figure finance has not committed to. Items come from one inventory organization agreed in discovery, because the items resource returns an item once for every organization it belongs to.

Fusion gets a watermark sync. The service holds a confidential application in the Fusion Applications identity domain and takes tokens with the client credentials grant, so no person’s password sits in the integration. For each resource it asks for records whose LastUpdateDate is later than the stored watermark, sorted on the resource’s unique id, and walks the pages until hasMore comes back false. Each resource keeps its own watermark in the service.

The HubSpot writer upserts in batches on Oracle’s ids, then a second pass associates orders to companies on the buying party and invoices on the bill-to account number. A reconciliation job compares keys and open balances per business unit every night and reports the differences instead of correcting them quietly.

Fusion can also raise business events, such as a receivables invoice being completed or paid, and deliver them to Oracle Integration. Where a client runs Oracle Integration, that event triggers an early read of the one invoice, and the scheduled read carries on behind it.

Whether the client already runs Oracle Integration shapes this choice more than anything else. Where it does, the ERP Cloud adapter can subscribe to Fusion business events and call the same REST resources, so the event half of the design can live there, with the team that owns Oracle.

Either way, the route we recommend for a first build is a custom API integration that reads the REST resources directly. It needs one confidential application and read access, and nothing else to license or run inside Oracle’s estate, which keeps the approval short.

The HubSpot App Marketplace does not offer a third way for Fusion. The JD Edwards connector from Commercient is built for JD Edwards, and no listing is named for Fusion or E-Business Suite, so a marketplace install is not an option here.

1. Scope. We confirm which Oracle ERP runs, which business units and organizations matter, and whether Oracle Integration is already licensed.
2. Architect. We fix the party key, the watermark and sort per resource, the invoice status rule and the item organization, and agree the security roles the integration needs.
3. Build. We build against the test environment, and the service refuses any Fusion host or HubSpot portal that is not on its allowlist.
4. Validate. We reconcile customers and open receivables per business unit against a Fusion report, and prove the paging with a window that changes mid read.
5. Operate. Cutover switches the host and the OAuth client. We watch run history, re-run the checks whenever a maintenance update lands in test, and adjust the mapping when finance changes a setup.