AI for e-conomic integration: what can be built in 2026
By Jacob Slot · Published
AI for e-conomic integration works best on the three steps where a person currently reads, types and checks: documents that need interpreting, drafts that need creating, and figures that need pulling into a report. The posted entry should still be approved by a human. That is not a limit of the technology. It is a choice you should make on purpose.
That is the short answer. The rest of this guide covers what the e-conomic API actually allows, where most projects stall, and how we test an integration on your own data before it goes live.
We build this kind of integration for Danish small and mid-sized businesses, so what follows comes from what went wrong in the first attempts, not from a feature list.
AI for e-conomic integration: the short answer
There are three levels, and they cost very different amounts. Most small businesses need level two but get sold level three.
| Level | What it is | Time to live | Suited for |
|---|---|---|---|
| 1: e-conomic's own features | Document scanning, bank reconciliation, payment reminders | Hours | Everyone. Always start here |
| 2: Ready-made integrations from the app marketplace | Webshop, payroll, inventory, company cards | Days | Standard flows between well-known systems |
| 3: Built on the API | Your own logic, your own rules, your own systems | Weeks | Flows no app covers |
Level three is the only place where the word AI means anything. Levels one and two are rule-based automation, and that is fine. A bank reconciliation does not need a language model.
AI only becomes relevant when something has to be interpreted: a supplier PDF that follows no fixed template, an email where a customer asks for a credit note without giving the invoice number, an account string that has to be guessed from a line of text. Those tasks involve judgment, and rules handle judgment badly.
What e-conomic does on its own before you build anything
The cheapest project is the one you never start. e-conomic already has document scanning, automatic bank reconciliation, recurring invoices and automatic payment reminders in its plans. It is described on e-conomic's page on automation, and it covers a surprisingly large share of an ordinary bookkeeping day.
The next step is the app marketplace. It holds ready-made integrations for webshops, payroll systems, inventory management and company cards, and they are typically set up in an afternoon. A ready-made app that covers most of your needs almost always beats a custom build that covers everything. The source for these is e-conomic's own catalogue of apps and extensions.
Ask yourself three things before you move on to the API:
- Is there an app that covers most of the task?
- Is the remaining part something a person can handle in under an hour a week?
- Can the process be changed so the need disappears?
If you answer yes to any of them, stop. We say the same to customers who call wanting something built that they can buy for the price of a lunch each month.
The two APIs behind every e-conomic integration
This is where it gets technical, and where most Danish articles stop. e-conomic runs two APIs side by side, and they do not do the same things.
The older Legacy REST API at restapi.e-conomic.com covers customers, products, orders, quotes, invoice drafts and booked invoices. It is well documented and stable, but it cannot post a journal voucher, and it has no webhooks.
The newer OpenAPI side covers dimensions, posted entries, webhooks and posting of journal vouchers. The journals endpoint can post a voucher, which e-conomic has described itself. If your integration needs to react to an event instead of asking every five minutes, you need webhooks, and that puts you on the newer side.
In practice, most real integrations use both. It is not pretty, but that is how it is, and it is worth knowing before anyone promises you a solution in two days.
Authentication and the role you cannot change
Every call is sent with two headers: X-AppSecretToken, which identifies your app, and X-AgreementGrantToken, which identifies access to the individual customer agreement. It is described in e-conomic's documentation on authentication, and you can test with demo tokens before you register anything.
The expensive detail: the app's role is set when you create the app in the developer portal, and it cannot be changed afterwards. An app created as Bookkeeping cannot read customers or products. If you find that out when half the build is done, the app has to be created from scratch and every customer has to grant access again. We have seen it cost a week.
Four automations we build on the e-conomic API
These are the four that most often pay for themselves. All four are built on the API, and all four have a person as the last step.
Documents to drafts. An incoming invoice lands in a mailbox. A model reads the supplier, amount, VAT and date, proposes an account coding based on how the same supplier was booked the last few times, and creates a draft. The bookkeeper approves. The time goes from a few minutes per document to one click.
Debtor follow-up with language. e-conomic can send payment reminders. What it cannot do is write differently to a customer who always pays on time and one who owes for the third time. A model pulls overdue items, groups them by customer and writes a draft email that you approve.
Reporting across systems. Figures from e-conomic are rarely enough on their own. Combined with hours from your project system or orders from your webshop, they become a contribution margin per customer. It is the same logic as in automated reporting, just with the accounts as the source.
Data sync in both directions. A new customer created in the CRM should exist in e-conomic without anyone typing it in again. It sounds trivial, and it is where most of the hours disappear in a small business. We have written more about this in the guide to automating data entry.
Where the limit for AI in e-conomic integration sits
Four limits are worth knowing before you decide anything.
Draft, not posting. A draft is created with one call, and posting is another. A posted invoice cannot be edited, only reversed with a counter-entry. That is why we let an agent create drafts and never post on its own. It is not because the model is poor. It is because a mistake in a draft is one click to fix, and a mistake in a posted entry is a correction in the accounts.
Fair use. e-conomic caps usage at 50,000 API calls per 24 hours per agreement and can restrict access without notice if an app puts too much load on the system. It is stated in their fair use policy. In practice you only hit it if you ask instead of listen, meaning you use polling rather than webhooks.
No official MCP server. If you want to connect a chat assistant directly to the accounts, know that there is no official MCP server from e-conomic. The ones marketed as such are third parties that store your two tokens on their servers. That can be a perfectly good solution. It is just one more data processor, and that decision belongs to you, not to a vendor.
Personal data. Accounting data contains names, addresses and payment patterns. If you send them to a language model, it is a transfer that has to be explainable. We therefore default to data minimisation: only the fields the task requires, and a model hosted in the EU where possible.
What does AI for e-conomic integration cost?
A single defined flow, meaning one of the four above, starts at $1,500 as a one-time build. If we also maintain it and keep building on it, it is from $750 a month. You own the code and the documentation, so you can take it with you if you want to go elsewhere.
The calculation you should make is not price against price. It is price against hours. A team that spends 15 hours a week typing and checking spends more than a third of a full-time job on it. A full-time hire in Denmark costs 25.000+ kr. a month and does it every month. An integration is built once.
Key numbers
15 hours
a week is what we typically find per customer
20,000 DKK/month
saved at Markeity on systems built once
53
automations in production
We have laid out the numbers in more detail in the guide to what AI automation costs, and you can see the bigger picture on our page about system integration.
How we test before anything goes live
We do not build against your production agreement. First against demo tokens, then against a copy of your own documents, then in parallel running where the flow proposes and a person compares it with what would otherwise have happened. Only after that does it take over. From audit to live is typically about 3 weeks.
Three mistakes that kill an e-conomic integration
The first: building against the production agreement from day one. It feels faster, and it is, right up until a test creates fifteen drafts that have to be deleted by hand. Build against demo tokens, and move over only when the flow does the right thing twice in a row.
The second: asking instead of listening. A flow that checks e-conomic every minute to see whether anything has happened uses more than 1,400 calls a day without having done anything at all. With ten customers on the same app you are approaching the cap. Webhooks solve it, because then e-conomic tells you when something has happened.
The third: automating a process nobody has written down. This is the most expensive one. Bookkeeping in a small business is rarely documented. It sits in the head of the person who has done it for five years. If you do not ask about the exceptions, you build a flow that is right in most cases and creates more work in the rest. That is why we always start by going through a week of documents together with the person who normally books them.
What the three have in common is that none of them is a technical problem. They are decisions made too early. An e-conomic integration is rarely hard to code. It is hard to scope, and that is where the work is.
FAQ
Can e-conomic post fully automatically with AI?
Technically yes, through the journals endpoint on the OpenAPI side. We do not recommend it as a starting point. Let AI create the draft and let a person approve it. Once the flow has run for a few months and the error rate is known, you can move the most predictable document types over to automatic posting.
Which API should I use for my e-conomic integration?
Both, most often. Legacy REST for customers, products, orders and invoices. The OpenAPI side for webhooks, dimensions, posted entries and posting of journal vouchers. Choose based on what the flow needs to do, not on what is easiest to get started with.
What does access to the e-conomic API cost?
Access to the API costs nothing in itself. You register an app in the developer portal and get demo tokens for free. What costs money is the plan you have with e-conomic and the work needed to build the integration.
Can I use n8n, Make or Zapier instead of building it myself?
Yes, for simple flows. All three can talk to e-conomic through HTTP calls, and for a chain of three steps it is faster. When the flow branches, or a model has to interpret something, the complexity comes back somewhere else. We have compared the three in n8n vs Make vs Zapier.
How long does an integration take to build?
A defined flow typically takes two to three weeks from first conversation to going live, and a large part of that is testing on your own data. What takes the time is rarely the code. It is working out how the bookkeeping actually happens at your company, as opposed to how it ought to happen.
AI for e-conomic integration is not a question of how clever the model is. It is a question of which steps you dare to let go of, and which you want to keep approving yourself.