“Select a Dimension Value Code for Dimension Code…” blocking an LS statement

Troubleshooting · 8 min read

The statement calculated cleanly. The tenders balance. You post it, and Business Central stops with a message along these lines:

Select a Dimension Value Code for Dimension Code <X> for G/L Account <Y>

The exact wording varies because the message is built from a template — Microsoft Learn's dimension troubleshooting page documents it as “Select a %1 for the %2 %3 for %4 %5”, where the placeholders are filled in with the dimension value code label, the dimension code, and the account the rule belongs to. Microsoft Support shows the same message fully rendered in another posting flow: “A dimension used in Gen. Journal Line … has caused an error. Select Dimension Value Code … for the Dimension Code … for Customer …”

Read the message as a sentence, not an accusation: some account this statement is about to post to has a rule that says “a value for dimension X is mandatory,” and the line about to post carries no value for dimension X. The statement is the messenger. This guide decodes which rule fired, how to find the account and the lines behind it, and — the part most write-ups skip — how to decide whether the setup or the data is the side that's actually wrong.

Where the requirement comes from: a rule side and a data side

Dimensions are values that categorize entries — department, store concept, sales channel, whatever the business reports by. Every journal line, document line, and statement-generated entry carries a dimension set: the combination of dimension values attached to that line. Posting validates each line's dimension set against the default dimension rules of the accounts involved.

The rule that produces this error is set on a record's Default Dimensions page, in the Value Posting field. Microsoft Learn's troubleshooting table names the exact combination: a blank dimension value code for a default dimension where Value Posting contains Code Mandatory. Unpacked, that means someone set up the dimension on the account, deliberately left the Dimension Value Code blank — which is the documented way to require a dimension without assigning a default value — and set the rule to Code Mandatory. From then on, any entry to that account without a value for that dimension is refused at posting.

The data side is where retail differs from ordinary journal posting. A person typing a journal gets stopped at the line and picks a value. A statement is different: its entries are generated from POS transactions recorded at the till. If the transaction data and the statement's own defaults don't supply a value for the mandatory dimension, the generated entry arrives at posting with a blank — and the rule fires. The transaction isn't malformed; it simply never had a reason to carry that dimension.

The Value Posting options, decoded

The fix depends on which rule is actually set, so it pays to know all four settings:

Two subtleties from the Microsoft documentation are worth knowing before you change anything. First, defaults exist at two levels: a default dimension can be set for an account type, and a default set on the specific account replaces the account type's default. So the Code Mandatory rule stopping your statement may not be on the account card you open first — it may be inherited from the account-type setup. Second, when several records (the store's customer record, an item, a location) each propose a default dimension for the same entry, Default Dimension Priorities decides which source wins — which is why an entry can end up with a value from a source you didn't expect, or with none when two defaults collide.

Finding the offending account and lines

The error message is the map — work from it, not from the statement totals:

1. Copy the full message before dismissing it. It names the dimension code and the account (the “for G/L Account …” part). That account is where the Code Mandatory rule lives — it is not necessarily the account with the biggest amount on the statement.
2. Open that account's Default Dimensions. From the Chart of Accounts, open the named G/L account and its Dimensions / Default Dimensions page. Find the line for the named dimension and read its Value Posting and Dimension Value Code fields. Expect: Code Mandatory, value blank.
3. If the account has no such line, check the account-type default. On the Dimensions page, the Account Type Default Dim. action shows the defaults defined per account type. An inherited rule explains why the account card looked innocent.
4. Identify which statement lines post to that account. The account tells you the family of lines to inspect — income, discount, tender difference, or similar statement lines, depending on your posting setup. Expect posting to stop at the first offending line; fixing one line can reveal the next, because the validation runs line by line.
5. Check whether the line's dimension set has the dimension at all. A line carrying the dimension with a blank value and a line carrying no dimension line at all fail the same way — both are “blank” to the Code Mandatory check.

The fix, step by step

Microsoft Learn lists exactly two solutions for this issue: change the Value Posting field on the Default Dimension page, or enter a nonblank dimension value for the conflicting dimension in the dimension set. In statement terms, those become three practical routes, in the order to try them:

1. Give the account a real default value (preferred when the value is always the same). On the account's Default Dimensions line for that dimension, enter the Dimension Value Code the entries should always carry. If exactly one value is ever correct, set Value Posting to Same Code so the default is also enforced; if several values are legitimate, keep Code Mandatory and use the Allowed Values Filter to checkmark which values are allowed. Future generated entries then arrive with a value and the error stops recurring.
2. Supply the value on the data side. If the value genuinely varies — by store, for example — the default belongs on the record that drives the statement's entries for that store, so the generated lines inherit it. This is the same default dimension mechanism: a default dimension assigned to a record is copied onto the documents and entries that record produces.
3. Relax the rule (only when the requirement itself was a mistake). Change Value Posting from Code Mandatory to blank. Do this when the dimension was made mandatory on an account that statement postings hit automatically and nobody actually reports on that dimension for that account. Be careful: Microsoft Learn warns specifically that accounts used by batch jobs such as Post Inventory Cost to G/L should not carry Code Mandatory or Same Code at all, because those batch jobs can't use dimension codes — mandatory-dimension rules on automatically-posted accounts are a recurring source of exactly this failure.
4. Re-post the statement. Don't hand-post journal lines to work around it; fix the rule or the default and let the statement generate its own entries (the same discipline as the general posting troubleshooting checklist).

What success looks like

The statement posts with no dimension error, and — this is the check people skip — the resulting G/L entries for the named account actually carry a value in the named dimension. Filter the G/L entries by the statement's posting and the account from the error message, and confirm the dimension value is present and is the value you intended. A statement that posts because someone quietly removed the mandatory rule, when the business genuinely reports by that dimension, is not a success: it trades a loud error today for silently incomplete reporting at month end. The close context for statements is in the end-of-day routine.

Deciding which side to fix permanently

Use this rule of thumb:

• The dimension is genuinely reported by account (finance slices this account's numbers by it every month) → fix the data side: a default value on the account or on the record driving the entries. Keep Code Mandatory — it caught a real gap.
• The value is always identical for this account → set the default value and Same Code. Mandatory-with-no-default was the worst of both worlds: all of the blocking, none of the automation.
• The account is posted to only by automatic processes (statement posting, cost posting) and the dimension adds no reporting value there → fix the rule side: the requirement never belonged on that account.
• The rule appeared after a setup change → check the account-type defaults before touching individual accounts. One inherited rule can break every store's statement on the same night, and fixing accounts one by one treats a single cause as twenty separate problems.