Error fixMicrosoft Dynamics 365 Business CentralGeneral Ledger / User Setup

Business Central: "Posting Date is not within your range of allowed posting dates"

Error
Posting Date is not within your range of allowed posting dates Business Central

Also searched as

  • business central posting date not within range of allowed posting dates
  • Allow Posting From Allow Posting To business central user setup
  • business central cannot post wrong work date

Short answer

Business Central blocks the posting because the document's Posting Date falls outside the Allow Posting From / Allow Posting To window. The window is read from the user's own row in User Setup first, and from General Ledger Setup only when the user row is empty. Fix the date on the document, or widen the right window, or change your work date if the wrong default was applied.

Applies to: Business Central online and on-premises, all recent versions (the same check exists back to Dynamics NAV)

How to resolve it

  1. 1Read the error carefully and note the Posting Date on the document header (sales, purchase, journal line, or the date typed in the Post dialog).
  2. 2Check why that date was used. Posting Date defaults from the Work Date, which is set in My Settings. If you logged in and the work date is old, correct it there first.
  3. 3Search for User Setup and open your own row. Look at Allow Posting From and Allow Posting To. If either is filled, those override General Ledger Setup for you.
  4. 4Search for General Ledger Setup, open the General fast tab, and read Allow Posting From and Allow Posting To. These apply to every user who has no value in User Setup.
  5. 5Decide whether the date is wrong or the window is wrong. For a legitimate late posting, a controller should widen the window (or blank it for a named user) in User Setup rather than opening it for everybody.
  6. 6For deferrals, check the separate Allow Deferral Posting From and Allow Deferral Posting To fields in the same two places.
  7. 7Retry the post. If the same document also hits an inventory period or accounting period block, resolve those separately as described below.
  8. 8Close the window again after the late postings are done, and note who changed it and when.

How the check works

Business Central validates the posting date during posting, not while you type it. The posting codeunits compare the date to the allowed range. The range is resolved per user: if the user's User Setup row has a value in Allow Posting From or Allow Posting To, that value is used; if the field is blank there, the value from General Ledger Setup is used. A blank value in both places means no limit on that side.

That is why one person can post into last month while a colleague cannot: their User Setup rows differ. It is also why the error appears right after month end. Finance sets General Ledger Setup to the first day of the new period, and anyone who still has an older or stricter date in User Setup keeps the stricter limit.

The error is about the document date being outside a window you are allowed to use. It is not a permission error. Permissions are a different check and produce a different message, so do not start by editing permission sets.

Work date versus posting date

A very common cause is not a locked window at all. The Work Date in My Settings is stored per user and persists between sessions. If it was set to a past date for a backdated entry and never reset, every new document picks up that old date as its Posting Date and then trips the range check, or worse, posts silently into the wrong period when the window is open.

Reset it under Settings, then My Settings, then Work Date. For API and Excel-based imports the date comes from the payload, so check the postingDate or documentDate values in the file instead. Scheduled jobs such as recurring general journals use the date from the batch's posting date formula, so check the formula when a job queue entry fails with this message.

On-premises check of effective limits (replace CRONUS with your company name):
SELECT [User ID], [Allow Posting From], [Allow Posting To]
FROM [CRONUS$User Setup]
WHERE [Allow Posting From] <> '1753-01-01' OR [Allow Posting To] <> '1753-01-01'

SELECT [Allow Posting From], [Allow Posting To]
FROM [CRONUS$General Ledger Setup]

Related blocks that look similar

Inventory Periods are a second gate for anything that touches item ledger entries. If the inventory period for that date is closed, posting fails with a message about the inventory period instead. Reopen it from Inventory Periods only if finance agrees, because cost adjustments after closure change values that were already reported.

Accounting Periods can be closed and locked too. The Date Locked flag and a closed fiscal year stop postings into that year, and closing a year is not meant to be reversed casually. Treat those as accounting decisions, not a setup tweak.

VAT and deferral dates have their own limits. In newer versions an Allow VAT Date From/To pair exists alongside the posting date pair, so a document can pass the posting date check and fail on the VAT date.

Controlling the window safely

Do not leave both windows wide open permanently. Use General Ledger Setup for the current open period and give only the controller and month-end team broader limits in User Setup. Record changes, because the fields are plain setup values and are easy to forget open.

If you extend Business Central with AL, you can use the same checks in your own posting routines instead of inventing a second rule. The standard checks live in the posting-date validation of the posting codeunits, so a custom report or import that posts through those codeunits gets the behaviour automatically.

Common pitfalls

  • !Widening General Ledger Setup for everyone to fix one person's problem. Use that user's row in User Setup instead.
  • !Forgetting that a filled User Setup value overrides General Ledger Setup, so changing the global window seems to do nothing for that user.
  • !Leaving the Work Date on an old value, which re-creates the error on every new document.
  • !Confusing this with an inventory period or accounting period closure and editing the wrong setup page.
  • !Opening a window and not closing it, so later users post into a period finance considers locked.

How an ERP-grounded AI assistant handles this

An assistant grounded in your Business Central data can answer the practical question behind this error: which window applies to this user, which row set it, and who last changed it. ERPray reads General Ledger Setup and User Setup read-only under the user's own role, shows the query it ran, and can list every user whose limits differ from the global window. It does not change the dates. Widening a window stays a human action by someone with the right permissions.

Frequently asked questions

Why does the error appear for me but not my colleague?

Each user can have their own Allow Posting From and To in User Setup, and that row overrides General Ledger Setup. Your colleague probably has no value in their row, so the global window applies, while yours holds a stricter date. Compare the two User Setup rows to confirm.

Where is Allow Posting From and Allow Posting To?

There are two places. Search for General Ledger Setup for the company-wide window, and search for User Setup for per-user overrides. Business Central reads the User Setup value first and falls back to General Ledger Setup only when that user's field is blank.

Does this error mean I lack permission?

No. It is a date-range check, not a permission check. Permission problems produce a different message that names the table or object you cannot access. Editing permission sets will not clear this error. You need a valid posting date or a wider allowed range.

Can I post into a closed inventory period by changing these fields?

No. Inventory Periods are a separate control. If the date falls inside a closed inventory period, you need that period reopened or a different posting date. Changing Allow Posting From or To will not bypass it, and it should be agreed with finance first.

Related

Error fix

Business Central: "You have insufficient quantity of Item on inventory"

Business Central raises this error when posting would take an item negative and Prevent Negative Inventory is switched on, either globally in Inventory Setup or on the item card. The usual root causes are a different location or variant than you expect, an earlier posting date, receipts not yet posted, or lot or serial numbers that are not available. Check the item ledger for the exact combination before changing the setting.

Error fix

Business Central: "Select a Dimension Value Code for the Dimension Code"

Business Central stops the post because a Default Dimension for an account, customer, vendor or item has Value Posting set to Code Mandatory, and the document has no value for that dimension. Either supply the dimension value on the line or header, or change the Value Posting rule if the requirement is wrong. Dimension combinations and priorities can produce similar-looking blocks.

Error fix

Fixing "You do not have the following permissions on TableData (table): (permission)" in Business Central AL

This runtime error means the current user's assigned permission sets do not grant the required Insert, Modify, Delete, Read, or Execute right on that specific table. It is most common right after installing or updating a custom AL extension, because Business Central checks object-level permissions even for tables an extension owns.

Error fix

Fixing "Cannot create a record in (table). The record already exists" in D365 F&SCM data entity imports

This is the standard kernel duplicate-key exception, thrown when the Data Management Framework tries to insert a staging row into a target table whose unique or alternate key already matches an existing record. It almost always means the entity's insert-vs-update logic did not recognize the target row as an update, not that you have a true accidental duplicate in your source file.

Error fix

Fixing "There are currently no batch servers available for processing" in D365 F&SCM

This message means the batch framework cannot find any AOS instance flagged as a batch server and available for the batch group the job is assigned to. The fix is almost always in server configuration (System administration > Servers) or batch group assignment, not in the batch job itself.

Error fix

Fixing "The CIL object was not found" in Dynamics AX 2012

This error appears when the AOS tries to execute compiled CIL for a class or method that has not actually been regenerated since a code change was imported or edited, so the .NET runtime has nothing matching to run. The fix is a full compile followed by a full CIL generation and an AOS restart, not just a partial or incremental rebuild.

AI for ERP

AI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot

AI for Business Central beyond Copilot: grounded question answering over BC's data via OData and APIs, for on-premises and SaaS tenants alike.

AI for ERP

AI for Business Central manufacturing operations, beyond Copilot

AI for Business Central manufacturing beyond Copilot: grounded answers on production orders, routings, and capacity via APIs v2.0, on-prem capable.

Stuck on Microsoft Dynamics 365 Business Central?

Talk to engineers who work inside Microsoft Dynamics 365 Business Central every week, and who build private AI that answers these questions from your own ERP data.