ERP integration that survives contact with reality
1C, Odoo and SAP Business One, connected properly

What it is

An ERP holds the operational truth of a business: stock levels, costs, open orders, sometimes production schedules. An ERP integration is the pipe connecting that truth to everything built around it. An online store needs real stock numbers. A CRM needs order status. A reporting layer needs cost data without someone exporting a spreadsheet every Friday. The hard part is rarely the API call. It’s the data model underneath. An ERP’s internal structure usually reflects years of accounting and operational decisions that don’t map cleanly onto a website’s idea of a “product.”

When you need this (and when you don’t)

You need this when stock or pricing shown to customers drifts from what’s actually in the warehouse. You also need it when a manager exports a spreadsheet from the ERP by hand to update a site or a CRM. The same goes when you’re moving off a cloud ERP and need the data to land somewhere self-hosted without losing history. It’s also the right project when a factory or distribution business wants its production or inventory numbers to reach a dashboard without a daily manual pull.

You don’t need a full integration if your sales volume is small enough that a weekly manual stock update costs less than the project itself. The same applies if your ERP vendor already offers a native, well-maintained plugin for the exact system you want to connect to. Check that first. It’s sometimes genuinely enough.

How we build it

The first two weeks almost always go into reading the ERP’s actual data model before writing an integration against it. Which fields are used consistently, and which are legacy and ignored? What does a “variant” or a “warehouse” mean in that specific installation? For 1C we typically work through its HTTP service or OData interface. For Odoo, its XML-RPC or REST API. For SAP Business One, the Service Layer API, or, where that isn’t licensed, a scheduled database export with strict validation on the way in.

Every sync writes a per-record log, so one bad SKU doesn’t block the other nine hundred. A conflict rule decides which system wins when two sides disagree. Usually it’s the ERP for stock and cost, the storefront for anything customer-facing, and we agree on it with you before the first sync runs live. We’ve done this recovery work before. We rebuilt a factory’s production and stock ERP onto self-hosted infrastructure the client controls, with zero data loss during the cutover.

What to watch

ERP vendor lock-in cuts both ways. The integration itself is built against a documented API or export format, so it survives an ERP version upgrade reasonably well. But the ERP vendor’s licensing, SAP’s Service Layer, for instance, can gate which integration method is available to you. We flag licensing constraints before scoping, not after.

The other real risk is scope creep inside the ERP itself. Once a sync exists, it’s tempting to route every report through it. We recommend keeping the ERP as the system of record for operational data, and letting a separate analytics layer handle reporting instead of overloading the live sync.

There’s also a staffing consideration. The person who understands the ERP’s quirks best is often the one at the company who has used it for years. A migration or integration project goes faster and safer when that person is involved from the first week. Bringing them in only to validate the result at the end costs you. We schedule time with them early for exactly this reason, not as a courtesy.

Price and timeline

What this pairs with

Built as part of custom development and setup and integrations. Often paired with data migration between platforms during a cutover, and monitoring and observability to watch the sync once it’s live. See the factory ERP recovery on self-hosted infrastructure for the recovery version of this project. Tell us which ERP and which systems need to talk to it: get in touch.