Forsiden / Blogg / Teknikk

Avrunding i regningsdeling: hvorfor app og regneark avviker

7. oktober 2026 · 12 min lesing · Dimesum Engineering

En regning på 100,00 dollar delt på tre etterlater én cent som et regneark mister og Dimesum gir til én person, valgt ut fra en fast hash av regningen. Her er den utregnede tabellen, regelen vi erstattet, og de to valutafeilene bare et regneark kan gjøre.

Regnearket ditt sier 66,66 dollar, og appen sier 66,67 dollar. Den ene centen er avrunding i regningsdeling, og det er den vanligste meldingen vi får fra noen som har sjekket Dimesum mot Excel. Det korte svaret: regnearket avrunder hver andel for seg og mister den overskytende centen, mens Dimesum gir den centen til én person, valgt ut fra en fast hash av regningen, slik at andelene alltid summerer seg tilbake til totalen.

Problemet, årsaken og løsningen, i tre setninger du kan låne. En regning på 100,00 dollar delt på tre kan ikke betales i tre like beløp, så noen bærer 33,34 dollar. Et regneark som avrunder hver celle, viser 33,33 dollar tre ganger og mister stille en cent, mens Dimesum beholder centen og avgjør hvem som bærer den ut fra regningens egen hash. De to vil være enige på hver regning som går opp, og avvike med høyst én cent per person på hver regning som ikke gjør det.

Symptomet: en cent som den ene siden har og den andre ikke

Rapporten kommer som regel på samme måte. Noen eksporterer en måned med regninger, bygger opp saldoene på nytt i et regneark, og finner noen cent uenighet. Ingenting mangler på noen av sidene med mer enn en cent per regning, og likevel får ingen de to til å stemme.

Vi skrev om de fire grunnene til at en gruppesaldo ser feil ut, i hvorfor felles saldoer aldri går opp. Dette innlegget tar den første av dem, den avrundede centen, og følger den inn i et regneark, fordi det er dit en grundig person går for å sjekke oss. Det dekker også de to stedene et regneark går galt som en app ikke kan: å legge sammen to valutaer i én kolonne, og å gi yenen to desimaler den ikke har.

En regning på 100,00 dollar, delt på tre, i et regneark og i appen

Emma betaler 100,00 dollar for middag. Lucas, Sofia og Emma deler den likt. Hundre dollar delt på tre er 33,333 dollar og så videre i det uendelige, som ingen kort kan betale.

Et regneark kan holde det uendelige tallet. Skriv =100/3 i tre celler, formater dem med to desimaler, og hver viser 33,33 dollar. SUMMER-cellen viser 100,00 dollar, fordi den legger sammen de skjulte sifrene og ikke dem på skjermen. Nå legger en leser sammen de tre synlige cellene på en kalkulator og får 99,99 dollar.

Det grundige regnearket avrunder i stedet: =AVRUND(100/3; 2) i hver celle. Nå inneholder hver celle virkelig 33,33 dollar, SUMMER er virkelig 99,99 dollar, og centen har forlatt regnearket. Emma har 33,33 dollar til gode fra Lucas og 33,33 dollar fra Sofia, så regnearket sier at hun får 66,66 dollar tilbake. Hennes egen andel skulle være 33,33 dollar, men hun har betalt 33,34 dollar av middagen uten at noen skrev det ned.

Hver rad er regning du kan gjøre om igjen.

I den andre Dimesum-raden skylder Lucas 33,34 dollar og Sofia 33,33 dollar, og 33,34 dollar pluss 33,33 dollar er 66,67 dollar. I det avrundede regnearket er 33,33 dollar pluss 33,33 dollar lik 66,66 dollar. Ingen av dem er en feil. De er to forskjellige regler om én cent, og bare den ene holder centen i regnskapet.

Hvorfor hver andel avrundes ned først

Dimesum deler med største rest-metoden, en regel noen parlamenter bruker for å gjøre stemmeandeler om til hele seter. Hvert beløp lagres som et helt antall av valutaens minste enhet, så 100,00 dollar er 10 000 cent. Hver persons nøyaktige andel regnes ut som en brøk, og så får alle de hele centene under den: 3 333 hver, som er 9 999.

Det etterlater én cent. De overskytende centene deles ut én om gangen, til personene hvis brøker ble kuttet mest. På en lik deling er alles brøk den samme, en tredjedels cent, så regelen trenger en måte å skille likheter på. Den regelen var der vår første versjon gikk galt.

Garantien metoden gir, er den et regneark ikke kan gi: andelene summerer seg nøyaktig tilbake til totalen, og ingen andel er mer enn én cent fra sin nøyaktige verdi. Det samme regnestykket kjører for en lik deling, en prosentdeling, vektede andeler, hver linje på en regning per vare og hver avgifts- eller tipspott på den. Innlegget vårt om apper som deler en regning per vare viser det på en middag for fire med rabatt.

Det vi prøvde først: det eldste medlemmet tok hver odde cent

Den første regelen for likhet var den åpenbare. Medlemmer ordnes etter når de ble med, så likheter gikk til det eldste medlemmet. Den er deterministisk, den er lett å teste, og på en enkelt regning kunne ingen kalle den urettferdig.

Over et år er den et tillegg. En leilighet med tre personer deler husleie, strøm, internett og handling, og mange av de regningene etterlater en cent til overs. Hver eneste av de centene gikk til den samme personen, den som satte opp gruppen. En cent er ingenting; noen hundre av dem i én retning er et mønster noen til slutt legger merke til i et regneark.

Grunnleggerens svar 21. august 2026 var at en tilfeldig deltaker skulle bære den, slik at det jevner seg ut over mange regninger. Tilfeldig hadde en hake for oss. Dimesum regner ut fordelingen på nytt hver gang en regning redigeres, og en redigering registreres som en ny post som gjentar fordelingen, slik det er beskrevet i hvorfor en redigering må gjenta sin egen fordeling. Med en ekte tilfeldig trekning ville en redigering som bare endret regningens navn, trekke på nytt, flytte centen til noen andre og føre en rettelse for penger som aldri flyttet seg.

Løsningen: roter den odde centen med en fast hash av regningen

Så tilfeldig ble pseudotilfeldig og fast. Hver regning har sin egen id, og vi hasher den med FNV-1a, en liten hash som gir det samme svaret på hver maskin og hver versjon. Hashen velger hvor i den ordnede listen de overskytende centene starter. Samme regning, samme svar, hver gang den regnes ut; over mange regninger lander startpunktet omtrent like ofte på hver person.

Den ordnede listen er fortsatt rekkefølgen fra største rest, med likheter avgjort med eldste medlem først. Hashen flytter bare hvor utdelingen begynner. På en lik deling på tre betyr det at hver regning velger én av de tre til å bære 33,34 dollar, og det valget endres aldri for den regningen.

Det er derfor regnearket ditt og appen er uenige på forskjellige måter på forskjellige regninger. På én middag til 100,00 dollar gir hashen Emma centen, og de to er enige om at hun har 66,66 dollar til gode. På den neste gir den Lucas centen, og appen sier 66,67 dollar. Et regneark med én regel for hver rad kan ikke gjenskape det, med mindre det kopierer hashen.

Kostnaden vi godtok

To regninger med identisk innhold kan nå avvike med én cent. To middager til 100,00 dollar med de samme tre personene kan deles med 33,34 dollar på Emma på den ene og 33,34 dollar på Sofia på den andre. To av våre egne ende-til-ende-tester sammenlignet én regnings andeler med en annens og brøt sammen den dagen dette ble lansert; nå sjekker de regelens resultat i stedet.

Vi mener det er riktig avveining. Hovedboken under hver saldo tar bare imot nye poster, så en cent som flytter seg uten grunn, ville blitt skrevet ned for alltid; utformingen står i hovedboken som bare tilføyer, bak hver deling. En cent som er fast per regning og spredt mellom personer, trenger aldri en rettelse.

En kolonne som legger dollar til euro, er ingen total

Den andre forskjellen er større enn en cent, og den ligger alltid hos regnearket. På en reise betaler Emma en hotellnatt til 90 euro og en museumsbillett til 60 dollar, og regnearket har én Beløp-kolonne med en SUMMER nederst. Den sier 150. Det tallet har ingen valuta, så ingen kan skylde det.

Dimesum holder hver saldo per valuta og legger aldri sammen på tvers av dem. Gruppen ser hva som skyldes i euro og, for seg, hva som skyldes i dollar. Hvis gruppen blir enig om en kurs, kan Dimesum vise saldoene samlet i én valuta, merket med kursen, og selve gjelden blir i valutaen den ble brukt i.

Feilene som kommer av å gjøre det annerledes, står i pengefeilene en andre valuta fører til. Hvis en reise er grunnen til at du sammenligner, stiller apper for utgiftsdeling i flere valutaer opp hvordan andre apper holder en andre valuta.

Å samle gir en egen avrunding. En omregning avrunder til hele cent, halvparten bort fra null, så saldoer som summerte seg til null i yen, kan summere seg til én cent over i dollar. Vi lar medlemmet med lavest id ta opp inntil én minste enhet per omregning, og utover det avvises oppgjørsplanen. En plan som stille er feil med 1 dollar, er verre enn en feilmelding, fordi noen ville betalt den.

Yenen har ingen cent, og et regneark gir den to likevel

Den tredje forskjellen dukker opp på hver reise til Japan. Yenen har ingen underenhet: eksponenten i valutastandarden ISO 4217 er null, så ¥1 er det minste beløpet noen kan betale. En middag til ¥10 000 delt på tre i Dimesum blir ¥3 334, ¥3 333 og ¥3 333, som blir ¥10 000 til sammen.

Et regneark formatert for penger viser ¥3 333,33 tre ganger, et tall ingen mynt kan betale. Avrund til hele yen, og det viser ¥3 333 tre ganger, som blir ¥9 999 til sammen. Yenen mister én enhet på samme måte som dollaren mistet en cent.

Vi ødela dette selv før vi rettet det.

Koden som leser et beløp ut av en tekstlinje, gjorde det en gang om til underenheter ved å gange med 100, som er riktig for dollar og euro og feil for yen: en taxi til ¥2 000 ble ¥200 000. Det var en feil på 100 ganger, og ingen avrundingsregel kunne ha fanget den.

Omregningen leser nå hver valutas eksponent fra ISO-tabellen, og et tall finere enn en valutas minste enhet avvises i stedet for å avrundes. Å lese beløp ut av tekst har en lengre historie hos oss, fortalt i hvorfor vi slettet utgiftsparseren vår. Hvordan en reise i yen deles uten de problemene, står i apper for regningsdeling i Japan.

Hva annet et regneark gjør med penger

Excel lagrer tall som binære flyttall, og noen desimaltall har ingen nøyaktig binær form. Microsofts egen merknad om flyttallsaritmetikk i Excel forklarer hvorfor en sum kan komme ut en hårsbredd fra tallet du venter. Som regel skjuler visningen det, og det er nettopp derfor cellen du ser og verdien du legger sammen, kan være forskjellige.

Avrundingsfunksjonene har også sine egne regler. Funksjonen AVRUND i Excel og AVRUND i Google Regneark avrunder hver celle for seg, uten å vite noe om de andre cellene i delingen. Det er hele forskjellen: en deling må avrunde andelene sammen, slik at de fortsatt summerer seg til regningen.

Dimesum lagrer aldri penger som en brøkdel av en enhet. Hvert beløp er et helt antall cent, eller yen, med valutaen skrevet ved siden av, og hver deling bevarer totalen sin nøyaktig. Hvis du likevel heller vil holde gruppens penger i et regneark, er malen vår for felles utgifter en grei start, og regneark eller app for felles utgifter dekker hvor regnearket slutter å være nok.

Slik får du regnearket ditt til å stemme med appen

Du kan gjenskape tallene til Dimesum for hånd. Arbeid i hele cent. Gi hver person de hele centene under den nøyaktige andelen sin, tell centene som er til overs, og del dem ut én om gangen.

1. Gjør regningen om til cent: 100,00 dollar er 10 000.
2. Gi hver person gulvet av den nøyaktige andelen sin: 3 333 hver, 9 999 til sammen.
3. Gi den overskytende centen til personen appen viser at bærer den, og sjekk at andelene blir 10 000 til sammen.
4. Hold ett regneark per valuta, og sett aldri en SUMMER på tvers av to av dem.

Steg tre er det eneste du ikke kan forutsi uten regningens hash, så les det av regningen i stedet. Det lengre regnestykket for enhver deling, med vekter og prosenter, står i kalkulatormetoden for å dele utgifter, og den samme sjekken brukt på en gruppes hele historikk står i slik holder du oversikt over hvem som skylder hvem på en reise.

Hva dette fortsatt ikke kan gjøre

Det kan ikke få regnearket ditt og appen til å være enige på hver regning uten innsats. Et regneark med én avrundingsregel per kolonne vil avvike fra Dimesum med en cent på omtrent hver regning som etterlater en rest, og personen som bærer centen, vil skifte fra regning til regning. Det er regelen som virker.

Det kan heller ikke gjøre en samlet total nøyaktig. En saldo vist i én valuta til en avtalt kurs er veiledende, og oppgjørsplanen bygget ut fra den kan bomme med én minste enhet per omregning. Gjelden som teller, blir i valutaen den ble brukt i, og derfor skjer oppgjøret i en gruppe én valuta om gangen.