# Betalinger Alunta kan registrere manuelle betalinger og forbinde dit teams egen konto hos de understøttede betalingsudbydere. Hvilke udbydere der er tilgængelige, er en teamindstilling. ## Hvornår et kort trækkes Alunta forsøger korttræk tre gange dagligt kl. 00, 08 og 16 i teamets tidszone. En periode bliver trækbar på sin første dag, og en første delperiode, der opkræves med næste fornyelse, på den fornyelse. En forbrugsbaseret periode bliver trækbar dagen efter periodens slutning, fordi forbruget først er kendt derefter. Trækket sker før fakturaen oprettes. Hvis automatisk korttræk er slået fra, dukker kortabonnementer op i den manuelle fakturaprompt. Når prompten bekræftes, trækkes kortet og fakturaen oprettes. Et abonnement der dækkes af en betaler, afregnes via betalerens samlede faktura, og en periode på nul efter rabat kræver ingen betaling. ## Stripe SEPA Direct Debit Når dit team bruger Stripe, kan slutkunder gemme SEPA Direct Debit som bankbetalingsmetode gennem den offentlige API, checkout eller kundeportalen. De hostede forløb tilbyder SEPA, når den tilsluttede Stripe-konto har metoden tilgængelig, og betalingen er i EUR. Der er ingen ekstra Alunta-indstilling. En integration kan beholde sit eget Stripe Elements-forløb med en gennemført SetupIntent til fremtidige betalinger og sende betalingsmetodens reference gennem samme API som for kort. SEPA kræver en aktiv genbrugelig betalingsaftale og kan kun opkræve EUR. Den gemte metode viser sikre sidste fire cifre og bankland, uden kortudløb. En tilbagekaldt eller frakoblet aftale kan ikke opkræve en ny betaling. Metoden springes over ved valg til et abonnement i en anden valuta; et udtrykkeligt valg af en uforenelig metode afvises. Opkrævninger følger Aluntas almindelige Stripe-opkrævninger og fejlregler, uden kortreservation på forhånd. En indsendt betaling kan være under behandling i flere bankdage. Ingen betaling eller betalt faktura registreres, før Stripe bekræfter resultatet, og et uafklaret forsøg opkræves ikke igen. Et køb eller en betalt genoptagelse afsluttes først efter den bekræftelse. Ved en betalt udvidelse af antal bliver den ekstra kapacitet først tilgængelig efter bekræftet betaling. Stripe indsamler samtykke og sender sine sædvanlige betalingsvarsler. SEPA-betalinger bruger den eksisterende Stripe-modkonto til kortbetalinger i bogføringen. Refunderinger kan være afventende. Bankens tilbageførsler følger forløbet for Stripe-tvister nedenfor, som åbner fakturaen igen uden automatisk ny opkrævning eller opsigelse. ## Når en betaling fejler - **Gør ingenting.** Fejlen registreres, og abonnementet fortsætter. - **Giv kunden besked om fejlet betaling.** Kunden får opfølgning efter 3 og 7 dage, hvis automatisk kortopfølgning er slået til i Rykkersystem. Denne indstilling opsiger aldrig abonnementet. - **Annuller med det samme.** Abonnementet afsluttes efter reglerne for beskyttede perioder. - **Prøv igen og annuller derefter.** Alunta forsøger igen frem til den gældende frist, normalt syv dage efter den dag, den fejlende periode blev trækbar (periodens første dag; for en forbrugsbaseret periode dagen efter periodens slutning; for en periode med fakturering på sidste dag, periodens sidste dag; for en første delperiode, der opkræves med næste fornyelse, den fornyelse) eller, for afdrag, efter faktureringsdatoen for den fejlende del. Reglerne gælder de træk, Alunta selv foretager. Er automatisk korttræk slået fra, hverken trækker eller genforsøger Alunta kortet: teamet trækker det fra fakturahandlingen, og en afvisning dér udløser ikke reglen, så kunden får ingen besked, og abonnementet opsiges ikke. En afvisning, som Stripe melder senere (fx ved SEPA Direct Debit), følger stadig reglen. Efter et reelt afvist træk venter Alunta 24 timer, før samme kort forsøges automatisk igen, uanset hvilken periode, afdragsdel eller pakkens engangsbetaling forsøget gjaldt, og opkrævningskørslen sender højst ét periode- eller afdragstræk pr. kørsel til et kort, der er afvist siden sidste gennemførte træk. Er kortet (eller en SEPA-aftale) afvist 8 gange i træk, uden at et træk på det er lykkedes ind imellem, stopper Alunta de automatiske forsøg på det, også forhåndsreservationer, og dashboardet viser kunden under "Automatiske kortforsøg er stoppet". Forsøgene starter igen, når kunden tilknytter et nyt kort, eller når et træk på kortet lykkes. En forhåndsreservation på et stoppet kort bliver ikke hævet og udløber. Med "Prøv igen og annuller derefter" forsøges et stoppet kort igen, højst én gang i døgnet, når fristen er nået, så abonnementet kan opsiges, hvis forsøget også fejler. Et manuelt genforsøg fra brugerfladen kan stadig foretages, også på et stoppet kort; fejler det, tæller det med i de 8 og starter ventetiden. Opkrævningen venter op til 24 timer, før den prøver igen, også efter at kunden har skiftet kort, så `awaiting_charge_run` kan betyde "efter den ventetid". På et stoppet kort kan `awaiting_charge_run` også dække over en opkrævning, som først forsøges, når kunden tilknytter et nyt kort. Hvad der sker bagefter, afgøres af den planregel der gjaldt da perioden blev oprettet. Trækker Alunta selv et gemt kort, og kortets bank kræver, at kunden godkender betalingen (fx 3D Secure), kan trækket ikke gennemføres uden kunden. Alunta lader ikke længere en sådan betaling stå som afventende: forsøget annulleres og behandles som en mislykket betaling, så den handling ved mislykket betaling, I har valgt, kører, og kunden bliver bedt om at opdatere kortet. Et checkout eller en genoptagelse, hvor kunden er til stede og gennemfører godkendelsen, står afventende, indtil kunden er færdig. En almindelig betalt eller faktureret periode er beskyttet ved opsigelse, så kunden normalt beholder den betalte periode. For afdrag vurderes hver ubetalt, forfalden del særskilt; en betalt del bliver ikke gjort ubetalt, men en endnu ikke forfalden del er ikke i sig selv en grund til at opsige hele abonnementet. Når en fejlet betaling afslutter abonnementet, løber tjenesten til udgangen af den sidste periode, der er betalt fuldt ud. En afdragsperiode tæller kun som betalt fuldt ud, når alle dens dele er afregnet. Er en del af den afdragsperiode, der løber i dag, betalt, løber tjenesten i stedet til datoen for fejlen; er ingen af delene opfyldt, er slutdatoen datoen for fejlen. En ældre, afsluttet afdragsperiode med kun nogle betalte dele forlænger ikke tjenesten. De ubetalte dele af en delvist betalt periode bliver ikke slettet, men de opkræves ikke længere, så længe abonnementet er afsluttet af en fejlet betaling: de bliver hverken opkrævet, faktureret eller vist som udestående, og perioden regnes ikke som betalt fuldt ud. Det gælder også for et team med manuel kortopkrævning, når et nyt kort tilknyttes, og når abonnementet opsiges igen med samme eller en tidligere slutdato: årsagen til afslutningen er stadig den fejlede betaling. Flyttes slutdatoen derimod senere, lader teamet abonnementet køre videre: den valgte årsag erstatter da den fejlede betaling, og abonnementet opkræves igen for den periode, det nu løber, og kan få knyttet et nyt kort. Hele perioder uden betaling slettes, som de altid er blevet; en ubetalt hel periode, som en senere betalt periode har låst, bliver stående, men opkræves og faktureres heller ikke. Perioder, der allerede er betalt, bliver stadig faktureret. Genoptages abonnementet, opkræves de ubetalte beløb igen. De dele, der allerede er betalt, bliver stadig faktureret, og kortet, der skulle opkræve resten, fjernes. Et ubetalt beløb, som ikke opkræves, vises i appen som "Ikke opkrævet" (abonnementet blev afsluttet på grund af en fejlet betaling), ikke som en betaling, der venter på at blive trukket, og det står ikke under "Kræver handling". Overføres det afsluttede abonnement til en anden kunde, faktureres den tidligere kundes ubetalte beløb ikke til den nye kunde; perioder, der allerede er betalt, bliver stadig faktureret. Kunden kan ikke genoptage abonnementet online med kortbetaling, mens en afdragsperiode, der løber i dag, allerede er delvist betalt: der oprettes ingen betaling, og kunden bliver bedt om at kontakte virksomheden. Et udløbet kort er ikke i sig selv bevis på at et tidligere forsøg fejlede. For afdrag vurderes den konkrete ubetalte, forfaldne del. Følg en afventende betaling før du vælger opsigelse. ## En betalingsstatus skal være bekræftet En planlagt dato eller reservation er ikke det samme som en gennemført betaling. Betalingen vises først som gennemført når udbyderen har bekræftet resultatet. Ved afvist eller afventende status skal du følge den viste handling og ikke sende en kvittering for betaling. Ved betaling af en eksisterende faktura via et Stripe-betalingslink kan nogle af teamets aktiverede betalingsmetoder være afventende i flere dage. Alunta registrerer først betalingen, når Stripe har bekræftet den. Mens betalingen er uafklaret, åbnes der ikke et nyt betalingsforsøg på linket. Når Stripe har bekræftet en afvisning uden modtaget beløb, kan slutkunden prøve igen på fakturaens betalingslink. Dette ændrer ikke, hvilke betalingsmetoder der kan gemmes til abonnementer. ## Refusioner og kreditnotaer En refundering, lokal tilbageførsel og chargeback er forskellige pengestrømme. Det normale kreditforløb kan sende en kreditnota, mens en tilbageført betaling ikke nødvendigvis gør det. Læs beløb og type på refunderingen, og behandl en anmodet refundering som afventende indtil den er gennemført. Webhooks kan leveres mere end én gang, så din integration bør kunne genkende den samme refundering. Hvis du bruger den offentlige faktura-webhook, indeholder `invoice.refunded` refunderingens `data.refund.kind` (`provider_refund`, `local_reversal` eller `chargeback`), `data.refund.amount`, `data.refund.uuid` og `data.refund.original_invoice_uuid`. Brug refunderingens UUID som idempotensnøgle, så en gentaget webhook ikke bogføres to gange. Følg også forskellen mellem en kreditnota og den oprindelige faktura: en kreditnota er dokumentet, mens refunderingen beskriver pengestrømmen. `chargeback` dækker både chargebacks fra Leverandørservice og Stripe-tvister, hvor Stripe har trukket pengene tilbage; den bevarer den oprindelige betaling og peger på den oprindelige faktura, og der oprettes ingen kreditnota. `invoice.paid` betyder, at en betaling har dækket hele den udestående saldo. En delbetaling udløser ikke eventet; det gør den første overgang til fuldt dækket saldo, også når status ender som overbetalt eller krediteret på grund af en relateret kreditnota. En krediteret originalfaktura og kreditnotaen er stadig separate dokumenter. ## Stripe-tvister Når en kunde anfægter en Stripe-betaling (kort eller SEPA), kan Stripe trække pengene fra din Stripe-konto, når tvisten åbnes. SEPA-tvister er endelige og kan ikke bestrides; korttvister kan behandles. Alunta reagerer i trin: - **Tvist åbnet.** Alunta giver kun dit team en besked ("Betaling anfægtet"), så I kan svare i Stripe inden fristen ved en korttvist. Ved SEPA følges der op direkte med slutkunden. Denne besked registrerer ikke i sig selv en pengestrøm, og Alunta svarer aldrig på eller accepterer en tvist på jeres vegne. - **Penge trukket tilbage.** Alunta registrerer en chargeback på betalingen (betalingen vises som "Tilbageført"), og fakturaen er åben igen for det anfægtede beløb; en delvist anfægtet betaling genåbner kun den del, og Alunta tilbagefører aldrig mere, end betalingen stadig rummer efter tidligere refunderinger. Dit team får en besked og en post under Stripe-fejl ("Stripe har trukket penge tilbage på grund af en betalingstvist"). Bruger teamet betalingspåmindelser, påmindes den genåbnede faktura kun efter teamets almindelige regler for påmindelser; tvisten udløser ikke en særlig påmindelse. - **Ingen automatisk opfølgning.** Alunta trækker ikke kunden igen, opsiger ikke abonnementet og sender ikke kunden en mail om mislykket betaling. Abonnementet kører videre, og I vælger selv, hvordan kunden følges op. - **Korttvist vundet.** Stripe returnerer pengene, og Alunta registrerer betalingen igen som en ny betaling på samme faktura. Fakturaen er betalt igen, betalingen synkroniseres til regnskabet som enhver anden betaling (i Billy, hvor Alunta ikke bogfører tilbageførslen automatisk, bogfører du også den returnerede betaling manuelt), og dit team får en besked om "Tvist vundet". Den oprindelige betaling og dens chargeback bliver stående som historik. Alunta bogfører højst det beløb, der blev tilbageført. Vil du refundere kunden, efter tvisten er vundet, gør du det som sædvanligt gennem Alunta: den returnerede betaling er en almindelig betaling på fakturaen. En betaling, der endnu ikke er knyttet til en faktura (fx en fornyelse trukket før faktureringskørslen), kan ikke tilbageføres endnu. Alunta forsøger automatisk igen, og et timevist tjek dækker tvister fra de seneste 420 dage. Kun tvister, hvor Stripe har trukket pengene tilbage fra og med 7. oktober 2026, registreres; ældre tvister importeres ikke, fordi teams allerede har håndteret dem selv. Har teamet slået betalingssynkronisering til regnskabet til, bogføres en chargeback også som en tilbageførsel i regnskabssystemet; se guiden om bogføringsintegrationer. Gennem API'et rapporteres en Stripe-tvist som `invoice.refunded` med `data.refund.kind` `chargeback`, aldrig som `invoice.payment_failed` eller `subscription.payment_failed`. ## Skift kort efter et fejlet træk Når kundeportalen viser **Opdater kort** på et abonnement med en fejlet betaling, kan kunden vælge et gemt kort eller tilføje et nyt. Kortskiftet opkræver ikke penge i sig selv. Kunden kan fortsat se næste trin, hvis det nye kort endnu ikke er knyttet til abonnementet, og en ny betaling følger det viste forsøg. Standardkortet til nye køb og kortet på et eksisterende abonnement er separate valg, så kontrollér hvilket kort der faktisk er ændret. ## Hvad jeres AI kan se om kortbetalinger Værktøjerne til kortbetalinger dukker først op, når teamet har en forbundet kortudbyder (Stripe, QuickPay, OnPay, PensoPay eller Cost+) eller abonnementer, der betales med kort. Slås en app eller et tilvalg til, skal AI-klienten genoprette forbindelsen eller genindlæse værktøjslisten for at se dem. Jeres egen AI kan se kortbetalinger på to niveauer. På det samlede niveau (`get_card_payment_overview`) kan den se, hvor mange kortabonnementer der har en udestående betaling lige nu, hvilken tilstand de er i, beløbet fordelt pr. valuta, fordelingen pr. udbyder og pr. regel for fejlet betaling, hvor mange der ender med automatisk opsigelse inden for 7 dage, hvor mange fejlede forsøg der var i en periode (slutdatoen må højst ligge 366 dage efter startdatoen), og hvor mange abonnementer der har et udløbet kort eller et kort, der udløber denne eller næste måned (abonnementer, som en forhandler betaler for, tæller ikke med, fordi de aldrig opkræves på deres eget kort). På detaljeniveau (`list_card_payment_issues`) kan den se de enkelte abonnementer med kunde, plan, udbyder, tilstand, beløb, forfaldsdato, seneste fejlårsag, regel for fejlet betaling, dage til opsigelse samt kortets mærke og udløbsmåned. Detaljeniveauet kræver, at både Kundedetaljer og Betalings- og bogføringsdetaljer er slået til under "Hvad AI må se". En udestående betaling er en abonnementsperiode - eller en forfalden, ubetalt rate, hvis perioden betales i rater - som den automatiske kortopkrævning burde have taget, men ikke har. Det er den regel, der giver status "Betaling fejlet" på abonnementet i appen, og den gælder både hele perioder og rater. Kundeportalen bruger samme regel for kundens egne abonnementer, men viser ikke annullerede abonnementer, så slutperioden i et netop afsluttet abonnement ses kun i appen og af AI'en. Appen viser derfor "Betaling fejlet" for enhver udestående betaling, også en der endnu ikke er forsøgt, mens AI'ens tilstand `failed` skelner en bekræftet fejl fra resten. En periode er forfalden, når den er startet (en forbrugsbaseret periode, når den er slut; en periode med fakturering på sidste dag, fra sidste dag; en første delperiode, der opkræves med næste fornyelse, fra den fornyelse), regnet efter opkrævningens egen kalenderdag. En rate er forfalden, når dens faktureringsdato er nået, selve raten hverken er betalt eller faktureret, og perioden ikke er opkrævet eller faktureret som helhed. Pause- og prøveperioder, perioder uden beløb eller uden noget at opkræve efter rabat eller forbrug, perioder uden for abonnementets faktureringsperiode, perioder der venter på et planskifte og abonnementer, som en forhandler betaler for, tæller ikke med. Slutperioden i et abonnement, der lige er afsluttet, tæller stadig, så længe den ligger inden for faktureringsperioden. Fejlede forsøg på slettede abonnementer tæller med i antal fejlede forsøg og i fordelingen efter årsag, men slettede abonnementer indgår hverken i antallet af berørte abonnementer eller i udfaldene. "Udestående" betyder forfalden og ikke betalt - ikke nødvendigvis noget, den næste opkrævning forsøger lige nu: opkrævningen springer for eksempel en periode eller en rate over i et døgn efter et fejlet forsøg. Hver udestående betaling har en tilstand: `processing` (et forsøg er i gang, og penge kan allerede være undervejs), `uncertain` (en betaling er trukket, men ikke knyttet til perioden eller raten, eller et forsøg har et uafklaret udfald - for eksempel et fejlet forsøg, udbyderen ikke har bekræftet, et uklart svar eller en reservation, der ikke er frigivet - så penge kan allerede være flyttet), `failed` (udbyderen har bekræftet et fejlet eller udløbet forsøg på abonnementets nuværende kort - et abonnement uden kort er aldrig `failed`), og for betalinger, der aldrig er forsøgt, årsagen til at ingen opkræver dem: `no_usable_card` (abonnementet har intet eget kort, kortet er slettet eller tilhører en anden kunde, eller kortet er udløbet, så opkrævningen ville fejle), `automatic_charging_off` (teamet har slået automatisk kortopkrævning fra eller har ingen faktureringsindstillinger, eller QuickPay-opkrævning er midlertidigt sat på pause for teamet), `provider_disconnected` eller `awaiting_charge_run` (næste opkrævning tager den, for eksempel fordi den først forfalder i dag). Forsøg, der hører til et andet team, en anden kunde eller en anden udbyder end abonnementets, tæller ikke med. Kun `failed` er en fejlet betaling. Beløbet er det udestående beløb pr. valuta, også for betalinger, som opkrævningen ikke kan tage lige nu (for eksempel fordi der ikke er noget brugbart kort), regnet som opkrævningen ville gøre det (pris efter rabat plus moms, samlet pr. kort; en rate opkræves for sig), og for `processing` og `uncertain` kan pengene allerede være flyttet. Antallet af abonnementer pr. tilstand eller pr. regel kan tilsammen overstige det samlede antal udestående abonnementer, når ét abonnement både har en periode og en rate udestående; rækkerne (items) stemmer præcist med listen. Dage til opsigelse og antallet af opsigelser inden for 7 dage gælder kun rækker i tilstanden `failed` på abonnementer med reglen "Prøv igen og annuller derefter", fordi Alunta først opsiger efter en fejlet opkrævning: tallet er de dage, der er tilbage af fristen, regnet fra den dag, rækkens ældste opkrævning forfaldt, eller for en rate fra ratens faktureringsdato, efter den regel der blev gemt på den periode. For en betaling, der er i gang, uafklaret eller aldrig forsøgt, for alle andre regler og for en fejlet betaling, som opkrævningen ikke forsøger igen (automatisk kortopkrævning er slået fra, eller teamet har ingen faktureringsindstillinger, QuickPay-opkrævning er sat på pause for teamet, eller kortudbyderen ikke er forbundet, så intet vil opsige abonnementet), er der intet tal, og rækken tæller ikke med. Yderligere to ting skal holdes adskilt. Et fejlet forsøg, der ikke længere er udestående, kaldes løst, ikke betalt: kunden kan have betalt, skiftet kort eller betalingsmetode, eller perioden kan være ryddet på anden vis. Og et udløbet eller snart udløbende kort er ikke en betalingsfejl i sig selv. Kortets udløbsmåned og forfaldsdatoer følger den tidszone, opkrævningen selv bruger. AI ser aldrig kortets sidste fire cifre, kort- eller betalingstokens, udbydernes interne id'er eller udbyderens egen fejltekst, og aldrig kundens kontaktoplysninger i disse svar. Hver afsøgning af rækker er begrænset; er der for mange, giver værktøjet en fejl i stedet for et delvist svar. ## Leverandørservice Leverandørservice har sin egen aftale og bankplan. Kunden skal have en aktiv aftale, og en indsendt opkrævning er ikke modtaget betaling. Derfor kan fakturaen stå som ubetalt længere end ved kortbetaling. ## Manuelle betalinger En manuel betaling kan registreres på en faktura med udestående saldo, f.eks. efter bankoverførsel. Kreditnotaer og fakturaer uden restsaldo kan ikke modtage en manuel betaling. En mindre betaling giver status delvist betalt, og fakturaen bliver først betalt når resten er dækket. ## Hvornår Alunta viser en faktura som ikke betalt Alunta markerer kun en faktura som "Ikke betalt" eller "Forfalden", når Alunta reelt kan se, om den er betalt: Alunta opkræver selv betalingen (kort, MobilePay eller Leverandørservice), teamet har slået "Vi registrerer betalinger i Alunta" til for bankoverførsler, eller Alunta henter afsluttede betalinger fra en tilsluttet e-conomic-, Billy- eller Dinero-konto med betalingsimport slået til (kun bogførte DKK-fakturaer, og kun betalinger udbyderen rapporterer på en måde Alunta kan matche til fakturaen). Betalingsimport er et tilvalg pr. forbindelse og er slået fra, indtil teamet slår det til; i Dinero hedder indstillingen "Registrér betalinger automatisk" under "Hent betalinger fra Dinero". For alle andre fakturaer - f.eks. en bankoverførselsfaktura teamet kun afstemmer i en e-conomic-, Billy- eller Dinero-forbindelse uden betalingsimport slået til - viser Alunta ingen betalingsstatus. Det gælder kun i appen: fakturalisten viser fakturaen uden betalingsstatus, og kundens "Ubetalt faktura"-badge, filteret "Overskredne fakturaer" og dashboard-widgetten "Forfaldne fakturaer" udelader den, fordi Alunta ikke kan bakke påstanden "ikke betalt"/"forfalden" op. Fakturaens egen status og udestående saldo i den offentlige API er uændrede. MCP-værktøjerne tæller dem derimod med. get_overdue_summary medregner dem i overdue_invoice_count og oplyser antallet i payment_status_tracking.unknown_payment_status_invoice_count; list_overdue_invoices returnerer dem med payment_status_known: false. Beskriv aldrig disse fakturaer som ubetalte, og foreslå ikke rykkere for dem, uden først at tjekke regnskabet. ## Betalingsstatus og opfølgning En betaling kan være planlagt, afvist, afventende, gennemført eller tilbageført. Brug status på den konkrete betaling og fakturaen sammen. En webhook om betalingsfejl kan komme igen ved et nyt forsøg; en senere webhook om betalt er ikke det samme som den tidligere fejl. Et abonnement der til sidst opsiges, har sin egen abonnementsstatus. Ved kortudløb skal du se efter uafklarede betalinger før du vælger automatisk opsigelse. Et kort der er udløbet, beviser ikke at et tidligere capture-forsøg mislykkedes. For afdrag vurderes den konkrete ubetalte og forfaldne del, ikke kun hovedperiodens status. ## Før du svarer kunden Kontrollér altid fire ting: betalingsudbyder, fakturaens restsaldo, den konkrete betalings status og om der findes en planlagt handling. Skriv ikke at penge er modtaget ud fra en reservationsdato, et gemt kort eller en indsendt Leverandørservice-opkrævning. Hvis en refundering står afventende, skal kunden have den viste status i stedet for en garanti om bankens behandlingstid. En kreditnota kan reducere en faktura uden at sende penge tilbage. En chargeback eller lokal tilbageførsel kan ændre betalingsstatus uden at skabe en kreditnota. Brug derfor fakturaens kreditspor og betalingens refundering separat ved afstemning.