e-conomic and Dinero in your own system: stop double entry

Over a year that is a job. Or at least a junior role you cannot afford. If you already pay for e-conomic or Dinero — and most do — the next right investment is rarely a new accounting package. It is letting what you already have talk to the system you actually work in.

What a real e-conomic integration is (and what Zapier is not)

Three levels people call “integration”:

1. Export to CSV. You download, you upload. That is not an integration. It is a faster USB stick.
2. A button that sends one invoice. Better. Still a human in the middle.
3. A flow. Order becomes invoice becomes posting becomes reminder becomes “blocked for new orders”, without anyone copying a CVR number.

Buy level 3 if double entry is your problem. Level 1 is what you have now. Zapier and Make can move fields between cloud tools. They are fine for marketing lists. They are a bad place to put your books if you have your own rules, your own SKUs and an accountant who asks where the posting came from.

Which accounting system you typically have — and what the API can do

e-conomic

e-conomic is the default in many Danish SMEs with a bookkeeper or accountant on the side. There is an older REST API and a newer OpenAPI. Visma (the owner) says new functionality lands on OpenAPI, and integrations should be OpenAPI-first.

Technically you sign in with two tokens (app token + agreement token). That is why “can’t you just get the code from the bookkeeper” does not work. An app has to be created and granted access on the agreement. e-conomic integration as a service.

• Customers / debtors
• Products and prices
• Invoices and credit notes
• Payment status
• Chart of accounts and dimensions (departments, cost centres)

Dinero

Dinero hits the smaller companies that run a simpler set of books themselves. The API is REST. There are partner integrations (OAuth via Visma Connect) and personal integrations with an API key for your own firm. Dinero publicly reports more than 90,000 active Danish companies. That is why a Dinero integration is not a niche. Dinero integration.

• Contacts
• Products
• Invoices and cash-book lines
• Expenses / vouchers
• Posted entries into reports in your own dashboard

Billy, Uniconta, Visma siblings

Same principle. Different API. Different mapping. If your studio says “we have done e-conomic, so Billy takes a day”, ask what is actually reused and what is new mapping.

The flow you actually want

1. Sales creates the order in your system.
2. CVR is looked up (cvr.dev or similar) so name and address are not typed wrong.
3. The customer is created or matched in e-conomic / Dinero.
4. The invoice is posted in the accounting system, not in a Word document.
5. Payment lands via QuickPay / MobilePay / Stripe.
6. Payment status is written back, so your system does not chase a customer who has paid.
7. The bookkeeper opens e-conomic and sees postings that are already right.

Step 6 is where most home-grown solutions die. They can send the invoice. They cannot survive a half payment, a bank transfer instead of the link, or a credit note.

Where the hours sit today

340 hours is more than six working weeks. Even at 250 DKK internal hourly cost that is 85,000 DKK a year. An integration inside an SME package costs somewhere between a fraction of that and one year of waste. If the sum is under 40 hours a year, wait. If it is over 150, the project is already late. What custom software costs.

What makes an integration expensive — and what makes it cheap

Cheap when the studio has built that exact accounting system before, you have clean SKUs and one VAT rate per line, you can accept that accounting is master of the customer number, and you do not need 2019 history synced backwards.

Expensive when you have three price lists and discount matrices nobody can explain, you want two-way sync on everything “just in case”, you mix private and business customers with no CVR field, or the bookkeeper uses a chart of accounts that is not written down.

The expensive part is almost never the HTTP call. It is agreeing what wins when the two systems disagree.

Payments, shipping and the other Danish pieces

Accounting is the hub. The other spokes SMEs typically also have:

• MobilePay / QuickPay / Stripe — the payment must match the invoice
• PostNord / GLS — the consignment note and tracking belong on the order, not in an email thread
• HubSpot / Pipedrive — sales should not type the customer a third time
• Penneo / MitID — a signed order is an event that may trigger an invoice. MitID in your own app
• cvr.dev — one lookup kills 80% of typing errors

A vendor that already has those modules can put 1–3 of them in a fixed package. A vendor that starts from scratch on e-conomic tokens every time is selling you a research project. Third-party integrations.

Security that must not be an afterthought

• Tokens and API keys belong in a secrets manager, not a Slack thread.
• Integrations should have the least rights that work. An app that can read invoices should not be able to delete the chart of accounts.
• Log every call that creates or posts something. The auditor will ask.
• Personal data in invoice lines (initials, case numbers that are really CPR) needs a policy.
• Dinero Pro is required for API access there. Check the licence before kickoff.

What to put in a brief

• We use: e-conomic / Dinero / Billy / other
• Master for the customer is: our system / the accounting system
• We want to: send invoices / pull arrears / both
• Payment happens with: MobilePay / card / bank / mixed
• Invoices per month
• New customers per month
• Special rules: discount, subscription, on-account, project
• Who approves that an invoice may be sent

With that list a studio can say whether you are a 1-integration package or a mid-size project. See pricing.

What to do now

Screenshot the last invoice you typed twice. Write how long it took. That is your business case. Then: one accounting system, one master rule, one flow. Not “can you just sync everything”. All services.