No change goes straight into your accounts

The road every change travels

Whether it is a new feature, a bug fix or a one-line text correction, the same four gates apply, and the order never changes. The human approval has two documented exceptions, described under that gate.

1. The change is built and tested in a separate test environment — never in production. The test environment runs against a copy of production data, refreshed every night, in which names, national identity numbers, addresses, account numbers and free text are replaced with synthetic values and the attachments are swapped out. Amounts and the accounting structure are untouched, so changes are tried on data that behaves like the real thing. A pseudonymised copy is still personal data, and is treated as such.
2. The change is put forward as a pull request on GitHub. Normally a human reads through it and approves it before anything goes live. There are two documented exceptions: a critical production fault can be fixed through an emergency route in which a script checks eight gates (never for VAT, payroll, year-end closing, reports or database changes), and the developer can, for a single working session, allow the AI agent to merge the changes itself. Whichever route is taken, every change is permanently traceable to who wrote it, who merged it and when.
3. Over 3,700 unit tests have to pass before a change can be merged, and over 800 integration tests against a real database run on top of them. They guard the accounting logic itself: that every entry balances, that VAT is calculated and settled correctly, that payroll, year-end closing and currency conversion produce the same right answer every time.
4. Only after approval is the change deployed to production — by the same automated procedure every time, with a self-test that verifies the pages actually respond afterwards. If anything is wrong, the previous version keeps running.

The test data is a scrubbed copy

Testing never touches the production database. The test environment gets a scrubbed copy: names, national identity numbers, addresses, account numbers and free text are pseudonymised, OCR text and logs are emptied, attachments are replaced and all keys and credentials are stripped, while amounts and the accounting structure are kept intact — because a change that works on toy data and fails on real-world bookkeeping is exactly the kind of failure we test to catch.

Changes to the database itself follow the same discipline. Every schema change is a numbered, versioned migration that is dry-run against a copy of the database before it is allowed anywhere near production. Your ledger is never converted by hand, and never in the blind.

The system checks itself while you sleep

Tests catch mistakes before a change ships. Continuous checks catch anything that slips past — and they run on a schedule, whether anyone is watching or not.

Openness is part of the design

You should not have to take our word for any of this. Every version of Macct carries a visible version number with its change log, one entry per release, readable from inside the app. The rules we enforce are listed openly, section by section, with the statutory references — and every rate we calculate with carries its source, so you can check us rather than trust us.

The rules, section by section · How the rates are kept current · The legal requirements, one by one

What we do not promise

Questions?

If you are an accountant or an auditor and want more detail about how changes are controlled, write to us — we answer these questions gladly. firmapost@macct.no