BreezyCorp Handbook

Appearance

Recover from a wrong action using the audit log ​

Who does this: Any staff role — most recoveries need a Payroll Lead or Senior Accountant to authorise the corrective step When: You clicked something on the wrong cycle, the wrong issue, the wrong contact, or the wrong journal entry Result: The mistake is reversed by a forward corrective action, fully audited, with the original mistake still on the record.

The platform deliberately does not have a generic Undo. The audit log is the source of truth for what actually happened, and edits to the audit log are not possible by anyone. To reverse a mistake, you perform a corrective forward action — a new event that puts the system back where it should be. The old event stays in history; the new event explains the recovery.

This page walks through the four mistakes that come up most often.

TIP

Before any recovery: open Activity log (sidebar → Activity log), filter by client / actor / date and find the offending event. Capture the row before you fix anything — you'll want it when you write the audit-log note for the corrective action.

Mistake 1 — You overrode a blocking issue you shouldn't have ​

Symptom: The Activity log shows issue.overridden against a cycle with a comment that doesn't match what you intended (or an override on the wrong cycle entirely).

Why it matters: An override removes a blocking validation rule. If the cycle proceeds to Generate export in this state, the export will be generated with data the rule was meant to catch.

Recovery:

  1. Find the offending event in the Activity log. Note the cycle and the issue.
  2. Open the cycle. Look at its current status.
  3. If the cycle is still pre-export (status is READY_FOR_EXPORT, ACTION_REQUIRED, or earlier):
    • Open the issue from the cycle's Issues tab.
    • Click Reopen issue. The issue returns to Open and the export button greys back out until the issue is resolved properly.
    • The audit log records issue.reopened with your note explaining the recovery.
  4. If you've already clicked Generate export under the bad override:
    • Stop. Do not upload the output back to the client.
    • Escalate to a Payroll Lead. They have authority to invalidate the generated export and reopen the cycle to READY_FOR_EXPORT.
    • The audit log records cycle.export_invalidated and cycle.reopened.
  5. Once the issue is reopened, resolve it the right way (Resolve a blocking issue) and re-run the export when ready.

WARNING

If the bad export was already sent to the client for approval (approval.requested exists in the audit log), retract it before doing anything else: open the cycle, click Retract approval request. The client's magic link is invalidated immediately and they'll see "This approval has been withdrawn" if they try to open it.

Mistake 2 — You finalised the wrong cycle ​

Symptom: The Activity log shows cycle.closed on a cycle for the wrong month, or for a cycle that still had outstanding revisions.

Why it matters: A closed cycle is locked from further edits. The retention clock starts ticking.

Recovery:

  1. Confirm the mistake from the Activity log — capture the cycle.closed event with its timestamp and your actor identity.
  2. Open the cycle. The status badge shows CLOSED.
  3. Within 7 days of close: a Payroll Lead can click Reopen cycle on the closed cycle's detail page. The cycle returns to its prior status (typically APPROVED), the retention timer resets, and the audit log records cycle.reopened with the Lead's note.
  4. After 7 days: the in-app reopen path is closed. This is rare, but if you hit it, escalate following your firm's incident process. The platform team can manually reopen via a runbook step, but it requires written authorisation. See your incident runbook for the exact path.
  5. After reopening, complete or correct whatever was wrong, then finalise the close again — properly this time.

NOTE

The 7-day window is deliberately tight. Closing a cycle is a strong commitment to the client and to your firm's quality bar; the longer the window, the easier it is to drift. If you find your team frequently bumping against the 7-day limit, that's a process signal — the close step is firing too early.

Mistake 3 — You deactivated the wrong contact or staff user ​

Symptom: A client contact or staff member can suddenly no longer access the platform. Activity log shows contact.deactivated or staff_user.deactivated against the wrong row.

Why it matters:

  • For client contacts: any magic links the contact already received (cycle invitations, approval requests, bookkeeping portal links) are invalidated immediately. Even if you reactivate, those specific links stay dead.
  • For staff users: the user's active sessions are killed on next request. They lose dashboard access entirely until reactivated.

Recovery:

  1. For a client contact: open the client → Contacts tab → find the row → click Reactivate. The contact is back. But:
    • Their old magic links remain dead. If they had a live cycle invitation when you deactivated them, you need to re-trigger the invite. From the cycle, click Resend invitation (which mints a fresh 48-hour link) — see Verify an email was sent to confirm it landed.
    • For an in-flight approval round, click Request approval again on the cycle to re-issue the approval magic link.
  2. For a staff user: open Team → find the row → click into them → Activate on the profile card. They can sign in immediately with their existing password and MFA. Their old sessions are not restored — they sign in fresh.
  3. The Activity log records contact.reactivated or staff_user.reactivated against you, completing the trail.

TIP

If you can't tell whether someone was deactivated by accident or on purpose, look at who did it: filter the Activity log by Actor — Payroll team and find the matching *.deactivated event. The actor name and the timestamp are usually enough to figure out the intent (or to ask the right person before reactivating).

Mistake 4 — You approved a journal entry that should have been rejected ​

Symptom: The Activity log shows journal_entry.approved on a line item that's wrong (wrong account, wrong amount, wrong vendor classification).

Why it matters: An approved entry counts toward the batch's approved tally. Once every entry in the batch is approved or rejected, the batch can be advanced to APPROVED status — at which point the upload file becomes generatable.

Recovery depends on the batch status:

  1. Batch is still DRAFT:
    • Open the batch, click into the offending entry.
    • Click Reopen entry (returns the entry to DRAFT so you can fix it).
    • Reject it properly, or correct the classification and re-approve.
    • Audit log records journal_entry.reopened then your corrective action.
  2. Batch has advanced to APPROVED:
    • You can no longer reopen the individual entry — the batch transition locks the line items.
    • Escalate to a Senior Accountant. They have the Override journal flag permission and can move the batch back to DRAFT for correction. The audit log records journal_batch.demoted against the Senior Accountant.
    • Then proceed as in (1).
  3. Upload file has already been generated and sent to the client's accounting platform (Xero / QuickBooks / Zoho / Tally):
    • The platform will not delete the upload file — it's already left the building. The corrective path is a reversing entry captured as a fresh journal entry in a new batch (debit and credit flipped, with a reference to the original entry's ID).
    • Create the reversing entry from Journal batches → (month) → New entry, link it to the original via the Reverses field, and put it through the normal approval flow.
    • Do not edit the original — the audit log relies on its immutability. The reversing entry is what makes the books correct again.

NOTE

The platform's journal model is append-only by design. There is no delete entry button anywhere — corrections always come through reversing entries. This matches Singapore accountancy practice (an auditor wants to see the wrong entry and the reversal, not a quietly-edited version).

How to know the recovery worked ​

In all four cases, the Activity log is the proof:

  • The original mistake event is still there with its original timestamp.
  • A new event records your corrective action — issue.reopened, cycle.reopened, contact.reactivated, journal_entry.reopened, etc.
  • The platform's status (cycle / batch / contact) reflects the corrected state.

When the recovery involves the client (resending an invitation, retracting an approval), confirm by verifying the email went out and capturing the outbox row.

When in doubt — capture, escalate, recover ​

If the corrective path isn't obvious from the four cases above:

  1. Capture the offending audit event (screenshot or print from the Activity log).
  2. Stop touching the affected entity — don't try to fix it with one more click on top.
  3. Escalate to the most senior person with the relevant role (Payroll Lead for payroll, Senior Accountant for bookkeeping, Platform Admin for staff/contact administration).
  4. Once they've decided the corrective path, execute it with a clear note in the audit log explaining what happened and what the recovery was. Future-you (and your auditor) will thank you.

Internal use only — BreezyCorp