Exact Online integration with your own software

Your online store sells, your ERP plans, your time tracking counts the hours and your accounts live in Exact Online, the Dutch cloud accounting package. Without an integration, someone re-keys that data, late and with mistakes. An integration fixes that, but only if you decide three things up front: which system is the source, which way the data flows and what happens when something goes wrong.

What exactly do you want to connect to Exact Online?

Start with the data flow, not the technology. In practice, these are the most common directions.

• Sales invoices: orders from an online store or platform become invoices or entries in Exact.
• Purchase invoices: incoming invoices are recognised, approved and then posted.
• Contacts: customers and suppliers are managed in one place and sent to the other systems.
• Items and stock: product data and stock levels stay in step between the ERP, the online store and Exact.
• Hours and projects: logged hours become invoices or cost entries.
• Payments: bank statements and payment statuses are fed back to the sales system.

Pick one to start with. An integration that tries six flows at once breaks six times in the first month, and you won't know why.

How does the integration work technically?

Exact Online offers a REST API. You sign in with OAuth on behalf of a user. You work per administration (a separate set of books), so you have to state explicitly which one you are writing to. There are limits on the number of calls. Check Exact's own documentation for the current values, because they change.

Those limits shape your design. Don't fetch everything every minute; ask only for changes since the last run. Process in batches where you can. And build a queue, so a spike in orders never means lost messages.

What else comes with an Exact integration is covered under Exact Online. Other packages are listed under integrations.

Step 1: decide which system is the source

For every piece of data, name one system that holds the truth. Customer details in your CRM, for example, items in your ERP and financial entries in Exact. The other systems follow.

Skip this and a customer address can be changed in two places, with nobody knowing which version wins. That is the most common reason an integration is no longer trusted after six months.

Step 2: decide per field which side wins

Go through the fields you sync and note the direction for each one: one way, back only, or both. Where data flows both ways, decide who wins in a conflict, usually based on when the change was made.

Watch the fields that fail quietly: VAT codes, general ledger accounts, currencies, payment terms and cost centres. Each package names them differently and allows different values. Keep the mapping in a table an administrator can edit, not in code.

Agree what happens to deleted records too. A customer marked inactive in one system shouldn't simply vanish from the other.

Step 3: build in retries from day one

Integrations fail. A system is down for maintenance, a limit is hit, a field is too long, a required value is missing. That is normal. What isn't normal is a message disappearing because of it.

Put every message in a queue with its own status. If it fails, the system retries at growing intervals. If it still fails, it lands on a separate list that someone reviews. Make sure a resend can never create a duplicate entry: give every message a unique key and check it before you write.

Step 4: make failures visible

An integration without a screen is an integration nobody trusts. Build an overview where an administrator can see how many messages were processed today, how many are waiting and which are stuck, with the reason in plain language.

Set alerts for two things: a message that stays stuck, and a flow that goes silent. The second is often forgotten, yet an integration that does nothing is as harmful as one that does the wrong thing.

Where does an Exact integration usually break?

Four causes come up again and again. First, nobody on the client side owns the mapping tables and makes decisions about them. Second, the structure of the books changes, such as a new financial year or an extra administration, and nobody checks the integration against it.

Third, existing data isn't cleaned before the first sync, so duplicate contacts multiply. Fourth, the number of calls hits the limit because everything is fetched too often instead of just the changes.

When is an integration not the answer?

When the volume is small. Re-keying ten items a week costs less than building and maintaining an integration. If both systems will be replaced within a year, wait. And if the real problem is the process rather than the hand-off of data, fix the process first.

There is a middle ground. If a standard connector between your packages does what you need, use it. Building your own makes sense when you need to combine several systems, need your own logic in the mapping, or when the standard connector lacks exactly the fields you care about.

What does an Exact Online integration cost?

It depends on the number of flows, the number of fields, the level of control required and whether data needs cleaning. One flow in one direction from a clean source is a contained project. Six flows in two directions with years of historical mess is not.

Indicative prices per type are on what an integration costs. If you also need custom software around the integration, see custom software. And if you first want to know which integration pays off most, that is exactly what the AI Opportunity Audit works out.