VAT Posting Setup missing on retail sales lines
The statement posting stops on tax: “The VAT Posting Setup does not exist. Identification fields and values: VAT Bus. Posting Group=…, VAT Prod. Posting Group=….” That identification-fields tail is the useful part — it hands you the exact pair of codes the posting went looking for. This error family has two different causes that share one message, and fixing the wrong one wastes a month-end.
Tax note: VAT rates, registrations, and what is taxable are set by your tax authority and your accountant. This guide covers Business Central setup mechanics only — it is general information, not professional tax advice.
What the error is telling you
VAT in Business Central is calculated from a matrix, the VAT Posting Setup: one row per combination of a VAT Bus. Posting Group (the “who” of the sale) and a VAT Prod. Posting Group (the “what”). Each row carries the VAT Identifier, the VAT %, the VAT Calculation Type — the method used to calculate the tax on a sale or purchase — and the accounts, including the Sales VAT Account and Purchase VAT Account. To set the matrix up at all, you define the posting groups, the rate, and the accounts for each combination.
When a retail sale posts, its lines arrive carrying a VAT bus./prod. pair. If no row exists for that pair, posting stops and the error names the pair in its identification fields — documented examples show it verbatim, values and all, e.g. VAT Bus. Posting Group=’DOMESTIC’, VAT Prod. Posting Group=’SERV NORM’. The pair is the diagnosis. Everything below works from those two codes.
How the VAT pair gets onto a retail sale line
Cashiers never type VAT groups, so the pair is assembled from defaults. Microsoft documents the mechanism: a VAT business posting group can be assigned to a general business posting group, and a VAT product posting group can be assigned on a general product posting group — the VAT group is then assigned when that business or product posting group is chosen for a customer, vendor, item, or resource. Applied to a till sale:
| Half of the pair | Chain of defaults | Where to inspect it |
|---|---|---|
| VAT Bus. Posting Group | The sale’s general business posting group — for a POS sale that starts with the store, and LS Central stores carry their own Gen. Business Posting Group — with the VAT business group assigned on that general business group | The store’s Gen. Business Posting Group; then the VAT Bus. Posting Group set on that general business posting group |
| VAT Prod. Posting Group | The item’s general product posting group, with the VAT product group assigned on it — or set directly per item | Item card, Price & Posting FastTab (choose Show more): the VAT Prod. Posting Group field; and the VAT product group on the item’s general product posting group |
You can see the result at the till: the LS Central POS receipt carries a tax group ID on its lines and totals per tax group, and the Z report shows total VAT grouped by VAT groups. When the pair is wrong, it is usually visible there first — a line taxed under a group it should not be in — long before the statement fails.
Missing pair or wrong pair: split the cause first
- The pair is genuinely missing. Both halves are the codes the business intends, but nobody ever created that row in VAT Posting Setup. Typical trigger: a new product category or a new jurisdiction’s goods reaching the shelf before finance extended the matrix.
- The pair is wrong, not missing. The row for the intended pair exists — but the transaction is carrying a different one. Typical triggers: a new item whose VAT Prod. Posting Group is blank or defaulted from the wrong general product group; an item whose per-item VAT group was set for a different tax treatment; or a store whose business-side defaulting resolves to a VAT business group that retail sales were never meant to use.
The split decides the fix. Creating a row for a wrong pair posts the sale at whatever rate that new row carries — the error disappears and the tax is wrong. Correcting an assignment when the row really is missing just moves the failure to the next statement.
The fix
- Copy the pair out of the error. Both identification-field values, exactly as written — including if one of them is blank. A blank half is itself the finding: something upstream assigned nothing.
- Check both assignments. Following the standard advice for this error: confirm that each side has a valid VAT posting group assigned and that the combination exists in VAT Posting Setup. Concretely — open the item from the failing sale and check its VAT Prod. Posting Group on the Price & Posting FastTab; then check the VAT business group that the sale’s general business posting group resolves to.
- Decide: intended pair or wrong pair? Compare against a similar item that posts cleanly at the same store. If the failing item should carry the same pair as its clean neighbour, the pair on the transaction is wrong — fix the assignment (step 4). If the pair is genuinely what this kind of sale should carry, the row is missing — create it (step 5).
- If the assignment is wrong: correct the VAT Prod. Posting Group on the item card, or the VAT group assigned on its general product posting group — whichever level your setup uses — then re-run the statement posting and confirm the failing lines now resolve to the intended pair.
- If the row is missing: open VAT Posting Setup and add the row for the exact pair. Fill in the VAT Identifier, the VAT %, the VAT Calculation Type, and the Sales VAT Account (and Purchase VAT Account if the pair is also used on purchases). Get the rate and accounts from your accountant or from the row for the closest equivalent pair — never from the receipt total backwards.
- Repost the statement, then check the next statement in the queue: a missing row usually blocks every store selling the same goods, not just the first one that reported it.
What success looks like
- The failed statement posts with no VAT error, with no change to the prices or amounts that were sold.
- A test sale of the same item shows the intended tax group on the receipt, and the VAT total for that group on the Z report moves by the expected tax on that sale.
- The VAT entries created by the posting carry the pair you intended and the VAT % from the setup row — not a pair you created on the spot to make the error go away.
Verify the row, not just its existence
One follow-up the error never asks for: a row can exist and still be wrong for the goods being sold. If a statement posts but the tax looks off, open the row for the pair the sale carried and check its contents — the VAT % against the rate that should apply to those goods, the VAT Calculation Type against how the tax is meant to be calculated, and that the Sales VAT Account is filled in. An existing row with a stale rate posts quietly wrong tax on every sale until someone checks, which is worse than a loud error at statement time. This is also why step 5 insists the rate comes from your accountant: the matrix will happily post any percentage you type into it.
FAQ
One half of the pair in the error is blank. Which side do I fix?
The blank side’s assignment chain. A blank VAT product half points at the item (or
its general product posting group); a blank VAT business half points at the
business-side defaulting for the sale. Fix the assignment — a VAT Posting Setup row
with a blank half is a workaround, not a setup.
Sales post but purchases of the same item fail with the same
error.
Same matrix, same pair — VAT Posting Setup rows serve both directions, and the row
needs its purchase-side fields (Purchase VAT Account) as well. Check the row’s
contents before assuming a second problem.
Is this the same as the “Gen. Posting Setup does not exist”
error?
A sibling, not a twin: that one is the general-ledger account matrix failing on the
general posting groups (see
“Gen. Posting Setup
does not exist” on POS sales). This one is the VAT matrix failing on the VAT
groups the sale resolved to. A statement can hit either — and fixing one does not
clear the other.