“Posting date is not within your range of allowed posting dates” when posting an LS statement

Troubleshooting · 7 min read

The statement is calculated, the tenders balance, and the store is waiting to close the month. You press Post and Business Central answers with:

Posting date is not within your range of allowed posting dates

That is the exact wording Microsoft documents for this error. It is not an LS Retail problem and it is not a problem with the statement's numbers. It is Business Central's period control doing its job — at the worst possible moment. This guide decodes what is being checked, why statement posting at period end walks straight into it, and how to let the legitimate late posting through without re-opening the closed period to everyone.

What the error is actually checking

Microsoft Learn's summary of the message is blunt: it indicates that you aren't allowed to post entries for the date you entered. Business Central has no hard monthly close of the kind legacy systems had — instead, the allowable posting date range is controlled through setup. When anything posts, the posting date on the entry is compared against an allowed range, and a date outside that range is refused.

Two details in that check matter more than everything else:

• Your range is checked first. The posting routine looks at the posting user's setup first. If your user has an allowable posting date range in User Setup, the statement's posting date must fall inside it — the company-wide range is not consulted.
• The company range is the fallback, not an override. Only if both date fields in your User Setup are blank does the routine fall back to the Allow Posting From / Allow Posting To range in General Ledger Setup.

So the error is personal before it is global. The same statement, posted by a different user whose User Setup range covers the date, can go through untouched. That is why the first diagnostic question is never “what is the company range?” but “who is posting, and what does their range say?”

Why it bites at period-end statement posting

Statement posting concentrates three things that rarely collide anywhere else:

• The posting date belongs to the old period. A statement covers a trading day. The last statement of the month carries a posting date on the last day of that month — but it is often calculated and posted a day or two later, after counting and difference checks. (The close order matters here; see the end-of-day routine.)
• The allowed ranges roll forward on the first of the month. Standard month-end practice is to move the General Ledger Setup range to the new month on day one, precisely so nobody posts into the month being closed. The moment that happens, any unposted statement still carrying last month's date is locked out.
• Retail posts late by nature. A statement that needed a tender recount, or a terminal that was offline and synced late, can easily surface after the roll-forward. The error then looks like a retail failure, when it is really a calendar failure.

Note what the error is not telling you: nothing about the statement is wrong. Recalculating it, recounting tenders, or re-running the close will produce the same message until a date range changes.

The three places the allowed range lives

Microsoft's own overview of this error's setup names three areas. They are not interchangeable:

One trap inside the table: blank fields are not “no restriction” in the way people expect. If Allow Posting From is blank but Allow Posting To is filled in, posting is allowed from the beginning of time up to that end date; a blank Allow Posting To with a filled-in From date allows posting indefinitely into the future. A half-filled range is an open door in one direction.

The fix: a narrow exception, step by step

The goal is to let this statement post with its date, for the shortest time, for the fewest people. Work it in this order:

1. Read the statement's posting date. Note the exact date the error is objecting to. Every fix below is about covering that one date — not “last month” in general.
2. Check the posting user's User Setup first. Search for User Setup, find the user who will run the posting, and look at their Allow Posting From / Allow Posting To. If a range is there and it excludes the statement date, this range — and only this range — is your blocker.
3. If the user has a range, widen that one, temporarily. Move their Allow Posting From back far enough to include the statement's date (for example, to the first day of the closing month). Leave the company-wide General Ledger Setup range exactly as it is.
4. If the user's dates are both blank, the General Ledger Setup is deciding. Do not widen the company range for one statement. Instead, give the posting user a User Setup range that spans the closing month — a user range takes precedence, so the statement can post while the company range stays rolled forward for everyone else.
5. Post the statement. Run the posting as that user, in the same session if possible, before doing anything else.
6. Put the exception back. Immediately restore the user's range to its normal span (typically the current open month). An exception left in place is next month's unexplained back-dated entry.
7. If inventory lines still refuse, check Inventory Periods: if the period containing the statement date is marked Closed, that gate also has to be addressed before the inventory-carrying part of the posting will pass.

What success looks like

The statement posts without the error, and the resulting G/L entries carry the statement's original posting date — in the closing month, where the trading day belongs. Spot-check two things before moving on: the posted statement shows as posted for the store and date you expected, and the User Setup range you touched is back to its normal values. If the date on the entries is today's date instead of the trading day, the statement was re-dated rather than unblocked — that is a different outcome, and it moves revenue into the wrong period.

Keeping legitimate late postings possible

The permanent fix is a routine, not a wider range. The month-end pattern experienced BC accountants use works well alongside a retail close:

• Never leave the General Ledger Setup dates blank. Blank company dates mean any date posts — including the typo'd future date nobody catches until the audit.
• Give User Setup dates only where they are needed. If a user's dates are blank, the General Ledger Setup controls them, which is the right default for store staff. Reserve personal ranges for the people who post statements and close the month.
• Let closers straddle two months, briefly. During the close, the people finishing last month can carry a User Setup range spanning the closing month and the new month, while the General Ledger Setup rolls forward on the first. When the month's entries are complete and the financials are published, narrow their range to the new month.
• Update the dates on the first of every month, in every company. Multi-company setups fail one company at a time; the company whose dates nobody rolled is the one whose statements stop.
• Post statements before you roll the range. Sequence the close so the last statements of the month post first and the range roll-forward happens after. Most occurrences of this error are a sequencing problem wearing an error message.

One decision rule covers almost every case: exceptions go on the user, policy goes on the company. If one person needs to post one late statement, that is a User Setup change measured in minutes. The General Ledger Setup range should only move on the monthly schedule — the day it starts moving for individual statements, the period control it exists to provide is gone. For the broader list of statement posting failures, see the posting troubleshooting checklist.