Completing a bank reconciliation is one thing. Protecting that completed reconciliation from being quietly undone is another. In practice, one of the most common causes of reconciliation chaos — "the numbers were fine last month and now they're not" — is a transaction that was edited, re-coded, or deleted after the period was signed off.
ReconLink's period locking feature exists specifically to prevent this. Once a period is locked, the transactions within it become read-only. No edits, no re-coding, no deletions — without a deliberate unlock workflow that creates an audit record.
This post covers why locking matters, the step-by-step workflow inside ReconLink, how to handle disputes and re-opens, and what the audit trail records.
Why Retroactive Edits Are a Real Problem
In a busy practice, multiple team members may access the same client file. A junior bookkeeper tidying up transaction descriptions, a partner adjusting an account code, or even a client with portal access reviewing their records — any of these people can inadvertently change a transaction in a period that's already been reconciled.
The consequences compound. A re-coded transaction changes the account balance, which changes the reconciliation balance, which may no longer tie to the bank statement. The next time the bookkeeper opens the file, the prior period shows an unexplained variance. Time is spent investigating something that should have been settled weeks ago.
For BAS lodgement purposes, this is more than inconvenient. If a GST code is changed on a transaction in a prior BAS period after the BAS has already been lodged, the BAS is now wrong. The error may need to be corrected via a GST adjustment in a subsequent period — creating a compliance tail that could have been avoided entirely.
Period locking eliminates this class of problem.
Locking a Period in ReconLink: Step-by-Step
Locking is available once a reconciliation has been completed and reviewed. The workflow is:
-
Complete the reconciliation. Open the reconciliation for the period and confirm the closing balance matches the bank statement. All transactions must be coded — ReconLink will not allow locking if any transactions in the period remain uncoded or have an "unresolved" flag.
-
Run the pre-lock checklist. ReconLink presents a summary screen showing: total debits and credits, any outstanding items flagged during the period, the GST reconciliation (total GST on coded transactions vs. BAS amounts for the period), and any transactions manually overridden from auto-coding suggestions. Review and confirm each item.
-
Select "Lock Period". This is available from the reconciliation actions menu. You'll be prompted to confirm the lock date (the end date of the period being locked) and enter an optional note — for example, "Q1 FY27 BAS lodged 28 Oct 2026."
-
Notify the client (optional). If the client has portal access, ReconLink can send an automated notification that their reconciliation for the period is complete and locked. This sets expectations: they can view transactions but cannot edit them.
Once locked, the period displays a padlock icon in the reconciliation list. Any attempt to edit a transaction in that period — from within the practice dashboard or the client portal — will return a clear message: "This transaction is in a locked period. Contact your accountant to request a re-open."
What Happens When a Client Disputes a Locked Period
Disputes happen. A client reviews their portal, sees a transaction coded to "Travel" that they believe should be "Entertainment" (with different GST implications), and contacts the practice.
The correct process in ReconLink is:
-
Review the dispute. Open the locked period and examine the transaction in question. ReconLink shows the full coding history: the original auto-coding suggestion, any manual override, and the user who made the final coding decision.
-
Determine the impact. If the recoding would change the GST amount, the BAS for that period may need to be amended. Assess whether the difference is material enough to warrant a BAS amendment or whether a GST adjustment in the next BAS period is more appropriate.
-
Re-open the period if necessary. Navigate to the locked reconciliation and select "Re-open Period." You'll be required to enter a reason — this is mandatory and creates an audit log entry. The reason is visible to all practice users with access to the file and cannot be edited after entry.
-
Make the correction, re-reconcile, and re-lock. After adjusting the transaction, the reconciliation needs to be re-run. ReconLink will highlight that the balance has changed from the prior locked state and will require you to confirm the new closing balance before re-locking.
The Audit Trail: What ReconLink Records
Every lock and unlock action is recorded in the client's audit log, accessible from the client settings panel. Each entry includes:
- The action (Lock or Re-open)
- The period affected
- The practice user who performed the action
- The timestamp (in AEST/AEDT)
- The reason provided (for re-opens)
This audit trail is not editable. It persists even if the user who performed the action is later removed from the practice. For practices that deal with client disputes, ATO queries, or internal reviews, this log provides a verifiable record of when books were settled and what, if anything, changed afterward.
Building Period Locking Into Your Practice Workflow
The most effective approach is to make period locking a routine step — not an afterthought. Build it into your end-of-period checklist:
- BAS period ends → code all transactions → reconcile → lock period → lodge BAS → note the lock date
- Year-end → reconcile all periods → lock all periods → finalise tax return
Some practices lock periods monthly even for quarterly BAS clients, preventing any mid-quarter edits from contaminating prior weeks. This adds a small amount of overhead but significantly reduces the risk of unexplained variances accumulating.
Period locking is one of those features that clients don't notice — until the day it saves them from a significant problem. That's exactly how it should work.