The Audit Log

The audit log records every meaningful change made in your tenant — bookings edited, customers merged, refunds issued, settings changed, users created, roles modified. It's the answer to "who changed this and when?" and the place to look when something doesn't match what you remember. This guide covers reading the log, filtering it, and the practical questions it answers.

Opening the audit log

Go to Reports → Audit Log. You'll see a chronological list of changes, most recent first.

What's recorded

Each entry has:

• When — timestamp in your branch's timezone.
• Who — the user who made the change.
• What — the action (e.g. "Updated booking #123", "Refunded $50 against booking #456", "Merged customer A into customer B").
• Before / after — for value changes, the previous and new values side-by-side.
• Context — the entity affected (booking, customer, room, voucher, setting, user) with a link through to it.

Filtering

The filter panel at the top lets you narrow down:

• Date range — defaults to the last 30 days.
• User — "show me everything Sarah did".
• Action type — bookings only, refunds only, settings changes only, etc.
• Entity — everything related to a specific booking, customer, or room.

Common questions and how to answer them

"Who refunded this booking?"

Filter by booking ID and action type "refund". The entry shows the user, the amount, the method, and the reason note.

"This booking's price doesn't match what I remember — what changed?"

Filter by booking ID. Look for "Updated booking" entries with player counts or pricing in the before/after diff.

"Why did this customer disappear?"

Two likely causes recorded in the log: deactivation ("Set Account active = off") or merging ("Merged customer X into customer Y"). Filter by the customer's record.

"Did someone change the tax rate without telling me?"

Filter by entity = "Branch settings". Settings changes show the field, before, and after.

"A staff member says they didn't make this booking — did someone else?"

Filter by the booking. The "Created" entry shows the user. Cross-reference with the auth log (see The Auth Log) to confirm that user was actually logged in at that time.

Retention

Audit log entries are kept for a long retention window (typically 12 months on standard plans). Older entries are archived — ask support if you need to retrieve audit data older than your retention.

Exporting

The audit log has an Export button that downloads the current filtered view as CSV. Use this for:

• Compliance reporting — some industries require periodic audit-log exports.
• Investigations where you want to slice the data in a spreadsheet.
• Sharing with an auditor or accountant who doesn't have Booking Phoenix access.

What's not in the audit log

Worth knowing for completeness:

• Read access — the log records changes, not "who looked at what". For login activity see The Auth Log.
• Customer-facing actions — widget bookings show as "Created by [system]" rather than tied to a staff user, since the customer made them.
• Stripe-side events — chargebacks, disputes, payouts. Those live in your Stripe dashboard.
• Background system actions — automatic emails, scheduled reports, cron jobs. They're logged separately if you need them — ask support.

Practical advice

• Check the audit log before assigning blame. "Who refunded this?" often turns out to be "I refunded this last Tuesday and forgot." The log resolves disputes quickly.
• Use it for staff training. If a process broke (e.g. a booking was edited in a way that lost a payment), walk through the audit trail with the team to show how to do it right next time.
• Pair with the auth log for security. The audit log says "Sarah did X" but the auth log says "Sarah logged in from this IP at this time". Together they reconstruct what happened during a security incident.