Audit and accountability: every change has a who, a when, and a why
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?
Is anything ever physically deleted?
Can franchisees see when head office acted in their site?
More Platform capabilities
Data protection: masked fields, encrypted secrets, and GDPR by design
How the platform protects personal data: field-level masking enforced in the API, encrypted payment details, soft traceable deletion, UK and EU Azure hosting, and federated sign-in.
Data classification: sensitivity tagged in code, enforced by tests
How the platform classifies personal data: sensitivity tiers and handling overlays on every sensitive field, native SQL sensitivity labels, blob index tags, and a coverage test that fails the build if a column is left unclassified.
Retention and erasure: storage limits enforced, not remembered
How the platform enforces storage limitation: retention rules per data class and jurisdiction, a scheduled job that anonymises or deletes on time, legal holds that override the schedule, and coverage enforced by a build-time test.
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