Skip to content
Platform capability

Audit and accountability: every change has a who, a when, and a why

Updated 4 min read

Audit is a platform foundation, not a module feature. Every entity carries its creation and modification audit events (who, when); charges, payments, refunds, and mandates keep full event histories so financial state transitions are preserved, not overwritten; deletion is soft and traceable; and head-office actions inside a franchisee’s site are explicitly flagged. Every change has evidence.

What does the capability do?

It makes “what happened, who did it, and when?” a question the system answers from data, across every module.

  • Audit events on everything. Every record links to the audit events that created and last modified it, carrying the actor and timestamp. There is no class of change that happens silently.
  • Event-sourced financial history. Charges, payments, refunds, and mandates do not just have a status; they have an event history. Each transition (submitted, collected, failed, refunded, cancelled) is recorded with its code and reason, so the current state is always backed by the trail that produced it.
  • Soft deletion. Records are marked deleted rather than destroyed, and reads exclude them. History survives, disputes can be investigated, and recovery is possible.
  • Interventions flagged. Where a head-office user acts inside a franchisee’s site, the audit trail records it as an explicit intervention, visible to both sides. See scoped permissions for the access model this sits on.
  • Batch lineage. Financial events link to the request or notification batch they arrived in, so a payment’s story can be followed from batch to bank and back.

Why event history beats a status field

A status field tells you where a record is; an event history tells you how it got there. When a member disputes a charge, when finance reconciles a batch, or when an auditor samples a refund, the answer is in the record itself rather than in a developer’s database query or someone’s memory. Systems that overwrite state cannot answer these questions honestly, and the cost lands exactly when the stakes are highest.

Why it matters

Regulated operators, franchise networks, and any organisation handling member money need to demonstrate control, not just assert it. Per-entity audit events, event-sourced money movements, soft deletion, and flagged interventions mean the evidence exists by construction. It is the same principle across the whole platform: financial state changes are events with evidence, and accountability is designed in rather than bolted on.

Frequently asked questions

What does the audit trail record?
Every entity carries its creation and modification audit events, recording who made the change and when. Financial records go further: charges, payments, refunds, and mandates each keep an event history, so every state transition is preserved with its reason rather than overwritten.
Is anything ever physically deleted?
No. Deletion is soft: records are marked deleted and excluded from reads, but the history remains traceable. Combined with the audit events, this means questions about past state can always be answered from data.
Can franchisees see when head office acted in their site?
Yes. Where a head-office user operates inside a franchisee's site, the action is explicitly flagged as an intervention in the audit trail, and franchisees can filter their own audit log to see when and what head office touched. Transparency runs in both directions.
See it live

See this working in a demo

Book a consultation and we will demonstrate this capability on the Platform accelerator, against your own scenarios.

Book a demo