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) |
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. |
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. |
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 }
}
}
}
}
}
}
}
}
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