Exact Online integration for when the App Store connector no longer fits

What is an Exact Online integration?

An Exact Online integration is software that exchanges data between Exact Online and another system through Exact's API, automatically and on a schedule or trigger. Typical examples: webshop orders becoming sales invoices, stock levels flowing to the shop, and customer records staying the same in your CRM and in Exact.

Exact Online is organised into divisions, which most Dutch users call administrations. Each division has its own customers, items, journals and VAT codes, and every API call targets one division. That structure explains many integration surprises: a connector that works for one administration may not handle a holding company with three.

The REST API covers a wide area. Exact's own resource documentation lists groups for financial data, sales, purchase, CRM, logistics, projects, manufacturing, HRM, documents and payroll. You rarely need more than four or five resources, but knowing they exist helps you see what is possible before you settle for manual exports.

• Inbound to Exact: sales orders, invoices, payments, new relations, time entries.
• Outbound from Exact: items, prices, stock positions, open balances, invoice PDFs.
• Both ways: relations and contacts, when CRM and Exact are both edited.

App Store connector or custom Exact Online integration: how do you decide?

Start with the Exact Online App Store. It has a dedicated category for webshop connections, and for a standard shop on a common platform a connector is often the cheapest and fastest route. Move to a custom Exact Online integration only when you can name the specific gaps.

Gaps we hear about most: the connector books everything on one revenue account when you need several, it cannot handle a second administration, it ignores a custom field your warehouse relies on, it has no way to push data from a system you built yourself, or failures only appear when your accountant finds a missing invoice at quarter end. Each is a legitimate reason to build. “We want our own” is not.

A middle route exists too. Sometimes the right answer is to keep the connector for orders and add a small custom sync for the one flow it lacks, such as stock per warehouse. That costs less and keeps the vendor responsible for the part that works.

Not sure which side you are on? Send us a list of what the current connector gets wrong and we will tell you honestly whether a custom build fixes it.

Which data should an Exact Online integration sync, and in which direction?

Decide one master per field before writing any code. Items and prices usually live in Exact; web content lives in the shop; orders start in the shop; invoices and payments are final in Exact. Syncing a field both ways without clear rules is how duplicates and overwrites happen.

For orders, you also choose the form they take in Exact: a sales order that your warehouse processes and invoices from, or a direct sales invoice when the shop has already taken payment. Wholesalers with stock in Exact tend to prefer sales orders; direct-to-consumer shops paid by iDEAL often book invoices with the payment already matched.

Relations need a matching rule. Is a returning customer recognised by email, by VAT number or by a code stored in both systems? For consumers, many businesses book webshop sales on a single collective debtor; for trade customers, each company should be its own relation. We write these rules down with your bookkeeper, because they decide how your ledger looks.

• Items, descriptions, prices: Exact to shop.
• Stock positions per warehouse: Exact to shop or marketplace.
• Orders: shop to Exact, as sales orders or invoices.
• Payments and refunds: payment provider to Exact, matched to invoices.
• Relations: agreed master, with a matching rule.
• Invoice PDFs and open balances: Exact to customer portal.

The sync map table below shows these flows with typical frequencies.

How does authentication work for an Exact Online integration?

Exact Online uses OAuth 2.0. You register an app in Exact's developer environment, a user with the right rights approves the connection once, and the integration then works with short-lived access tokens that it renews with a refresh token. Nobody stores an Exact password in the integration.

The details matter in production. The token refresh must be handled by one process at a time, otherwise two workers refreshing at once can invalidate each other's tokens and the sync stops at night. Tokens should be stored encrypted, and the approving user should be a dedicated integration user where your subscription allows, so the connection does not break when an employee leaves.

We register the app under your Exact account, not ours. That way the connection belongs to your business, appears in your list of connected apps, and can be revoked by you at any moment. Rights are kept to what the flows need: an order sync does not need payroll access.

• App registered under your Exact account with a redirect URL you control.
• One-time consent by an authorised user in the right division.
• Access token refreshed by a single, locked process.
• Tokens encrypted at rest; secrets never in the code repository.
• Minimum rights for the flows in scope.

What are the Exact Online API limits, and how does an integration stay within them?

Exact's knowledge base lists a limit of 60 API calls per minute and 5,000 calls per day per company, with calls over the limit rejected with an HTTP 429 response. A well-built Exact Online integration plans for those numbers from day one rather than discovering them during the Christmas rush.

Three techniques keep a sync within budget. First, read in bulk: Exact's REST documentation notes that most endpoints return pages of 60 records, while the bulk and sync endpoints return pages of 1,000, and it recommends the sync endpoints where possible. Second, only fetch what changed since the last run instead of the whole item list. Third, queue writes and pace them, backing off when a 429 arrives rather than hammering the API.

Webhooks help too. Exact's API has a WebhookSubscriptions resource, so for supported topics the integration can be told that a record changed instead of polling for it. The notification tells you what changed; the integration then fetches the details, still within the limits.

Limits can change and may differ by subscription, so we read the current values from the rate-limit headers in each response instead of hard-coding them. See Exact's knowledge-base article on API limits for the latest figures.

How does an integration handle several Exact administrations?

With routing rules. Each order, invoice or relation is sent to the division it belongs to, decided by a rule such as the shop's country, the brand, or the legal entity on the order. The rule lives in configuration, so adding a fourth administration later is a setting, not a rebuild.

Groups with several entities often have shared items but separate ledgers, VAT setups and journals. An Exact Online integration for such a group needs mapping tables per division: which revenue account, which VAT code, which journal. We store these in a small admin screen your finance team can maintain, so they are not buried in code.

Rate limits count per company, which usually means per division, so a group with several administrations also has more room overall. The integration still needs to track each division's budget separately.

Error monitoring and reconciliation: how do you know the sync is right?

You know because the integration tells you every day, not because your accountant finds a gap three months later. Every run is logged, every failed record is shown with a readable reason, and a daily report compares totals between the source system and Exact.

Most failures have ordinary causes: a new product not yet created as an item in Exact, a VAT code that does not match a new country, a closed financial period, or a relation code typed differently. The integration should catch these, park the record in an error list, alert a named person, and retry automatically once the cause is fixed. Silent skipping is the one outcome it must never allow.

Reconciliation closes the loop. Each morning the integration counts yesterday's orders and their totals in the shop, counts what arrived in Exact for the same day, and flags any difference. It takes minutes to read and saves the painful end-of-quarter search.

• Run log with start time, records processed and errors.
• Error list with the record, the reason and a retry button.
• Alerts by email or WhatsApp to a named person.
• Daily reconciliation of counts and totals per flow.
• Idempotent writes, so a retry never creates a duplicate invoice.

VAT codes, ledger accounts and journals: why your bookkeeper must be involved

Because the integration books entries in your ledger, its mapping decides how your accounts look. Your bookkeeper or accountant should approve which revenue account, VAT code and journal each type of sale uses before the integration goes live.

Cross-border sales make this concrete. A shop selling to consumers in Belgium and Germany may need different VAT codes per country, depending on how your business is set up; shipping costs and discounts may need their own accounts; marketplace sales may go to a separate journal. We implement the mapping; we do not decide the tax treatment. That is your accountant's call.

Payments deserve the same care. When the shop takes payment through a payment provider, the provider pays out in batches with fees deducted. A good Exact Online integration books those payouts so bank reconciliation in Exact works, instead of leaving your bookkeeper to match hundreds of small amounts by hand.

We write the agreed mapping into a one-page document that your accountant signs off; it becomes the test script for go-live.

Exact Online integration for Shopify and WooCommerce webshops

For Shopify, the integration listens for order events through Shopify's webhooks and writes to Exact; stock and prices travel back through the Shopify Admin API. For WooCommerce, the same happens through WooCommerce's REST API and webhooks, with a small plugin only where a hook is missing.

The webshop side has its own traps. Order edits after payment, partial refunds, gift cards and discounts spread across lines all need a clear booking in Exact. Bundles in the shop may need to become separate items in Exact for stock. Product variants need a stable link to Exact item codes, ideally stored as a field on both sides.

We also plan for volume spikes. A sale day can produce more orders in an hour than Exact's per-minute limit handles directly, so orders queue and flow in steadily. Customers see their confirmation instantly; the booking follows a little later, in order, without errors.

Building or rebuilding the shop itself? Our Shopify and WooCommerce pages for Dutch merchants cover the storefront side.

Connecting a custom portal, CRM or planning tool to Exact

When the other system is your own software, there is no connector to buy, so a custom Exact Online integration is the only route. The upside is full control: the portal can show a customer's open invoices from Exact, create quotes that become sales orders, or push approved hours as time transactions for invoicing.

We design these as a small service between your portal and Exact rather than calling Exact directly from every screen. The service handles tokens, limits, caching and errors in one place, and your portal simply asks it for data. If you later add Moneybird for a second company or move to another package, only the service changes.

Caching matters for portals. A customer opening their invoice page should not trigger five live Exact calls; the service keeps a recent copy and refreshes it on a schedule or when a webhook says something changed.

For portal projects in general, see custom software development for Dutch SMEs.

Similar builds for Moneybird, Twinfield and AFAS

The same pattern works for other Dutch accounting and ERP packages: one integration service, one master per field, logs, alerts and reconciliation. What changes is each vendor's API, authentication method and limits, which we read in their current documentation before quoting.

Moneybird is common with smaller businesses and freelancers; Twinfield often appears where an accounting office manages several clients; AFAS is typical for mid-sized organisations that run finance, HR and projects in one suite, with its own connector mechanism. Some groups use two at once, for example after an acquisition, and need data moved between them.

If you are choosing a package rather than integrating one, we cannot advise on that choice as accountants would, but we can tell you which APIs are easier to build against for the flows you have in mind.

How much does an Exact Online integration cost?

With BtechWaleTech, a focused Exact Online integration of one or two flows starts from US$600, and a full integration with several flows, divisions or a custom portal starts from US$900. Care after the two free months starts from US$120/mo. The written quote lists each flow separately.

The price depends on the number of flows, the number of divisions, how unusual your mappings are, the volume you need to handle within API limits, and whether you want a monitoring dashboard or a simple email alert. Rescuing an existing integration is quoted after we have read its code, because the state of that code decides the effort.

Separate running costs are paid by you: your Exact subscription and any API-related charges Exact applies to your plan, hosting for the integration service, and subscriptions for other systems involved. Quotes from other developers vary widely; compare them on the same list of flows, error handling and reconciliation, not on the headline figure.

The table below shows typical scopes. Our pricing page lists every starting price.

How long does an Exact Online integration take to build and test?

Two to four weeks for a focused sync and six to twelve weeks for a full integration, from written approval. Testing against a separate test administration takes a real share of that time, and it should.

The build starts with the data map and your bookkeeper's mapping approval. Then comes authentication and the first read-only flow, so you can see data moving without anything being written. Write flows follow, first to the test administration, where we replay a few weeks of real orders and compare the results with what your bookkeeper booked by hand. Only after that match does the integration switch to your live administration, usually from a clean cut-off date.

• Week 1: data map, mapping sign-off, app registration.
• Week 2: read-only flows and logging.
• Weeks 2–4: write flows to the test administration, replay of real data.
• Final step: cut-off date, go-live, first reconciliation report reviewed together.

Ask for a test administration from your Exact partner or accountant early; it is the one thing that most often delays go-live.

Working with an integration team in India from the Netherlands

Integration work suits remote collaboration: most of it is reading documentation, writing code and checking logs, and the few decisions that need people are made with your bookkeeper on a call. We share several working hours with you each day, starting in your late morning, since India is three and a half to four and a half hours ahead depending on the season.

In practice: an intake call with you and your bookkeeper, a shared data-map document everyone comments on, a weekly short call, and WhatsApp for quick questions any day of the week. You receive an itemised USD quote within about two working days, nothing is billed before your written approval, and payments go in milestones by Wise, bank wire or PayPal, invoiced from India.

Access is granted by you, not requested as passwords. Your Exact administrator authorises the app, your hosting account runs the service, and our access can be removed the day the project ends. We do not need, and do not ask for, rights beyond the flows in scope.

Another of us handles cloud hosting and data, one of us the integration code, and the third of us the automation logic and planning. More on the remote model: hire developers in India.

Who owns the integration, and how is financial data kept safe?

You own the code, the hosting and the Exact app registration. The integration runs in your cloud account, the repository is yours, and the documentation explains every flow well enough for another developer to maintain it.

Financial and customer data is sensitive, so the build keeps exposure small: encrypted connections, secrets in a proper secret store, logs that record IDs and errors rather than full personal details, and access limited to named people. Personal data in relations and invoices falls under the AVG, where your business is the controller; your adviser decides what agreements you need, and the integration is built to support those obligations.

• Integration service hosted in an EU region on your cloud account.
• Secrets in a managed secret store, never in the repository.
• Logs without full personal data; retention you choose.
• Access removed from us at project end if you wish.

For privacy-focused builds in general, see GDPR-compliant development.

Worked example: a hypothetical e-bike parts webshop in Amersfoort

An illustration, not a client. Imagine a business in Amersfoort selling e-bike parts through a WooCommerce shop and on bol.com, with two Exact administrations: one for the Dutch trading company and one for a Belgian sister company. An App Store connector handles Dutch webshop orders, but Belgian orders, bol.com sales and stock from the second warehouse are typed in by hand every morning.

A custom Exact Online integration here would add three flows. Orders from both channels route to the correct administration by shipping country and brand. Stock from both warehouses flows to WooCommerce and bol.com every few minutes during the day, using sync endpoints to stay within limits. Marketplace payouts are booked so the bank reconciliation matches.

The team would keep the existing connector for Dutch webshop orders during the first phase, then decide whether to replace it once the custom flows have run cleanly for a month. The bookkeeper signs off the VAT-code mapping for Belgian orders before anything goes live. A daily reconciliation email lands at 8:00, and the morning typing session disappears.

Exact Online integration checklist before you ask for quotes

Have these answers ready and any developer can quote accurately, including us.

• Which systems connect to Exact, and which platform versions they run.
• How many Exact administrations are involved, and which one each sale belongs to.
• The flows you need, with direction and a rough daily volume.
• Your current connector, if any, and exactly what it gets wrong.
• Your bookkeeper's preferred booking for orders, payments, fees and refunds.
• Whether a test administration is available.
• Who should receive alerts, and how quickly they can act.
• Where the integration will be hosted, in your name.

Share the list on WhatsApp via our contact page; a rough draft is enough to start.