Integrations between your systems
Retyping invoices, mailing exports back and forth, the same correction every month. As long as two systems do not talk to each other, someone is doing that work by hand. We build the bridge between them.
Every manual hand-off is a chance to get it wrong
Your order system knows what was sold, accounting has to invoice it, and the bank delivers the statements somewhere else again. As long as someone sits in between with an export and an import, it costs time — and now and then it goes wrong, usually in the week of the month-end close.
An integration takes those steps away. Not by replacing everything, but by letting the systems you already have talk to each other directly.
Get in touch →From accounting to bank statement
It nearly always starts with one tedious manual step. That is the one we remove first; the rest follows on its own.
Accounting packages
Pushing invoices, customer records and journal entries across automatically. We have built integrations with Twinfield and SnelStart, including pulling invoice and customer data back out.
Bank statements
Reading and processing MT940 files, so payments are reconciled automatically instead of line by line by hand.
Orders and sales
Connecting your webshop, order system or customer portal to the back office, so a sale becomes an invoice straight away and nobody has to retype anything.
System integrations
REST with JSON, SOAP with XML, file exchange over SFTP or EDI messages — whatever the system on the other end speaks.
Keeping databases in step
Keeping data synchronised between two databases or platforms, with a check afterwards on what did and did not come across.
Reporting
Bringing data from several systems together into one report or data warehouse, so the figures come from a single source.
Building it is the easy part
An integration that only works when everything goes right is not one. The difference shows when something fails.
Working out what actually happens
Which data goes where, who corrects things by hand today, and what exceptions have crept in over the years? That last one usually decides how big the job is.
Building the integration
We talk to the interface the package offers and stay within its rules, so an update on that side does not knock the whole thing over.
Catching the failures
One bad record does not hold up the rest: it is set aside and reported. Everything is logged, so afterwards you can see what was processed and what was not.
Keeping it running
Packages change, certificates expire and passwords get rotated. We keep an eye on the integration, so you do not find out through an empty ledger.
What we have connected before
For a financial services firm we built integrations with Twinfield and SnelStart: pulling customer and invoice data, reading bank statements over MT940 and keeping the bookkeeping data in step, with a SQL database underneath for the automated processing.
For a regulator we connected external parties to a central system over SSH and SFTP using EDI messages. And for a bank we built an interface between the production environment and the data warehouse for management reporting, with REST and JSON integrations to the systems behind it.
An integration rarely stands on its own
It often turns out along the way that something needs doing to the system the data comes from as well — or that it is smarter to set the reporting up properly straight away. We do that work ourselves, so you do not have to bring in a second supplier.
See all our services →Frequently asked questions
Which accounting packages can you connect to?
We have built connections to Twinfield and SnelStart among others: pushing invoices and debtors through, retrieving data and keeping the bookkeeping in step. Other packages work too, as long as there is an interface — an API, an export format, or a database we are allowed to reach.
What is MT940 and what can I do with it?
MT940 is the standard file banks use to deliver statements. Reading that file automatically means payments are matched without anyone comparing line by line. Almost every Dutch bank supplies it, and it is usually the quickest win in an administration.
What happens if one record in the connection is wrong?
That record is set aside and reported; the rest carries on. Everything is logged, so it is clear afterwards what was processed and what was not. A connection that stops at the first deviation creates more work than it saves.
What if the supplier changes their API?
We allow for that by following the rules of the interface rather than taking clever shortcuts. If something does change, we notice it through monitoring — you do not notice it through an empty ledger. Maintenance is part of a connection.
How long does it take to build a connection?
That is almost never decided by the building itself, but by the groundwork: which data goes where, who corrects things by hand today, and which exceptions have crept in over the years. The last of those determines the size of the job.
Can you connect to a package that is not listed here?
Usually yes. We speak REST with JSON, SOAP with XML, file exchange over SFTP and EDI messages. More important than the name of the package is whether it offers an interface and what the supplier permits. We establish that up front.
