> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to Lock and Unlock Accounting Periods

> Lock and unlock accounting periods in DualEntry to protect closed books, manage late-entry exceptions, and maintain an audit trail.

Period locking prevents journal entries from being posted to, edited in, or voided from a closed period. Use it to protect your books after the month-end close is complete and financials have been reviewed.

## How period locking works

When you lock a period, DualEntry rejects any attempt to create or modify a journal entry with an accounting date in that period. This applies to manual entries, entries generated by sub-ledgers ([Accounts Payable](../accounts-payable/index), [Accounts Receivable](../accounts-receivable/index)), integration syncs, and API calls. The lock is enforced at the `date` field on the journal entry header: if the date falls within a locked period, the operation fails with a locked-period error.

Locking is per-company. In a multi-entity setup, you lock each entity's period independently so entities on different close schedules don't block each other. For example, if your US entity closes on Day 3 and your UK entity closes on Day 5, you can lock the US entity's period as soon as its close is complete without waiting for the UK entity to finish. This per-entity approach also means you can unlock a single entity's period for a correction without affecting the lock status of other entities.

## Soft lock vs. hard lock

DualEntry supports two lock levels that give you graduated control over who can still post to a closed period.

| Lock level    | Who can override  | Use case                                                                                                         |
| ------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Soft lock** | Admin, Controller | Period is closed but late adjustments may still be needed. Controllers can post entries without unlocking first. |
| **Hard lock** | Admin only        | Period is final. Used after audit review or board sign-off. Only an admin can unlock.                            |

Start with a soft lock when you finish the [month-end close checklist](../close-management/month-end-close-checklist). Upgrade to a hard lock once the period has passed final review. This two-step approach gives controllers flexibility for last-minute adjustments while still signaling that the period is nominally closed. Most organizations upgrade from soft to hard lock within one to two weeks of the initial close, once all late adjustments are captured and the controller has signed off on final balances.

## Lock and unlock a period

To lock a period:

1. Navigate to **Settings → Period Locking**.
2. Select the company and the period (month/quarter) you want to lock.
3. Choose **Soft Lock** or **Hard Lock**.
4. Confirm the action.

DualEntry locks the period immediately. Any in-flight draft entries dated within the locked period remain as drafts but cannot be posted until the period is unlocked or the entry date is changed to an open period. You can also lock periods programmatically as the final step of an automated close workflow.

To unlock a period:

1. Navigate to **Settings → Period Locking**.
2. Select the locked period.
3. Choose **Unlock**.
4. Enter a reason for unlocking. This field is required and recorded in the audit trail.

After unlocking, the period is fully open for editing. Re-lock it once the correction is posted to restore protection. Only users with the required permission level can unlock: controllers can unlock soft locks, but only admins can unlock hard locks.

<Warning>
  Locking a period does not retroactively void or reverse entries. It only prevents new changes. Review all posted entries and complete your [account reconciliations](../close-management/account-reconciliation) before locking.
</Warning>

## Permissions and audit trail

The following table shows which roles can perform lock and unlock actions:

| Action                | Soft lock         | Hard lock         |
| --------------------- | ----------------- | ----------------- |
| Lock                  | Admin, Controller | Admin, Controller |
| Post during soft lock | Admin, Controller | N/A               |
| Unlock                | Admin, Controller | Admin only        |

Assign these roles thoughtfully. In most organizations, the controller locks periods as part of close, and the admin role is reserved for the CFO or system administrator who can override a hard lock if needed.

Every lock and unlock event is recorded in the audit trail with the following detail:

* **User** - who performed the action.
* **Timestamp** - when it happened.
* **Action** - lock, unlock, or upgrade (soft to hard).
* **Reason** - the required explanation entered during unlock.
* **Period** - the affected company and date range.

Access the audit trail from **Settings → Period Locking → Audit Log** or from the [Close Management](../close-management/index) dashboard. Auditors commonly request this log during year-end fieldwork to confirm that periods were locked timely and that any unlocks were justified. The audit trail is immutable; even admins cannot edit or delete lock/unlock log entries.

<Info>
  Period locking is the final step in the [month-end close checklist](../close-management/month-end-close-checklist). If you lock the period before all checklist tasks are marked complete, DualEntry shows a warning but does not block the lock.
</Info>

## Controlling future-dated transactions

Period locking protects the past. To constrain how far *ahead* users can date transactions, use the organization-level future-dating setting.

Navigate to **Settings → Organization → Transaction Dating**. The **Allow future-dated transactions** control has two parts:

* **Toggle** - turn future dating on or off for the organization. When off, DualEntry rejects any transaction with an accounting date after today.
* **Maximum days ahead** - when future dating is on, set the number of days past today that transactions may be dated. Leave blank for no upper bound.

The limit applies to all transaction types that carry an accounting date: journal entries, bills, invoices, customer and vendor payments, and any sub-ledger entries. It is enforced at save time on manual entries, imports, integration syncs, and API calls, so an out-of-range date fails with a validation error rather than silently posting.

Common values:

| Setting       | Behavior                                                                                      |
| ------------- | --------------------------------------------------------------------------------------------- |
| Off           | No future-dated transactions allowed. Useful for teams that only book actuals.                |
| On, `0` days  | Same-day only. Blocks anything dated after today but allows today's date.                     |
| On, `30` days | Permits routine forward-dating (e.g., recurring invoices, scheduled bills) up to a month out. |
| On, blank     | No cap. Any future date is accepted.                                                          |

The setting is org-wide and applies uniformly to every entity in a multi-entity tenant. Changing the value affects new entries and edits going forward; previously posted future-dated transactions are not re-validated. Only users with the Admin role can change this setting, and every change is written to the audit trail alongside period lock events.

Recurring templates ([recurring bills](../accounts-payable/bill-management#recurring-bills), [recurring invoices](../accounts-receivable/invoicing-and-dunning#recurring-invoices)) that generate drafts beyond the future-dating limit will fail to post those drafts until the limit is raised or the entry date is adjusted. Set the cap wide enough to cover your normal scheduling horizon.

After locking a period, your closed books are protected from accidental or unauthorized changes. For the full close workflow, see [Month-End Close Checklist](../close-management/month-end-close-checklist). To review the entries you've locked in, see [Journal Entries](./journal-entries).