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 to you.

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"