ERP and PLM reference architecture

Overview

ION integrates with two adjacent system classes in every hardware-manufacturing stack: PLM (Product Lifecycle Management) upstream and ERP (Enterprise Resource Planning) downstream. This page is the reference for those integrations: what flows where, what doesn’t, and the recommended deployment sequence. Read this before scoping an integration with Arena, NetSuite, Teamcenter, Duro, Onshape, or any other ERP or PLM system. The per-vendor pages cover how a specific connector works; this page covers why the architecture is shaped the way it is.

Diagrams in this doc are authored in Mermaid and render natively in the manual.

ION in the factory stack

ION Factory OS is a Manufacturing Execution System (MES) at Level 3 of the ISA-95 enterprise-control hierarchy, with native production planning extending into Level 4. ION’s job is to track and document the transformation of raw materials into finished goods on the production floor, and to be the closed-loop bridge between the engineering systems that define what gets built (PLM) and the financial systems that transact what gets bought, sold, and counted (ERP). Every integration question reduces to which level owns this data, and who else needs a copy? The rules below fall out of this picture.

Why integrate at all: the business goals

Every ERP and PLM integration ION ships should trace back to one or more of these outcomes. If a proposed integration scope does not advance one of these, it is not the right scope.

Goal	What it means in practice	Where the integration lives
Proper billing with 3-way match	Vendor invoices are paid only when PO + Bill + Item Receipt match. No phantom payments, no missed receipts.	ERP ↔ ION
Inventory valuation	Finance can value on-hand and WIP inventory in dollars, with audit trail back to receipts and consumption.	ION → ERP (receipts, completions, consumption)
Accurate COGS: material + labor	Cost of goods sold is calculated from actual material consumed and actual labor recorded, not standard-cost approximations. Critical for cost-plus contracts and gross margin reporting.	ION → ERP (consumption + labor)
Reduce ERP seat license cost	Production teams work in ION, not in NetSuite, Dynamics, or SAP. Only finance and procurement need ERP seats.	ION as the production UI; ERP for finance only
Engineering change traceability	Production reflects the released engineering revision; as-built records tie back to the design version that produced them.	PLM ↔ ION
Closed-loop quality	NCRs and deviations found in production feed back into engineering as ECRs; production runs don’t proceed against stale revisions.	ION → PLM (NCRs / MRBs / inspection results)

These are the goals to lead with on the first slide of any integration scoping conversation. Everything below is the architecture that makes them deliverable.

The triad: PLM, MES (ION), ERP

These three systems are the operational triad of any modern hardware manufacturer. Each owns a distinct part of the product’s life. Trouble starts when one tries to do another’s job. One-line summary:

PLM = the intent (engineering definition).
MES (ION) = the reality (what actually happened on the floor).
ERP = the accounting (what was bought, what was received, what was paid).

The rest of this document is precision around what flows between them.

PLM ↔ ION reference architecture

PLM is the system of record for the engineering definition of the product. ION is the system of record for what the production floor does with that definition.

The BOM lifecycle: eBOM → mBOM → aBOM

The BOM is not a single object. It evolves across the manufacturing lifecycle, and each stage has a different owner. Conflating them is the most common source of integration scope confusion.

Stage	Owner	What it is	Lifetime
eBOM, Engineering BOM	PLM	The design intent. The list of parts and assemblies the engineer specifies, by revision. Released into production.	Tied to the engineering revision; immutable once released.
mBOM, Manufacturing BOM	ION	The manufacturing-ready BOM, derived from the eBOM. Adds manufacturing-only items (consumables, fasteners, fixtures), alternates, work-center assignments, kit groupings.	One per procedure version; updates with procedure revisions.
aBOM, As-built BOM	ION	The actual record of what was consumed in a specific serial number or lot. Captures substitutions, scrap, rework, and deviations.	One per serial number or run; immutable once the run closes.

The flow is eBOM (PLM) → mBOM (ION) → aBOM (ION) → optional feedback to PLM.

When there is no PLM: Many small or mid-stage manufacturers have no formal PLM. In that case, ION holds what is functionally an mBOM (sometimes informally called “the BOM”), and there is no upstream eBOM. This is acceptable for Phase 1 deployments. As soon as PLM is introduced (often Phase 3), eBOM authority moves to PLM, and ION’s BOM becomes explicitly the mBOM. The “BOM lives in ION” state is transitional, not a permanent architectural commitment.

Canonical data flows: PLM → ION

Object	Direction	Purpose	ION’s role
Items / Parts (engineering identity)	PLM → ION	Establish the part the floor builds or consumes; carry engineering revision and lifecycle state.	Manufacturing reference; ION can also hold financial-side metadata that mirrors ERP’s Items.
eBOM (engineering BOM)	PLM → ION	Define what should be in the assembly per the engineering revision.	Source from which ION derives its mBOM.
Routings (engineering definition)	PLM → ION	Define the high-level steps of manufacture.	Imported as procedure / step templates.
ECN / ECR notifications	PLM → ION	Propagate engineering change.	Trigger procedure revision; surface to operators in-context; gate runs against stale revisions.
Drawings / CAD links	PLM → ION (reference only)	Operator access to design spec.	Reference link in step content; ION does not host the CAD.

On Items duplication: Items typically exist in both PLM (engineering identity: revision, lifecycle, drawing reference) and ERP (financial identity: cost, GL account, tax code, vendor part number). PLM is the upstream source for the engineering attributes; ERP is the upstream source for the financial attributes. ION holds the operational view: the item as it appears on the floor, kitted, consumed, scanned. ION can pull from either or both depending on what’s in the customer’s stack.

Canonical data flows: ION → PLM

Object	Direction	Purpose	PLM’s role
As-built BOM (aBOM)	ION → PLM	What was actually consumed and built per serial number, with substitutions and lot/serial detail.	Engineering audit trail; configuration management; type certification record.
NCRs / MRB outcomes	ION → PLM	Defects, deviations, dispositions found in production.	Source for ECRs back into engineering.
In-process inspection / test results	ION → PLM	Production verification data.	Engineering certification, type acceptance, design-of-experiments feedback.
Production traceability records	ION → PLM (reference)	“This serial number was built from these parts via these procedures against this revision.”	Linked to the design version that produced it.

What does NOT cross the PLM ↔ ION line

eBOM authoring in ION. PLM owns the engineering BOM when PLM exists. ION derives an mBOM from it; ION does not modify the eBOM.
Drawings / CAD in ION. ION holds reference links, not drawings. PLM is the source.
Engineering revisions in ION. Revision authority lives in PLM. ION shows the released revision in production context.
Real-time CAD round-trip. No live CAD editing from ION. If the operator finds a problem, that becomes an NCR or MRB, which feeds an ECR back to PLM, where the engineer makes the change.

ION’s PLM connector posture

Production today: Arena (multiple A&D customers), Onshape (selected customers), Duro (in deployment).
Partner-built: Teamcenter (via a PLM systems-integrator partner). Teamcenter integration sits at the PLM customization edge: most customers engage their PLM consultant for the Teamcenter side, and ION owns the ION side.
Verify before scope: PLM systems often have major version differences (Duro vs. Duro Hub, Windchill versions, on-prem vs. cloud Teamcenter). Verify the customer’s actual deployment before signing scope.

ERP ↔ ION reference architecture

ERP is the system of record for financial transactions. ION is the system of record for production execution. They share a small, well-defined set of objects.

Canonical data flows: ERP → ION

Object	Direction	Purpose	ION’s role
Purchase Orders	ERP → ION	Procurement → production trigger	Read-only execution view; lines mapped to ION parts
Suppliers	ERP → ION (via PO)	Identify vendor on the floor	Created in ION as a side-effect of PO sync
Payment Terms	ERP → ION	Reference data on POs	Display only
Item master (financial)	ERP → ION (optional, lookup)	Item identity for non-PLM-driven shops	Read-only reference; PLM is preferred source if both exist

Canonical data flows: ION → ERP

Object	Direction	Purpose	ERP’s role
Receipts (shop-floor)	ION → ERP	Materials physically received against PO	Triggers Item Receipt + financial posting
Work order completions	ION → ERP	Production output recorded for cost rollup	GL recognition of completed inventory
Labor / time	ION → ERP (cost-plus customers)	Direct labor on jobs	Cost-plus billing, GL labor allocation
Inventory reconciliation	ION → ERP (report, not sync)	Periodic reconciliation between shop-floor reality and financial inventory	Adjusting entries; not real-time mirror

Syncing to ERP

Prefer event-driven sync over scheduled polling. ION emits webhooks the moment an event occurs, such as a run completing or a receipt posting, so the ERP stays current and failures surface in context instead of on the next poll. If your ERP doesn’t need updates that often, have your integration queue ION’s events and batch them into the ERP on a schedule. ION has supported integrations with NetSuite, Epicor, Dynamics 365, Business Central, Odoo, and Infor. To sync as-built consumption to the ERP, query the aBOM installations on the part inventory produced by completed runs:

query ($filters: RunsInputFilters) {
  runs(filters: $filters) {
    edges {
      node {
        title
        partInventory {
          part { partNumber }
          quantity
          buildRequirements {
            abomInstallations {
              quantityInstalledPerParentPartInventory
              partInventory {
                location { id }
                part { partNumber }
              }
            }
          }
        }
      }
    }
  }
}

For each installed part inventory, multiply the quantity produced by quantityInstalledPerParentPartInventory to get total consumption. The same component can appear more than once when it’s installed from different inventory locations. For a run that produced three of Assembly Part One, that gives 15 of Component Part One (2.4 × 3 + 2.6 × 3) and 9 of Component Part Two (3 × 3).

What does NOT cross the ERP ↔ ION line

Bidirectional inventory sync. ION owns shop-floor inventory in real time. ERP owns financial inventory at posting cadence. They reconcile periodically. They do not bidirectionally mirror. This is the single most damaging anti-pattern in MES/ERP integration. (See Rule 5 below.)
Production scheduling in ERP. Work order release and floor scheduling live in ION. ERP can hold high-level demand or master schedule, but the dispatch happens in MES.
GL postings authored by ION. ION emits the events (receipt, completion, labor). ERP posts to GL according to its own rules.
Vendor bills, invoices, AP, AR. ERP-only. Out of any normal ION integration scope.
Items master authored by ION. If PLM is in the picture, PLM authors. If ERP is the only product-data system (rare for hardware companies that build), ERP authors. ION never authors.

ION’s ERP connector posture

Production today: NetSuite (multiple deployments), Dynamics 365 (electric aviation customer).
In-flight: SAP (early scoping; pattern not yet certified).
Customer-side configuration is the customer’s responsibility: custom forms, scripts, saved searches, OAuth, role permissions, sandbox provisioning. Either the customer’s internal ERP admin or the customer’s ERP consulting partner.

The 3-way match: the canonical AP control loop

The single most-asked-for outcome from any ERP integration is 3-way match: the financial control that prevents an invoice from being paid unless three documents agree. ION’s role in 3-way match: ION’s job is to make the Item Receipt real, automatic, and accurate by recording what physically arrived at the receiving dock and triggering the matching ERP record. Without a connected ION, the Item Receipt is a manual data-entry step in the ERP that operators forget, mis-key, or batch up. This is where most “phantom payments” and “missed receipts” come from. Why this is the lead outcome: every CFO understands 3-way match. It is the easiest integration goal to socialize internally and the most defensible ROI story. What 3-way match needs from each side:

Side	Required	Why
ERP	Purchase Orders with line-level detail (item, qty, price); Vendor Bill workflow; Item Receipt entity that can be created via API.	The match logic lives in ERP.
ION	Receipts at the line level, tied back to the originating PO via a durable join key; quantity and item agreement with the PO line.	The trigger event lives in ION.
Customer process	Vendor invoices submitted to AP through a defined channel; receiving discipline at the dock (don’t receive what didn’t arrive).	The control only works if the human process feeds it.

Multi-location and inter-location transfers

Customers with multiple physical sites introduce a class of integration questions that single-site customers do not face:

Where does inter-location inventory transfer get recorded? ION owns the operational transfer (parts physically move site-to-site under custody chain). ERP owns the financial reclassification (inventory by location for tax / GL).
Granularity question: does the ERP need site-level inventory tracking, or is location-level handled entirely in ION? Most customers benefit from site-level rollups in ERP and bin/cell-level granularity in ION.
Planning question: does demand at one site automatically trigger procurement at another, or are sites planned independently? This is a planning-system question more than a strict integration question, but it shapes how much of MRP / Autoplan to expose across sites.

These are scoping questions for the Phase 2 / Phase 3 conversation. Surface them early when the customer has more than one site.

PO setup attributes

ERP POs typically carry attributes that ION needs but doesn’t author: department, location, cost center, project code, GL account override, tax code. These need to flow with the PO so that ION can route receipts to the correct location and so that downstream financial events (consumption, completion) carry the right tags. The ION NetSuite connector handles this via configurable PO Header and PO Line attribute data maps. For non-NetSuite ERPs, equivalent mappings need to be defined per integration. This is configuration, not code, but it is non-trivial work that should not be skipped at scoping time.

The combined picture: ION as the execution spine

In a fully-instrumented A&D or hardware manufacturer, the three systems form a closed loop. Engineering defines (PLM), production executes (ION), finance accounts (ERP). Each cycle of build → release → ship → invoice closes through ION.

Granular entity flow

The triad above is the executive view. Below is the entity-level flow used in scoping. Each circle is a real object that exists in one of the three systems; each arrow is a real integration touchpoint. How to read this diagram:

Solid arrows are first-class integration flows that ship in certified connectors.
Dotted arrows are reconciliation / posting flows that happen on a cadence rather than per-event (consumption postings, financial inventory reconciliation, as-built feedback to PLM).
The 3-way match cluster is the canonical AP control described above.
Sales order / demand is the entry point. Demand into ION can come from ERP sales orders, internal Autoplan / MRP, or both.
Run is the unit of execution in ION. Everything downstream (aBOM, receipts, quality, labor, scrap) is keyed to a run.

Reference deployments

ION is in production across the following ERP and PLM combinations. New customers can scope against these patterns rather than starting from scratch.

Industry segment	ERP	PLM	Integration shape	Status
Satellite communications (mid-size)	NetSuite	Arena	PO sync NS→ION; Item Receipts ION→NS; Arena part / eBOM sync	Live
Autonomous maritime (mid-size)	NetSuite	None	PO sync; inventory reconciliation reporting	Live
Electric aviation (large)	Dynamics 365	(mixed)	ERP sync; webhook-based event flow	Live
Defense maritime (small, high-growth)	NetSuite	None	Phased: ION standalone → NS PO + receipt sync	In deployment
Defense / aerospace tooling	NetSuite	Teamcenter	Three-system: NetSuite ERP + Teamcenter PLM + ION MES	Active scoping
Defense engine components	(varies)	Arena	Quality + procedure sync	Active

The recommended sequence for a new customer

The following deployment sequence is recommended. Each phase is useful on its own, so you can adopt them in order without waiting to finish the rest. Phase 1, Foundation. ION is deployed standalone as the production system of record. Procedures, runs, quality, kitting, traceability, and shop-floor inventory live in ION. ERP and PLM continue to operate as today. No integration dependency for go-live. This pattern protects margin and de-risks the launch. Phase 2, Connect (ERP). A pre-built, certified connector links ION to the ERP. POs flow into ION, receipts flow back. The customer’s ERP admin or consultant configures the ERP-side; ION’s team configures the ION-side. Configuration, not custom development. Phase 3, Engineering loop (PLM). PLM integration brings part master, eBOM, and engineering change notifications into ION; sends as-built and NCR data back. Often phased: parts + eBOM first; ECNs and as-built second. Phase 4, Orchestrate. Forward-deployed engineering work that goes beyond the certified connectors: ION-driven PO creation via Autoplan, financial cost roll-ups, outside processing flows, cost-plus labor reporting. Scoped per engagement, not assumed.

Canonical rules

The following rules apply to every ION integration. They are the distillation of canonical MES/ERP/PLM literature (ISA-95, MESA) and the accumulated experience across 20+ customer deployments. They exist to keep integration scope aligned with what actually works, and to prevent the failure patterns that are easy to fall into during early scoping conversations.

#	Rule	Why
1	PLM owns engineering intent. ION owns production reality. ERP owns financial transactions.	The triad. Every other rule follows from this.
2	PLM authors the eBOM. ION produces the as-built BOM. They are different objects with different lifecycles.	The eBOM is design-time; the aBOM is run-time. Trying to merge them creates ambiguous state.
3	*Engineering revisions are released into* production, not authored from it.** Operator-found problems become NCRs/MRBs that feed ECRs back to PLM, where the engineer makes the change.	Configuration management requires a single authoring path.
4	POs are owned by ERP. Receipts on the floor are owned by ION. A receipt in ION triggers an Item Receipt in ERP, not the reverse.	Production reality leads; financial recording follows.
5	Inventory does not bidirectionally sync between ION and ERP. ION holds shop-floor reality in real time; ERP holds financial inventory at posting cadence. They reconcile, they do not mirror.	The single most damaging anti-pattern in MES/ERP integration. Bidirectional sync creates race conditions, conflicting truths, and reconciliation hell.
6	Inventory and locations are out of scope for any first-pass ERP integration. Phase 3+ conversation, scoped explicitly.	Pulling inventory into a first-pass ERP sync creates more reconciliation pain than it solves.
7	Production scheduling lives in MES. ERP can hold demand or master schedule; dispatch happens in ION.	Schedule rigidity in ERP is incompatible with shop-floor reality.
8	Items master lives where it was born. PLM if engineering-led, ERP if procurement-led. ION never authors. If both PLM and ERP claim it, PLM wins for hardware companies.	Single source of truth for item identity.
9	Connectors before commitments. ION integrations are available via pre-built, certified connectors. New connectors are scoped, priced, and sequenced separately, not assumed in a master agreement.	Avoids the “we’ll build it” trap that produces multi-month delays and missed scope.
10	Every integration ships with a defined acceptance criterion, owner, and SLA. No indefinite UAT states.	UAT-stuck-at-90% is the second-most-common failure pattern after scope ambiguity.
11	Health monitoring is part of the integration, not a follow-up. Integrations that “worked at handoff” but degraded silently are unacceptable.	Post-launch silent degradation is how customers lose confidence in months, not weeks.
12	Verify the customer’s actual environment before scoping. ERP version, PLM version, on-prem vs. cloud, custom forms / scripts already in place.	Wrong-version assumptions cause weeks of delay.
13	Three-party engagements (ION + customer + customer’s SI) require explicit scoping with all three named on the SOW.	Scoping gaps between ION and the customer’s SI cause silent failures and finger-pointing.
14	Default to two-party (ION + customer). Insert third-party SI only when the customer’s environment requires it (for example, PLM that needs vendor expertise like Teamcenter) or the customer asks for it.	Smaller engagement, fewer hand-offs, less cost.

Source documents

ISA-95 standard: ANSI/ISA-95.00.01 Enterprise-Control System Integration
MESA model: Manufacturing Enterprise Solutions Association, MESA-11 functional areas

Bills of Materials: mBOM and aBOM in detail
Purchasing: POs and the ERP receipt loop
Receiving: the dock-side trigger for 3-way match
Issues and NCRs: the quality feedback loop into PLM

Getting Started

Build Hardware

Manage Supply Chain

Track Quality

Automate with ION

Administration

API Reference

ERP and PLM reference architecture

Overview

ION in the factory stack

Why integrate at all: the business goals

The triad: PLM, MES (ION), ERP

PLM ↔ ION reference architecture

The BOM lifecycle: eBOM → mBOM → aBOM

Canonical data flows: PLM → ION

Canonical data flows: ION → PLM

What does NOT cross the PLM ↔ ION line

ION’s PLM connector posture

ERP ↔ ION reference architecture

Canonical data flows: ERP → ION

Canonical data flows: ION → ERP

Syncing to ERP

What does NOT cross the ERP ↔ ION line

ION’s ERP connector posture

The 3-way match: the canonical AP control loop

Multi-location and inter-location transfers

PO setup attributes

The combined picture: ION as the execution spine

Granular entity flow

Reference deployments

The recommended sequence for a new customer

Canonical rules

Source documents

​Overview

​ION in the factory stack

​Why integrate at all: the business goals

​The triad: PLM, MES (ION), ERP

​PLM ↔ ION reference architecture

​The BOM lifecycle: eBOM → mBOM → aBOM

​Canonical data flows: PLM → ION

​Canonical data flows: ION → PLM

​What does NOT cross the PLM ↔ ION line

​ION’s PLM connector posture

​ERP ↔ ION reference architecture

​Canonical data flows: ERP → ION

​Canonical data flows: ION → ERP

​Syncing to ERP

​What does NOT cross the ERP ↔ ION line

​ION’s ERP connector posture

​The 3-way match: the canonical AP control loop

​Multi-location and inter-location transfers

​PO setup attributes

​The combined picture: ION as the execution spine

​Granular entity flow

​Reference deployments

​The recommended sequence for a new customer

​Canonical rules

​Source documents

​Related

Overview

ION in the factory stack

Why integrate at all: the business goals

The triad: PLM, MES (ION), ERP

PLM ↔ ION reference architecture

The BOM lifecycle: eBOM → mBOM → aBOM

Canonical data flows: PLM → ION

Canonical data flows: ION → PLM

What does NOT cross the PLM ↔ ION line

ION’s PLM connector posture

ERP ↔ ION reference architecture

Canonical data flows: ERP → ION

Canonical data flows: ION → ERP

Syncing to ERP

What does NOT cross the ERP ↔ ION line

ION’s ERP connector posture

The 3-way match: the canonical AP control loop

Multi-location and inter-location transfers

PO setup attributes

The combined picture: ION as the execution spine

Granular entity flow

Reference deployments

The recommended sequence for a new customer

Canonical rules

Source documents

Related