“Gen. Posting Type Must Not Be…” in Business Central: What the Error Really Means

This cryptic Microsoft Dynamics 365 Business Central posting error is not telling you to pick Purchase or Sale at random. It means the posting type, general posting groups, VAT posting groups, and the side of the entry no longer describe one coherent transaction. Here is how the validation works, how journals differ from sales and purchase documents, and how to fix the source without corrupting VAT or subledger reporting.

Why the wording is so confusing

Two generations of error text are still encountered in supported Business Central environments and older Dynamics NAV installations. A current client may say:

“Posting to Account 9110 must either be of type Purchase or Sale (see Gen. Posting Type), because there are specified values in one of the following fields: Gen. Bus. Posting Group, Gen. Prod. Posting Group, VAT Bus. Posting Group, or VAT Prod. Posting Group.”

Older validation produced the shorter “Gen. Posting Type must not be … in Gen. Journal Line”. The phrase must not be is generated by a field check; it is not a recommendation to remove the field. If nothing appears between be and in, the blank value is what is forbidden. If the message names Purchase or Sale, that named value is present where the posting engine expects a different state, often blank.

A prefix such as Bal. Gen. Posting Type changes the diagnosis: inspect the balancing-account fields and any balancing account inherited from the journal batch, not only the visible account side.

The five fields do not all do the same job

The fastest way to misdiagnose this error is to treat every “posting group” as a VAT field. Business Central carries two related but distinct account-selection systems.

In the current standard G/L-account check, the clearer error is raised when at least one of the four general/VAT group fields contains a value while Gen. Posting Type is blank. The reverse is not the same validation and is not a licence to fill every field. Requirements depend on how the transaction was created and whether VAT must be calculated. Localisations and extensions can add other checks or posting types.

Where the values come from

The same message can have different root causes because values arrive from different sources.

1. Direct general journal: the G/L account card can supply posting type and groups when Copy VAT Setup to Jnl. Lines is enabled on the journal batch. The journal also has a separate balancing context.
2. Sales or purchase document: the customer or vendor supplies the business groups; the item, resource, or G/L account on the line supplies product groups; the document determines the sales or purchase direction.
3. General Posting Setup: the general business/product combination chooses operating accounts. A missing or inappropriate combination is a different problem from a missing VAT combination, even if both appear during the same post. A blank group is a literal blank key in the setup—not a wildcard that matches every group.
4. VAT Posting Setup: the VAT business/product combination supplies the VAT calculation and accounts.
5. Generated posting lines: payment discounts, invoice discounts, rounding, prepayments, deferrals, exchange differences, item charges, and extensions can create temporary general journal lines that are not visible on the source document.

Microsoft’s current purchase posting code explicitly assigns Purchase to ordinary generated invoice posting lines; sales posting assigns Sale. That is why manually changing a document’s final posting type is usually the wrong level of repair. The inconsistency normally began in master data, setup, a copied document line, or custom posting code.

Four common scenarios

1. A general journal entry with no VAT

An accrual, opening balance, or internal reclassification often has no VAT event. In that case the posting type and VAT groups on the relevant journal side should be blank. General posting-group values copied from the account can still create a contradiction. Use a journal batch intentionally configured for non-VAT entries and confirm both account and balancing fields.

2. A direct G/L journal that must calculate VAT

A directly posted bank fee or expense may need Purchase VAT; a direct revenue entry may need Sale VAT. The relevant G/L side needs the correct type and VAT business/ product combination, and that combination must exist in VAT Posting Setup. Enabling Copy VAT Setup to Jnl. Lines can copy those defaults from the G/L account, but it should be a deliberate batch policy—not a troubleshooting toggle.

3. A sales or purchase document

Do not inspect only the G/L account named by the error. Check the customer/vendor business groups, the item/resource/G/L line’s product groups, and both posting setup matrices. For a G/L Account document line, the selected G/L account commonly provides product-side defaults while the document header provides the business-side values. For item and resource lines, their cards are the usual product-side source.

4. The error names line 0 or an unfamiliar account

An empty journal template, empty batch, or line number 0 often means posting failed on a temporary line generated behind the document. Use Preview Posting and the error details first. If the source remains unclear, a consultant or developer should inspect the AL call stack and any extension subscribers rather than changing random accounts.

A safe diagnostic and repair sequence

1. Preserve the complete error. Record the account number, whether the field starts with Bal., and the journal template, batch, and line number.
2. Decide the intended result. Is this a purchase, a sale, a system-run VAT settlement, or a transaction that must create no VAT entry?
3. Expose the posting fields. Personalize the journal or inspect the page to show Gen. Posting Type, both general groups, both VAT groups, and the five balancing equivalents.
4. Identify the creation path. Separate a direct journal from a purchase/sales document and from a generated posting line.
5. Trace the source. Check the journal batch, G/L account, customer or vendor, item/resource/document line, General Posting Setup, and VAT Posting Setup as applicable.
6. Correct master setup first. Fix the value that is wrong for the intended accounting treatment. Do not create a fictitious VAT combination or reclassify a control account merely to satisfy validation.
7. Refresh the transaction. Existing lines retain copied values. Revalidate or re-enter the account/line after preserving quantities, dimensions, descriptions, and other business data.
8. Preview and verify. Preview Posting must complete, but also inspect the proposed G/L and VAT entries. Confirm account, VAT base, VAT amount, direction, dimensions, and subledger impact before posting.

Prevent the error from returning

• Maintain separate, clearly named journal batches for VAT-bearing and non-VAT entries, with an intentional Copy VAT Setup policy.
• Set Direct Posting to No on subledger control accounts so users cannot bypass customer, vendor, bank, inventory, or fixed-asset ledgers.
• Restrict changes to the chart of accounts and posting setup, and test changes in a sandbox with representative sales, purchase, payment, credit memo, and reversal cases.
• After changing master data, refresh open document and journal lines that already copied the old values.
• For extensions, validate temporary general journal lines on both sides and test VAT, no-VAT, reverse-charge, discount, prepayment, and rounding paths.