How Posting Groups Actually Work in Business Central

Ask ten Business Central users what a posting group is and you'll get ten shrugs. It's the piece of the system almost nobody sets out to learn, yet it quietly decides which G/L account every single transaction lands in. Get it right and the general ledger populates itself, invisibly, forever. Get it wrong and you meet Business Central's most infamous error message at the worst possible moment — mid-invoice, with a customer waiting.

Here's the explainer we wish someone had handed us on day one — a clear line from "I posted an invoice" to "here's why it hit account 6100."

Why posting groups exist at all

Business Central doesn't post most transactions straight to the general ledger. It posts them to sub-ledgers first — the customer, vendor, item and bank ledgers. That's where the detail lives: who owes what, which item moved, which invoice is still open.

But your accountant thinks in G/L accounts — Trade Debtors, Sales, Output VAT, Stock. Something has to translate "an invoice to Contoso for 10 widgets" into the right debits and credits on the right accounts.

That translator is the posting group — the bridge from the sub-ledger world (customers, items, banks) to the G/L world (account numbers). You tag your master data once, and from then on every transaction knows where to go. No one keys an account number on a sales invoice, and that's by design.

Think of a posting group as answering one question: "When something happens to this thing, which account does it touch?"

The two families of posting group

There are two mechanisms, and mixing them up is the root of most confusion.

1. Single-dimension posting groups — one tag, one lookup, one account (or a small set). These cover the balance-sheet side:

• Customer Posting Group → which Receivables account this customer's debt sits in.
• Vendor Posting Group → which Payables account.
• Inventory Posting Group (with Location) → which Stock account item value sits in.
• Bank Account Posting Group → which G/L account mirrors this bank account (the one your bank reconciliation clears against).
• FA Posting Group → the Fixed Asset accounts (acquisition cost, accumulated depreciation, disposal).

Each is a straight tag on the master record: a customer carries a Customer Posting Group, you look it up, you get the receivables account. Simple.

2. Combination posting groups — two tags crossed in a matrix. These cover the P&L and VAT side, and they're where people come unstuck:

• General Posting Setup = Gen. Business Posting Group × Gen. Product Posting Group.
• VAT Posting Setup = VAT Business Posting Group × VAT Product Posting Group.

The word to hold onto is matrix. It's not one tag — it's a row for every combination of a "who" tag and a "what" tag.

The matrix, properly explained

Take General Posting Setup, the one that trips everyone up.

Every customer and vendor carries a Gen. Bus. Posting Group — the who ("what kind of trading partner is this?"). Typical values: DOMESTIC, EU, EXPORT. Every item, resource and G/L account carries a Gen. Prod. Posting Group — the what ("what kind of thing is being sold or bought?"). Typical values: GOODS, SERVICES, FREIGHT.

The General Posting Setup page is the grid where those two axes meet. Each row is one combination — say DOMESTIC × GOODS — and on that row you specify the accounts to use when that kind of partner trades that kind of thing: the Sales Account (revenue on a sale), the Purch. Account (cost on a purchase), plus COGS, discount and inventory-adjustment accounts.

So a sale of GOODS to a DOMESTIC customer books revenue to a different account than SERVICES to an EXPORT customer — automatically, because they land on different rows. Your P&L splits itself by partner type and product type without anyone choosing an account — ready to slice further in your account schedules.

VAT Posting Setup works identically, just for tax. Every partner carries a VAT Bus. Posting Group (DOMESTIC, EU, EXPORT) and every item a VAT Prod. Posting Group (STANDARD, REDUCED, ZERO, EXEMPT). Cross them and each row holds the VAT %, the VAT Calculation Type, and the Sales/Purchase VAT accounts. DOMESTIC × STANDARD gives 20% to the output VAT account; EXPORT × ZERO gives 0% and a different account. Same matrix, tax edition.

Walking one transaction all the way through

Here's the payoff — what actually happens when you post a sales invoice for 10 widgets to Contoso (a domestic customer):

1. Contoso's Customer Posting Group → the Receivables account is debited with the gross total. (Single-dimension lookup.)
2. Contoso's Gen. Bus. Posting Group (DOMESTIC) crossed with the widget's Gen. Prod. Posting Group (GOODS) → finds the DOMESTIC/GOODS row in General Posting Setup → the Sales Account is credited with the net. (Matrix lookup.)
3. Contoso's VAT Bus. Posting Group (DOMESTIC) crossed with the widget's VAT Prod. Posting Group (STANDARD) → finds the row in VAT Posting Setup → 20% is credited to the Output VAT account. (Matrix lookup.)
4. If it ships from stock, the item's Inventory Posting Group + location → the Stock account is credited and COGS debited.

Four posting groups, one invoice, zero account numbers typed by a human — every debit and credit resolved from tags. That's Business Central working as intended.

The single most common mistake

Because General Posting Setup is a matrix, it only works if the exact combination exists as a row. Miss one, and the moment someone posts that combination, Business Central stops dead:

"The Gen. Posting Setup does not exist. Identification fields and values: Gen. Bus. Posting Group='EXPORT', Gen. Prod. Posting Group='SERVICES'."

Read that message like a map — it names the table (Gen. Posting Setup, or VAT Posting Setup) and gives you both values of the combination that has no row. The fix is almost never to change the customer or the item. It's to add the missing row: create a line for EXPORT × SERVICES, and — the safest way — copy the account choices from an existing, similar row (e.g. DOMESTIC × SERVICES) and adjust. Post again; it goes straight through.

You'll see the identical pattern for tax ("VAT Posting Setup does not exist…") and, occasionally, for a customer or vendor whose posting-group field was left blank. The diagnosis is always the same three steps: read which table, read the two values, add or fix that row.

Why does it happen? Usually a new posting-group value was introduced — someone added an EXPORT business group or a SERVICES product group — but nobody filled in the matrix rows for it.

Keep the matrix lean

Here's the trap, though: General Posting Setup rows grow multiplicatively — 6 business groups × 8 product groups is 48 rows to maintain, each a chance for a wrong account. A few habits keep it sane:

• Only create a value if it drives a different account. If GOODS and MATERIALS post to the same sales and COGS accounts, they should be one product group, not two. Posting groups are about accounting outcomes, not describing the item.
• Use dimensions for analysis, posting groups for accounts. Want sales by department or region? That's a dimension, not a posting group. Overloading posting groups to get reporting splits is the fastest way to a matrix nobody understands. (We wrote a whole guide on doing dimensions properly.)
• Fill the matrix completely at setup, then re-check it whenever you add any value. A five-minute review beats a blocked invoice.
• Keep names boring and consistent. DOMESTIC, EU, EXPORT beats a clever scheme you'll be decoding in a year.

The bottom line

Posting groups are the wiring behind Business Central's general ledger. Single-dimension groups (Customer, Vendor, Inventory, Bank, FA) tag one thing to one account. Combination groups (General and VAT Posting Setup) cross a who and a what in a matrix to drive your P&L and tax accounts. Once you see a transaction as a set of tag-lookups, the "…is not defined" error stops being scary — it's just Business Central telling you which row of the matrix you forgot to build. Set the matrix up completely, keep it as small as it can honestly be, and the general ledger looks after itself.

Inherited a Business Central with a tangled posting-group matrix — or hitting "…is not defined" errors you can't pin down? At Amplio we untangle and streamline posting setups as part of every implementation, and we can review an existing one without disturbing your data. Get in touch and we'll take a look.