Sådan bygger en CFO et dashboard med e-conomic REST API
Mange CFO’er, der bruger e-conomic, bygger stadig rapporter manuelt i Excel hver måned.
Vi forbandt e-conomic direkte med et CFO-dashboard via REST API og løste samtidig
udfordringen med at placere omsætningen i den rigtige måned ved hjælp af periodiseringsbaseret parsing. I denne blog viser vi præcist, hvordan autentificering, pagination, batch fetching og periodiseringslogik fungerer i praksis.
Hvis du som CFO styrer virksomhedens økonomi gennem e-conomic, ved du allerede, at platformen rummer en stor mængde data: kontoplan, bogførte fakturaer, regnskabsår, kundesaldi og meget mere. Det, som mange CFO’er og virksomheder endnu ikke har udforsket, er, at alle disse data er tilgængelige programmatisk gennem e-conomic REST API. Det betyder, at du kan trække dem direkte ind i dine egne CFO-dashboards, automatisere afstemninger i bogføringen eller bygge skræddersyede rapporteringsværktøjer tilpasset din virksomhed og dit økonomiteam.
Denne blog er skrevet til den teknisk kyndige CFO eller bogholder og gennemgår præcis, hvordan vi arbejder, når vi bygger et internt CFO-dashboard ved hjælp af e-conomic REST API.
Vi gennemgår autentificering, de vigtigste endpoints, hvordan man håndterer pagination, og et virkeligt periodiseringsmønster, som krævede en del nøje overvejelser for at få det til at fungere korrekt.
Book et gratis møde på 30 minutter
Ingen binding. Vælg her et tidspunkt, der passer dig
e-conomic REST API
e-conomic REST API er et velstruktureret JSON API, der hostes på https://restapi.e-conomic.com. Det følger standard REST-konventioner og returnerer paginerede samlinger for listebaserede ressourcer. De endpoints, der er mest nyttige til finansiel rapportering, er opsummeret i tabellen nedenfor.
| Endpoint | Hvad det returnerer |
|---|---|
GET / |
Virksomhedsinformation og forbindelsestest |
GET /accounting-years |
Alle regnskabsår på aftalen |
GET /accounting-years/{year}/totals |
Afsluttende kontobalancer for et helt år |
GET /accounting-years/{year}/periods |
Månedlige perioder inden for et år |
GET /accounting-years/{year}/periods/{n}/totals |
Kontobalancer for en bestemt måned |
GET /accounts |
Den fulde kontoplan |
GET /invoices/booked |
Alle bogførte (endelige) fakturaer |
GET /invoices/booked/{id} |
Enkeltfaktura med linjedetaljer |
GET /customers |
Kundeliste med saldi |
API’et er primært læsetungt til rapporteringsformål. Skriveoperationer findes også (oprettelse af fakturaer, posteringer osv.), men ligger uden for rammerne af denne guide.
Trin 1: Oprettelse af din CFO-app og hentning af tokens
Autentificering bruger to tokens, som du sender som HTTP headers på hver request. Der er ikke noget OAuth-flow, der skal administreres, kun to statiske strenge.
X-AppSecretToken identificerer din integrationsapp. Den opretter du én gang i e-conomic developer-portalen på https://www.e-conomic.com/developer. Når du registrerer en app, giver e-conomic dig et App Secret Token. Hold det privat. Det svarer til en adgangskode.
X-AgreementGrantToken identificerer den specifikke kundeaftale, altså den virksomhed, hvis data du får adgang til. Hver af dine kunder giver din app adgang inde fra deres e-conomic-konto, og du modtager et unikt Agreement Grant Token pr. kunde.
Det betyder, at du kan bygge én integration og forbinde den til flere kundeselskaber ved at gemme ét token pr. kunde.
En vigtig note om rettigheder: Når du registrerer din CFO-app i developer-portalen, vælger du en app role. Hvis du senere får 403-fejl på bestemte endpoints (som for eksempel AccountingYear), betyder det, at din app role ikke har adgang til den pågældende enhed. Gå til Settings → Integrations → Apps → your app → Role inde i e-conomic, og sæt rollen til SuperUser for at få fuld læseadgang.
Trin 2: En genanvendelig fetch-wrapper
I stedet for at gentage autentificeringsheaders på hver eneste request håndterer en lille wrapperfunktion dette på en ren måde. Mønstret nedenfor er det, vi bruger i produktion.
Denne wrapper tager imod en path, for eksempel /accounts, credentials-objektet og eventuelt et map af query string-parametre. Den opbygger den fulde URL, tilføjer autentificeringsheaders og kaster en beskrivende fejl, hvis responsen ikke er succesfuld.
At teste forbindelsen bliver derefter blot et enkelt kald til root-endpointet /, som returnerer virksomhedens navn og bekræfter, at tokens er gyldige.
Trin 3: Håndtering af pagination
De fleste liste-endpoints i e-conomic returnerer maksimalt 1.000 poster pr. side. Responsen indeholder et pagination-objekt med en nextPage-URL, når der findes flere poster. En robust paginator følger dette link, indtil det ikke længere findes.
Den vigtige detalje er, at nextPage er en fuldt dannet URL. Du behøver ikke selv at konstruere den, du skal blot følge den, som den er, i hver iteration.
Ved at sætte pagesize=1000 på den første request reducerer du antallet af round trips ved store datamængder. Når denne paginator først er på plads, er hentning af hele kontoplanen eller alle bogførte fakturaer blot ét funktionskald.
Trin 4: Filtrering af fakturaer efter dato
Liste-endpointet for fakturaer understøtter server-side filtrering ved hjælp af e-conomic’s filter-query parameter-syntaks. Det betyder, at du undgår at hente tusindvis af fakturaer, når du kun har brug for en bestemt periode.
Filter-syntaksen bruger $gte (greater than or equal), $lte (less than or equal) og $and til at kombinere betingelser:
GET /invoices/booked?filter=date$gte:2026-01-01$and:date$lte:2026-01-31Du kan også filtrere på kundenummer, valuta og andre felter. Den fulde filterreference findes i e-conomic REST API-dokumentationen.
Brug altid formatet YYYY-MM-DD til datoer. Andre formater vil stille og roligt returnere tomme resultater.
Trin 5: Hentning af fakturalinjernes detaljer
Liste-endpointet for bogførte fakturaer returnerer kun fakturahoveder: dato, kunde og totalbeløb. For at få de enkelte linjer (hvilket produkt der blev solgt og til hvilket beløb), skal du hente hver faktura individuelt på /invoices/booked/{bookedInvoiceNumber}.
Ved store mængder er dette langsomt, hvis det gøres sekventielt. Løsningen er at batch-hente requests parallelt i grupper på 50.
Batching i grupper på 50 i stedet for at sende dem alle på én gang hjælper med at balancere hastighed mod rate limits, samtidig med at det er væsentligt hurtigere end sekventiel hentning.
.catch(() => null) på hver enkelt request sikrer, at én enkelt fejlet faktura ikke afbryder hele batchen.
Trin 6: Klassificering af konti til resultatopgørelse og balance
Når du har kontoplanen, skal du klassificere hver konto som enten en post i resultatopgørelsen eller en post i balancen.
e-conomic stiller et felt til rådighed, der hedder accountType, men værdierne er ikke altid konsistente på tværs af forskellige virksomhedsopsætninger. En pålidelig tilgang kombinerer derfor account type-strengen med kontonummerets interval, som følger den standard danske kontoplan.
Intervallerne i fallback-logikken er taget direkte fra Erhvervsstyrelsens officielle standardkontoplan, som er den kontoplan, e-conomic leverer som standard.
I den plan dækker konti fra 1000 til 4999 hele resultatopgørelsen (omsætning, vareforbrug, eksterne omkostninger, personaleomkostninger, afskrivninger og finansielle poster).
Balancen begynder ved 5001: aktiver går fra 5001 til 6499, egenkapital fra 6501 til 6971, hensættelser fra 6972 til 7051, langfristet gæld fra 7052 til 7261 og kortfristet gæld fra 7262 til 9950.
Trin 7: Periodiseret omsætningsindregning
Det er her, det bliver interessant for mange virksomheder.
e-conomic registrerer omsætning på fakturadatoen, altså den dato, hvor fakturaen blev bogført. Men til ledelsesrapportering ønsker man ofte, at omsætningen bliver indregnet i den periode, hvor arbejdet faktisk blev udført, og ikke når fakturaen blev oprettet.
I dette eksempel (din situation kan selvfølgelig være anderledes) bliver fakturaer typisk oprettet i måneden efter, at arbejdet blev udført.
Hver fakturalinjebeskrivelse indeholder en DDMMYY-datokode (for eksempel 050226 for 5. februar 2026), som angiver den faktiske serviceperiode. Vi parser denne kode for at placere hver linje i den rigtige periodiseringsmåned.
For linjer uden datokode falder vi tilbage på at læse fakturaens overskrift (fx "Ydelser for februar") og til sidst på selve fakturadatoen. Resultatet er, at hver fakturalinje bliver henført til den rigtige måned, uanset hvornår fakturaen faktisk blev udstedt.
Den praktiske konsekvens for datahentningen i dette eksempel er, at du skal hente fakturaer fra januar, februar og marts for at få den korrekte omsætning for fx januar, fordi noget af arbejdet fra januar først optræder på fakturaer i februar eller marts. Periodiseringsfilteret udvælger derefter kun de linjer, der hører til januar.
Sikker opbevaring af tokens
Tokens må aldrig være hardcodet eller gemt i klartekst. I vores dashboard krypterer vi dem i databasen og viser kun maskerede versioner (kun de sidste 4 tegn) i brugerfladen. De rigtige tokens bliver først dekrypteret på serveren i det øjeblik, der foretages et API-kald.
I praksis er flowet enkelt. Brugeren indtaster sine to tokens på indstillingssiden. Serveren tester straks forbindelsen for at validere dem, og hvis det lykkes, gemmes de krypteret i databasen sammen med virksomhedens navn, som vises i brugerfladen. Alle efterfølgende API-kald henter tokens fra databasen på serveren, så brugerfladen aldrig ser de rigtige værdier. Det betyder, at selv hvis en browsersession bliver kompromitteret, er selve tokens ikke eksponeret.
Typiske fejl og hvordan du løser dem
Tabellen nedenfor viser de fejl, du med størst sandsynlighed støder på, når du forbinder første gang.
| Fejl | Årsag | Løsning |
|---|---|---|
401 Unauthorized |
Ugyldigt eller udløbet token | Tjek begge tokens igen i developer-portalen |
403 Forbidden (E02500) |
Appens rolle har ikke adgang til enheden | Skift app role til SuperUser under indstillinger i e-conomic |
429 Too Many Requests |
Rate limit er nået | Indsæt pauser mellem batches, og brug pagesize=1000 for at reducere antallet af kald |
Tomt collection-array |
Datofilteret giver ingen resultater | Tjek, at datoformatet er YYYY-MM-DD, og at regnskabsåret findes |
| Pagination-loop | Fejl i håndteringen af nextPage-URL’en |
Brug altid nextPage-URL’en direkte uden ændringer |
Det kan du bygge med e-conomic REST API
Når forbindelsen virker, bliver dataene grundlaget for en række værktøjer, der går langt videre end e-conomics indbyggede rapporter. Det dashboard, vi har bygget, bruger integrationen til en resultatopgørelse i realtid med sammenligning måned for måned og grafer år for år, en balance, der opdateres automatisk uden manuel eksport, og en oversigt over salgsafvigelser. Den sammenligner den faktisk fakturerede omsætning fra e-conomic med den forventede omsætning fra CRM-systemet pr. kunde, pr. måned og pr. ydelsestype og viser de største afvigelser øverst.
Ud over disse kernerapporter bruges de samme data til en likviditetsprognose, der ud fra de seneste 12 måneders faktiske tal fremskriver de næste 6 måneder med trendanalyse, og til en budgetopfølgning, hvor CFO’en kan indtaste budgettal direkte i dashboardet og se afvigelserne opdateret i realtid. Det hele kører på aktuelle data, der opdateres efter behov, helt uden manuelle eksporter eller vedligeholdelse af regneark.
Kom godt i gang
Dokumentationen til e-conomic REST API findes på https://restapi.e-conomic.com og indeholder et interaktivt værktøj, hvor du kan teste endpoints direkte mod din egen virksomheds data. Developer-portalen til registrering af apps findes på https://www.e-conomic.com/developer.
Overvejer du som CFO at bygge en lignende integration til dit regnskabs- og økonomiteam, dækker de mønstre, vi har beskrevet her, størstedelen af det, du har brug for for at komme i gang: autentificering, pagination, batch-hentning og periodiseret indregning.
Kilder
e-conomic REST API-dokumentation
e-conomic Developer Portal
e-conomic API filtersyntaks
Vil du have et CFO-dashboard med data fra e-conomic? Vi tager gerne et gratis og uforpligtende intromøde, hvor vi taler om jeres behov og hjælper jer godt på vej.
Book et gratis introduktionsmøde
(Denne blog blev sidst opdateret: 9.10.2026)
FAQ
Skal jeg være udvikler for at kunne forbinde til e-conomic REST API?
Ikke helt, men du har brug for en person med grundlæggende programmeringsforståelse til at sætte det op. Selve API’et er veldokumenteret og forholdsvis ligetil - autentificeringen består blot af to tokens, som sendes som HTTP headers, og svarene returneres som standard JSON.
En juniorudvikler eller en teknisk stærk person eller bogholder, som er tryg ved TypeScript eller Python, kan normalt få en fungerende forbindelse op at køre på en dag.
Det mere komplekse arbejde ligger i datalogikken: at klassificere konti korrekt, håndtere pagination og få periodiseringsperioderne til at passe.
Det er her, erfaring med regnskabsdata og datastrukturer virkelig gør en forskel.
Hvad er de to tokens, og hvor får jeg dem?
Det første er App Secret Token, som identificerer din integration. Det opretter du én gang ved at registrere en app i e-conomic developer-portalen på e-conomic.com/developer.
Det andet er Agreement Grant Token, som identificerer den konkrete virksomhed, hvis data du får adgang til. Det genererer du inde fra din e-conomic-konto ved at give din app adgang.
Er det sikkert at forbinde et tredjepartsværktøj til mine e-conomic-konti?
Ja, hvis du håndterer tokens ansvarligt. Tokens bør krypteres ved lagring i databasen og må aldrig eksponeres i browseren eller indgå i frontend-kode.
I eksemplet bliver de rå tokens kun dekrypteret server-side i det øjeblik, et API-kald foretages, og frontend’en ser kun en maskeret version med de sidste fire tegn. e-conomic API’et bruges desuden kun som read-only til de use cases, der er beskrevet i bloggen – vi skriver, ændrer eller sletter ikke data i e-conomic.
Hvad sker der, hvis nogen tilbagekalder adgangen?
Hvis nogen tilbagekalder Agreement Grant Token inde fra deres e-conomic-konto, vil alle efterfølgende API-kald med det token returnere en 401 Unauthorized-fejl.
Din integration bør håndtere dette på en ordentlig måde ved at fange fejlen og vise en klar besked til brugeren om, at forbindelsen skal oprettes igen. Man skal derefter blot give adgang igen i sine e-conomic-indstillinger og hente det nye token.
Hvor meget data kan jeg hente ad gangen, og findes der rate limits?
Hvert liste-endpoint returnerer op til 1.000 poster pr. side, og API’et giver et nextPage-link i svaret, hvis der findes flere resultater.
For de fleste virksomheder vil hele kontoplanen og en måneds fakturaer kunne være på én side. For større virksomheder med tusindvis af fakturaer vil paginatoren, som beskrevet i bloggen, håndtere det automatisk.
e-conomic har også rate limits, og den mest almindelige måde at ramme dem på er ved at hente individuelle fakturadetaljer sekventielt. Ved at batch’e forespørgsler i parallelle grupper på 50, som beskrevet i trin 5 i bloggen, holder man sig typisk fint inden for grænserne.
Hvorfor anbefaler bloggen at hente tre måneders fakturaer for at få én måneds omsætning?
Fordi e-conomic registrerer omsætning på fakturadatoen og ikke på den periode, arbejdet faktisk vedrører. Hvis arbejde udført i januar først faktureres i februar eller marts, vil du derfor overse en del af januar-omsætningen, hvis du kun henter januar-fakturaer.
Ved i stedet at hente fakturaer fra januar, februar og marts og derefter filtrere linjerne ud fra deres periodisering, kan du finde den omsætning, der reelt hører til januar, uanset hvornår fakturaen blev oprettet. Det er netop forskellen mellem kontantprincip og periodiseret regnskab.
Hvad hvis vores fakturalinjebeskrivelser ikke indeholder en datokode?
Datokode-konventionen med seks cifre i starten af linjebeskrivelsen er kun én mulig opsætning. Hvis jeres virksomhed bruger en anden struktur, skal periodiseringslogikken tilpasses det format, I faktisk bruger.
Typiske alternativer er at udlede måneden fra fakturaoverskriften, f.eks. “Services for February”, bruge et brugerdefineret felt på fakturaen eller som fallback anvende fakturadatoen, hvis I normalt fakturerer i samme måned, som arbejdet udføres.
Bloggen beskriver disse tre fallback-niveauer i prioriteret rækkefølge: 1) datokode i linjebeskrivelsen, 2) periode udledt fra anden fakturatekst eller et custom felt, 3) fakturadato som sidste udvej.
Kan jeg bruge dette til at bygge en Budget vs Actual-rapport?
Ja, og det er en af de mest værdifulde rapporter, du kan bygge oven på denne integration.
Actuals kommer direkte fra e-conomic via API’et. Budgettallene indtastes manuelt af CFO’en (eller hentes fra et andet system) i dit dashboard og gemmes i din egen database.
Sammenligningen er derefter en ligetil beregning pr. konto pr. måned. Fordi actuals opdateres on demand fra e-conomic, er afvigelsestallene altid aktuelle uden manuel eksport eller dataindtastning på regnskabssiden.
Fungerer dette for kunder, der bruger e-conomic i flere valutaer?
Ja. API’et returnerer beløb i den valuta, som hver transaktion er bogført i, sammen med den valutakurs, der gjaldt på bogføringstidspunktet.
Hvis du vil lave konsolideret rapportering på tværs af flere valutaer, skal du selv vælge en rapporteringsvaluta og anvende enten den historiske kurs fra transaktionen eller en gennemsnitskurs for perioden.
API’et foretager ikke denne omregning for dig – det er noget, dit rapporteringslag selv skal håndtere.
Hvor lang tid tager det at bygge noget som dette op fra bunden?
En grundlæggende fungerende forbindelse, som kan hente konti og fakturaer og vise en simpel resultatopgørelse, tager typisk cirka én til to dage for en erfaren udvikler.
At få periodiseringslogikken helt rigtig, håndtere edge cases i kontoklassificering og bygge et gennemarbejdet dashboard med korrekt fejlhåndtering og sikker håndtering af credentials tager snarere to til fire ugers fokuseret udvikling.
De mønstre, der beskrives i bloggen - fetch-wrapperen, paginatoren, batch fetcheren og accrual-parseren - er de centrale byggesten, og når de er dokumenteret klart, reducerer det udviklingstiden mærkbart.