Accounting Lock Dates: What Happens to a Late Document?

A closed accounting period needs more than a disabled Edit button. Before connecting an order or document app to your accounts, agree which accounting dates are protected, what happens to a late document and who may authorise an exception. A document arriving today does not itself decide which period it belongs in.

This guide concerns software requirements. Your accountant must decide the appropriate dates, permitted adjustments and closing procedure. A product setting is not proof that a business meets local accounting or tax obligations.

Specify the boundary in accounting dates

Ask for the actual company, lock type and inclusive cutoff date to be visible to the people preparing entries. Distinguish the accounting date from a document's original date and the time the app received it. Do not overwrite the original document merely to fit an open period.

Odoo 19's year-end documentation describes a Lock Everything date that prevents modification of posted journal entries with an accounting date on or before that date. It also prevents posting new entries into that range. In that situation, the documented system automatically sets the accounting date to the day after the lock date.

That last behaviour matters when reviewing an integration. A successful submission does not necessarily mean the accounting system retained the date your app requested. Require the integration to show the accounting date actually accepted, not just the value it sent. If your intended workflow instead stops for review, specify that explicitly and check what the connected product supports.

Give late documents a reviewable path

Consider a hypothetical supplier document received after a period has been locked. Staff should see the original document date, requested accounting date, current restriction and actual result returned by the accounting system. The accountant decides whether the supported open-period treatment is appropriate or an authorised exception is needed.

Keep a refused or unresolved submission identifiable. Do not let an empty local accounting reference look like a completed posting. If a response is uncertain, reconcile the original submission before trying again; a new date is not a reason to create another copy of the same business document.

These are integration requirements, not claims that the cited page specifies a complete import or duplicate-prevention mechanism.

Make exceptions narrower than ordinary access

Odoo documents exceptions created by users with Administrator access to Accounting. The exception can apply to the current user or everyone, with a chosen duration; a reason can be added, and the information is logged on the company record. Do not infer that every user with ordinary editing permission may reopen the period.

For a commissioned workflow, agree the authorised person, affected company, audience, duration and reason before allowing an exception. A personal exception and a company-wide opening have different consequences. Make their scope visible, and demonstrate what happens after a time-limited exception expires. Requiring a reason in your own workflow is an additional requirement; the source describes that field as optional.

Separate the decision to permit a correction from the correction itself. Record the resulting accounting entry or error, rather than treating approval of an exception as evidence that the intended work succeeded.

Do not offer an undo promise for every lock

The same documentation distinguishes an ordinary lock, removable through an everyone/forever exception, from an irreversible Hard Lock. Never give both a generic Reopen button or promise that an administrator can always undo the choice.

Have the accountant and implementer review the actual configuration before a permanent restriction is set. Test the proposed confirmation in an isolated environment; do not exercise irreversible controls on live books merely to prove the interface works. This article does not recommend when any jurisdiction requires a hard lock.

Demonstrate the boundary, not just the button

Use synthetic records to test an accounting date before the cutoff, exactly on it and after it. Include a late document, an automatically changed accounting date, an unauthorised exception attempt and a permitted temporary exception followed by expiry. Check the company and actual acting user throughout.

Add these outcomes to the acceptance criteria for your accounting integration. The useful result is a traceable decision about when an entry may be posted or changed, not a reassuring Closed label that hides how a late document was handled.