Short answer. Yes, NetSuite integrates with Dynamics 365 (Business Central or Finance & Operations) and with SAP (Business One, ECC or S/4HANA). The route depends on which Microsoft or SAP product you run, which records must move, and who owns each record. A first live flow usually takes weeks, not months; a full multi-entity hybrid programme takes longer.
Hybrid is a strategy, not a failure
Most groups do not choose to run two ERPs. It happens to them. A NetSuite group buys a company that runs Dynamics 365 Business Central. A corporate SAP landscape spins off a business unit onto NetSuite. Shared-services finance consolidates on one ERP while local operations keep the system that knows their warehouses, statutory reporting and tax rules.
There is plenty of good material on migrating from Dynamics or SAP to NetSuite, and sometimes migration is the right answer. But a migration done under time pressure, before the acquired business is understood, is how groups end up with a new ERP full of bad data. If coexistence will last two or three years, treat it as the plan and build the bridge properly.
That does not rule out a single ERP later. A well-designed bridge makes the eventual cutover easier, because it forces the questions a migration also has to answer: which system owns the customer, how accounts map, which item codes are real. When the day comes, the discipline in data migration is the project still applies.
What usually has to move between the ERPs
The first design decision is not the tool. It is which records cross the boundary, in which direction, and which system has the last word on each.
| Domain | Typical direction | What decides the design |
|---|---|---|
| Customers and vendors | From the owning ERP to the other, rarely both ways | One owner per record, a shared key, and what happens when both sides edit the same field |
| Items and pricing | From the ERP that owns the catalogue | Item code mapping, units of measure, which attributes the receiving side actually needs |
| Sales orders, purchase orders, invoices | From where the transaction happens to where it is fulfilled or booked | Status updates coming back, partial shipments, credit notes |
| Inventory positions | Summaries, rarely every movement | How fresh the figure must be, and whether a daily snapshot is enough |
| Intercompany transactions | Both sides, as matching entries | Both legs agreeing on amount, currency, date and counterparty |
| Chart of accounts and dimensions | Mapping, not sync | A maintained mapping table from local accounts to the group chart; see one chart of accounts across subsidiaries and currencies |
| Consolidation feeds | Subsidiary ERP to the consolidating ERP | Period close timing, trial balance or journal level, FX rates |
Sometimes a CRM sits in the middle as well: Salesforce feeding orders to both ERPs, or holding the customer master. That changes who owns the customer, not the logic above. Keeping one customer record consistent across two systems is its own problem, covered in one customer record, two systems.
Dynamics 365 with NetSuite: Business Central and Finance & Operations
"Dynamics 365" names two different ERPs, and the integration looks different for each.
Business Central is the one we see most often next to NetSuite: a subsidiary or an acquired company runs BC while the group runs NetSuite, or the reverse. Business Central exposes a standard REST API (v2.0). One detail matters for scoping: Microsoft's documentation states that the standard APIs cannot be extended with additional fields; if you need a custom field, you copy the AL code of the API and publish a custom API (Microsoft Learn, API v2.0 for Business Central, checked 29 Sep 2026). Any customisation of the BC side therefore shows up in the integration estimate.
Finance & Operations (Finance, Supply Chain Management) is a larger system with a different surface. Data entities marked public are exposed through an OData endpoint for create, read, update and delete (Microsoft Learn, OData, checked 29 Sep 2026). For file-based and bulk scenarios Microsoft offers the Data management package API and the recurring integrations API (Microsoft Learn, Data management package REST API, checked 29 Sep 2026). Which one fits depends on volume and timing, which is why F&O projects start with discovery.
On the platform side, Celigo lists support for both Business Central and Finance & Supply Chain Management, and publishes a Business Central – NetSuite integration template whose included flows are BC invoices to NetSuite invoices and BC accounts to NetSuite customers (Celigo, Business Central – NetSuite template, checked 29 Sep 2026). That is a starting point, not a full hybrid design: items, orders, intercompany and consolidation feeds are still yours to scope.
Is MuleSoft overkill here?
Often, yes. If the scope is a narrow Business Central ↔ NetSuite or Business Central ↔ Salesforce flow and your group does not already run MuleSoft, an enterprise API-led platform brings more operational weight than the problem needs. If MuleSoft is already the group standard, with the team and the contract in place, building on it can be the sensible choice, and we will say so. Match the weight of the tool to the landscape. The longer version of that trade-off is in our Heroku Connect vs Celigo vs MuleSoft decision framework.
SAP with NetSuite: Business One, ECC and S/4HANA
SAP is also several products, and each has a different integration shape.
- SAP Business One is common in smaller subsidiaries. It is usually integrated through its Service Layer, a web API over the Business One objects, or the older DI API.
- SAP ECC landscapes typically exchange data through IDocs, BAPIs and RFCs, often behind middleware the group already runs.
- SAP S/4HANA adds a published catalogue of OData and SOAP APIs, listed on the SAP Business Accelerator Hub (checked 29 Sep 2026).
What we do not do is pretend to be an SAP partner. We are not one. Our strength is the NetSuite side (records, subsidiaries, intercompany, SuiteScript, the REST and SOAP web services) and the integration layer itself. On the SAP side we work with your SAP team or partner, against interfaces they expose and support. When an SAP landscape has no stable interface for the data you need, we tell you before the project starts, not in week six.
Prebuilt coverage is thinner here than for Business Central. Celigo's SAP page lists prebuilt integrations such as SAP Business Network – NetSuite and Loop Returns – SAP Business One (Celigo, SAP integration, checked 29 Sep 2026), not a packaged SAP ERP ↔ NetSuite flow. Expect NetSuite ↔ SAP ERP flows to be built on the platform's generic connectors or written against the APIs.
Four ways to build the bridge
We build integrations four ways, and the choice follows the case: volume, the latency you actually need, whether data may leave your infrastructure, and what your team will maintain afterwards (our integration approach).
| Route | Fits a hybrid ERP bridge when | Watch out for |
|---|---|---|
| Celigo (iPaaS) | You want vendor-backed connectors and monitoring for scheduled or event-driven ERP flows | Prebuilt templates cover a slice; the rest is configured on top |
| n8n (orchestration) | The process has steps, branches and approvals across several systems, or must run self-hosted | It orchestrates; it is not a data-sync engine |
| Custom, written against the APIs | No platform fits, or you want no third-party licence in the middle | You own the code, so documentation and monitoring must ship with it |
| Stacksync (real-time sync) | A CRM or database edge needs sub-second, two-way sync next to the ERPs | Usually secondary in an ERP-to-ERP bridge |
If your group already owns an enterprise iPaaS such as MuleSoft or Boomi, the comparison is at capability level: connector coverage for your specific Dynamics or SAP product, how errors are surfaced and retried, who in your team can change a mapping, and what it costs to run. We do not score platforms we are not implementing for you. For the general trade-off between platforms, point-to-point code and middleware, see iPaaS vs point-to-point vs middleware.
One qualification on "real-time": not every ERP object needs it, and not every route delivers it. Customer and item changes can often be event-driven; consolidation feeds normally follow the close calendar; inventory is often fine as a scheduled summary. We state the latency per flow, not per project.
Governance: source of truth, conflicts and cutover
Hybrid integrations fail on governance more often than on code. Before building, we agree and write down:
- One owner per record type. Customer, vendor and item masters each have a system of record. The other side receives a copy, and edits there are either blocked or routed back.
- Conflict rules. What happens when both ERPs change the same field in the same window: which side wins, and who gets told.
- Read-only replica or dual write. A read-only copy is simpler and safer. Writing from both sides is sometimes necessary, and then every flow needs idempotency and a reconciliation report.
- Mapping tables with an owner. Accounts, dimensions, tax codes, units of measure and subsidiaries live in maintained tables, not inside flow logic.
- Monitoring from day one. Error handling, retries and alerts ship with the first flow, and someone on your side sees them.
- A sunset plan. If one ERP is meant to disappear, each flow has an end date and a cutover step, and the bridge keeps master data clean for that day.
Go-live is not the end of it. Integrations need someone watching them while the ERPs keep changing around them, which is what life after go-live is about.
Project shape and why Atypical
A typical engagement runs in this order:
- Discovery. Which Dynamics or SAP product, which entities, current interfaces, ownership rules and volumes.
- Route and design. Celigo, n8n, custom or a mix, with the governance decisions above written down.
- First live flow. Usually master data or invoices, live within weeks rather than months.
- Extend. Orders, intercompany, consolidation feeds, in the order that removes the most manual work.
- Run. Monitoring, retries, alerts and changes as both ERPs evolve, operated by us or handed over to your team with documentation.
We are integration engineers across the stack European mid-market groups actually run, not a NetSuite implementer trying to replace your other ERP. We are an implementation partner for Celigo and a partner for Stacksync, we build directly against APIs when no platform fits, and we work from Spain in English, Spanish, Portuguese and Catalan. More about the team is on about us.