Connecting your accounting package to your website or software
Retyping invoices from your online store or time tracking is work software can take over. Here is how an integration with your accounting package works, and what to check before you have one built.
What an API is, in plain terms
An API is a doorway a software package opens up for other software. Where you log in through a screen, your online store or time tracking presents itself at that doorway with a key of its own. It can then request and write data, within the rights attached to that key.
For your accounting, that means your online store can create an invoice in your package by itself, and your software can see in the package that the invoice has been paid. Nobody retypes anything anymore, and retyping is exactly where the mistakes happen.
Every integration between two systems runs through such a doorway. So the real question is whether your package offers one, and what is allowed 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. How you get access differs per package.
| Package | API | Worth knowing |
|---|---|---|
| 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 in practice
Most integrations revolve around a small number of flows. Which ones you need depends on where the retyping happens today.
Pay attention to direction in the design. One way is simple and predictable. Two ways is possible too, but then it must be settled which system wins when both change something 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
- Payment status back: your software sees in the package that an invoice has been paid and updates the order or the file
- Synchronising customers and products: one place is the source, so a change of address does not have to happen in three places
- 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. Some packages include the API in every subscription, others only in the higher plans or as a separate option, and others grant access only after a request. Check this before anything gets built, because without that access there is nothing to connect to.
- 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
What makes an integration robust
An integration that only works when everything goes right costs more than it delivers. The difference lies in what happens when things go wrong.
Errors must be visible. An invoice the package rejects, for instance over a missing VAT code or an unknown customer, belongs on a list somebody sees. An integration that lets errors drop silently gives you months of feeling that everything is fine.
The package is sometimes down for a while, and so is your own software. A good integration then puts the entry in a queue and tries again later. Nothing is lost, and nobody has to keep track of what happened during the outage.
And retrying must never book twice. For that, the integration sends its own reference with every entry, or checks first whether the entry already exists. Duplicate invoices only surface when a customer calls or when the VAT return does not add up, and then it is detective work.
Having it built or using middleware like Zapier
You can also put a middleware layer between two packages, such as Zapier or Make. You click a flow together 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, and then we say so.
There is a trade-off. Your data travels through that middleware's servers, so your customer and invoice data passes an extra party. You pay per month and per number of tasks, and that grows with your volume. And the flow leans on every step: if one of the two packages changes a field, the flow stops, and you often notice late.
Custom work puts the logic in your own software, with the error handling from the previous block and without a third party between your administration and your system. That pays off when the flow has to do more than pass things along: checking, merging, waiting for a payment or combining data from several sources.
We build these integrations as part of custom software and online stores, directly against the APIs above. That works like all our work: a fixed price after a free introduction.
Sources
Frequently asked questions
Which package is easiest to connect?
With Moneybird you can start quickly for your own administration: you create a token yourself. With AFAS an administrator sets up connectors first, and with SnelStart you request access. Choose your package for your bookkeeping and your accountant; all five connect well.
Our accountant works with one of these packages. Do we have to switch for an integration?
Usually not. You build an integration against the package that is already there, and your accountant keeps their own way of working. Do discuss it upfront: the administration often sits on the accountant's subscription, and then you arrange the API access together.
What happens when the accounting package is down for a while?
With a well-built integration, not much. The entries wait in a queue and go through once the package is back. Ask about this explicitly when someone builds your integration, because this is the part you do not see in a demo.
Can an integration cause double bookings?
Yes, if it is built naively: an outage halfway through and a retry then produce two invoices. That is why a good integration sends its own reference with every entry, or checks first whether the entry already exists.
Is Zapier not simply enough?
For a simple one-way flow it often is, and then we say so. Custom work pays off when the flow needs logic, when the volume grows, or when you do not want your administration passing through an extra party.
Do you also build an integration separate from a larger project?
Yes. An integration between existing software and one of these packages can be a project in itself. In a free introduction we first look at your package, your subscription and the flow you want, and after that you get a fixed price.
Our package is not in the list. Is it still possible?
If the package has an API with documentation, usually yes. That is the first thing we check during the introduction, because the whole plan depends on it.