How to design one ERP company with several VAT registrations
Draw the legal entity and its registrations before deciding how many technical ERP companies to create. One legal entity can have several tax identifiers, while a customer can also have alternative VAT numbers. Those are different requirements, despite similarly titled product documentation.
This guide designs a reporting and reconciliation model for an entity already assumed to have the required registrations. It does not decide whether a warehouse, establishment or sales activity creates a registration obligation. Those questions require their own local analysis.
Use the registration-routing worksheet to preserve the operating model, product scope and transaction population. The worked example uses approved tax assumptions rather than a universal country setup rule.
Keep five objects distinct
Identify the legal entity that contracts with the customer, any establishment relevant to the transaction, the entity's own tax registrations, the physical stock location and the customer's identity and registrations.
Give each object its own identifier and relationship. A warehouse code is not a legal entity. A customer's German VAT number does not become the seller's German registration. A branch identifier may have a different function from either VAT number.
Dynamics 365 Finance documents registration information associated with party addresses, including legal entities and counterparties. The purpose and address context matter to which identifier is used. Microsoft, Finance registration IDs.
Ask tax and legal owners to approve the actual structure. Then specify the relevant accounting, invoice, tax-return, trade-reporting and retention outputs for each population. Do not assume one successful VAT return establishes every other obligation in that registration country.
Read the two Microsoft product claims correctly
Business Central's multiple-VAT-registration page describes alternative customer VAT numbers and identifies availability from version 25. It does not establish support for the seller's own foreign-registration reporting. Microsoft, Business Central customer VAT registrations.
Dynamics 365 Finance separately documents reporting several registrations from one legal entity, with named countries, prerequisites and a scope limited to VAT declarations, EU sales lists and Intrastat. It expressly limits access to other foreign-country functionality. Finance is a different product from Business Central and is used here as an architectural example outside the site's current ERP catalogue. Microsoft, multiple-registration reporting in Finance.
Record the exact family, release, localisation, tax service and report formats in a capability decision. A partner extension can be part of the chosen design, but its own-registration scenario needs separate evidence. Absence of that evidence is unresolved scope, not proof that a feature is impossible.
Choose the technical company structure deliberately
Compare one technical company with registration-specific reporting against separate technical companies linked by a controlled statutory aggregation. Include extensions or an external reporting service where relevant.
For each option, explain how the single legal entity's accounts remain complete, how one customer balance is managed and how transfers between locations avoid false external revenue. Consider numbering, corrections, user access, tax reporting and historical retrieval together.
Do not turn a technical split into a fictitious legal sale. If software requires internal documents, identify their technical purpose and ensure the approved accounting and tax treatment is preserved. Conversely, do not suppress a required tax document merely because both locations belong to one company.
Own-goods movements across borders need explicit tax and trade review. This guide leaves their legal treatment outside the worked sales example instead of assigning a generic zero-tax code to every transfer.
Work a registration-specific sales example
Assume one French legal entity has valid French and German VAT registrations. All figures are EUR. Tax has approved three ordinary domestic transaction treatments: a French sale of 1,000 net plus 200 VAT, a German sale of 2,000 net plus 380 VAT and a later German credit of 400 net plus 76 VAT.
The example assumes the credit corrects the German sale and uses its original registration context. It contains no exemptions, currency differences, stock transfers, purchases or cash-accounting scheme. Rates and classifications are inputs already approved for these transactions, not rules for every French or German supply.
The French registration's signed sales population is 1,000 net and 200 output VAT, with gross receivables of 1,200. The German registration has net sales of 2,000 minus 400, or 1,600, and VAT of 380 minus 76, or 304. Its gross balance is 1,904.
Across the legal entity, net revenue is 2,600 and output VAT is 504. Receivables total 3,104. The isolated ledger balances: receivables 3,104 equal revenue/profit contribution 2,600 plus tax liability 504.
Route documents and preserve corrections
The posting specification should preserve the seller's relevant own registration, customer registration, supply classification, stock or delivery context and report population. Give tax determination a recorded rationale rather than inferring it solely from the customer's postal address.
Retain the registration selected on a posted document. A later master-data change should not silently relabel the original sale. Corrections need a supported link to the original document and a tax-approved reporting treatment.
For the example, the credit must reduce Germany's population by 400 net and 76 VAT. The legal-entity ledger total alone cannot establish that routing: the same aggregate totals could be produced with the credit assigned to France.
Define the handoff from posted transactions to each report. Where an accountant submits an ERP-generated file, record generation, review, submission and acknowledgement as separate steps. Assign the report owner by registration rather than assuming the entity's headquarters tax team files everything automatically.
Detect a correct total assigned to the wrong country
Suppose the German credit is routed to France. The entity's combined revenue remains 2,600 and VAT remains 504, so a company-wide check passes.
France now incorrectly shows net sales of 600 and VAT of 124. Germany incorrectly shows 2,000 and 380. The German population is overstated by 400 net and 76 tax, and the French population is understated by the same amounts.
The reporting operator compares each document's own-registration context to its original invoice reference and flags the mismatch. Tax determines the correct report period and correction route. The application owner corrects the mapping or source treatment through the supported process, then both registration reports are regenerated and reconciled.
Do not repair one return with an unlinked spreadsheet adjustment and leave the ERP exporting the same wrong record next period. If a temporary manual correction is necessary, preserve its identifier and the rule preventing repeat inclusion.
Complete the architectural acceptance
The tax owner approves registration applicability and transaction routing. The local controller accepts the single legal entity's complete accounts. The application owner implements the company and registration structure; report owners accept each output and its filing evidence.
Before completion, confirm:
- Legal entity, establishments, warehouses and own/customer registrations are separately represented.
- The proposed product feature covers the required own-registration scenario.
- Foreign-country functions outside that feature have an explicit solution.
- Sales and credits remain tied to their approved registration context.
- Each registration reconciles independently before company totals are combined.
- Technical internal documents do not create fictitious external revenue.
- Manual report corrections have controlled return-to-source handling.
Retain the architecture decision, tested routing examples and report bridges. Use company registration, VAT and permanent establishment for the legal distinctions and local statutory accounts for the complete entity reporting process.
Source verification date: 17 October 2026. No live Finance or Business Central configuration was executed, and no blanket country-per-company rule is proposed.
Worksheet: Multiple VAT registration routing worksheet
Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment.
Show the worksheet
Use with the multiple-registration guide. One legal entity may have multiple approved tax identities; this worksheet does not establish registration obligations.
Registration and route
- Legal entity and each own VAT registration, validity and evidence:
- Warehouse, dispatch, destination and transaction category:
- Approved own registration, tax treatment and reporting population:
- Customer VAT ID validation, separate from seller registration:
- ERP family/version, reporting prerequisites and owner:
Invoice-to-return reconciliation
For each invoice and credit record legal entity, own registration, document ID, net/tax/gross and intended return. Reconcile totals per registration and then reconcile their sum to the entity ledger. Investigate routing even where company totals balance.
Rehearsal: France1,000 net/200 tax; Germany2,000/380 less German credit400/76. Final France1,000/200, Germany1,600/304; entity2,600 net plus504 tax equals3,104 receivable.
Failure and sign-off
Move the German credit incorrectly to France in a test copy. Entity totals remain unchanged, but France becomes600/124 and Germany2,000/380. Prove the registration-level control detects both errors.
- Tax owner approval of route and treatment:
- Accounting reconciliation and adjustments:
- ERP/reporting evidence and unresolved limitations:
- Controller sign-off:
Related on this site
- Country pages: key facts with sources
- E-invoicing matrix: country × ERP support
- All guides
Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17.
Related: Glossary – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).
Page last updated: · Markdown version