# Fakturering og levering Alunta bygger fakturaer ud fra abonnementsperioder og eventuelle andre fakturalinjer på kunden. Bogføring, afsendelse og betaling er tre forskellige tilstande, så en faktura der er sendt eller bogført i dit regnskabssystem, er ikke nødvendigvis betalt. ## Hvornår en abonnementsperiode bliver til en faktura Alunta leder efter fakturerbare perioder hver time. En periode faktureres på sin egen fakturadato, som normalt er periodens første dag på det faktureringstidspunkt du har valgt under faktureringsindstillinger (09:00 når intet er sat). Tidspunktet gælder i dit firmas tidszone. Fire ting kan flytte den dato: - **Den første selvbetjenings- eller checkoutfaktura.** På et automatisk fornyet abonnement der betales med faktura, faktureres første periode straks, når checkout sker på eller efter dens startdato. Senere fornyelser bruger som normalt det valgte faktureringstidspunkt og dagsforskydningen. - **Faktura som betalingsmetode.** Perioden faktureres på periodens første dag plus den dagsforskydning du har konfigureret. En negativ forskydning fakturerer forud for perioden, en positiv fakturerer efter den er begyndt. Det er sådan du sender en faktura fjorten dage før perioden løber. - **Forbrugsbaserede abonnementer.** De afregnes altid bagud. Forbruget gøres op når perioden er slut, og fakturaen oprettes dagen efter periodens afslutning. Dagsforskydningen gælder også her, men en negativ forskydning kan ikke trække faktureringen tidligere end dagen efter periodens afslutning, fordi forbrugstallet ikke findes før da. - **Første delperiode opkræves med næste fornyelse.** Ved fast fornyelse kan et team vælge **Opkræv sammen med næste fornyelse** i fornyelsesindstillingerne. Et abonnement oprettet i appen, via API'et eller købt via checkout, der starter mellem to fornyelsesdatoer, får så sin første delperiode faktureret eller trukket sammen med næste periode, på næste fornyelsesdato og med den periodes dagsforskydning og faktureringstidspunkt: én faktura med en linje for hver periode. Et køb via checkout udskydes kun, når den fornyelse faktureres eller trækkes automatisk. Det gælder kun, når delperioden ligger inden for én kalendermåned, og ikke importerede abonnementer, fakturering på sidste dag, rater eller forbrugsbaserede planer. Valget låses på abonnementet, når det oprettes (ved et køb via checkout, når checkout prissætter købet), så en senere ændring af indstillingen flytter hverken et eksisterende abonnement eller et køb, kunden allerede har fået vist. Et abonnement der betales med kort, trækkes først og faktureres derefter, så fakturaen oprettes med betalingen allerede tilknyttet. Ved automatisk fakturering sker korttrækket i den timevise betalingsproces; ved semiautomatisk fakturering udfører brugerens manuelle fakturahandling trækket lige før fakturaen oprettes. Et abonnement der betales på faktura, faktureres først og betales senere. For API-integrationer følger transaktionens `ready_to_invoice`-felt grundfilteret `ready_to_invoice=1`: periodestart må højst være i dag plus 60 dage, inklusive ældre ufakturerede perioder uden nedre datogrænse. Betalingsregler, fakturadato og automatisk/manuel fakturering gælder stadig. Nye API-planer arver firmaets indstilling for automatisk fakturering; kontrollér den i dashboardet før oprettelse af planer. Dagsforskydningen (`invoicing_days_offset`) kan ændres i dashboardet, men ikke via public v1. ## Hvorfor en periode ikke blev faktureret Den timevise kørsel springer stiltiende en periode over, hvis bare ét af punkterne herunder gælder. Listen er tjeklisten når en kunde siger at der mangler en faktura: - Fakturadatoen er ikke nået endnu. Intet faktureres mere end 60 dage før perioden begynder. - Abonnementet fornyes ikke automatisk. De perioder venter på at nogen fakturerer dem manuelt. - Det er første periode på et almindeligt manuelt oprettet abonnement uden avancerede rater. Den første faktura er bevidst overladt til et menneske og dukker i stedet op i den manuelle fakturaprompt. Det gælder ikke et fremtidsdateret abonnement: er abonnementet oprettet før perioden begyndte, fik ingen valget, og perioden faktureres automatisk når den forfalder. - Perioden er en prøveperiode eller en pause. Begge er nulprisperioder efter hensigten og faktureres aldrig, men de findes stadig, så tidslinjen ikke får huller. - En rabat bringer abonnementsperioden ned på nul. Så oprettes der ingen nulfaktura. Hvis der samtidig er et positivt engangsbeløb, oprettes fakturaen stadig for det beløb; rabatten på abonnementet reducerer ikke engangsbeløbet. - En forbrugsbaseret periodes beregnede beløb er nul, når inkluderet antal og et eventuelt minimumsfakturerbart antal er anvendt. Manglende registreret forbrug er ikke i sig selv nok til at springe faktureringen over, hvis der er aftalt et positivt minimum. - Perioden er en første delperiode, der opkræves med næste fornyelse, og dagen, hvor den faktureres sammen med næste periode, er ikke nået endnu. Manuel fakturering kan heller ikke fakturere den tidligere. - Abonnementet betales med kort, automatisk korttræk er slået til, og kortet er ikke trukket endnu. Trækket skal lykkes før fakturaen oprettes. - Perioden slutter efter abonnementets slutdato, fordi abonnementet er opsagt. - Der ligger et planskift på abonnementet, som endnu ikke er trådt i kraft. - Perioden hører til en ratebetaling. Rater har hver sin forfaldsdato og fakturalinje. Forfaldne ratelinjer i samme valuta kan dog samles på én faktura; de faktureres ikke som én samlet serviceperiode. ## Minimumsantal til fakturering af forbrug Et individuelt forbrugsbaseret abonnement kan have et minimumsantal pr. faktureringsperiode. Angiv det under Flere aftalevilkår ved oprettelse, eller brug Rediger minimumsfakturerbart antal i abonnementets menu. API-feltet ved oprettelse hedder `minimum_billable_quantity`; `0` betyder intet minimum. De faktiske forbrugsposter bevares uændret. Hvis prislinjen har et inkluderet antal, trækkes det først fra det faktiske forbrug, dog mindst ned til nul, og derefter anvendes minimumstallet: fakturerbart antal er `max(minimum_billable_quantity, max(0, actual_usage - included_quantity))`. Stykprisen anvendes på dette antal før en eventuel procentrabat. En periode uden forbrug kan derfor stadig give en faktura, hvis der er sat et minimum. Når minimum anvendes, forklarer fakturaen både det registrerede antal og minimumsafregningen. Det fulde minimum gælder også en forkortet almindelig faktureringsperiode. Prøveperioder og pauser har intet minimum, og ubrugte enheder overføres ikke. Ændringer på et eksisterende abonnement gælder fra næste tilgængelige almindelige fremtidige periode; den aktuelle periode og tidligere fakturerede perioder beholder deres vilkår. En afventende betaling kan udskyde denne grænse. Abonnementet viser den planlagte værdi og ikrafttrædelsesdato. ## Avancerede kalendermånedsrater med semiautomatisk fakturering På egnede fleksible fastprisabonnementer med fakturabetaling bruger avancerede rater kalendermånedsforskydninger og procenter for hver hel abonnementsperiode. Prøveperioder, kort, checkout, fælles fornyelsesdato, kunder med en anden betaler og forbrugs-, niveau- og licenspriser understøttes fortsat ikke. En plan med standardprøveperiode kan bruges, når abonnementet oprettes uden prøveperiode (i API'et `apply_plan_trial: false`); det afvises, så længe en prøveperiode stadig gælder. Får kunden en betaler efter købet, faktureres betaleren. På en semiautomatisk plan gemmer oprettelse af et avanceret abonnement rateplanen uden at oprette eller sende en faktura. Første abonnementsrate, oprettelsesrate, senere rater og en lille positiv periode, som ikke kan deles, kræver alle en aktiv fakturahandling, når de er klar. En pakke med mindst én semiautomatisk plan oprettes også uden faktura; fuldautomatiske pakker beholder deres første faktura for beløb, der allerede er klar. Opret manuelle avancerede abonnementer og fuldautomatiske avancerede pakker hver for sig i oprettelsesformularen. Brug kundens fakturaprompt til at forhåndsvise og derefter aktivt oprette fakturaen. Prompten kan vise oprettelsesgebyrer, selv om ingen abonnementsrate er klar, og den viser allerede ældre, manuelle beløb for den kunde. Har abonnementet en anden betaler, bruges betalerens fakturahandling. På oversigten viser afsnittet "Rater kræver manuel fakturering" forfaldent manuelt arbejde pr. betalende kunde. Fremtidige rater medtages ikke. En fakturahandling for bestemte transaktioner medtager ikke pakkens øvrige oprettelsesrater. Via API opretter du først abonnementet eller pakken og bruger derefter `POST /api/v1/customers/{uuid}/invoices/preview` (eller `/preview/pdf`), før du aktivt kalder `POST /api/v1/customers/{uuid}/invoices`. Brug betalerens kunde-UUID, når en anden kunde betaler. Klare beløb grupperes efter valuta; brug det eksisterende `should_send`-valg til levering. En forhåndsvisning eller en nået faktureringsdato er ikke en godkendelse af fakturering. Forbrugsbaserede fakturapreviews i UI og API beregner periodens aktuelle forbrug i hukommelsen uden at gemme transaktionen eller tilknytte forbrugsrecords. Nye eller rettede records inden den faktiske fakturering eller kortbetaling kan ændre det endelige beløb. Allerede afregnede perioder beholder deres afregnede beløb. `GET /api/v1/customers/{uuid}/upcoming-invoices` viser uden at ændre noget, hvad kunden bliver trukket og faktureret på sin næste faktureringsdato, eller på en dato inden for 12 måneder (`?date=`). Den bruger de samme datoer og den samme gruppering som de automatiske kørsler og de samme fakturalinjer som en rigtig faktura, og viser korttrækket pr. betalingsmetode. Forbrug i en periode, der ikke er slut, beregnes ud fra det indrapporterede indtil nu og er markeret som et estimat. Ventende engangsbeløb, oprettelsesgebyrer og forholdsmæssige reguleringer vises kun på den dato, hvor deres abonnement faktureres næste gang, fordi de kommer med på abonnementets næste faktura. Abonnementsperioden følger den aktuelle indstilling på sin oprindelige plan, ikke en senere udskiftningsplan. Fælles oprettelsesrater følger alle oprindeligt købte planer: de er manuelle, hvis mindst én er manuel, eller en oprindelig plan ikke kan findes. Ændringer af pakkeskabelonen eller opsigelse af ét abonnement gør ikke fælles oprettelsesrater automatiske. Fuldt opsagte køb udelades fortsat. Abonnementsperioder beholder deres eksisterende fallback til den gemte planindstilling, hvis planen mangler; fælles oprettelsesrater kræver i stedet manuel fakturering. Arkiverede/slettede oprindelige planer kan stadig levere indstillingen; firmaets fælles skift af faktureringsmetode ændrer ikke slettede planer. Når automatisk fakturering slås til, kan allerede faktureringsklare, ubetalte avancerede beløb blive faktureret ved næste normale kørsel, også første lille udelte periode. Når den slås fra, standses nye automatiske faktureringer, også rater hos en anden betaler og oprettelsesrater på en anden automatisk faktura. En allerede oprettet faktura omgøres ikke, og dens godkendte levering standses ikke. Gemte beløb, oprettelsestekst, datoer, regnskabsprodukter og en fast momssats fra tilbuddet ændres ikke ved skiftet. Uden en fast momssats i tilbuddet følger momsen på en oprettelsesrate den kunde, der faktureres for raten, så en betaler tilføjet efter købet faktureres med sin egen sats. Ældre delvist afregnede avancerede perioder kan afvise deaktivering af rateplanen for at bevare reglerne for de resterende rater. `bill_at` er den planlagte faktureringsdato i firmaets tidszone, ikke en betalingsfrist. Fakturerer du senere, regnes betalingsfristen fra den faktiske fakturadato. Prognoser medtager manuelle beløb og markerer dem som manuelt faktureringsarbejde, også for tidligere perioder; de er estimater, ikke udstedte tilgodehavender. Selvstændige engangslinjer beholder deres nuværende placering på første rate og opdeles ikke i pakkers oprettelsesrater. ## Én faktura per kunde og valuta Alle perioder der er klar til den samme betalende kunde, samles på én faktura per valuta. Er en kunde sat op som betaler for andre kunder, samles deres abonnementer også på betalerens faktura, mens et abonnement som underkunden selv betaler, bliver på sin egen faktura. En kunde med abonnementer i to valutaer får derfor to fakturaer, ikke én. ## Hvorfor fakturaen har to forskellige numre Har den samme faktura tilsyneladende to forskellige numre, har både Alunta og regnskabssystemet tildelt den et nummer. Hvilket nummer API'et returnerer, afhænger af hvordan teamet udgiver fakturaer. Når du udgiver PDF'en fra dit regnskabssystem (e-conomic, Dinero, Billy eller Uniconta), begynder `number` som et foreløbigt Alunta-nummer og overskrives med det bogførte regnskabsnummer, når bogføringssynkroniseringen afsluttes korrekt. Det kan derfor ændre sig mellem oprettelsen og en senere læsning efter bogføring; det er ikke en stabil identifikator. Et team der sender Aluntas egen PDF, kan også konfigurere dokumentet til at vise det bogførte regnskabsnummer. I den opsætning returnerer v1-API'et stadig Aluntas nummer som `number`, mens regnskabsnummeret som kunden ser, ikke returneres af fakturaendepunkterne i dag. Afstem det nummer gennem regnskabssystemet. Kun når teamet bruger Aluntas egen nummerering hele vejen igennem, svarer `number` konsekvent til kundens dokument. Brug i alle opsætninger fakturaens `uuid` som den stabile API-identitet, og få bekræftet hvilken nummerering teamet bruger, før du afstemmer på et vist fakturanummer. Alunta udsteder aldrig det samme fakturanummer to gange. Et nummer er brugt, når en faktura eller kreditnota oprettes med det, også hvis dokumentet senere slettes. En sletning efterlader derfor et hul i nummerrækken i stedet for at lade næste faktura genbruge nummeret. ## E-mail eller EAN En faktura leveres på e-mail, medmindre kunden er sat op til EAN/NemHandel og modtageradressen kan leveres til; så sendes den som e-faktura i stedet. E-mailen undertrykkes netop når EAN-afsendelsen skal ske, så en faktura ikke ved et uheld leveres to gange. Der er én bevidst undtagelse: en kunde kan sættes op til at modtage en kopi på e-mail ud over e-fakturaen. Er det slået til, sendes begge, og det er den ønskede adfærd, ikke en dublet. ## Sletning af en faktura En faktura, der er oprettet, fjernes aldrig. **Slet faktura** annullerer den i stedet med en kreditnota for hele restbeløbet, så kunden ikke længere skylder beløbet, og begge dokumenter bliver liggende under Fakturaer, hvor fakturaen vises som krediteret. Kreditnotaen sendes samme vej som fakturaen: via EAN, på mail til alle, der fik fakturaen på mail, eller slet ikke, hvis kunden aldrig har fået fakturaen (dens ventende mail stoppes så). Er fakturaen kun markeret som sendt uden om Alunta, sender teamet selv kreditnotaen. En betalt faktura krediteres i kreditdialogen, hvor teamet tager stilling til tilbagebetaling, og en faktura med en betaling på vej (en Leverandørservice-opkrævning hos banken eller en åben kortautorisation) kan ikke annulleres, før betalingen er gennemført. Alunta fakturerer ikke perioden igen af sig selv; en rettet faktura er en ny engangsfaktura. ## Besked til teamets ejer Teamets ejer kan slå e-mailbeskeden "Faktura sendt" til under notifikationsindstillinger. Den sendes efter at e-mailtransporten har accepteret en kundemail med faktura, kreditnota eller Leverandørservicefaktura med tilmeldingslink. Transportaccept bekræfter ikke, at kundemailen er nået frem til kundens indbakke. ## Hvorfor en EAN-faktura kan tage tid Dokument-id'et på en e-faktura skal være det endelige fakturanummer. For teams hvor regnskabssystemet ejer nummeret, holder Alunta derfor EAN-afsendelsen tilbage, indtil fakturaen er bogført og det endelige nummer er kendt, og sender først bagefter. For teams hvor Alunta ejer nummeret, er nummeret endeligt med det samme, og e-fakturaen går af sted straks. Er regnskabssynkroniseringen langsom, venter leveringen i stedet for at sende et nummer der er ved at blive ændret. Viser det sig at EAN-levering alligevel ikke er mulig, sendes fakturaen på e-mail. Den fallback er ikke en ubetinget garanti. Venter fakturaen stadig på sit bogføringsnummer, sender Alunta bevidst ingenting frem for at sende et nummer der bliver erstattet, og melder det i stedet som en integrationsfejl. Det samme gælder hvis kunden ikke har en brugbar fakturamail. En udskudt faktura der ikke er kommet frem, er derfor et signal om at tjekke regnskabssynkroniseringen, ikke noget der løser sig selv. ## Sådan tjekker du det for dit eget team Alt ovenstående beskriver hvordan Alunta opfører sig generelt. Om EAN er sat op, hvilket regnskabssystem der ejer dine numre, og om automatisk korttræk er slået til, er teamindstillinger. Åbn teamets app- og integrationsoversigt for at se om EAN er aktiv, og åbn derefter EAN- eller integrationsstatussen for den konkrete leveringsstatus. ## Fakturasprog og betalingsfrist Fakturaer, kreditnotaer og kundemails fra Alunta skrives på dansk, når kundens land er Danmark, og på engelsk for alle andre kunder, også kunder uden land. Sproget kan ikke vælges for den enkelte kunde, kun via kundens land. Bruger teamet bogføringssystemets PDF, er det bogføringssystemet, der bestemmer dokumentets layout og sprog. Checkout og kundeportal har deres eget sprogvalg (se vejledningen om checkout og selvbetjening). Aluntas standardbetalingsfrist sættes i fakturaindstillingerne under **Betalingsfrist** som et antal dage fra fakturadatoen. Standard er 7 dage. Via API'et ændres den med feltet `invoice_due_days` på `PUT /team`. Kunder bruger automatisk denne standard. Ved oprettelse eller redigering vises en kort oversigt under **Betalingsbetingelser**. Klik **Tilpas**, hvis kunden skal have sin egen aftale; først da vises de ekstra felter. **Brug virksomhedens standard** fjerner kundens egne betingelser, når du gemmer kunden. Kundekortet viser kun betalingsbetingelser, hvis kunden har en egen aftale. Kundens betingelser kan være **N dage netto** eller **Månedens udgang + N dage**, med 0 til 365 dage. Netto regnes fra fakturadatoen; løbende måned regnes fra den sidste kalenderdag i fakturamåneden. En faktura dateret 10. april med netto 30 forfalder 10. maj; løbende måned + 30 forfalder 30. maj. Betingelserne gælder nye abonnements-, bundle- og engangsfakturaer samt fakturaer oprettet via checkout eller API. En særskilt valgt forfaldsdato på en manuel engangsfaktura har forrang. Eksisterende fakturaer ændres ikke. Via kunde-API'et sættes `payment_terms_type` (`net` eller `end_of_month`) og `payment_terms_days` sammen. Udelad begge for at bevare den eksisterende indstilling, eller send begge som `null` for at bruge teamets standard. MCP-værktøjet `create_customer` accepterer samme par. Leverandørservice planlægger nye træk efter fakturaens forfaldsdato, tilpasset bankdage, indsendelsesfrister og eksisterende adviseringskrav. Kundens betingelser udskyder ikke automatiske kortbetalinger. Kortfakturaer, Betalingsservice og kreditnotaer beholder deres eksisterende regler. Bogføringssystemet kan have sine egne betalingsbetingelser. I e-conomic-indstillingerne vælges en **Standard betalingsbetingelse** og eventuelt **Betalingsbetingelser pr. betalingsmetode**, som sendes med den bogførte faktura. Bruger teamet e-conomics PDF, følger forfaldsdatoen den bogførte faktura (se næste afsnit). Med **Brug kundens betalingsbetingelser fra e-conomic** bruger fakturaer med manuel betaling de betalingsbetingelser, der er valgt på kunden i e-conomic, og forfaldsdatoen ligger først fast, når fakturaen er bogført. Kortbetaling, Leverandørservice og kreditnotaer bruger stadig de konfigurerede betalingsbetingelser. Dinero har en tilsvarende standard betalingsbetingelse og betalingsbetingelser pr. betalingsmetode. Kun e-conomic kan bruge kundens egne betalingsbetingelser fra bogføringssystemet. Når e-conomic styrer betalingsbetingelserne eller PDF'en, skjules redigeringen i Alunta, og egne Alunta-betingelser kan ikke sættes via API eller MCP. Du ændrer dem i e-conomic. ## Når betalingsvilkårene afventer regnskabet På manuelle fakturaer med valgte eksterne betalingsvilkår følger forfald den verificerede bogførte faktura. Et endeligt fakturanummer alene frigiver ikke dokumentet: betalingsvilkårene skal også være endelige. Mens de afventer, tilbageholdes kundevendt dokumentafsendelse og automatiske rykkere. API'et viser `payment_terms_status: pending` og `due_date: null`, så en foreløbig dato ikke bliver præsenteret som endelig. Fakturaer med lokal betalingspolitik beholder Aluntas dato. Regnskabets eventuelle afvigende dato skal afklares særskilt. Betalingsfristen ændrer ikke automatisk hævedatoen for kort. Nye Leverandørservice-træk planlægges efter fakturaens gemte forfaldsdato; en historisk datorettelse er ikke en automatisk ændring af et allerede planlagt træk. En historisk datorettelse nulstiller ikke allerede afsendte rykkertrin og gensender ikke fakturaen.