Audit log and change history

Overview

Who changed what and when? For compliance and troubleshooting, a reliable change history matters. Kyvento logs security- and business-relevant events internally in a tamper-proof audit system; of these, the email log is currently viewable in the account itself. This article puts into context what is recorded and which records are available.

What Kyvento logs internally

The system-side audit log is append-only – once written, entries can be neither changed nor deleted. Recorded, among others, are:

• Sign-ins to the system (successful as well as failed)
• Invoice events – from finalization to e-invoice generation
• Customer changes and GDPR anonymizations
• Dunning events
• Configuration changes to account settings

The entries are retained for at least 12 months, and security-critical and privileged operations for 24 months. A self-service view of this complete log is not currently available in the account – it serves system security and investigation in support cases.

What you can view directly

• Email log (Settings → "Email log"): every system email sent, with recipient, subject and time – your proof that an invoice or dunning notice was actually dispatched.
• Document chain: invoices are immutable after finalization; corrections exist only as standalone cancellation documents referencing the original. The "change history" of an invoice can thus always be read in full from the documents themselves.
• Status and timestamps: subscriptions, invoices and payments carry their status history visibly in the detail views – such as start, cancellation date or payment time.

Change protection instead of a change list

For tax-relevant data, Kyvento does not rely on retrospective change logs but prevents changes from the outset: finalized documents are write-protected and secured with a SHA-256 checksum (PDF, financial data, e-invoice). What cannot be changed needs no change history – details in the article GoBD-compliant archiving.

Recommendations for your team

• Work with personal user accounts instead of shared logins – only then do operations remain attributable to individual people (see Inviting team members and managing permissions).
• Assign permissions according to the principle of least privilege – anyone who only needs to read does not need full rights.
• Enable two-factor authentication for all accounts with financial access.

Next steps

• Immutability and checksums in detail – see GoBD-compliant archiving
• Check dispatch proofs – see Sending invoices by email