> ## 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

> Steps to lock and unlock accounting periods in DualEntry to protect closed books, handle late-entry exceptions, and preserve a full audit trail for closes.

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.

## The four lock sections

Locking is not a single switch. Each company carries a locked-through date for four separate sections of the ledger, and you set them independently:

| Section                   | Covers                                                                     |
| ------------------------- | -------------------------------------------------------------------------- |
| **A/R Transactions**      | Receivable-side records: invoices, customer payments, credits, and refunds |
| **A/P Transactions**      | Payable-side records: bills, vendor payments, credits, and refunds         |
| **Other GL Transactions** | Journal entries and other general ledger activity                          |
| **Non GL Transactions**   | Records that do not post to the ledger                                     |

Each section stores a date rather than a state, so locking A/R through 03/31/2026 closes every receivable record dated on or before that day while leaving April open.

This split is what lets you close a sub-ledger before the general ledger. A typical close locks A/R and A/P first, once the sub-ledgers are reconciled, then locks Other GL after the final journal entries are posted.

DualEntry enforces that ordering. Other GL cannot be locked until A/P and A/R are locked, and it must be unlocked before you can unlock A/R or A/P, which prevents the state where the ledger is sealed but the sub-ledgers feeding it are not.

**Lock All** and **Unlock All** apply every section at once when you do not need the staged approach.

## Lock and unlock a period

To lock a period:

1. Navigate to **Close Management → Close Workflows → Period Locking**.
2. Choose the company, or work across **All companies**.
3. Choose **Manage Period Locking**, then set the date you want each section locked through.
4. Choose **Lock A/R**, **Lock A/P**, **Lock Other GL**, **Lock Non GL**, or **Lock All**, and confirm.

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 **Close Management → Close Workflows → Period Locking**.
2. Choose the company whose period you want to reopen.
3. Choose the section to unlock, or **Unlock All**.

Unlock Other GL before unlocking A/R or A/P; DualEntry blocks the reverse order. After unlocking, the period is open for editing again, so re-lock it once the correction is posted.

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

## Permissions and audit trail

Locking and unlocking are governed by the period lock permission on a user's role, and the page itself is gated behind the period locking subscription. Someone without that permission does not see the Period Locking entry under Close Workflows at all, which is the usual explanation when a user reports the page missing rather than empty.

There is no override that lets a privileged user post into a locked section. A locked period is locked for everyone, including admins, so the only route to a late adjustment is to unlock, post, and lock again. That is deliberate: it leaves a record of the reopening rather than a silent exception.

Assign the permission narrowly. In most organizations the controller locks periods as part of close, and the ability to unlock is kept with whoever is accountable for the reported numbers.

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 or unlock, per section.
* **Reason**: the required explanation entered during unlock.
* **Period**: the affected company and date range.

Access the audit trail from **Settings → Audit Trail** or from the [Close Management](./index) dashboard. Auditors commonly request this log during quarterly, interim, or year-end reviews and audits 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](./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](./month-end-close-checklist). To review the entries you've locked in, see [Journal Entries](../general-ledger/journal-entries).