Beregninger og datakvalitet

Pengebeløb i en app: undgå øre-fejl i priser, rabatter og moms

En app kan vise pæne beløb og gennemføre en betaling, selv om beregningen bagved er forkert. Når tilbud, ordrer eller fakturagrundlag får virkelige konsekvenser, skal valuta, decimaler, rabatter, moms og afrunding følge én dokumenteret regel fra input til afstemning.

Udgivet 16. september 2026 · Ca. 12 minutters læsetid

Et pengebeløb er mere end et tal

Et brugbart pengebeløb består mindst af en værdi og en valuta. Ofte hører der også en regel til for rabat, moms, præcision og tidspunktet for afrunding. Hvis appen kun gemmertotal: 125, kan andre ikke sikkert afgøre, om det betyder kroner, euro, øre, et beløb med eller uden moms eller et resultat, som senere kan genberegnes.

Værdi: Det præcise beløb i en aftalt repræsentation, fx hele minor units eller en decimaltype.
Valuta: En entydig valutakode på selve ordren eller beløbet – ikke kun et symbol i brugerfladen.
Beregning: Den aftalte rækkefølge for antal, pris, rabat, afgift, moms og afrunding.
Historik: De værdier og den beregningsversion, som gjaldt, da dokumentet blev godkendt.

Brug ikke et almindeligt flydende tal som facit

JavaScripts almindelige Numberer et binært flydende tal. Mange decimaltal kan derfor kun gemmes som en tilnærmelse. Små afvigelser bliver synlige, når værdier summeres, sammenlignes eller afrundes flere steder. Formatering med to decimaler gør visningen pæn, men ændrer ikke den underliggende beregning til en præcis pengemodel.

Et faresignal: Frontend, backend, database og betalingsudbyder bruger hver sin måde at gange, afrunde og formatere samme beløb på. Så kan to korrekte lokale beregninger stadig give forskellige totaler.

Vælg repræsentation efter stack og forretning

Der findes ikke én datatype, som alle apps skal bruge. Vælg en model, som hele kæden kan bevare uden skjulte konverteringer, og dokumentér hvor mange decimaler der må indgå i beregningen før det endelige resultat.

Hele minor units

En app med enkle priser kan gemme fx øre som heltal sammen med valutakoden. Modellen passer godt til betalings-API'er, som forventer beløbet i valutaens mindste enhed. Antag dog ikke, at alle valutaer har to decimaler; leverandørens aktuelle valutaregler skal være kilden. Kontrollér også heltallets sikre område i det sprog og den database, I bruger.

Decimaltype i SQL

PostgreSQLs numerickan gemme og beregne decimaltal nøjagtigt, hvor det er muligt, og dokumentationen anbefaler typen til pengebeløb, hvor præcision er nødvendig. Vælg precision og scale efter de største beløb og mellemregninger, som domænet faktisk kræver – ikke blot efter hvordan beløbet vises.

Dokumentdatabase som Firestore

Firestore understøtter både signed 64-bit integers og IEEE 754-double. En praktisk model til en enkel valuta er derfor ofte heltal i minor units plus valutakode. JavaScript-klienten har et mindre sikkert heltalsområde end Firestores lagring, så meget store summer og tællere skal gennemgås særskilt. Håndhæv felttype og tilladte ændringer i backend eller Security Rules, fordi databasen ellers er skemaløs.

Saml beregningen ét sted

Skriv én navngiven beregningsfunktion eller et afgrænset domænemodul, som bruges af API, job og import. Browseren må gerne vise et foreløbigt resultat, men serveren skal beregne og validere det endelige beløb ud fra betroede priser og regler, før en ordre, betaling eller fakturakladde godkendes.

1. Definér input: Antal, enhedspris, valuta, rabat, momsregel og de nødvendige datoer eller kundevilkår.
2. Beskriv rækkefølgen: Aftal om rabat anvendes før eller efter andre tillæg, og på hvilket niveau der afrundes.
3. Returnér delresultater: Linjebeløb, rabat, momsgrundlag, moms og total skal kunne forklares og afstemmes.
4. Validér på serveren: Accepter ikke klientens total som sandhed, selv om brugerfladen selv har beregnet den.
5. Versionsmærk reglen: En senere ændring må ikke lydløst omskrive historiske dokumenter.

Aftal afrundingen – og gør den synlig i tests

Afrunding er en forretningsregel, ikke oprydning til sidst. Et system kan afrunde pr. ordrelinje, pr. momskategori eller på dokumentets total og få forskellige resultater. Skattestyrelsens juridiske vejledning angiver for dansk moms, at fakturerede beløb ikke må afrundes før beregningen af momsgrundlaget. Den konkrete model skal fortsat afklares med virksomhedens bogholder eller revisor og passe til de dokumenter og systemer, appen udveksler data med.

Bevar nødvendige mellemregninger: Visning med to decimaler er ikke i sig selv en regel for intern præcision.
Afrund ikke ved hver tilfældig grænse: Gentagen afrunding kan flytte totalen, selv om hvert trin ser rimeligt ud.
Brug samme regel ved kredit og tilbageførsel: Et negativt dokument skal kunne forbindes med det oprindelige beregningsgrundlag.
Gør differencer forklarlige: Hvis et eksternt økonomisystem afrunder anderledes, skal integrationen opdage og håndtere forskellen bevidst.

Formatering er kun præsentation. Brug fxIntl.NumberFormattil lokale skilletegn og valutasymboler, men behold den kanoniske værdi og valutakode separat. En dansk tekst som “1.234,50 kr.” bør ikke være databasens beregningsformat.

Frys det godkendte beløb som historik

En gammel ordre må ikke ændre total, fordi produktets aktuelle pris, kundens rabat eller momsopsætningen senere bliver rettet. Når et dokument godkendes, bør appen gemme de afgørende værdier som et snapshot sammen med referencerne til produkt og kunde.

Enhedspris, antal, valuta og relevant måleenhed.
Rabatgrundlag, rabattype og beregnet rabatbeløb.
Momsregel eller sats samt beregnet momsgrundlag og momsbeløb.
Linjetotaler, dokumenttotal og eventuel eksplicit afrundingsdifference.
Beregningens version, godkendelsestidspunkt og aktør.

Gem kun de oplysninger, som dokumentation og drift kræver. Et snapshot skal gøre resultatet forklarligt; det er ikke en undskyldning for at kopiere alle kunde- og produktdata uden slettefrist eller adgangskontrol.

Kontrollér hver systemgrænse

Den hyppigste fejl opstår ved konvertering mellem brugerflade, API, database, betalingsudbyder og økonomisystem. Stripe forventer eksempelvis normalt API-beløb i valutaens minor unit, mens rapportfiler kan repræsentere beløb anderledes. Konverter derfor ved én tydelig grænse og sammenlign altid både værdi og valuta.

Input: Fortolk komma, punktum, tomme værdier og tusindtalsseparatorer efter en eksplicit lokal regel.
API: Dokumentér om feltet er major units, minor units eller decimaltekst; navnet amount er ikke nok.
Betaling: Opret beløbet fra serverens ordre, og bekræft det mod udbyderens hændelse – ikke mod retur-siden.
Bogføring: Afstem antal dokumenter, nettobeløb, moms og bruttobeløb pr. valuta og periode.
Valutaomregning: Læg ikke to valutaer sammen. Gem kurs, kilde og tidspunkt, hvis virksomheden har besluttet at omregne.

Ret eksisterende beløb som en datamigrering

Hvis appen allerede bruger flydende tal eller uklare felter, må de ikke blot ændres i produktion med en hurtig multiplikation. Kortlæg først de eksisterende formater og historiske undtagelser, beregn den nye model i et separat felt, og afstem differencer på et kontrolleret datasæt.

Find alle beløbsfelter og beregningssteder i browser, backend, database, imports, exports og integrationer.
Fastlæg den kanoniske model og dokumentér præcision, valuta, afrunding og versionsregel.
Kør gammel og ny beregning parallelt på repræsentative ordrer uden at ændre det godkendte facit.
Undersøg alle differencer over en aftalt grænse; et gennemsnit kan skjule enkelte alvorlige fejl.
Migrér i afgrænsede batches med backup, sporbar status og mulighed for at genkøre sikkert.
Bevar historiske snapshots, hvis det gamle dokument skal forklare den handel, der faktisk blev godkendt.

Test kendte facitter og ubehagelige grænser

Brug eksempler, som virksomhedens økonomiansvarlige kan godkende manuelt, og gem dem som automatiske regressionstests. Test hele vejen fra indtastning til database, dokument, betalingsrequest og afstemning – ikke kun en isoleret hjælpefunktion.

Små beløb, nul, store antal og værdier præcis omkring en afrundingsgrænse.
Procent- og beløbsrabat, flere rabatter og en kredit af en tidligere linje.
Flere momskategorier på samme dokument og en ordre uden moms, hvor det er relevant.
Valutaer med forskelligt antal minor units, hvis appen faktisk understøtter flere valutaer.
Browserinput med dansk komma, kopieret tusindtalsseparator og ugyldige tegn.
Afstemning hvor summen af linjer, moms og total skal passe til det eksterne system.

Typiske fejl

Der sættes bare to decimaler på: Formateringen skjuler afvigelsen uden at rette beregningsmodellen.
Valutaen findes kun som “kr.”: Data kan ikke sikkert udveksles eller afstemmes på tværs af systemer.
Browserens total gemmes direkte: En ændret request eller gammel frontend kan sende et andet facit.
Alt ganges med 100: Løsningen antager to decimaler for alle valutaer og ignorerer mellemregningers præcision.
Priser genberegnes historisk: Ændrede produktdata omskriver gamle ordrer eller rapporter.
Hver integration afrunder selv: App, betaling og bogføring ender med tre nært beslægtede, men forskellige beløb.
Kun glade tal testes: Rabatter, kreditering, valutaer og grænsetilfælde opdages først i afstemningen.

Tjekliste til troværdige pengebeløb

☐ Alle beløbsfelter har en entydig værdi, valuta og enhed.
☐ Beregninger bruger heltal i minor units eller en egnet decimaltype – ikke flydende tal som facit.
☐ Præcision og afrunding er dokumenteret for linjer, moms, rabat og total.
☐ Serveren genberegner endelige beløb ud fra betroede priser og regler.
☐ Godkendte ordrer og dokumenter bevarer de værdier og den beregningsversion, der gjaldt.
☐ API-felter angiver, om beløb er decimaler, major units eller minor units.
☐ Betalings- og økonomisystemer afstemmes på både beløb og valuta.
☐ Tests dækker grænser, rabatter, kredit, moms og de valutaer, appen reelt understøtter.
☐ Eksisterende data migreres med parallel beregning, differencerapport og gendannelsesvej.
☐ Den økonomiansvarlige har godkendt konkrete facitter og afrundingsregler.

Relaterede guides

Sikker onlinebetaling fra ordre til bekræftet levering SQL, PostgreSQL og præcise datatyper Sikker dataimport og migrering af eksisterende beløb Revisionslog for kritiske ændringer Teststrategi for kritiske brugerrejser og beregninger Se hele guidebiblioteket

Officielle kilder

Datatyper, valutaregler og leverandørformater ændrer sig. Kontrollér den aktuelle dokumentation og virksomhedens bogføringspraksis, før beregningsmodellen bruges i drift.

Virker appen, men kan beløbene ikke forklares og afstemmes?

Startklar er til virksomheder med en fungerende AI-bygget app, som skal gøres sikker og stabil til daglig brug. Vi kan gennemgå pengebeløb, datamodel, beregninger, integrationer og tests i den stack, appen allerede bruger – uden at gøre løsningen større end nødvendigt.

Se Startklar-forløbet