How Macct changes — tested, reviewed, approved

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. None of them can be skipped, and the order never changes.

The change is built and tested in a separate test environment — never in production. The test environment runs against an anonymised copy of production data, refreshed every night, so changes are tried on data that behaves like the real thing without being the real thing.
The change is put forward as a pull request on GitHub. A human reads through it and approves it before anything goes live — no change reaches production without that review, and every change is permanently traceable to who wrote it, who approved it and when.
Over 1,500 automated tests have to pass. 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.
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.

Your data is never the test data

Testing never touches production data. The test environment gets a scrubbed copy: contact details are anonymised and all keys and credentials are stripped, while the accounting structure is 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.

Every night

Reconciliations

Customer and supplier balances are reconciled against the general ledger, and every stored currency amount is re-checked against the rate it was booked with. A discrepancy raises an alarm the same night — not at year-end.

Daily and weekly

Backups that are actually restored

Backups are taken daily and stored off-site in a second data centre. And because an untested backup is only a hope, a full restore is performed from them on a schedule — a backup does not count until it has been brought back to life.

Every week

A full accounting life cycle

A canary run creates a fresh company and takes it through the whole journey — opening balance, invoices, purchases, payroll, reports, year-end — and cross-checks every result against the ledger before tearing it all down again.

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

We will not tell you that mistakes cannot happen. Software is built by people, and people make mistakes — including us. What this whole page describes is the machinery that exists because of that fact: mistakes are made in the test environment instead of in your accounts, caught by a review or a test instead of by you, and when one does slip through, it is found by a nightly check, traced to the exact change that caused it, and rolled back. That is the promise — not perfection, but a short distance between a mistake and its discovery.

No change goes straight into your accounts