Warning: Undefined variable $html in /home/fri-software/public_html/wp-content/plugins/sponsorposts/sponsorposts.php on line 32
En Stripe-udbetaling på bankkontoen ligner et færdigt tal. Det er den sjældent. Beløbet er summen af mange betalinger fra flere dage, fratrukket gebyrer og refusioner og måske omregnet fra en anden valuta. Når du sætter e-conomic Stripe-forbindelsen op, bliver meget af arbejdet automatisk, men ikke det hele. Appen skal ligge oven på en webshop-integration, og prismodellerne belønner forskellige transaktionsmængder. Gebyrerne skal desuden stå på egne konti, hvis omsætningen skal passe. Selv når hver udbetaling er afstemt til sidste krone, ved du stadig ikke, hvor meget tilbagevendende omsætning du har, eller hvem der har opsagt. Artiklen tager seks udbredte antagelser om de to systemer op én ad gangen og viser, hvor de holder, og hvor de knækker. Den er skrevet til dig, der driver en abonnementsvirksomhed og vil have både regnskab og nøgletal til at hænge sammen.
“Stripe og e-conomic snakker sammen af sig selv”
Mange går ud fra, at to så udbredte systemer selvfølgelig er koblet sammen fra starten. e-conomic oplyser selv at have omkring 250.000 kunder, og Stripe er en af de mest brugte betalingsløsninger online. Alligevel sker der intet mellem dem, før du selv sætter en forbindelse op.
Forbindelsen hedder en app. I e-conomics egen oversigt over apps og udvidelser finder du Stripe Payouts, som leveres af IEX ApS. Den henter dine udbetalinger fra Stripe og fører dem automatisk over på en balancekonto i e-conomic. Du bestemmer selv, om hver udbetaling skal bogføres som én samlet post eller deles op på linjeniveau. Den samlede post giver et roligt kontokort. Linjeniveauet gør det lettere at finde den enkelte betaling igen, når noget ikke stemmer. Stripes gebyrer bliver lagt på særskilte konti, så de ikke forsvinder inde i nettobeløbet.
Svaret på, om du kan bogføre Stripe-betalinger automatisk, er altså ja. Men der er en forudsætning, som mange overser. Appen kræver, at du allerede har en webshop-integration kørende. Den er en tilføjelse oven på den, ikke en erstatning for den. Har du ingen webshop koblet til e-conomic, skal det på plads først.
Prisen står ikke på appens side. Den får du først at vide, når du kontakter partneren bag. Spørg derfor både til pris og til, hvilke webshop-integrationer appen fungerer sammen med, før du vælger løsning.
“Integrationerne er stort set ens, så tag den billigste”
Halvdelen af antagelsen holder. Der findes flere tredjeparts-apps end e-conomics egen til at forbinde Stripe med e-conomic, blandt andet fra 2app og emonkey. Ren afstemning af betalinger og udbetalinger er derfor et modent marked. Prismodellerne er bare skruet forskelligt sammen, og hvad der ender som billigst, afhænger af, hvor mange betalinger du har.
Hos 2app betaler du et engangsgebyr på 999 kr. for opsætning. Derefter koster driften 199 kr. om måneden, så længe du holder dig under 200 transaktioner om måneden. Kommer du over, rykker du op i niveauet til 599 kr. om måneden, som dækker op til 9.000 transaktioner. Support foregår på telefon og e-mail på hverdage. Priserne gælder pr. september 2026.
emonkey har ingen opstartspris, og abonnementet starter ved 245 kr. om måneden. “Starter ved” er nøgleordet. Spørg, hvad det koster ved din mængde af transaktioner, før du sammenligner.
Regn det igennem med dine egne tal. Har du under 200 betalinger om måneden, er 2app 46 kr. billigere pr. måned. Engangsgebyret skal dog tjenes hjem først, og det tager knap to år. Skal du skifte løsning inden da, er den billigste månedspris ikke den billigste samlede pris.
Den anden forskel handler om bogføringen. 2app lægger kreditkortbetalingerne i kassekladden, hvor du selv gennemser dem, før de bogføres. emonkey bogfører betalinger, gebyrer og afregninger direkte på separate konti for bank, gebyrer og mellemregning. Vil du have kontrol linje for linje, passer den første model bedst. Vil du hellere slippe for at røre posterne, passer den anden bedst.
“Gebyrerne kan bare trækkes fra i udbetalingen”
Det lyder logisk. Stripe sender et nettobeløb til banken, og det er jo det beløb, der lander på kontoen. Men bogfører du kun nettoudbetalingen, passer din omsætning ikke. Kunden har betalt hele beløbet, og det er det hele beløb, der skal stå som salg. Gebyret er en udgift, og den skal have sin egen konto.
Forskellen kan hurtigt blive mærkbar. Stripes satser i Danmark lød i januar 2026 på 1,5 % + 1,80 kr. for kort udstedt i EØS og 1,9 % + 1,80 kr. for premiumkort fra EØS. For kort udstedt uden for EØS var satsen 3,25 % + 1,80 kr., og hertil kommer 2 % for valutakonvertering. MobilePay kostede fra omkring 1 % pr. transaktion, mens SEPA-direkte debitering kostede 2,50 kr. pr. betaling. Har du mange udenlandske kunder, bliver gebyrerne en post, du vil kunne følge for sig selv.
Det nemmeste er at lade alt gå gennem en mellemregningskonto. Salget bogføres brutto, gebyret bogføres som udgift, og udbetalingen flytter nettobeløbet videre til banken. Når mellemregningen står på nul efter hver udbetaling, ved du, at tallene hænger sammen. Står der et restbeløb, kan du se præcis, hvilken udbetaling der mangler at blive afstemt.
Bruger du Stripes abonnementsfunktioner, opkræver Stripe tillægsgebyrer for dem oven i transaktionsgebyret. De optræder ikke på samme måde som kortgebyrerne, så giv dem en særskilt konto i kontoplanen. Ellers ender de som en uforklarlig difference, når du afstemmer måneden.
“Et abonnement er et abonnement, uanset hvordan kunden betaler”
Det lyder rimeligt. Kunden betaler det samme beløb hver måned, så betalingsmetoden burde være underordnet for bogføringen. Men i en dansk abonnementsvirksomhed betaler kunderne på forskellige måder, og hver metode sætter sit eget aftryk i regnskabet.
Kort, MobilePay og direkte debitering har hver sin gebyrmodel, som afsnittet ovenfor viste. En procentsats med et fast tillæg opfører sig anderledes end et fast beløb pr. betaling. Derfor ændrer din gebyrprocent sig, hvis kundernes fordeling mellem metoderne ændrer sig, selv om prisen på abonnementet står stille.
Metoderne fejler heller ikke på samme måde. Et kort kan udløbe eller blive spærret midt i en abonnementsperiode. En debitering kan blive afvist eller trukket tilbage. Hver hændelse giver sine egne posteringer, og de skal kunne findes igen, når du undersøger, hvorfor en måned ser skæv ud.
Gruppér derfor betalingsmetoderne fra starten. Giv dem hver sin gebyrkonto, eller brug en dimension eller afdeling i e-conomic, hvis din kontoplan allerede er stram. Så kan du bagefter se, hvad hver metode koster dig, og hvor de mislykkede betalinger kommer fra. Den opdeling er svær at lave bagud, når et års posteringer ligger samlet på én konto.
“Når bogføringen stemmer, har jeg også styr på MRR og churn”
Det er en forståelig antagelse. Hvis hver Stripe-udbetaling lander rigtigt i e-conomic, virker det, som om tallene er på plads. Men bogføringen svarer på et andet spørgsmål. Den viser, hvad der kom ind, og hvornår. Den siger ikke, hvor meget tilbagevendende omsætning du har lige nu, hvilke kunder der har opsagt, eller hvor længe en kunde bliver.
En udbetaling fra Stripe er summen af mange betalinger minus gebyrer og refusioner. Når den er bogført, er koblingen til den enkelte kunde og det enkelte abonnement væk. Du kan ikke se, om en svag måned skyldes opsigelser, fejlede kortbetalinger eller bare færre årsbetalinger den måned.
Årsabonnementer gør billedet endnu mere skævt. En kunde, der betaler for tolv måneder på én gang, giver et hop i indbetalingerne i netop den måned. Periodiserer du beløbet i regnskabet, bliver det fordelt over året. Ingen af de to billeder er MRR. Indbetalingen overdriver måneden, og periodiseringen jævner beløbet ud uden at vise, hvilke abonnementer der er kommet til, og hvilke der er faldet fra.
Selve abonnementsopkrævningen styres i Stripe eller i et faktureringssystem. Udbetalingsintegrationerne opkræver ikke noget. De sørger for, at pengene bliver bogført korrekt i e-conomic. Nøgletallene skal derfor hentes fra abonnementsdataene, hvor hver kunde, plan og ændring stadig ligger enkeltvis. Et analyseværktøj som Metriks kan læse de data og beregne MRR, churn og kundelevetid, mens e-conomic forbliver stedet, hvor regnskabet føres. Så har bogføring og nøgletal hver sin opgave og kører side om side.
“Et regneark klarer afstemningen fint”
Det gør det, så længe der kun er få betalinger om måneden. Problemet opstår, når udbetalingerne fra Stripe ikke passer én til én med dine fakturaer.
En enkelt udbetaling kan dække salg fra flere dage. Beløbet på bankkontoen skal derfor splittes ud på en række betalinger, før du kan se, hvilke fakturaer der er betalt. Refusioner trækkes fra i samme udbetaling, så summen bliver mindre end salget, uden at det fremgår af banklinjen hvorfor. Betaler en kunde i en anden valuta, skal omregningen stemme med den kurs, Stripe brugte, og ikke med dagens kurs i dit regneark.
Gebyrerne er en klassisk fejlkilde. Bogfører du både bruttobeløbet og gebyret hver for sig, og en kollega samtidig bogfører nettobeløbet fra banken, står gebyret der to gange. Kunder skaber også rod, hvis de hedder én ting i Stripe og noget andet i e-conomic. Så skal nogen gætte, hvem der har betalt.
Der er også regler at tage hensyn til. Bogføringsloven kræver digital bogføring, og det omfatter blandt andet, at du kan sende og modtage e-fakturaer via NemHandel i formaterne OIOUBL eller Peppol BIS. Er du i tvivl om, hvad kravene betyder for netop din virksomhed, så tjek de officielle regler eller spørg din revisor.
Det, der stadig ligger på dit bord
Integrationen flytter pengene fra Stripe ind i e-conomic. Alt det, der kræver en beslutning, er stadig dit. Du vælger, om posterne skal gennemses i kassekladden eller bogføres direkte. Du bestemmer også, hvordan kontoplanen skal skelne mellem kort, MobilePay og debitering, og hvor abonnementstillæggene skal stå. De valg er lettest at træffe, før det første år har samlet sig på én konto. Nøgletallene kræver deres egen kilde, fordi en afstemt udbetaling ikke kan fortælle, hvilke kunder der er faldet fra.
Hvordan kravene til digital bogføring og e-fakturering rammer netop din virksomhed, og om din kontoplan holder, kan ingen artikel se udefra. Tag din opsætning med til din revisor, gerne inden du slår automatikken til.