It looks like you’re from {country}
Accounting
e-Boekhouden.nl is one of the oldest online accounting packages in the Netherlands and has an enormous installed base of small businesses and associations. It also has an API — the most-searched thing about it, which tells you who is looking.
It is a SOAP-era interface with session tokens rather than a modern REST API, and that is not a reason to avoid it. It is a reason to build against it carefully, because the failure modes are less forgiving.
e-Boekhouden.nl is a Dutch online accounting package aimed at small businesses, freelancers and associations: invoicing, bank import, VAT returns, ledger, and a large library of import templates. It is priced low and it is very widely used, especially by accountants who standardised on it years ago.
Its API is a SOAP web service. You open a session, get a session ID, and use it for a limited window before it expires; there is a documented set of calls for adding invoices, adding and reading relations, and reading mutations. It is entirely workable, but it is stateful in a way modern APIs are not, and a connection that ignores the session lifecycle will fail intermittently in ways that look random.
Two of these three are specific to how this API works, which is exactly why a connection built by somebody who has not met it before tends to be flaky for the first six months.
A naive connection opens a session, starts pushing forty invoices, and the session times out on number twenty-eight. Twelve invoices vanish, no error reaches anyone, and the difference is found at the quarter.
What you see instead
Sessions are refreshed before they expire and every invoice is confirmed individually before it is marked done. A session that dies mid-batch means the rest waits in the queue, not that it disappears.
A call times out but actually succeeded on the server. The connection retries, and now there are two invoices for one order. Since the numbering is sequential, spotting the duplicate later means reading them.
What you see instead
Every order carries its own reference into the invoice, and the connection checks for it before creating anything. A retry finds the existing invoice and moves on.
Many e-Boekhouden users already have their accountant importing something monthly from a CSV. Add a live connection without telling them and the same turnover is booked twice, on different ledger accounts.
What you see instead
The ledger mapping is agreed with whoever does your books before the first invoice is sent, and the old import is switched off in the same week. Ten minutes of coordination, and a month of confusion avoided.
The typical e-Boekhouden user is cost-conscious by definition — it is part of why they chose it — so the honest framing here is not "you are wasting thousands", it is "here is the volume at which this stops being sensible".
Below about fifty invoices a month, typing them in is genuinely fine and a connection is a luxury. Between fifty and two hundred it becomes a real cost, mostly through the mistakes rather than the minutes: an invoice on the wrong ledger account is corrected by your accountant, at their rate. Above two hundred, doing it by hand is the more expensive option by a comfortable margin.
For e-Boekhouden users the site or shop is usually the newest thing in the company and the bookkeeping the oldest, which makes the two-ends point unusually literal: the connection is only worth building if the front end is worth connecting to.
A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.
The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.
WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.
WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.
When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.
The API's vocabulary is invoices, relations and mutations, so those are the flows. No stock, no orders.
Orders as sales invoices, on agreed ledger accounts (into the tool)
Lines, quantities, VAT codes and the ledger account per product group, with the order reference carried through so duplicates are impossible.
Relations: customers and suppliers (both ways)
Created and updated from whichever system you name as the owner, matched on relation code or email.
Mutations and open items (out of the tool)
Read back into a dashboard or a customer portal, so open balances can be shown without anyone logging into the accounting package.
Payment status per invoice (into the tool)
From Mollie or another provider, so an invoice paid online is not chased by a reminder.
The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.
Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.
A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.
Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.
Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.
This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.
A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.
Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.
APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.
For e-Boekhouden.nl specifically, budget a little more than for a modern REST API of the same scope: the session and duplicate handling is real work, and skipping it is what makes these connections flaky. It is also work that only needs doing once.
A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.
What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.
Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.
Yes, with the caveat that it asks more of the connection than a modern one does. Sessions, sequential invoice numbering and no idempotency key of its own mean the reliability has to be built on our side rather than assumed from theirs.
Once that is done it is stable. The connections we run against it are no more trouble than the REST ones; the difference is entirely in the first build, not in the years afterwards.
Technically yes, practically no, and we would advise against it. Two routes booking the same turnover is how you get a year that has to be unpicked.
The right sequence is to agree the ledger mapping with your accountant first, run the connection in parallel for one month while comparing, and switch the import off at the end of it. Your accountant is usually pleased: it is work they were doing that they no longer have to.
Yes, and it is one of the better uses of it, because associations are exactly where e-Boekhouden.nl is common and where the manual work is concentrated in one annual batch that somebody dreads.
A membership administration on the website — join, change, cancel, dues per category — creating the invoices in one run, with payment status coming back so the treasurer can see who has paid without opening the books. This tends to be a smaller project than a shop connection.
