What an ERP interface has to deliver
An ERP interface is the connection between your ERP system and a second system that needs the same data: orders from the web shop, contacts from the CRM, invoices into accounting, incoming payments from the bank. Without an interface this data travels through exports, spreadsheets and re-keying. Each of these stations costs time and creates discrepancies that surface weeks later, usually in accounting.
A well-built ERP interface meets four requirements:
- Unambiguous mapping: every field on one side has a clearly defined counterpart on the other. Anything that cannot be mapped is reported, not guessed.
- Traceability: every transfer is logged with timestamp, record and result. You can check afterwards when which document was transferred.
- Error handling: discrepancies and rejections by the target system are made visible, for example by email or in an error list. An interface that silently skips errors is worse than none.
- Repeatability: an aborted run can be restarted without creating duplicate records.
The terms ERP integration, API integration and system integration describe the same undertaking from different angles: the API is the technical access point, the interface is the piece of software that uses it, and system integration is the outcome, where two systems work as one.
REST, GraphQL or file export?
The route an ERP integration takes depends on what the systems involved offer. In practice there are three options:
- Application programming interface (REST or GraphQL): the target system exposes functions to read, create and update records. Odoo, sevDesk, Lexware Office, most shop systems and CRM tools provide this. Advantage: data flows promptly and in both directions, and errors are reported immediately. Precondition: the vendor’s API covers the fields you need, which you should verify before the quote.
- File export and import (CSV, XML, DATEV format): the source system writes a file, the target system reads it. Typical for handing data to a tax adviser via DATEV export, or for systems without an API. Advantage: simple, robust, supported by every system. Disadvantage: delay, one direction only, and errors surface only at import.
- Direct database access: the interface reads straight from the source system’s database. Only sensible if the vendor explicitly allows it; otherwise every update of the system endangers the interface.
Choosing between REST and GraphQL is rarely a matter of principle. It follows what the other system understands. More important than the protocol is how the interface handles edge cases: a customer whose name differs slightly between systems, an item without a tax rate, an invoice that already exists in the target system.
Example: connecting inventory management to accounting
The most common case in mid-sized companies: orders and invoices originate in the inventory or shop system, while accounting runs in Lexware, sevDesk or at the tax adviser via DATEV. Without an interface, invoices are exported once a month, cleaned up in a spreadsheet and imported. Anyone who has done this knows the typical errors: missing debtor numbers, mismatched tax rates, invoices that arrive twice or not at all.
An ERP interface for this case works like this:
- Every new invoice in the inventory system is handed to accounting promptly, with customer, line items, tax rate and due date.
- Customers are matched via a shared identifier, such as the customer number. If it is missing, the interface creates the customer according to fixed rules or flags the case for review.
- Every handover is logged. Accounting can see which invoice arrived when.
- If accounting rejects a record, for example because of an unknown tax code, the case appears in an error list and is transferred again after correction.
The same structure applies in the opposite direction for incoming payments. How an interface between your bank account and open invoices works, and why matches fail, is described in the guide on automatic payment matching.
How an interface project runs
ERP interface development does not start with coding but with the question of how data gets from A to B today. A project runs in four steps:
- Discovery: which systems are involved, which data flows in which direction, how often, and what is done by hand today? This is also where it becomes clear whether the target system offers an API at all and what it covers.
- Field mapping: for every field you define where it comes from, where it goes and how it is converted: tax rates, units, date formats, identifiers. This table is the most important document of the project and remains the reference in operation.
- Test run with real data: the interface first runs against test environments or a limited data set. Every edge case from discovery is deliberately played through before the first real document is transferred.
- Operation and monitoring: after go-live, logs and the error list are reviewed regularly, daily at first. Changes to either system, such as an accounting update, are checked for impact in advance.
Which technologies RLOX uses for interfaces and how such a project is scoped in a quote is described on the custom software development page (in German).
What an ERP interface costs: the drivers
A reliable figure only exists after discovery. What drives the effort can be named in advance:
- Number of systems and directions: a one-way handover is the simplest case. As soon as data flows both ways, the interface has to resolve conflicts: who wins if the same customer was changed in both systems?
- Data quality: duplicate customers, missing identifiers and inconsistent spellings must be cleaned up before go-live or handled by the interface. Both cost money; cleaning up is usually cheaper.
- Quality of the API: well-documented, stable APIs such as those of Odoo or sevDesk shorten development. Systems without an API force the file route with all its limitations.
- Timeliness requirements: a nightly run is simpler than a transfer within seconds that must cope with outages of the other system.
- Operation: an interface runs permanently and needs someone to review error lists and check, after updates of the connected systems, that everything still fits. This item is the one most often missing from quotes.
Common mistakes in ERP integration
- Errors are skipped silently. The interface transfers what it can and discards the rest. The discrepancy shows up months later at year-end closing.
- No log. Nobody can say whether and when a document was transferred. Every query turns into a search across two systems.
- Matching by name instead of identifier. “Müller GmbH” and “Mueller GmbH” become two customers, or worse, the wrong one.
- No repeatability. An aborted run creates duplicate records on restart because the interface does not know what has already been transferred.
- Direct database access without vendor approval. Works until the next update.
- Operation not assigned. The interface runs, but nobody reads the error list.
When an off-the-shelf integration is enough
Not every ERP integration needs custom interface development. Many systems ship with ready-made integrations: shop systems to common accounting packages, CRM tools to newsletter services, accounting software to the bank. A ready-made integration is the right choice if three conditions are met:
- It covers the fields you actually need, including your specifics for tax rates, cost centres or payment terms.
- It reports errors visibly, not only in a log nobody opens.
- The vendor keeps maintaining it when either system changes.
A custom interface pays off if one of these conditions fails, if a system involved has no ready-made integration, or if data has to be converted before handover according to rules that apply only in your company. Often the trigger is a second project: as soon as customers are to view orders or invoices themselves, the interface becomes the foundation of a customer portal.
Whether a ready-made integration or custom development is the better route can usually be settled in half an hour in a first conversation. What matters is that the answer is fixed before the quote, not during implementation.
