Connecting your accounting package to your website or software
Retyping invoices from your online store or time tracking is work software can take over.
What an API is
An API is an entry point a software package provides for other software. Where you log in through a screen, your online store or time tracking signs in through that entry point with a key of its own. It can then request and write data, within the rights attached to that key.
Every integration between two systems runs through such an entry point. So the main question is whether your package offers one, and which data an integration may read and write through it.
These packages have an API
Five packages that are common among Dutch small and medium-sized businesses all offer an API with public documentation.
| Package | API | Notes |
|---|---|---|
| Exact Online | REST API with webhooks, alongside an older XML API | Exact runs its own developer portal and an app store with ready-made integrations. |
| Moneybird | REST API | For your own administration you create a personal token yourself; an app for third parties is registered with Moneybird. |
| e-Boekhouden.nl | REST API, alongside an older SOAP variant | The technical documentation is publicly available online. |
| AFAS | REST connectors: GetConnectors read, UpdateConnectors write | An administrator decides within the AFAS environment which data an integration may read and write. |
| SnelStart | REST API through a developer portal | You request access from SnelStart; a production integration requires OAuth and is reviewed by SnelStart first. |
What such an integration does
Most integrations consist of a small number of flows. Which ones you need follows from where data is being retyped today.
Pay attention to the direction of the data in the design. A one-way integration is simple and predictable. A two-way integration is possible too, but then it must be agreed which system takes precedence when both are changed at the same time.
- Writing invoices: an order in your online store or a finished project in your software automatically becomes an invoice or entry in your package
- Retrieving payment status: your software checks in the package whether an invoice has been paid and updates the order or the record
- Synchronising customers and products: one system is the source, so a change of address only has to be made in one place
- Exporting hours: tracked hours go to the package as invoice lines or entries, per period or per project
Check your subscription first
API access is not part of every plan, so check this before anything gets built.
- Is API access part of your subscription, or only of a higher plan or a separate option
- Who manages the administration: if it sits on your accountant's subscription, you arrange the access together with your accountant
- How you obtain a key: with one package you create it yourself, with another you request it and the integration is reviewed first
- Which rights the key gets: read-only where reading is enough, so a fault in the integration cannot change any entries
Error handling
Integrations differ mainly in what happens when something goes wrong.
Errors must be visible. An invoice the package rejects, for instance because of a missing VAT code or an unknown customer, should appear on a list that someone checks. An integration that does not report errors can give the impression for months that everything is in order.
The package is sometimes temporarily unavailable, and so is your own software. A good integration then puts the entry in a queue and tries again later, so nothing is lost and nobody has to keep track of what happened during the outage.
Retrying must never lead to a duplicate entry. That is why the integration sends its own reference with every entry, or first checks whether the entry already exists. Duplicate invoices only come to light when a customer calls or when the VAT return does not add up, and tracing them then takes a lot of time.
Having it built or using middleware like Zapier
You can also put a middleware layer between two packages, such as Zapier or Make. In such a tool, you set up a flow without programming: when something happens in system A, do this in system B. For a simple flow, such as staging every new order as a draft invoice, that is sometimes the better choice.
Middleware also has drawbacks. Your customer and invoice data travels through that middleware's servers, and so passes through an extra party. You pay per month and per number of tasks, and those costs rise with your volume. The flow also depends on every step. If one of the two packages changes a field, the flow stops, and you often only notice later.
With custom work, the logic sits in your own software, with the error handling described above and without a third party between your administration and your system. That pays off when the flow has to do more than pass data along, for example checking, merging, waiting for a payment or combining data from several sources.
Sources
Frequently asked questions
Our accountant works with one of these packages. Do we have to switch for an integration?
Usually we build the integration for the package you already use, so your accountant can keep working the same way.
What happens if the accounting package is temporarily unavailable?
With a well-built integration, the entries go into a queue and are processed once the package is available again.
Can an integration cause double bookings?
It can happen if, after an outage, the integration resends an entry that had already arrived. Sending its own reference with every entry prevents that, because the integration can then tell that the invoice is already in the package.
When is Zapier enough?
Zapier is often enough for a simple one-way flow.
Do you also build an integration separate from a larger project?
We also build an integration between your existing software and one of these packages as a separate project.