ERP Integration: What to Connect First and How to Decide

An order may be recorded in an online store, inventory in a spreadsheet and the invoice in the ERP. While volumes remain manageable, the team compensates for those differences by checking, copying and asking questions. When that is no longer feasible, connecting tools may seem like the obvious solution. But a poorly scoped ERP integration can also transfer incorrect data more quickly.

The decision is not about connecting everything possible. It is about choosing which workflow should no longer depend on manual tasks, which data must be reliable and who must be able to intervene when an exception occurs. By the end of this article, you will be able to decide which integration deserves priority and which conditions you should define before implementing it.

What an ERP integration needs to address

An integration connects the ERP — the system where you centralise part of your business management — with another tool to exchange information or trigger actions. This may be an online store, a CRM, a warehouse system, an internal application or an invoicing service.

For the connection to serve an operational purpose, review these seven elements:

1. A specific objective

   Start with the change you need, not with the tool you want to connect. For example: preventing a confirmed order from being entered into the ERP again, checking inventory from a single reference data source or preventing a cancelled order from being invoiced.

   An objective such as “integrate the systems” is too broad to define the scope. By contrast, “record paid orders in the ERP with their lines, taxes and customer” makes it possible to check whether the integration meets the need.

2. The event that triggers the workflow

   Define what must happen for the exchange to begin: a paid order, a newly created customer, a status change, an accepted return or a product update.

   This prevents automation from occurring at the wrong time. A created order and a paid order may require different handling. The integration should reflect the business rule you decide.

3. The data exchanged between systems

   It is not enough to say “send orders”. List the required fields: identifier, customer data, items, quantities, prices, taxes, address, payment method and status, where they apply to the workflow.

   You must also agree on how this data is matched. If a product has one name in the store and another in the ERP, you need a shared reference or a matching rule. Without it, the system cannot reliably identify which item each line relates to.

4. The system that is authoritative for each data item

   When two tools can modify the same field, clarify which one is the primary source. For example, the ERP may be the reference for inventory and prices, while the store captures orders and shipping data.

   This decision prevents conflicts such as overwriting a correction made by the team or synchronising outdated inventory in both directions.

5. The direction and frequency of the exchange

   An integration can send information only to the ERP, receive it from the ERP or operate in both directions. The more information is exchanged, the more rules and scenarios need to be validated.

   Also decide when each data item is updated: when the event occurs, at defined intervals or after manual review. Not every process needs the same immediacy; the choice should reflect actual operations.

6. Exceptions and human controls

   Incomplete data, missing references, connection errors or duplicate records do not disappear through automation. Define what the system will do if an address is missing, a product has no matching reference or the ERP does not respond.

   Someone should be able to identify what failed, review the reason and decide whether to correct, retry or cancel the operation. Automation reduces repetitive intervention; it does not remove the need to oversee rules and exceptions.

7. Maintenance of the connection

   The integration depends on access, permissions, data formats and functions available in the connected tools. If these change, the workflow may need to be reviewed.

   Before proceeding, clarify who holds the credentials, who receives failure alerts and who authorises changes to the rules. It is also advisable to document the workflow so that it does not depend on the knowledge of a single person.

How to prioritise an ERP integration

Do not try to solve every process at once. Classify each potential connection according to its relationship with a critical task and the level of uncertainty it introduces.

• Essential in an initial phase: the workflow without which the objective cannot be achieved. If the issue is recording confirmed orders, this may include creating the order, identifying the customer and its product lines.
• Desirable: improves the work, but can wait without blocking the main workflow. For example, sending an additional internal note or synchronising a secondary tag.
• Future: makes sense once the foundation is working, but depends on rules that have not yet been defined or on a tool that has yet to be introduced.
• Out of scope: belongs to a different problem. Connecting campaigns, reports, customer service and accounting within the same initial integration can make it harder to know which part is failing and why.

To assign these categories, answer the following for each workflow:

1. Which specific manual task, delay or error do you want to avoid?
2. Who uses the result, and what do they need to see or do afterwards?
3. What happens if this connection is postponed?
4. Which data, permissions or third-party decisions still need to be confirmed?
5. How will you verify that the workflow has been completed correctly?

A workflow with a clear objective, identified data and few dependencies is usually a better candidate to start with than one that connects many areas with rules that are still ambiguous.

Hypothetical example: orders and inventory

Imagine a small business that sells products through an online store and manages its operations in an ERP. The team manually enters paid orders and checks inventory in two places before confirming some sales.

The objective could be defined as follows: record in the ERP the orders that have reached the defined payment status and update the availability displayed in the store based on the agreed inventory data.

An initial integration could be scoped as follows:

• Event: the order changes to “paid”.
• Data sent to the ERP: order identifier, customer, product lines, quantities, amounts and the required shipping information.
• Reference data source for inventory: the ERP, if the business decides this is where operational inventory is controlled.
• Matching rule: each product shares a unique reference in both systems.
• Exception: if a reference does not exist in the ERP, the order is not recorded automatically and is flagged for review.
• Validation: sample orders are tested with simple items, multiple lines, incomplete data and unmatched references before the workflow is used in normal operations.

In this first phase, price changes, returns, the issuance of additional documents and sales reports would be excluded, for example. Not because they lack value, but because they require their own rules. Keeping them separate makes it possible to validate the essential part of the process first.

What should be left out of the initial decision

There are important matters that should not be considered resolved simply by choosing an integration tool:

• Tax, accounting or data protection rules. The technical connection must comply with the obligations applicable to your business. Their interpretation requires validation by the responsible professionals.
• Data without an owner. If no one can confirm where the correct price, inventory figure or order status comes from, the integration will only reproduce that uncertainty.
• Automations based on assumptions. Terms such as “valid order”, “duplicate customer” or “available inventory” must be turned into verifiable rules before they are configured.
• Undecided process changes. Integration does not replace the decision about who approves a return, when an order is put on hold or what to do when an issue occurs.
• A technical solution chosen before the scope. The availability of an API — the means through which two systems exchange information — along with the permissions and limits of each tool, must be reviewed for the specific use case. A platform being able to connect does not, by itself, define the appropriate workflow.

Next step: turn the idea into a verifiable scope

Before requesting an ERP integration, gather a real or representative example of the workflow: what triggers it, which data is involved, what result you expect and which exceptions you already know about. Add which tool should be the reference for each relevant data item. This foundation will make it easier to distinguish a simple connection from a project that needs to analyse rules, migrations or multiple systems.

If you need to organise that scope and assess how to automate a workflow without losing control over the data, you can tell AVSISTEC about your automation project.