AI til e-conomic integration: hvad kan bygges i 2026?

AI til e-conomic integration virker bedst på de tre led, hvor et menneske i dag læser, taster og tjekker: bilag der skal tolkes, kladder der skal oprettes, og tal der skal samles til en rapport. Den bogførte postering skal et menneske stadig godkende, og det er ikke en begrænsning i teknikken, det er et valg du bør træffe med vilje.

Det er det korte svar. Resten af denne vejledning handler om, hvad e-conomics API faktisk tillader, hvor de fleste projekter går i stå, og hvordan vi tester en integration på dine egne data, før den bliver sat i drift.

Vi bygger den slags integrationer for danske SMV'er, så det her er skrevet ud fra, hvad der gik galt i de første forsøg, ikke ud fra en funktionsliste.

AI til e-conomic integration: det korte svar

Der er tre niveauer, og de koster vidt forskelligt. De fleste SMV'er har brug for niveau to, men bliver solgt niveau tre.

Niveau tre er det eneste sted, hvor ordet AI betyder noget. Niveau et og to er regelbaseret automatisering, og det er fint. En bankafstemning har ikke brug for en sprogmodel.

AI bliver først relevant, når noget skal tolkes: en PDF fra en leverandør, der ikke følger en fast skabelon, en mail hvor en kunde beder om en kreditnota uden at sige fakturanummeret, en kontostreng der skal gættes ud fra en tekst. Det er opgaver med et skøn i sig, og dem løser regler dårligt.

Hvad e-conomic klarer selv, før du bygger noget

Det billigste projekt er det, du ikke sætter i gang. e-conomic har allerede bilagsscanning, automatisk bankafstemning, tilbagevendende fakturaer og automatiske rykkere i sine pakker. Det står beskrevet på e-conomics side om automatisering, og det dækker en overraskende stor del af en almindelig bogholderidag.

Næste skridt er appmarkedet. Der ligger færdige integrationer til webshop, lønsystem, lagerstyring og firmakort, og de er typisk sat op på en eftermiddag. En færdig app, der dækker de fleste af dine behov, slår næsten altid en skræddersyet løsning, der dækker alt. Kilden til den slags apps er e-conomics eget katalog over apps og udvidelser.

Spørg dig selv tre ting, før du går videre til API'et:

• Findes der en app, der dækker det meste af opgaven?
• Er den resterende del noget, en person kan klare på under en time om ugen?
• Kan processen laves om, så behovet forsvinder?

Hvis du svarer ja til et af dem, så stop. Vi siger det samme til kunder, der ringer og vil have bygget noget, de kan købe for en femhundredekroneseddel om måneden.

De to API'er bag enhver e-conomic integration

Her bliver det teknisk, og det er her de fleste danske artikler stopper. e-conomic kører to API'er side om side, og de kan ikke det samme.

Det gamle Legacy REST på restapi.e-conomic.com dækker kunder, varer, ordrer, tilbud, fakturakladder og bogførte fakturaer. Det er veldokumenteret og stabilt, men det kan ikke bogføre et kassekladdebilag, og det har ingen webhooks.

Den nyere OpenAPI-side dækker dimensioner, bogførte poster, webhooks og bogføring af kassekladder. Journals-endpointet kan bogføre et bilag, hvilket e-conomic selv har beskrevet. Skal din integration reagere på en hændelse i stedet for at spørge hvert femte minut, skal du bruge webhooks, og så er du på den nyere side.

I praksis bruger de fleste rigtige integrationer begge. Det er ikke pænt, men det er sådan det er, og det er værd at vide, før nogen lover dig en løsning på to dage.

Autentificering og den rolle, du ikke kan lave om

Hvert kald sendes med to headere: X-AppSecretToken, der identificerer din app, og X-AgreementGrantToken, der identificerer adgangen til den enkelte kundeaftale. Det er beskrevet i e-conomics dokumentation om autentificering, og du kan teste med demo-tokens, før du registrerer noget.

Den dyre detalje: appens rolle sættes, når du opretter appen i udviklerportalen, og den kan ikke laves om bagefter. En app, der er oprettet som Bookkeeping, kan ikke læse kunder eller varer. Opdager du det, når halvdelen er bygget, skal appen oprettes forfra, og alle kunder skal give adgang igen. Vi har set det koste en uge.

Fire automatiseringer vi bygger på e-conomic API'et

Det her er de fire, der oftest betaler sig hjem. De er alle fire bygget på API'et, og alle fire har et menneske som sidste led.

Bilag til kladde. En indgående faktura lander i en mailboks. En model læser leverandør, beløb, moms og dato, foreslår en kontering ud fra, hvordan den samme leverandør blev bogført de sidste gange, og opretter en kladde. Bogholderen godkender. Tiden går fra et par minutter per bilag til et klik.

Debitoropfølgning med sprog. e-conomic kan sende rykkere. Det, det ikke kan, er at skrive forskelligt til en kunde, der altid betaler til tiden, og en der skylder for tredje gang. En model henter forfaldne poster, grupperer dem per kunde og skriver et oplæg til en mail, som du godkender.

Rapportering på tværs. Tal fra e-conomic er sjældent nok i sig selv. Sammen med timer fra dit projektsystem eller ordrer fra din webshop bliver de en dækningsgrad per kunde. Det er den samme logik som i automatisk rapportering, bare med regnskabet som kilde.

Datasynk begge veje. En ny kunde oprettet i CRM skal findes i e-conomic uden at nogen taster den igen. Det lyder trivielt, og det er der, de fleste timer forsvinder i en SMV. Vi har skrevet mere om den slags i vejledningen om at automatisere dataindtastning.

Her går grænsen for AI til e-conomic integration

Fire grænser er værd at kende, før du beslutter noget.

Kladde, ikke bogføring. En kladde oprettes med et kald, og bogføring er et andet. En bogført faktura kan ikke rettes, kun modposteres. Derfor lader vi en agent oprette kladder og aldrig bogføre selv. Det er ikke fordi modellen er dårlig, men fordi en fejl i en kladde er et klik at rette, og en fejl i en bogført post er en rettelse i regnskabet.

Fair use. e-conomic sætter et loft på 50.000 API-kald per døgn per aftale og kan begrænse adgangen uden varsel, hvis en app belaster for meget. Det står i deres fair use-politik. I praksis rammer man det kun, hvis man spørger i stedet for at lytte, altså bruger polling frem for webhooks.

Ingen officiel MCP-server. Vil du koble en chatassistent direkte på regnskabet, så vid, at der ikke findes en officiel MCP-server fra e-conomic. De løsninger, der markedsføres som det, er tredjeparter, der gemmer dine to tokens på deres servere. Det kan være en fin løsning. Det er bare en databehandler mere, og den beslutning hører hjemme hos dig, ikke hos en leverandør.

Persondata. Regnskabsdata indeholder navne, adresser og betalingsmønstre. Sender du dem til en sprogmodel, er det en overførsel, der skal kunne forklares. Vi kører derfor med dataminimering som udgangspunkt: kun de felter, opgaven kræver, og en model i EU hvor det kan lade sig gøre.

Hvad koster AI til e-conomic integration?

Et afgrænset flow, altså en af de fire ovenfor, starter hos os på 10.000 kr. som engangsbeløb. Skal vi også passe på det løbende og bygge videre, er det fra 5.000 kr./md. Du ejer koden og dokumentationen, så du kan tage den med, hvis du vil noget andet.

Regnestykket, du bør lave, er ikke pris mod pris. Det er pris mod timer. Et team, der bruger 15 timer om ugen på at taste og tjekke, bruger mere end en halv stilling på det. En fuldtidsansat koster 25.000+ kr./md. og gør det hver måned. En integration bygges en gang.

Nøgletal

15 timer

vi typisk finder per kunde om ugen

20.000 kr./md.

sparet hos Markeity på systemer bygget en gang

53

automatiseringer sat i drift

Vi har sat tallene op mere grundigt i vejledningen om hvad AI-automatisering koster, og du kan se en større sammenhæng i vores side om systemintegration.

Sådan tester vi, før noget sættes i drift

Vi bygger ikke mod din produktionsaftale. Først mod demo-tokens, så mod en kopi af dine egne bilag, så i parallel drift hvor flowet foreslår og et menneske sammenligner med det, der ellers ville være sket. Først derefter overtager det. Fra audit til drift er typisk omkring 3 uger.

Tre fejl der dræber en e-conomic integration

Den første: at bygge mod produktionsaftalen fra dag et. Det føles hurtigere, og det er det også, lige indtil en test opretter femten kladder, der skal slettes i hånden. Byg mod demo-tokens, og flyt først over, når flowet gør det rigtige to gange i træk.

Den anden: at spørge i stedet for at lytte. Et flow, der tjekker e-conomic hvert minut for at se, om der er sket noget, bruger over 1.400 kald i døgnet uden at have gjort noget som helst. Med ti kunder på samme app nærmer du dig loftet. Webhooks løser det, fordi e-conomic så selv fortæller, når noget er sket.

Den tredje: at automatisere en proces, ingen har beskrevet. Det er den dyreste af dem. Bogføring i en SMV er sjældent dokumenteret, den sidder i hovedet på den, der har gjort det i fem år. Spørger du ikke om undtagelserne, bygger du et flow, der rammer rigtigt i de fleste tilfælde og skaber mere arbejde i resten. Derfor starter vi altid med at se en uges bilag igennem sammen med den, der plejer at bogføre dem.

Fællestrækket er, at ingen af de tre er tekniske problemer. De er beslutninger, der blev truffet for tidligt. En integration til e-conomic er sjældent svær at kode. Den er svær at afgrænse, og det er der, arbejdet ligger.

FAQ

Kan e-conomic bogføre helt automatisk med AI?

Teknisk ja, via journals-endpointet på OpenAPI-siden. Vi anbefaler det ikke som udgangspunkt. Lad AI oprette kladden og lad et menneske godkende. Når flowet har kørt nogle måneder, og fejlraten er kendt, kan du flytte de mest forudsigelige bilagstyper over til automatisk bogføring.

Hvilket API skal jeg bruge til min e-conomic integration?

Begge, oftest. Legacy REST til kunder, varer, ordrer og fakturaer. OpenAPI-siden til webhooks, dimensioner, bogførte poster og bogføring af kassekladder. Vælg ud fra, hvad flowet skal kunne, ikke ud fra hvad der er nemmest at komme i gang med.

Hvad koster adgangen til e-conomics API?

Adgangen til API'et koster ikke noget i sig selv. Du registrerer en app i udviklerportalen og får demo-tokens gratis. Det, der koster, er den pakke, du har hos e-conomic, og det arbejde, der skal til at bygge integrationen.

Kan jeg bruge n8n, Make eller Zapier i stedet for at bygge selv?

Ja, til simple flows. Alle tre kan tale med e-conomic via HTTP-kald, og for en kæde på tre trin er det hurtigere. Bliver flowet forgrenet, eller skal en model tolke noget, kommer kompleksiteten tilbage et andet sted. Vi har sammenlignet de tre i n8n vs Make vs Zapier.

Hvor lang tid tager en integration at bygge?

Et afgrænset flow tager typisk to til tre uger fra første samtale til drift, hvoraf en stor del er test på dine egne data. Det, der trækker tiden, er sjældent koden. Det er at finde ud af, hvordan bogføringen faktisk foregår hos dig, i modsætning til hvordan den burde foregå.

AI til e-conomic integration er ikke et spørgsmål om, hvor smart modellen er. Det er et spørgsmål om, hvilke led du tør slippe, og hvilke du vil blive ved med at godkende selv.