Connecting your ERP to custom software: Robaws, Odoo, Exact and more

Almost any ERP with an API can be connected to software that actually works on site: Robaws, Odoo, Exact Online, Teamleader, SAP, plus your accounting package, your planning tool and your payroll provider. The question is not whether it can be done, but how: directly through the API, via middleware, with an add-on from your ERP vendor, or with a custom layer alongside it. Below: the approach, what we have already integrated for construction companies, and where it goes wrong technically.

In short

• Direct API integration: one data flow between two systems. Fast and cheap, as long as it stays at one.
• Middleware: several systems through one intermediate layer, with central error handling. Extra subscription and management.
• ERP add-on: fast if your process fits the module. The code stays with the vendor.
• Custom layer: built around your site planning, work orders and approvals, with the ERP as the source for customers, projects and invoices.

Why would a construction company want to integrate its ERP?

Because the ERP handles the administration and not the site. Robaws, Odoo, Exact Online or Teamleader manage customers, projects and invoices just fine. But planners still assign crews in Excel, foremen send work orders and hours via WhatsApp or on paper, and the office types everything in again. Every handover is a chance for a missing hour, a wrong project number or an invoice that never goes out.

An ERP integration lets site software and ERP work together. The planner pulls the project from Robaws, the crew records hours and work orders in a screen that works on site, and approved hours go back to the ERP or straight to Yuki or Billit for invoicing. Everyone records something once. The ERP stays the source.

Which systems do we integrate with?

Anything that has an API or an export format. At construction, transport and maritime companies the same names keep coming up:

• ERP and project management: Robaws, Odoo, Exact Online, Teamleader, SAP, Oracle.
• Accounting and invoicing: Yuki, Billit, Octopus, Exact Online, Codabox, Isabel, and e-invoicing via Peppol.
• Payroll and HR: SD Worx, Acerta, Geodynamics for time registration.
• Planning and transport: Dashdoc, Qargo, Timocom, Navitrans, Transics.
• What everyone has open anyway: Outlook, Gmail, Google Calendar, WhatsApp and Excel.

If your package is not on the list, the first question is whether it has an API and how well it is documented. That matters more than the name of the package.

How do you connect an ERP to custom software?

In four ways, and the difference lies in how many systems need to talk and how far your site process deviates from what the ERP expects.

Direct API integration

The custom software reads and writes directly in the ERP through its API. This suits a single, well-defined data flow. For Goeyvaerts-R we built a certificate tool in two weeks that hangs directly off Odoo: hundreds of VCA and forklift certificates are tracked automatically, without a separate integration layer. With one data source, few fields and a stable API, this is the fastest and cheapest option. Watch out for API rate limits at high volumes, and agree who tests the integration after an ERP update.

Middleware or integration platform

A central layer that every system talks to instead of talking to each other. Planning, work orders, hours and accounting all four hang off it. The big advantage is error handling: failed transactions are stored, retried and reported, so an ERP outage does not end in missing hours or duplicate invoice lines. The downside is an extra subscription, technical management and dependence on the platform. For one data flow this is overkill; with three or more systems it starts to make sense.

ERP add-on

A module from your ERP vendor that turns hours into invoice lines or attaches work orders to projects. If your process fits what the module expects, you get started quickly. Construction-specific exceptions expose the limits fast: subcontractors, equipment, photos and signatures on the work order, variations. Then either you adapt your way of working, or you add manual work. And the code belongs to the vendor. You get a licence to use it, not the ability to change it.

Custom layer alongside the ERP

Software built around your site process, exchanging data with the ERP through its API. This is what we build most often for construction and maritime companies:

• At ZET Wonen the post-calculation tool hangs directly off Robaws. Projects, hours and work orders come from there, the tool writes back to it, and the planning per crew and van sits in the same screen.
• At K&C Marine Contractors divers fill in their inspection report in an app; the integration with Robaws synchronises projects and customers, so no duplicate administration builds up.
• At Antwerp Underwater Solutions the crew checks equipment in and out with a single scan, and the integration with Yuki takes care of automatic reordering.

Changing a screen or an approval step is possible without touching the accounts. The integration itself needs maintenance with every API change in the ERP, and that belongs in the contract. Read more about what we built around Robaws, including an AI integration that lets you query Robaws in plain language, in Robaws x Build More.

Which form suits your situation?

In the end, the quality of the ERP API weighs more than the form you choose. Robaws and Odoo have a well-documented API; with older packages, that is often the first question you ask.

Where does an ERP integration go wrong technically?

In five places, and all of them are avoidable if you name them up front.

• No agreed source of truth. Two systems change the same record and overwrite each other. Define per data item who the source is: the ERP for customers and invoices, the custom software for work orders and planning.
• Field mapping that is off. A project number in Robaws has to land on the right site file, and a status like "completed" can mean something different in the ERP.
• Duplicate records. A request succeeds, the confirmation is lost to a time-out, and the integration retries. A unique external ID per record prevents one work order from producing two invoice lines.
• Too much access. A timesheet app reads and writes hours and project codes, but should never touch suppliers or payment details. API keys in a vault, never in code or a spreadsheet.
• Silent failures. An outage that stays invisible for days. Invalid data goes into a separate error list, and someone responsible gets a notification as soon as a threshold is exceeded.

And if no ERP fits at all?

Then you build the core process yourself. At De Greef Spoorkranen we looked at Robaws and Timeking, and nothing fit the way rail cranes, skips, operators and hauliers are planned per site. We built a custom ERP: one platform for all resources, zero paper work orders, and invoicing that goes straight to Billit. That is the exception, not the rule. When a package is enough, you can read in custom software for construction companies in Antwerp.

How does such a project run, and what determines the price?

Four phases. Discovery: how do planning, work orders, hours and invoicing run today, and who is the source of truth per data item. A clickable prototype, so planners and foremen see the screens before any code is written. Build in weekly releases, each with a working piece of integration that you test with real sites. Acceptance in a test environment, including a test migration and a simulated ERP outage. A first working version is usually there in about eight weeks; at Goeyvaerts-R it was two, at De Greef sixteen.

The price depends on four things: the number of connections and the quality of the APIs, the amount of construction-specific logic, the data volume and synchronisation frequency, and the maintenance you agree on. A fixed price without a defined scope does not exist. After a first conversation we give you a scope and price indication within 24 hours, with build and management listed separately.

What do you check before requesting a quote?

• Request the API documentation for your ERP, and check whether your subscription includes that API access.
• Inventory every data source and assign one source of truth per data item.
• Describe the fields to be exchanged, with a filled-in example for customer, project, hours and work order.
• Define how often synchronisation happens and who takes priority in a conflict.
• Define five real-world scenarios for the acceptance test, including a corrected work order and a duplicate time entry.
• Ask who becomes the owner of code and documentation, and have maintenance and support for ERP updates written into the quote.

Torn between an add-on from your ERP vendor and a custom layer? Get in touch and we will look at your Robaws, Odoo or Exact environment together. Sometimes the conclusion is that the add-on is enough. If so, you will hear that from us too.