Audit

Audit in the sidebar shows the company’s history: who did what, when, and from where. The owner and accountant can see it. A custom role does not get it, whatever its rights, because it sums up every agenda.

The database itself writes every change in the data, in the same transaction as the change. So it does not matter whether the change came from the app, the API, MCP, an import, or a background job. An entry cannot be changed or deleted. The only exception is deleting the whole company, which removes its audit too: where an accounting record was corrected by rewriting it, the audit is the proof of the correction (Accounting Act § 35(3)), and the law may require you to keep it with the accounting records (§ 31). So download the whole-company export before deleting; the audit is in it.

What is in it

One entry is one action. Issuing an invoice is one line, even if it changed fourteen rows in the database. When an action sets up many things at once, such as a first invoice founding the chart of accounts, they fold into one line that opens on request. Open it to see:

• Who: a person with their name and e-mail at that moment, an API key, a connected app, or which background job. When a person stands behind a key, a connection, or a job they started, they are shown too. A change with nobody known behind it shows as “Nobody known”.
• What: the agenda, the document or contact, and every field that changed, before and after.
• From where: the app, the public API, MCP, a background job, an import, a public link, or a webhook, with the IP address and browser.

Besides changes in the data, it records things that change nothing but should show: sign-ins and failed sign-ins, downloads of a whole-company export, payroll documents and bulk files, use of the send permission through the API, and downloads of the audit itself. Ordinary reading and browsing is not recorded.

Search and export

Filter by person or key, agenda, action, place, and period, or search for something like an invoice number. CSV and XLSX download what you see, up to 20,000 entries. The file sums up each entry on one line; individual fields are in the app and the API. The whole audit, with every field before and after, is in the whole-company export under Settings > Import and export, in the files data/audit_transactions.json, data/audit_changes.json and data/audit_seals.json.

A document’s history

On invoices and other documents, contacts, employees, and stock documents you will find a History button; for cash documents it is in the row’s menu. It shows the record’s whole trail, including its lines and payments. Anyone who may read that record can see it, only without IP addresses.

What the audit does not keep

For secrets, the audit records only that they changed, never the value: passwords, tokens, certificates, keys, and credentials for banks and authorities, and parts of them too, such as the start of an API key or a carrier login. A webhook’s address keeps only its server, and a message in a connected mailbox only that it arrived. Full birth numbers and bank accounts are not in it. It shows the same mask as the rest of the app, for example 850101/**** and ****1234/0100.

Payroll data follows the same rule. For employees and pay, the audit says who changed which field and when, but not the amount, the address, or health details. Only what names the record stays: name, personal number, status, period.

Verifying integrity

Entries are regularly sealed into a chain of hashes, separately for each company. Verify integrity recomputes the chain from the stored data and says whether anyone changed entries already sealed. The result stays on the page and is itself an entry. You can note down the hash at the end of the chain and compare it later: if someone with direct access to the database rewrote the whole chain, that is the only way to tell.

Through the API and MCP

All of it is available through the API and MCP: GET /v1/audit/entries, GET /v1/audit/entries/{id}, GET /v1/audit/objects/{id}/history, GET /v1/audit/chain, and POST /v1/audit/verify. The locale parameter picks the language. A key needs the role of owner or accountant; a record’s history needs the right to read that record. The earlier GET /v1/audit-events stays.