Integrating Exact Online With Your Own Software: When, How and What It Costs

Introduction

For many Dutch businesses, Exact Online is the financial backbone. At the same time, those same businesses often run their own software alongside it: a webshop, a customer portal, a planning tool or an internal system. The moment those two worlds do not talk to each other, the familiar pattern emerges of double entry, manual retyping and reconciliation differences at month-end close.

An integration between your own software and Exact Online solves that, but it is not a switch you simply flip. In this guide we explain when an integration is worth it, what is technically possible via the REST API, where it gets hard and roughly what it costs. We write this from experience in Haarlem; our page on the Exact Online integration and the broader API integrations hub covers the technical approach in even more depth.

When an Exact Online integration is worth it

The clearest signals are operational. Someone creates an order in your system and then manually retypes that same order into Exact. Or finance waits every month for exports from different tools to reconcile the books. Or customers call to ask whether their invoice has been paid, while that information is readily available in Exact. Each of these is a moment where an integration removes time and errors.

The value of an integration is usually more than time savings. Real-time insight into outstanding invoices and cash flow helps with steering, and an automated integration produces an auditable trail of every entry. For sectors with tight margins, like wholesale or e-commerce, the difference between manual and automated translates directly into operations.

Not every situation needs a full integration immediately. Sometimes one-way traffic (orders to Exact) is enough before you flow payment status back to a customer portal. Our page on software integrations helps determine which scope fits your stage and budget.

What you can do with the REST API

Exact Online exposes a comprehensive REST API that lets you read and write almost every entity: sales orders, draft invoices, purchase invoices, general ledger accounts, relations and project entries. The full resource list is in the official Exact Online API documentation. In practice this means an order in your system can automatically become a sales entry or draft invoice in Exact, and payment statuses can flow back to your own application.

For real-time behaviour we use webhooks where possible, so your application knows within seconds that something has changed. Where webhooks are not available, we supplement with scheduled synchronisation that only processes differences. Exact also publishes changes and known issues via Support Exact Online; we follow that actively so breaking changes do not arrive as surprises.

If you are still building the application itself, our page on having a web application built is a logical starting point. Design an integration from the data model onwards, not as a last layer after go-live.

OAuth 2.0 and token management: where integrations stall

Exact uses OAuth 2.0 for API access, following the model described in RFC 6749. Your application asks an Exact user for consent, receives an access token and a refresh token, and uses those tokens on every API call. Access tokens expire; refresh tokens must be renewed periodically. If that rotation is not built as a reliable background process, the integration will stall sooner or later at an inconvenient moment, often overnight or just before month-end close.

The Exact Online developer portal describes app registration, scopes and redirect URIs. We store tokens encrypted, log refresh failures and alert when a token can no longer be renewed. Microsoft’s explanation of the authorization code flow is useful as a reference even though Exact runs on its own endpoints: the pattern of code exchange, refresh and scope is the same.

A common mistake is putting tokens in plain configuration files or refresh logic only in a cron job without retry. Treat OAuth as production infrastructure, not as a one-time setup during the first sprint.

Administrations, ledger mapping and rate limits

"The integration itself is rarely the hard part. The hard part is getting the accounting logic around it right."

— Sidney de Geus, co-founder MG Software

Many organisations manage multiple legal entities or branches in separate divisions. Every API call must explicitly name the correct administration. Mistakes in that mapping can land entries in the wrong administration; you often only notice at consolidation or audit, when recovery is expensive.

Ledger mapping is at least as important. How an order, discount or shipping cost translates into ledger lines differs per company and requires close collaboration with your finance team. We document mapping as configuration per division, not as hardcoded logic scattered through the code.

Finally, Exact’s rate limits are more restrictive than many teams expect, especially when importing historical data or running bulk syncs. Batch processing, backoff and idempotent requests are not nice-to-have; they prevent duplicate entries when a request times out and is sent again.

What an integration costs and how long it takes

A first production integration with a defined goal, for example sales orders that land as draft invoices in Exact, usually fits within a few sprints. The price within that scope depends on the number of entities you want to synchronise, the complexity of the ledger mapping and whether a test environment is available.

For organisations with multiple administrations, complex mapping or high volumes, we recommend a phased approach where each phase delivers a working and testable result. That avoids a long project without interim value. Phase one often delivers most of the time savings; phase two might add payment status back to your portal.

For a first range you can use our calculator, and on the page about software integrations you can read how we price and maintain integrations in general. Post-launch maintenance belongs in your annual plan: Exact changes APIs, and OAuth tokens keep needing attention.

Common mistakes

The most common mistake is trying to synchronise everything at once. An integration that covers orders, invoices, stock, relations and projects in one go is hard to test and hard to maintain. Start small, with the flow that costs the most manual time, and then expand based on what proves to work in production.

A second classic is ignoring error handling. An API call can fail due to a timeout, a rate limit or temporary unavailability. Without idempotent requests and a proper queue for failed mutations, you get duplicate entries or silent data errors. Those are exactly the kind of errors that only surface at month-end close, when they are most expensive to investigate.

A third mistake is no monitoring after go-live. An integration that stalls because of an expired token only becomes visible when finance notices no new invoices are arriving. We actively monitor sync lag, failed jobs and token age, often in the same maintenance retainer model as the rest of the application.

Lessons from Haarlem: Exact integrations in projects

At MG Software in Haarlem we have built several Exact integrations for clients in wholesale, services and e-commerce. A recent project: an order portal for a wholesaler in the Haarlem-Amsterdam region, where approved orders automatically land as draft invoices in Exact and payment statuses sync back to the portal overnight. Discovery took one week, OAuth and division mapping two sprints, the first production flow another two sprints. Only then did we add stock mutations.

What we learned: finance must review mapping before the first test entry, not afterwards. Exact’s test administration caught three mapping errors that would have been visible immediately in production. Rate limiting only became an issue during bulk import of historical orders; nightly batches and exponential backoff solved it without data loss.

Those projects now run on a maintenance retainer where we quarterly check Exact API release notes and apply dependency updates. An integration is not a one-off project; it is a living connection. Teams that understand that upfront budget more realistically and avoid surprises when Exact deprecates an endpoint.

How we approach it

We start with a short discovery in which we determine together which Exact entities are relevant, in which direction data flows and which accounting rules apply. We then set up OAuth 2.0 securely, with encrypted token storage and automatic rotation, and develop against an Exact test administration so we never experiment with production data.

Every mutation is built to be idempotent, failed requests land in a queue with full context, and we actively monitor the integration after go-live. Because Exact regularly makes API changes, we build an abstraction layer that isolates such changes, so an Exact update does not touch your entire integration.

Want to compare the process with other ERP or accounting integrations, see our integrations overview. If legacy software sits between your portal and Exact, phased redevelopment is sometimes cheaper than yet another export script.

Conclusion

An Exact Online integration is not a technical trick, but an investment that structurally removes manual work and errors. The success is not in the API itself, but in the care around OAuth, administrations, ledger mapping, rate limits and error handling. Start small, build reliably, and expand based on what works.

Want your own software to talk to Exact Online? Get in touch with MG Software or first review our detailed page on the Exact Online integration. We map your process and build an integration that holds up at month-end close too.