Integration til e-conomic, Dinero og andre: sådan kobler du dit system sammen

En integration til e-conomic eller Dinero kobler dit eget system til regnskabet, så fakturaer, kunder og betalinger flytter sig automatisk i stedet for at blive tastet ind to gange. Findes der en færdig app til netop jeres flow, er den næsten altid billigst. Skal integrationen bygges, er mit grove skøn 15-30 timer for en simpel envejs-integration og 40-80 timer for en tovejs-synkronisering med ordentlig fejlhåndtering.

Jeg bygger selv integrationer og har dermed en interesse i emnet. Derfor handler en del af guiden også om hvornår du ikke skal have bygget noget.

Den korte version

Start med at finde ud af om der findes en færdig kobling mellem dine systemer. Først når svaret er nej, eller når den færdige app ikke kan det jeres proces kræver, er det tid til at få bygget noget. Tabellen viser typiske integrationer hos danske virksomheder.

Skønnene gælder for en erfaren udvikler og et system med et dokumenteret API og et testmiljø. Mangler et af de to, stiger timerne. Min tommelfingerregel: kan du ikke beskrive på en halv side hvilke data der skal flyttes, og hvornår, så er det for tidligt at bede om en pris.

En integration bliver sjældent bygget alene. Den er som regel en del af et større projekt, og hvordan sådan et forløb typisk foregår, har jeg beskrevet i guiden til softwareudviklingsprocessen fra idé til drift.

Hvad en integration er, og de tre måder den kan virke på

En integration er kode der flytter data mellem to systemer via deres API, altså den indgang et system stiller til rådighed for andre programmer. Er begrebet nyt, så start med hvad et API er, og hvorfor dit system har brug for et.

I praksis virker integrationer på en af tre måder:

• En envejs-integration sender data videre når noget sker. Dit system opretter fx en faktura i e-conomic når en ordre er leveret. Det er den simpleste type, og den er ofte nok.
• En tovejs-synkronisering holder kunder, varer eller priser ens i to systemer. Her skal du beslutte hvilket system der ejer hvert felt. Ellers overskriver systemerne hinanden.
• Med webhooks giver det andet system selv besked når noget sker, fx når en betaling er gennemført. Alternativet er at spørge med faste mellemrum, kaldet polling. Det er enklere at bygge, men giver forsinkelse.

Der er sjældent brug for realtid. En faktura der når regnskabet efter fem minutter eller i nat, er som regel fin, og realtid er dyrere at bygge og overvåge.

De typiske danske integrationer

Regnskab: e-conomic, Dinero og de andre

e-conomic forbinder apps med to nøgler: en AppSecretToken der identificerer integrationen, og en AgreementGrantToken som opstår når virksomheden godkender at appen må tilgå dens regnskab. Udvikleraftalen er gratis, og ifølge e-conomics API-dokumentation findes der en demo-adgang til at afprøve API'et, dog kun til at læse data. API'et understøtter også en såkaldt idempotensnøgle, som forhindrer at den samme faktura bliver oprettet to gange hvis et kald bliver sendt igen.

Dinero bruger Visma Connect med OAuth 2.0, et standardiseret login hvor brugeren selv godkender adgangen. Det er løsningen til integrationer der skal kobles på andre virksomheders regnskab. Vil du kun automatisere din egen virksomheds bogføring, har Dinero en separat og enklere ordning til personlige integrationer. Nye apps skal godkendes af Dinero, og der er en grænse for hvor mange kald en integration må lave.

Billy og Uniconta har også API'er, og mønsteret er det samme: en adgangsnøgle, kald til kunder, varer og fakturaer, og en række danske detaljer som momskoder og kontoplaner der skal passe til virksomhedens opsætning. Tjek også jeres abonnement, for hos nogle udbydere kan API-adgang være knyttet til bestemte pakker.

Betaling: Stripe, Vipps MobilePay og QuickPay

Betalingsintegrationer er hændelsesbaserede. Kunden betaler hos betalingsudbyderen, og udbyderen sender en besked til dit system når betalingen er gennemført.

Det svære er detaljerne. Stripe skriver i sin dokumentation at den samme hændelse kan blive leveret mere end én gang, at rækkefølgen ikke er garanteret, og at mislykkede leveringer bliver forsøgt igen i op til tre dage. Dit system skal derfor kunne tåle at få beskeden "betaling gennemført" to gange uden at sende to pakker af sted. Det princip gælder hos alle betalingsudbydere, ikke kun Stripe.

Sælger I abonnementer, så regn med flere timer end tabellen viser. Fornyelser, afviste kort og op- eller nedgraderinger midt i en periode kræver hver deres regel.

CRM og ERP

CRM-systemer som HubSpot og Pipedrive har velbeskrevne API'er, og en envejs-integration, fx nye kunder fra webshoppen ind som kontakter, er overskuelig. Faldgruben er dubletter: den samme kunde med to e-mailadresser, eller et firma der findes både med og uden "ApS".

ERP-systemer som Business Central og Uniconta er en anden størrelse. De er ofte tilpasset den enkelte virksomhed, så felter og regler kan afvige fra standarddokumentationen. Afsæt tid til at afklare opsætningen med den partner der har sat systemet op før nogen skriver kode.

Hvad koster en integration i tid og penge?

Timerne afhænger mindre af hvilket system der er tale om, og mere af fem ting:

• Retningen: en tovejs-synkronisering kræver regler for konflikter og koster typisk mindst det dobbelte af envejs.
• Kvaliteten af API'et: god dokumentation og et testmiljø sparer mange timer. Et dårligt dokumenteret API betyder gætværk og mails frem og tilbage med leverandøren.
• Særtilfældene: kreditnotaer, delbetalinger, flere valutaer og flere momssatser kræver hver deres regel.
• Historiske data: skal tidligere kunder eller fakturaer flyttes med, er det en opgave for sig.
• Kravene til overvågning: en mail ved fejl er billig. Et overblik hvor dine medarbejdere selv kan se og genstarte fejlede synkroniseringer, koster mere.

Omregnet med en timepris på 800-1.200 kr. ekskl. moms, som er det typiske niveau for en erfaren freelancer ifølge min gennemgang af timepriser for freelance udviklere, ser det groft sådan ud:

Hertil kommer driften. Regn med nogle timer om året pr. integration til opdateringer, fornyede nøgler og ændringer hos udbyderen, og flere hvis udbyderen lægger sit API om. Bed om at hver integration bliver prissat for sig i et tilbud, så du kan fravælge den hvis en færdig app er billigere.

Bogføringsloven: lad regnskabsprogrammet bogføre

Den vigtigste beslutning i en dansk regnskabsintegration handler om lovgivning. Efter bogføringsloven skal virksomheder bogføre i et digitalt bogføringssystem. Det kan være et standardsystem der er registreret hos Erhvervsstyrelsen, eller et system virksomheden selv har fået udviklet. I det sidste tilfælde er det ledelsen der står inde for at systemet opfylder kravene.

For virksomheder der aflægger årsregnskab, fx selskaber, er kravene trådt i kraft i 2024 eller 2025, afhængigt af regnskabsår og systemtype. For virksomheder der ikke aflægger årsregnskab efter årsregnskabsloven, fx mange personligt ejede virksomheder, gælder de fra 1. januar 2026 hvis nettoomsætningen har været over 300.000 kr. to år i træk. Du finder reglerne hos Erhvervsstyrelsen.

Derfor anbefaler jeg næsten altid den samme opdeling. Dit eget system håndterer ordrer, kunder og arbejdsgange og sender fakturagrundlag og bilag videre til e-conomic, Dinero eller et andet registreret system, som står for selve bogføringen, momsen og opbevaringen. Så skal dit eget system som udgangspunkt ikke leve op til lovens krav til et bogføringssystem, og din revisor arbejder i et program vedkommende kender.

Det er ikke juridisk rådgivning. Er du i tvivl om hvordan reglerne rammer jer, så tal med din revisor før integrationen bliver designet.

Sådan bygger du integrationen: 7 trin

1. Beskriv dataflowet

Skriv ned hvilke data der skal flyttes, i hvilken retning og hvornår. Fx: "Når en ordre markeres som leveret, oprettes en faktura i e-conomic med kunde, varelinjer og betalingsbetingelser." Skriv for hvert felt hvilket system der ejer det. Er integrationen en del af et større projekt, kan beskrivelsen gå direkte ind i din kravspecifikation.

2. Led efter en færdig løsning

Gennemgå regnskabsprogrammets oversigt over apps, og se om værktøjer som Zapier eller Make har forbindelser til begge systemer. Dækker en færdig løsning det meste af behovet, så overvej at tilpasse processen en smule i stedet for at bygge.

3. Afklar adgang, abonnement og testmiljø

Hvem opretter udvikleraftalen eller appen? Hvem hos jer godkender adgangen til regnskabet? Giver jeres abonnement adgang til API'et? Og findes der et testregnskab, så der ikke bliver testet på rigtige tal? Svarene kan tage tid at få fra leverandørerne, så stil spørgsmålene tidligt.

4. Oversæt felterne mellem systemerne

Udviklere kalder det mapping: at beslutte hvordan et felt i det ene system svarer til et felt i det andet. Momskoder, kontonumre, varenumre, betalingsbetingelser, valuta og afdelinger skal passe til regnskabets opsætning. Kreditnotaer, delbetalinger og rabatter skal også have en regel. Det er her de fleste timer forsvinder, og din bogholder eller revisor bør være med.

5. Byg fejlhåndtering ind fra start

Integrationen skal tåle at det andet system er nede, svarer langsomt eller afviser et kald. Det kræver en kø (en liste af opgaver der behandles i baggrunden og kan forsøges igen), genforsøg med pause imellem, beskyttelse mod dubletter og en log over hvad der er sendt. Nøgler skal opbevares krypteret og aldrig ligge i koden. Det hører med til de grundlæggende krav til websikkerhed.

6. Test med rigtige data

Kør integrationen mod et testregnskab med en kopi af rigtige ordrer og kunder. Opdigtede testdata afslører ikke kunden med to adresser eller varen uden momskode. Når testen holder, så kør gerne integrationen side om side med det manuelle arbejde en periode før I stopper med at gøre det i hånden.

7. Sæt overvågning og ansvar op

Bestem hvem der får besked når en synkronisering fejler, og hvordan fejlen bliver rettet. En integration der stopper i stilhed, bliver ofte først opdaget ved momsafregningen eller når revisoren spørger.

Hvornår du ikke skal have bygget en integration

En bygget integration er ikke altid svaret, heller ikke når det er mig der skal bygge den. Jeg fraråder det i disse situationer:

• Der findes en færdig app der dækker behovet. Et månedligt abonnement er billigere end udvikling og vedligehold, og leverandøren tager sig af ændringer i API'et.
• Mængden er lille. Sender du 20 fakturaer om måneden, tager det måske en time at taste dem. Med 15-30 timers udvikling og løbende vedligehold går der let et par år før integrationen har tjent sig hjem.
• Processen er ikke på plads. Ændrer I stadig på hvordan ordrer og fakturaer håndteres, så vent. Ellers kommer integrationen til at blive bygget to gange.
• Et af systemerne skal snart udskiftes. Byg ikke en kobling til et system I alligevel forlader om et halvt år.
• Zapier eller Make kan klare det. Simple envejs-flows kan ofte sættes op uden kode. Skift først til en bygget løsning når flowet kræver regler, fejlhåndtering eller mængder som værktøjet ikke kan klare.

Omvendt er en bygget integration typisk det rigtige valg når den er en del af et system du selv ejer, når jeres proces afviger fra det de færdige apps er lavet til, eller når data skal igennem regler som ingen standardløsning understøtter.

Næste skridt

Har du styr på de fleste punkter, kan en udvikler give dig et realistisk estimat. Ved større opgaver, fx et ERP-system der skal synkroniseres begge veje, starter jeg med et betalt forprojekt til fast pris, hvor dataflow og feltoversættelse bliver afklaret før udviklingen. På siden om webapps og platforme der skal tale med jeres øvrige systemer kan du se hvad jeg bygger, og hvordan et samarbejde starter.

Ofte stillede spørgsmål

Hvor lang tid tager en integration til e-conomic i kalendertid?+

Længere end timerne antyder. Et arbejde på 15-30 timer kan sagtens fordele sig over et par uger fordi der skal ventes på adgang, godkendelse af appen, svar fra revisoren om momskoder og en testperiode med rigtige data. Dinero oplyser fx at godkendelsen af en ny app normalt tager op til en arbejdsdag. Sæt de ting i gang før udviklingen starter, så bliver kalendertiden kortere.

Er det sikkert at give en udvikler adgang til vores regnskab?+

Ja, når adgangen går gennem regnskabsprogrammets egen app-godkendelse og ikke gennem et delt login. Så får integrationen sin egen adgang, som kan begrænses og typisk trækkes tilbage igen uden at I skal skifte adgangskoder. Giv kun adgang til det regnskab integrationen skal bruge, brug et testregnskab under udviklingen, og sørg for at nøglerne opbevares krypteret.

Hvem ejer integrationen når den er bygget?+

Det bør din virksomhed gøre. Aftal i kontrakten at koden tilhører jer, og at den ligger i et kodearkiv I har adgang til. Appen hos e-conomic eller Dinero bør også være oprettet i jeres navn eller kunne overdrages. Jeg arbejder selv sådan at kunden ejer koden fra første dag, så et skifte af udvikler ikke betyder at integrationen skal bygges forfra.

Hvad sker der når e-conomic eller Dinero ændrer deres API?+

Så skal koden opdateres, og nogen skal have ansvaret for at holde øje. Store udbydere varsler typisk ændringer på forhånd, men varslet hjælper kun hvis nogen læser det. Aftal derfor i en serviceaftale hvem der følger med og retter integrationen. Uden overvågning opdager du ofte først problemet når data mangler i regnskabet.

Kan én integration bruges til flere regnskabsprogrammer?+

Nej, hvert regnskabsprogram har sit eget API og sine egne regler. Bygger du en SaaS hvor kunderne bruger forskellige programmer, så lav ét fælles lag i dit system og en adapter pr. program, og start med det program flest af dine kunder bruger. Der findes også tjenester der samler flere regnskabsprogrammer bag ét API, men de koster et abonnement og dækker ikke altid danske detaljer.