How to integrate a custom application with your existing ERP

To integrate a custom application with an existing ERP, first decide which system is the system of record for each piece of data, then pick the exchange method your ERP actually supports: a documented API, scheduled file exchange, or an intermediate layer. After that, the real work is error handling, a dedicated service account with minimal permissions, a sandbox to test in, and monitoring once the integration is live.

The ERP stays the backbone of finance and operations; the custom app covers what it does poorly. This guide explains how to make the two work together without weakening either, and gives you the questions to ask before anyone sends you a quote.

Why build an app next to the ERP at all

An ERP is excellent at what it was designed for: accounting, purchasing, inventory, invoicing, with rules shared by thousands of companies. It is far less comfortable with a process specific to your business: a mobile form for field technicians, an unusual approval chain, a pricing calculation nobody else does.

Two reflexes cost a lot. The first is to bend the ERP with heavy customisation, which makes every upgrade harder and more expensive. The second is to leave the process in spreadsheets, then re-key the results into the ERP. The third option, a focused application that exchanges data with the ERP, is often the most sensible one. Our comparison of custom ERP and off-the-shelf ERP covers that trade-off in more depth.

Step 1: map the data flows

Before any technical question, list the data that needs to move. A simple table is enough.

This illustrative table is the one you would draw for an order-taking or field service app. Yours will differ, but it will have the same shape, and it already describes most of the integration work. It also becomes the core of the integration section in your software requirements document.

Step 2: one system of record per data item

This is the rule that prevents most incidents: every piece of data has exactly one master. If a customer can be edited in both the ERP and the app, the two versions will drift apart, and nobody will know which one is right.

In practice, the ERP stays master of financial and operational reference data (customers, items, prices, ledger entries), and the app becomes master of what it produces (field entries, approvals, photos and attachments). When a change must flow back, it flows through the agreed interface, never through double entry.

Step 3: choose the integration method

Most current ERPs publish a documented interface, for instance Odoo's external API or the Microsoft Dynamics 365 Business Central APIs. When an API exists, it is almost always the best route. Reading from a database replica can be acceptable for dashboards; writing directly into the production database is not. If the word API is still fuzzy, our plain explanation of what an API is for a business starts from scratch.

A note on iPaaS and no-code connectors

Integration platforms and automation tools can be the right answer when the flows are simple and the company already pays for one. They become fragile when the logic gets heavy: complex mappings, retries, deduplication and exceptions are hard to test and version in a visual editor. Past a handful of rules and error paths, code that can be reviewed, tested and versioned is usually the safer home for that logic.

Real-time or batch

Real-time is attractive, but it has a price: every ERP outage becomes an outage of your app. Reserve it for data where a decision depends on the current value, like stock checked before confirming an order.

For everything else, a scheduled sync is more robust. If the ERP is under maintenance at night, the next sync catches up, and the app keeps working with the last known version of the data. Event-driven integrations (the ERP notifies the app through a webhook when something changes) sit in between, when the ERP supports them.

Where the real work is: the failure cases

The happy path of an integration is quick to build. What takes care is everything else:

• the ERP does not respond: the app queues the message and retries it, instead of losing the data;
• the data is rejected: an unknown item code, a blocked customer, a field too long; the rejection is logged and routed to someone who can act on it;
• the same message arrives twice: the exchange is designed to be idempotent, so a second delivery does not create a duplicate order;
• formats diverge: dates, decimals, units of measure, item codes; every mapping is written down and tested.

This is often the most underestimated line in a quote, as we explain in our guide to what a custom business application costs.

Security and access

• A dedicated service account for the integration, never an employee's login, with only the permissions the agreed flows need.
• Secrets kept out of the code (API keys, passwords), and rotatable without redeploying the application.
• A log of every exchange: who, what, when, with what result.
• Data protection applied to the flows: if you process personal data of people in the EU or UK, the GDPR principle of data minimisation applies, so only send the personal data each flow needs and document where it goes.

Test without touching production

An integration is tested against a sandbox or test instance of the ERP, loaded with representative data. If your ERP does not have one, that is the first question for your vendor or partner: testing a connector directly on production means creating real orders and real ledger entries to check that it works.

Plan a gradual rollout as well: a few users, or a single flow, during an observation period, before switching everything on. User acceptance testing should include the failure cases above, not only the happy path.

After go-live

An integration is never finished. The ERP receives updates, its configuration evolves, new edge cases appear. Three habits prevent silent breakage:

1. monitor the exchanges, with an alert when a flow fails or simply stops;
2. retest the integration before every major ERP upgrade, in the sandbox;
3. include the integration in the maintenance agreement of the application, as we detail in our article on business application maintenance.

Questions to ask before anyone quotes

To your ERP vendor or implementation partner:

• Which ERP version are we on, and when is the next major upgrade planned?
• Does the ERP expose an API, and is its documentation available to a third party?
• Is there a sandbox or test environment, and how do we get access?
• What permissions can a service account be given?
• Do our customisations change the objects this integration will touch?

To the developer of the new application:

• How do you handle an ERP outage?
• How do you prevent duplicates when a message is replayed?
• How are rejections reported, and to whom?
• Who maintains the connector when the ERP changes?

How we approach it

At LPR Studio, we connect to your ERP, accounting software, CRM and existing databases rather than replacing them: an application that ignores the rest of your systems helps nobody. Our free visual prototype, presented over video within 5 working days, already shows where each piece of data is entered and where it comes from, before a single line of code. How that works is explained in see your software before you pay.