Unified.to
All articles

What is ERP integration?


August 13, 2026

ERP integration is the work of connecting your product to your customers' ERP platforms, such as NetSuite, SAP S/4HANA Cloud, or Microsoft Dynamics 365 Business Central, so your application can read and write their financial, employee, inventory, order, and fulfillment data. An ERP is not one data category. At Unified, ERP includes the HR & Directory, Accounting, E-Commerce, Shipping, and Payment APIs: one authorized connection to a customer's ERP serves every one of those category APIs, across 452+ integrations as of August 2026.

Why is an ERP not a single integration category?

An ERP is a suite, so its data belongs to several categories at once. NetSuite holds a general ledger, but it also holds employee records, purchase orders, inventory, and shipments. Treating "ERP" as one flat category forces every one of those data types through a single generic schema, and the schema can only be as deep as its shallowest member.

Unified models it the other way around: the ERP is one integration, and each kind of data it holds is served through the category API built for that data.

ERP domainUnified category APIObjects
General ledger and financialsAccountingaccount, journal, transaction, invoice, bill, credit memo, vendor credit, expense
Financial statementsAccountingbalance sheet, trial balance, cash flow, aged receivables, aged payables
Orders and procurementAccountingorder, purchase order, sales order, quote
People and org structureHR & Directoryemployee, group, location, time off, attendance, payslip
Catalog and inventoryE-Commerceitem, item variant, collection, inventory, sales channel
FulfillmentShippingshipment, label, tracking, rate, carrier
Money movementPaymentspayment, refund, payout, subscription
One placement worth knowing before you scope: orders live in the Accounting API, not E-Commerce. The [E-Commerce API](/commerce) carries the catalog and stock; the order, purchase order, and sales order objects sit with the ledger they post to.

The same pattern is the honest trade of the composition approach. A single flattened ERP schema gives you one model to learn; five category APIs give you deeper models and a discovery cost, because you have to find which category holds the data you need and join identity across them. The capability matrix and the category docs exist to pay that cost down before you build rather than during it.

How does ERP integration work through a unified API?

One authorized connection to the customer's ERP carries every category that integration supports, and your application calls each category-scoped API with the same connection ID. NetSuite, for example, is live in all five: when a customer authorizes NetSuite once, your accounting API calls, your employee reads, your catalog and payment reads, and your shipment tracking all run through that single authorization. Which categories each platform spans is on its integration page, and it varies: Microsoft Dynamics 365 Business Central serves the accounting and HR APIs, while Unit4 ERPx adds commerce and payments.

Requests are routed directly to the source API. Unified is a real-time pass-through system rather than a fetch-and-store system: there is no copy of your customer's ledger or employee records sitting in a vendor database between your application and the ERP. Reads transform in memory, and a write is applied against the system of record when you make it, not on a sync cycle. For a ledger, that distinction is the whole product: an invoice your application creates exists in the customer's ERP when your request returns, so a report run that afternoon reflects it.

For anything outside the unified data models, every object returns the original provider fields in raw, and the Passthrough API reaches any endpoint the ERP's own API offers, on the same connection and the same authorization. That matters for ERPs specifically, because ERP surface area is enormous and no unified schema covers all of it.

Does the data model handle multi-entity ERPs?

The accounting objects are built for multi-entity structures, which is much of what makes a platform an ERP rather than a bookkeeping tool. The organization object carries a parent_id for entity hierarchies and an is_elimination flag for elimination entities, and ledger objects carry an organization_id, so transactions, invoices, and reports resolve to the entity they belong to rather than collapsing into one book.

What can you build with ERP integration?

The four builds the ERP surface serves most directly:

  • Employee directory sync. Read employee profiles, departments, and reporting structures from the ERP's HR module, in the same employee objects your HRIS integrations return.
  • Invoices and GL. Read and write AR/AP and journal entries against the customer's ledger, and read financial statements, through the accounting API.
  • Catalog, orders, and inventory. Read items and stock through the e-commerce API, and orders through the accounting API, so operations and financials agree.
  • Shipment tracking. Create labels and track shipments through the shipping API, so fulfillment state lives next to the order it belongs to.

Which ERP platforms does Unified support?

The live integration directory is the current source, and as of August 2026 it includes NetSuite, SAP S/4HANA Cloud, Microsoft Dynamics 365 Business Central, Microsoft Dynamics 365 Finance and Operations, Acumatica, Oracle Fusion ERP, Sage Intacct, Epicor Kinetic, Unit4 ERPx, Visma.net ERP, and Intuit Enterprise Suite, alongside the accounting, HR, commerce, shipping, and payment platforms the same five category APIs serve. Which objects and fields each platform supports is documented per integration, and coverage differs by platform because each ERP's own API determines what Unified can support.

How do other unified APIs handle ERP?

Three approaches exist in the market. Some vendors offer an ERP-labeled API: Apideck's ERP surface sits over its Accounting API rather than being separately documented, backed by genuine accounting depth including bank feeds, in beta across 9 ledgers as of August 2026; the full breakdown is in Apideck vs Unified.to. Some provide infrastructure to build your own: on Nango, you define your own data models and write TypeScript functions per integration, which is real engineering investment and real control, and the right trade when a customer's tenant-specific NetSuite configuration has to show up faithfully in your product; that comparison is in Nango vs. Unified.to.

Unified takes the third approach: no ERP label and no mapping code, five deep category APIs on one connection, with the per-integration capability matrix published before you build. A fourth option sits outside the unified API category entirely: embedded iPaaS platforms such as Paragon reach the same underlying ERP APIs through per-vendor actions and a workflow engine rather than a normalized data model, a different product for a different problem, covered in Paragon vs. Unified.to. The approaches can also coexist; some teams use a managed unified API for category breadth and build-your-own infrastructure for the one integration where native depth is the requirement.

Start your 30-day free trialBook a demo

FAQ

Does ERP integration include writing data back? Yes, where the object and the ERP's own API support it. Invoices, bills, journals, employees, items, and shipments all carry create and update methods, and a write is applied against the ERP directly rather than landing in an intermediary database first. Which fields are writable on which platform is in the per-integration documentation.

Do I need separate connections for accounting and HR data from the same ERP? No. One authorized connection carries every category the ERP integration supports, and each category API is called with the same connection ID.

Is ERP a category in the Unified API? No, and that's deliberate. ERP at Unified is the HR & Directory, Accounting, E-Commerce, Shipping, and Payment APIs together on one connection, so each kind of ERP data gets the deep model built for its category instead of one flattened ERP schema. Some vendors market an ERP-labeled API; the question to ask any of them is which model an employee record, a shipment, or a payment comes back in, and whether it's the same model that serves their dedicated category for that data. The label matters less than what a read returns.

What if the data I need isn't in the unified models? Every object returns the original provider fields in raw, and the Passthrough API reaches any endpoint of the ERP's API on the same connection.


Author

Written for Unified.to by Mallory Greene

About the author: Mallory Greene is a writer specializing in generative engine optimization (GEO) and content, through her practice Search Everywhere. She covers integration infrastructure and technical content across Unified.to's technical content library. Based in Toronto.

All articles