Connecting AI to your existing software: Exact, AFAS, Microsoft 365 and the rest

The demo always looks good. Someone types a question and out comes a tidy answer. What you do not see is where the data came from. In your business it sits in your accounting package, your ERP, your time tracking, your mailbox and probably in a few Excel files on a network drive as well. As long as the AI cannot reach any of that, it does nothing you would not do faster yourself.

This is the point where most automation plans at SMEs stall. Not on the AI, but on the question of how that AI gets at your data and how it gets results back in. This article is about that part.

Why a standalone AI tool without an integration delivers little

An AI with no access to your systems knows nothing about your business. It does not know your customers, your prices or your stock. It can write nicely, but it cannot look anything up and cannot record anything. In practice that means someone copies information out of the package into the AI and pastes the answer back. You have not removed any work, you have added two steps.

Take a wholesaler that wants to get quotes out faster. Without an integration, the inside sales team still has to look up and retype the customer details, the volume price and the lead time. The AI writes a neat text around it. That was never the expensive part. With an integration, the same system fetches the customer, the price agreement and the stock level itself and puts the quote ready for checking. Only then does your turnaround time change.

The rule of thumb: the more copying and pasting grows up around your AI tool, the less that tool delivers. If you see people putting screens side by side to transfer data, an integration is missing.

What an integration is, in plain language

An integration is an agreed way for two pieces of software to ask each other for something. The word you will meet in quotes is API. There is nothing magical about it: it is a list of questions a package is willing to answer and instructions it is willing to carry out, plus the form in which you have to put them.

Think of it as a service desk. Behind that desk sits your accounting package with everything in it. You are not allowed to walk behind it yourself. You put your question to the desk: give me all outstanding invoices for this customer. Book these hours to this project. The desk checks whether you have a valid pass and answers in a fixed format. That pass is called a key or a token, and it also decides what you may do. You can set an integration up so that it may only read and may not change anything. On a first project that is almost always sensible.

Two things follow from that. An integration can never do more than the vendor offers at that desk: if a field is not on the list, you cannot fetch it, however visible it is on screen. And the vendor sets the opening hours. They may rebuild the desk, and sometimes they may close it.

The question is never whether AI can do something. The question is whether your package opens the door, and on what terms.

Connecting AI to existing software: four ways

There are four ways to get at your data. They differ in price, in reliability and in how much trouble they cause later. Usually the answer is a combination: the most important flow properly integrated, the rest handled another way for now.

• The official integration. Your package offers an API and you use it. Reliable, repeatable, and the vendor usually warns you before making changes. Drawback: it may require a more expensive licence or an extra module, you have to arrange permission and keys, and not every field you see on screen is in there.
• Export and import. A file out every night, processed, the result back in again. Cheap and it works everywhere. Drawback: you work with yesterday’s data, and a manual export gets forgotten the moment the person who makes it goes on holiday. Fine as a stopgap, poor as a permanent answer for anything a customer is waiting on.
• A middle layer. An integration platform or small piece of custom software that sits in between, pulls from several systems, translates and passes on. Handy with four packages that each speak their own language and you want one place where you can see what went wrong. Drawback: it is one more system, with its own costs, its own maintenance and a vendor to depend on.
• Someone retyping it. Sounds like no solution at all, but it is the most widely used one. Sometimes it is also the right one: you do not build an integration for ten lines a week. Drawback: it does not scale, typos creep in, and it disappears into the working day without anyone seeing it as a cost. Choose it deliberately and write down what it costs per month.

A pattern that often works: start by reading through the official integration, let the AI produce proposals, and let a person approve them. Only once that has gone well for months do you grant write access. At an installation company processing job sheets that means: read the sheet, propose the hours and materials, engineer or planner presses approve. Less exciting than fully automatic, and it saves you six months of clean-up.

What to ask your software vendor before you start

Have this conversation before you accept a quote for the build work, not after. Send the questions by email, so you have the answer in writing. A vendor who stays vague here is already a risk in your project.

1. Is there an API, and where is the documentation? Ask for the link. If it sits behind a partner portal, ask how your builder gets access.
2. Is that API included in my current licence, or do I need a different tier or an extra module? Ask for the amount, per month and per year.
3. Which data can I read and which can I write back? Name concretely what you need: customers, products, price agreements, hours, invoices, documents.
4. Are there limits on the number of requests per minute or per day? That decides whether you can refresh every five minutes or once a night.
5. How do you announce changes, how far in advance, and how long does an old version keep working? This predicts your maintenance load better than anything else.
6. Where is the data held, and may my integration reach it from another environment? Ask about the region and about what the terms say on transfers.
7. Am I allowed to have data from this package processed by an AI model? Some terms forbid that or require permission up front.
8. Who do I contact when the integration stops, and is that covered by my support contract?

Names like Exact, AFAS, Microsoft 365, Moneybird and HubSpot come up most often in these conversations, simply because many SMEs work with them. What each of those packages offers right now, and at which licence tier, changes regularly. We deliberately say nothing about that in an article that will sit here for a year. Put the questions above to your own vendor, about your own version and licence, and go by what you get in writing.

What it costs in time

The time rarely goes into the programming. It goes into working out what is allowed and possible, into getting access arranged, and into the mess in your data. That last one is almost always the biggest block. Two systems that spell the same customer differently, product numbers with and without a hyphen, projects that have a number here and a name there: someone lines all that up by hand before anything can run automatically.

In your plan you put, in this order: the conversation with your vendor and the wait for keys, cleaning up your data, the building and testing, and then a period in which the system runs alongside and a person checks the outcomes. People love to skip that last period. That is where the mistakes sit that you pay for later.

With us it starts with a half-day core session (four hours) on your own shop floor, in which we follow the process and the systems involved from start to finish. That costs €596 excluding VAT and travel expenses. Build work after that is charged per hour: €110 for straightforward work such as setting up a standard integration, €165 for complex development. What it costs in your case depends mostly on how clean your data is and how many exceptions your process has.

When an integration is not possible or not allowed

Sometimes the answer is simply no. Annoying, but better in week one than in week six. Four reasons come up most often.

• The vendor keeps it closed. No API for customers, only for certified partners, or only in the most expensive subscription. Sometimes it is policy: they do not want data flowing out of their system. That is their right and there is little you can change about it.
• The licence terms forbid it. Automated access, reading screens or passing data to a third party can be explicitly prohibited. Read that before you build, not after you have been noticed.
• The data is not allowed to leave. If you work with personal data, the GDPR sets the conditions under which you may have it processed by someone else and where that may happen. An AI service outside the EU is then a choice with consequences. This weighs heavily with staff records and with client files at an accounting firm.
• It is possible, but not worth it. You will not earn back an integration for a process that happens twice a month. Then someone retyping it is the right answer.

If you get stuck on the first two, something usually remains: a scheduled export to a secure folder, a vendor who will build an integration for a fee, or shifting the process to a system that does open up. Not elegant, but working. And it is a good reason to put the question of how well something integrates at the front of your next package selection.

An integration is never finished

This rarely comes up in sales conversations: you do not build an integration, you maintain one. Your vendor changes their software, because that is what a living package does. A field gets renamed, an old API version is switched off, a key expires, a security rule gets stricter. Then your integration stops, and usually you hear it from a customer on the phone.

What helps: build it from day one so the system tells you when something goes wrong. An alert to a mailbox someone watches, an overview of what was processed and what was left behind, and a manual route to push something through anyway. At a haulage firm that invoices trips automatically, you do not want to discover on Monday that nothing has come through since Thursday.

And agree who fixes it. Put in the quote who looks at it when an integration stops, within what timeframe and at what rate. Without that agreement, every outage becomes a fresh negotiation at the worst possible moment.

When you need us and when you do not

If you have two common packages that offer a standard integration with each other, you do not need us. Switching it on and configuring it is an afternoon’s work and your vendor will help you. The same goes if an off-the-shelf integration from a marketplace solves your question. Take it.

We are useful as soon as several systems are involved that do not speak each other’s language, as soon as logic is needed around it that no standard integration provides, or as soon as you want to know whether it is possible at all before you put money into it. In that last case, the core session is the cheapest way to find out that you should not build something.