Engineering · 5 min read · January 2026
ERP integration stopped being a separate project
For years, "integrate with the ERP" was the budget line that blew up. ERPs with a decent API changed that — but they didn't solve everything.
Why it used to be expensive
Old-school ERPs integrated through files, direct database access, or an API that changed without notice. Every integration was a mini reverse-engineering project, with a consultant billing by the hour who knew the undocumented endpoints.
What got better
The current generation — and several newer versions of traditional ERPs — exposes a documented REST API, webhooks and a staging environment. You can develop against a sandbox, actually test it, and version the integration like any other code.
What's still work
- Reconciliation: the data that exists on both sides and needs to match. Correlation keys, idempotency, what to do when it diverges.
- Queue and retry: the ERP goes down, your operation can't stop.
- Business rules at the edge: the ERP has its own way of doing things; your operation has another. Someone has to decide where the rule lives.
The point
Integration today fits inside the scope of a software project — it doesn't become a separate "integration" line item or a stand-alone contract with a specialist. If you're being told it does, it's worth a second opinion.