VAT and sales tax setup in Business Central

By Emil Björk · Microsoft business apps consultant, Gothenburg

How Business Central calculates and reports VAT — VAT posting groups, EU rules, OSS, reverse charge, and country reporting.

Reviewed August 20263 min read · 794 wordsPublished Updated
On this page (11)

VAT and sales tax are the area of Business Central where country localizations matter most. The core engine is the same everywhere, but every country layers its own rules and reports on top.

The posting-group model

Business Central calculates VAT by intersecting two posting groups on every transaction line: the VAT business posting group (who you are trading with — domestic customer, EU customer, export, reverse-charge subcontractor) and the VAT product posting group (what's being sold — standard goods, food, services, exempt). The intersection in the VAT posting setup table defines the rate, the GL accounts to post to, the calculation type (normal, reverse charge, sales tax, full VAT), and the EC reporting category.

Setup discipline

Every customer, vendor, and G/L account default a posting group, so most postings get the right VAT without manual intervention. Mistakes typically come from new countries, new product categories, or split-purpose accounts; spend the time getting defaults right.

EU rules

Built-in support for EU intra-community supplies, reverse-charge purchases, triangulation, and the EC Sales List. The VAT Statement report builds country-specific VAT returns line by line by combining VAT entries.

One-Stop Shop (OSS)

For EU B2C cross-border sales, Business Central supports the OSS scheme, with VAT calculated at the customer's country rate and a separate OSS return posted to the supplier's home tax authority.

Reverse charge

Both EU reverse charge and country-specific domestic reverse-charge schemes (construction services, scrap metal, mobile phones, gold) are supported through the posting setup type.

Sales tax (US/Canada)

A separate sales-tax engine, configurable by tax area, tax jurisdiction, and tax group, handles state, county, and city tax composition. For high-volume US businesses, ISV partners deliver Avalara or Vertex integrations from AppSource.

Country reporting

VAT returns (Making Tax Digital in the UK, SAF-T, real-time invoice reporting in Spain/Italy/Hungary, e-invoicing) ship per country, either from Microsoft or from a localization ISV. Always verify country coverage before committing to BC for a particular jurisdiction.

Unrealized VAT and the VAT date

Two settings deserve a deliberate decision at implementation rather than a default. Unrealized VAT shifts the tax point from invoice to payment — cash-accounting schemes, and mandatory in some jurisdictions for certain flows. It changes which GL accounts VAT sits on and when it hits the return, so switching it on later is painful; decide up front with your accountant. The VAT date (separate from posting date and document date) determines which VAT reporting period an entry lands in. Since its introduction it has quietly become the most important date on late-arriving supplier invoices: a January invoice posted in February can carry a January VAT date and land on the right return. Decide who is allowed to backdate it and lock closed VAT periods with the VAT return period controls, or your filed return and BC will drift apart.

Implementation discipline

The posting-group model is elegant and unforgiving: a wrong intersection posts confidently at the wrong rate, at volume, until someone notices — often the tax authority. What works in practice:

  • Keep the matrix small. Every business and product posting group multiplies the setup table. Resist a group per edge case; most SMBs need well under ten product groups.
  • Test the matrix, not the concept. Before go-live, post one test document through every combination that can occur — domestic sale, EU B2B sale, export, reverse-charge purchase, import — and have the accountant sign off the VAT entries each produces.
  • Watch data migration. Migrated customers and vendors arrive with whatever posting groups the migration mapped, and a NAV-era mapping copied forward uncritically is a classic source of wrong-rate postings in month one. Sample-check aggressively after data migration.
  • Guard the manual override. Users can change VAT groups on a document line. Sometimes that's legitimate (zero-rated export evidence); mostly it's a mistake. Restrict who can, and review VAT entries by group monthly — a five-minute pivot that catches most setup drift.

When something posts wrong anyway

Don't edit your way out. Posted VAT entries are immutable by design; the fix for a wrong-rate posting is a credit memo or a correcting entry that reverses the original VAT and posts it correctly, keeping the audit trail contiguous. For systematic errors discovered late (a whole quarter at the wrong rate), involve the accountant before mass-correcting — some jurisdictions want a disclosure alongside the correction, and the mechanics differ if the return has been filed.

Audit and corrections

Posted VAT entries are immutable; corrections post a counter-entry. The VAT register is the canonical audit trail, and the posted VAT return periods tie each entry to the return it was reported on. If you operate in multiple countries, remember that VAT correctness is a property of the country localization, not of the base product — verify both the rules and the digital-filing formats per jurisdiction as part of country setup and localisation before committing.

Further reading

Related guides

Browse every guide in Business Central or just Compliance & localisation.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.