How to connect ION Factory OS to Xero: options in 2026

If you run ION Factory OS for manufacturing and Xero for accounting, you have two systems that describe the same purchases and disagree about almost everything else. ION thinks in parts, revisions, POs and receipts. Xero thinks in contacts, bills and payments. Somewhere between “we cut PO-0871 for 40 machined housings” and “we paid Apex Machining $12,400” sits a mapping problem that your company solves either with software or with somebody’s Tuesday afternoons.

This post lays out the four realistic ways to connect them in 2026, with the trade-offs we’d want spelled out if we were choosing. (Disclosure: we build bomrail, which is option four. We’ll try to be fair to the other three — we’ve lived all of them.)

First, be honest about what “connect” means for you

Teams say “connect ION to Xero” and mean at least three different things:

1. Data transfer — POs raised in ION should become draft bills in Xero (or receipts should trigger bill matching) without retyping.
2. Reconciliation — someone needs to verify, periodically, that what ION says was ordered and received agrees with what Xero says was billed and paid.
3. Answers — people across the company need to ask questions that span both systems: “has the supplier holding our parts been paid?”, “what did the prototype run cost?”

Most integration approaches optimize for #1 and quietly assume it solves #2 and #3. It doesn’t. A perfect sync still can’t answer a question; it just means the data you manually cross-reference is fresher. Keep the three jobs separate as you evaluate the options below.

Option 1: Manual export and spreadsheet

The default. Someone exports POs from ION to CSV, pulls a bill report from Xero, and VLOOKUPs them together — at month end, or when something looks wrong.

What’s good about it: zero setup cost, zero new vendors, complete flexibility. The person doing it usually develops genuine cross-system intuition, which is worth something.

Where it breaks: it scales with headcount, not with software. The reconciliation happens on a schedule, so problems surface weeks after they occur — a bill that doesn’t match a receipt gets discovered after it’s paid, not before. And the intuition lives in one person; when they leave, the process leaves with them. Reasonable up to perhaps 20–30 POs a month. Past that, the Tuesday afternoons stop being occasional.

Option 2: iPaaS middleware (Zapier, Make, Workato and friends)

Wire ION webhooks or polling to Xero actions through a low-code platform: new PO in ION → draft bill in Xero, or receipt logged → bill status updated.

What’s good about it: fast to stand up for simple, one-directional record creation. Fine for the “stop retyping bills” job if your PO-to-bill mapping is trivial.

Where it breaks: hardware procurement data is not trivial. Partial receipts, multi-line POs with mixed tax treatments, revision changes mid-order, rejected quantities at incoming inspection — each becomes a branch in a visual workflow editor, and visual workflow editors handle branching about as well as whiteboards handle version control. You also now own a middleware layer: when ION changes an API field or Xero rate-limits you, the failure is silent until someone notices bills stopped appearing. And crucially, iPaaS does nothing for reconciliation or answers — it moves records; it can’t tell you whether the records agree.

Option 3: Custom API integration

Both ION and Xero have real APIs. A competent engineer can build a service that syncs exactly what you need, with your business rules, your retry logic, your alerting.

What’s good about it: total control. Your edge cases, handled your way. For a specific, stable, high-volume flow — say, receipts driving bill approval — a custom integration is the correct engineering answer.

Where it breaks: the estimate. The build is two or three weeks; the ownership is forever. OAuth token refresh, API version migrations, the Xero rate limiter, schema changes, the person who built it changing teams. Hardware startups have this conversation constantly: the integration works, the engineer who owns it is now needed on the actual product, and nobody wants to inherit a service whose entire job is moving other people’s data. You are also, again, solving job #1. The custom sync doesn’t answer questions either.

Option 4: An MCP server — connect both systems to an AI agent instead of to each other

The newer approach, and the one we build: don’t sync ION and Xero at all. Give an AI agent (Claude, or anything MCP-compatible) live, read-only, typed access to both systems through a hosted MCP server, and let it join the data at question time.

Ask “does the Apex bill from last week match what we ordered and received?” and the agent reads the bill from Xero, finds the PO in ION, pulls the receiving record, and answers — with each fact cited to its source system. No pipeline ran overnight. No mapping table exists to go stale. The join happened in the agent’s reasoning, against live data, exactly once, for exactly the question asked.

What’s good about it: it directly solves jobs #2 and #3 — reconciliation becomes a question you ask (“show me this month’s bills with no matching receipt”), and cross-system answers become available to everyone, not just the spreadsheet owner. Setup is OAuth sign-in to both systems, not an engineering project. Done right, it’s read-only by default with a full audit log, which makes it safer than the CSV exports it replaces — those never had an access log.

Where it breaks: it is not a data-transfer tool. If you need every ION PO to physically exist in Xero as a draft bill, an agent answering questions doesn’t do that (agent-drafted writes with human approval exist, but that’s assistance, not batch sync). Fuzzy joins are real: if your Xero bills never reference PO numbers, the agent must match on supplier and amount and should tell you it’s inferring. And you’re trusting a vendor with API access to both systems — which is why read-only defaults, audit trails and scoped OAuth should be non-negotiable in whatever you pick. We wrote up how we handle exactly that on the ION + Xero integration page and our security page.

How to choose

• Under ~30 POs/month, one person owns both systems: stay manual. Genuinely.
• One simple, high-volume record flow, no branching: iPaaS, with monitoring you actually check.
• A stable, business-critical sync with hard edge cases and engineering capacity to own it: custom integration.
• Reconciliation and cross-system questions are the real pain, and you want your team asking them directly: an MCP server — that’s the job it exists for, and the two approaches compose fine if you need transfer too.

The trap to avoid is buying a sync to solve a question-answering problem. If the sentence in your head is “I just want to know whether…”, no amount of data movement fixes that — something has to read both sides and reason. In 2026, that something can be an agent your whole team already uses.

If ION + Xero is your stack, bomrail’s design-partner program is onboarding now.