Slik endres Macct — testet, gjennomgått, godkjent

Veien hver endring må gå

Enten det er en ny funksjon, en feilretting eller en tekstendring på én linje, gjelder de samme fire portene, og rekkefølgen endres aldri. Den menneskelige godkjenningen har to dokumenterte unntak, beskrevet under den porten.

Endringen bygges og testes i et eget testmiljø — aldri i produksjon. Testmiljøet kjører mot en kopi av produksjonsdata, fornyet hver natt, der navn, fødselsnummer, adresser, kontonumre og fritekst er byttet ut med syntetiske verdier og vedleggene erstattet. Beløpene og regnskapsstrukturen er urørt, så endringer prøves på data som oppfører seg som ekte data. En pseudonymisert kopi er fortsatt personopplysninger, og behandles deretter.
Endringen legges fram som en pull request på GitHub. Normalt leser et menneske gjennom og godkjenner før noe settes i drift. To unntak er dokumentert: en kritisk produksjonsfeil kan rettes via et hasteløp der et skript kontrollerer åtte porter (aldri for MVA, lønn, årsoppgjør, rapporter eller databaseendringer), og utvikleren kan i en enkelt arbeidsøkt gi AI-agenten lov til å slå sammen endringene selv. Uansett vei kan hver endring for alltid spores til hvem som skrev den, hvem som slo den sammen og når.
Over 3 700 enhetstester må være grønne før en endring kan slås sammen, og over 800 integrasjonstester mot en ekte database kjøres i tillegg. De vokter selve regnskapslogikken: at hvert bilag balanserer, at MVA beregnes og gjøres opp riktig, at lønn, årsoppgjør og valutaomregning gir samme riktige svar hver gang.
Først etter godkjenning settes endringen i produksjon — med samme automatiserte prosedyre hver gang, og en selvtest som verifiserer at sidene faktisk svarer etterpå. Er noe galt, blir forrige versjon stående.

Testdataene er en vasket kopi

Testing rører aldri produksjonsdatabasen. Testmiljøet får en vasket kopi: navn, fødselsnummer, adresser, kontonumre og fritekst pseudonymiseres, OCR-tekst og logger tømmes, vedlegg byttes ut, og alle nøkler og tilganger fjernes — mens beløp og regnskapsstruktur beholdes intakt — for en endring som virker på lekedata og feiler på virkelig bokføring, er akkurat den typen feil vi tester for å fange.

Endringer i selve databasen følger samme disiplin. Hver skjemaendring er en nummerert, versjonert migrasjon som tørrkjøres mot en kopi av databasen før den slipper i nærheten av produksjon. Hovedboken din konverteres aldri for hånd, og aldri i blinde.

Systemet kontrollerer seg selv mens du sover

Tester fanger feil før en endring slippes. Kontinuerlige kontroller fanger det som likevel skulle slippe forbi — og de kjører på fast tid, enten noen følger med eller ikke.

Hver natt

Avstemminger

Kunde- og leverandørsaldoer avstemmes mot hovedboken, og hvert lagret valutabeløp etterprøves mot kursen det ble bokført med. Et avvik utløser alarm samme natt — ikke ved årsoppgjøret.

Daglig og ukentlig

Sikkerhetskopier som faktisk gjenopprettes

Sikkerhetskopier tas daglig og lagres eksternt i et annet datasenter. Og fordi en utestet sikkerhetskopi bare er et håp, gjennomføres full gjenoppretting fra dem på fast plan — en kopi teller ikke før den har vært vekket til live.

Hver uke

Et helt regnskapsløp

En kanari-kjøring oppretter et ferskt selskap og tar det gjennom hele løpet — inngående balanse, fakturaer, kjøp, lønn, rapporter, årsavslutning — og kryssjekker hvert resultat mot hovedboken før alt rigges ned igjen.

Åpenhet er en del av konstruksjonen

Du skal ikke måtte ta vårt ord for noe av dette. Hver versjon av Macct bærer et synlig versjonsnummer med sin endringslogg, én linje per utgivelse, lesbar inne i appen. Reglene vi håndhever ligger åpent, paragraf for paragraf, med lovhenvisningene — og hver sats vi regner med bærer kilden sin, så du kan kontrollere oss i stedet for å stole på oss.

Reglene, paragraf for paragraf · Slik holdes satsene oppdatert · Lovkravene, ett for ett

Hva vi ikke lover

Vi kommer ikke til å fortelle deg at feil ikke kan skje. Programvare bygges av mennesker, og mennesker gjør feil — også vi. Det hele denne siden beskriver, er maskineriet som finnes nettopp derfor: feil gjøres i testmiljøet i stedet for i regnskapet ditt, fanges av en gjennomgang eller en test i stedet for av deg, og når én likevel slipper gjennom, finnes den av en nattlig kontroll, spores til den eksakte endringen som forårsaket den, og rulles tilbake. Det er løftet — ikke feilfrihet, men kort avstand mellom en feil og oppdagelsen av den.

Ingen endring går rett inn i regnskapet ditt