e-conomic API Integration: How to Connect Your Systems to Danish Accounting

An e-conomic API integration connects your web app, online store or SaaS product to e-conomic, the Danish accounting software from Visma, so invoices, customers and payments move across without anyone retyping them. If a ready-made app already covers your flow, buy it. If not, my rough estimate is 15-30 hours for a simple one-way integration and 40-80 hours for a two-way sync with proper error handling.

You usually need one if you run a Danish subsidiary that keeps its books in e-conomic, or if you sell software to Danish businesses that expect it to talk to their accounting. I build integrations myself, so weigh my view accordingly, which is also why part of this guide covers when not to build one.

The short answer

Start by finding out whether a connector already exists between your systems. Only when the answer is no, or when the existing app can't handle how you actually work, is it time to build. The table covers typical integrations for businesses operating in Denmark and the Nordics.

These estimates assume an experienced developer and a system with a documented API and a test environment. Take either away and the hours go up. My rule of thumb: if you can't describe on half a page which data moves, in which direction and when, it's too early to ask for a quote.

An integration is rarely a project of its own. It's usually one part of a larger build, and I've described how those run in my guide to the software development process from idea to launch.

Three ways an integration can work

An integration is code that moves data between two systems through their APIs, the entry points a system exposes to other software. New to the term? Start with what an API is and why your system needs one.

In practice, integrations follow one of three patterns:

• A one-way integration pushes data when something happens. Your system creates an invoice in e-conomic when an order ships, for example. It's the simplest pattern, and it's often all you need.
• A two-way sync keeps customers, products or prices identical in two systems. You have to decide which system owns each field, or the two will keep overwriting each other.
• With webhooks, the other system notifies you when something happens, for example when a payment succeeds. The alternative is polling, asking at fixed intervals, which is simpler to build but adds delay.

You rarely need real time. An invoice that reaches accounting five minutes later, or overnight, is usually fine, and real time costs more to build and monitor.

How the e-conomic and Dinero APIs work

e-conomic

e-conomic's REST API authenticates with two tokens: an AppSecretToken that identifies your integration, and an AgreementGrantToken that's issued when a business grants your app access to its accounts. There's a demo mode for trying the API before you register a developer agreement, though it only allows reading data. The REST API also supports an idempotency key, which stops the same invoice from being created twice if a request gets retried.

For a SaaS vendor, the token model matters. Each Danish customer installs your app and approves access to their own accounts, so you'll store one grant per customer and need a way to handle customers who revoke it.

Dinero

Dinero, also owned by Visma, uses Visma Connect with OAuth 2.0 for integrations that connect to other companies' accounts. If you only want to automate your own company's books, Dinero has a separate and simpler setup for personal integrations. New apps have to be approved by Dinero, and there's a limit on how many requests an integration can make.

Other markets work the same way: Fortnox in Sweden, Tripletex in Norway and Xero, popular in the UK, all have their own APIs, each with its own authentication, data model and local VAT rules.

Payments and CRM: same idea, different traps

The customer pays through the provider, and the provider tells your system when the payment has gone through. Stripe's documentation states that the same event can be delivered more than once, that delivery order isn't guaranteed, and that failed deliveries are retried for up to three days in live mode. Your system has to handle "payment succeeded" twice without shipping two orders. That applies to every payment provider, not only Stripe.

CRMs like HubSpot and Pipedrive have well-documented APIs, and a one-way flow is manageable. The trap is duplicates: one customer with two email addresses, or the same company entered with and without "Ltd".

What an integration costs in time and money

The hours depend less on which system it is and more on five things:

• Direction: a two-way sync needs conflict rules and typically costs at least twice as much as one-way.
• API quality: good documentation and a test environment save a lot of hours. A poorly documented API means guesswork and back-and-forth with the vendor.
• Edge cases: credit notes, partial payments, multiple currencies and multiple VAT rates each need their own rule.
• Historical data: moving existing customers or invoices across is a job of its own.
• Monitoring: an email on failure is cheap. A screen where your team can see and rerun failed syncs costs more.

Converted at DKK 800-1,200 an hour (roughly €105-160) excluding VAT, the typical range for an experienced freelancer in Denmark according to my breakdown of freelance developer rates in Denmark, it looks roughly like this:

Then there's upkeep. Expect a few hours a year per integration for updates, renewed tokens and changes on the provider's side, and more if the provider overhauls its API. Ask for each integration to be priced as a separate line in any quote, so you can drop it if an off-the-shelf app turns out cheaper.

Why Danish bookkeeping rules shape the design

If your company has a Danish entity, this is the most important design decision, and it's a legal one. Under the Danish Bookkeeping Act, businesses must keep their books in a digital bookkeeping system. That can be a standard system registered with the Danish Business Authority, or one the business has had built itself, in which case management must make sure it meets the requirements. For businesses that file annual reports, such as limited companies, the rules took effect in 2024 or 2025 depending on financial year and system type. The Danish Business Authority's bookkeeping page (in Danish) has the details.

So I almost always recommend the same split: your system handles orders, customers and workflows and sends invoice data and receipts to e-conomic, Dinero or another registered system, which handles the bookkeeping, VAT and record retention. As a starting point, that keeps your own system out of the Act's requirements for a bookkeeping system, and your Danish accountant works in software they know.

The EU is heading the same way. Under the VAT in the Digital Age (ViDA) package, digital reporting requirements apply to cross-border B2B transactions from 1 July 2030, and structured invoice data in a proper accounting system is a far better starting point than invoices assembled by hand.

None of this is legal or tax advice. If you're unsure how the rules apply to you, talk to a Danish accountant before the integration is designed.

How to build an e-conomic integration in 7 steps

1. Describe the data flow

Write down which data moves, in which direction and when. For example: "When an order is marked as shipped, create an invoice in e-conomic with the customer, line items and payment terms." For each field, note which system owns it. If the integration is part of a bigger build, this description belongs in your software requirements specification.

2. Look for an existing solution

Go through the accounting software's app directory, and check whether Zapier or Make connect both systems. If an existing solution covers most of your needs, consider adjusting your process slightly instead of building.

3. Sort out access, subscriptions and a test environment

Who creates the developer agreement or the app? Who on your side approves access to the accounts? Does your subscription include API access? Is there a test company, so nobody tests against real figures? Vendors can take a while to answer, so ask early.

4. Map the fields between systems

Mapping means deciding how each field in one system corresponds to a field in the other. VAT codes, account numbers, product numbers, payment terms, currency and departments all have to match the accounting setup. Credit notes, partial payments and discounts need rules too. This is where most of the hours go, and your bookkeeper or accountant should be involved.

5. Build error handling in from day one

The integration has to cope with the other system being down, slow or rejecting a request. That means a queue (a list of jobs processed in the background that can be retried), retries with a pause in between, protection against duplicates and a log of what was sent. Tokens must be stored encrypted and never live in the code, which is part of any web application security checklist.

6. Test with real data

Run the integration against a test company using a copy of real orders and customers. Made-up test data won't surface the customer with two addresses or the product with no VAT code. Once it holds up, run it alongside the manual process for a while before switching the manual work off.

7. Set up monitoring and ownership

Decide who gets notified when a sync fails and how it gets fixed. An integration that fails silently is often discovered at the VAT return or when the accountant starts asking questions.

When you shouldn't build a custom integration

A custom integration isn't always the answer, even when I'd be the one building it. I'd advise against it when:

• An existing app covers your needs. A monthly subscription is cheaper than development and upkeep, and the vendor deals with API changes.
• Volumes are low. If you send 20 invoices a month, entering them takes maybe an hour. With 15-30 hours of development plus upkeep, it can easily take a couple of years for the integration to pay for itself.
• Your process isn't settled. If you're still changing how orders and invoices work, wait. Otherwise you'll build the integration twice.
• One of the systems is about to be replaced. Don't build a connection to something you're leaving in six months.
• Zapier or Make can handle it. Simple one-way flows can often be set up without code. Move to a custom build when the flow needs business rules, proper error handling or volumes the tool can't cope with.

On the other hand, a custom integration is usually the right call when it's part of a product you own, when your process differs from what the off-the-shelf apps were made for, or when data has to pass through rules no standard tool supports.

Next steps

With most of those answered, a developer can give you a realistic estimate. For bigger jobs, such as an ERP that syncs in both directions, I start with a paid, fixed-price discovery phase where the data flow and field mapping get settled before any code is written. My page on custom web apps that connect to the rest of your stack shows what I build and how working together starts.

Frequently asked questions

Do I need a Danish developer to build an e-conomic integration?+

No. e-conomic's developer documentation is in English, and the API works like most modern REST APIs. What you do need is someone who understands Danish VAT codes, the chart of accounts your company uses and the bookkeeping rules, or a developer who works closely with your Danish accountant. Most of the risk sits in that mapping, not in the code.

How long does an e-conomic integration take in calendar time?+

Longer than the hours suggest. Fifteen to thirty hours of work can easily stretch over a few weeks, because you wait for access, app approval, answers from your accountant about VAT codes and a test period with real data. Dinero, for example, says approving a new app usually takes up to a working day. Start those requests before development begins, and the calendar time shrinks.

Can one integration support e-conomic, Fortnox and Xero?+

Not directly, because each system has its own API, data model and local VAT rules. If you're building a SaaS for customers across the Nordics or Europe, build one shared layer in your product and a separate adapter per accounting system, starting with the one most of your customers use. Unified accounting APIs also exist, but they add a subscription and don't always cover local details.

Who owns the integration once it's built?+

Your company should. Make sure the contract states that the code belongs to you and that it lives in a repository you control. The app registration with e-conomic or Dinero should also be in your company's name, or be transferable. I work so that clients own the code from day one, so changing developers doesn't force you to rebuild the integration.

What happens when e-conomic changes its API?+

The code needs updating, and someone has to be responsible for watching out for it. Large providers typically announce changes in advance, but notice only helps if somebody reads it. Put that responsibility in a maintenance agreement. Without monitoring, you often won't notice a problem until data is missing from your accounts.