Inventory-ERP integration: what to check before signing

"Integrates with your ERP" is one of the most-used — and vaguest — phrases in inventory management software sales material. It can mean automatic, real-time synchronization, or it can mean "you can export a CSV and import it manually on the other end." The difference between those two things decides whether the system actually solves the problem or just moves the manual data entry somewhere else.

What "integration" can actually mean

Native integration via API. The counting system talks directly to the ERP, in real time or on a scheduled sync, without manual intervention. It's the most robust standard, but it depends on the ERP in question having an available, documented API — not every legacy ERP has one.

File-based integration (CSV/spreadsheet). Data is exported from one system and imported into the other, manually or on a scheduled routine. It works, but it reintroduces exactly the kind of manual step that generates discrepancy — and it depends on someone remembering to run the process.

"Integration" that's actually just a report export. The system generates a nice report, but the data doesn't automatically flow back into the ERP — whoever decides what to do with the information still has to act manually.

Questions to ask before signing

1. Is the integration real-time, scheduled, or manual? Ask to see it working, not just described on a slide.
2. What data flows in both directions? Just counted quantity, or also cost, location, batch, expiration date? Depends on what your operation actually needs to track.
3. What happens when the integration fails? Does the system notify someone, or does the error stay silent until a discrepancy shows up weeks later?
4. Is there already a ready-made integration with your specific ERP, or would it be developed on demand? This completely changes implementation timeline and cost.
5. Who's responsible for keeping the integration working after the ERP updates to a new version? Different vendors have very different policies here.
6. Does the integration support multiple companies or branches, if that's your case, or was it designed only for a single operation?

Common warning signs

• A vendor being evasive about "which ERPs we already integrate with today." A vague answer usually means the integration would be built from scratch for your case — which is possible, but should be clear in the quote and the timeline.
• A demo that only shows the inventory system's screen, never the ERP receiving the data. Ask to see the full cycle, not just half of it.
• "We'll figure out the integration later," said during the sales process. If the integration isn't in the defined scope from the start, it tends to become a separate project, with a separate cost and timeline, after the contract has already been signed.

The real cost of a bad integration

When the integration is fragile or manual, the problem isn't just the rework — it's that the ERP's stock number and the physically counted stock go back to diverging, which is exactly the problem that motivated the search for a better counting system in the first place. Integration isn't a backend technical detail — it's what decides whether the stock number the business makes decisions on is actually reliable.

It's worth treating the question "how does the integration work" with the same weight as price and counting features — because, in practice, that's what determines whether the system solves the problem or just relocates it.