Which VAT rate a B2B shop applies at checkout is not decided by the shop but by the ERP. Whether it is the standard 19 percent, a tax-exempt intra-community supply with reverse charge under Section 13b of the German VAT Act, or a destination-country rate for distance sales: the basis is the tax codes and tax classification in the master data of SAP, DATEV or Microsoft Dynamics 365, not a second tax table maintained in parallel in the shop. The stakes are high, as the EU VAT gap shows: the compliance gap alone stood at around 128 billion euro in 2023, or 9.5 percent of the theoretical VAT liability (European Commission). This article shows why tax determination belongs in the ERP, how a middleware mirrors it into the checkout instead of duplicating it, and how real-time verification of the VAT ID via the European Commission's VIES system and the German BZSt portal stops invalid orders automatically. We build ERP-driven tax determination as an API service that brings the tax rate, reverse-charge flag and VAT-ID check live into the order process.
Key takeaways
- The correct VAT results from the tax codes and tax classification in the ERP master data, not from a separate tax table in the shop.
- For intra-community B2B supplies, the tax-exempt supply under Section 4(1)(b) and Section 6a of the German VAT Act and the reverse-charge mechanism under Section 13b for cross-border services apply -- both require a valid VAT ID.
- For distance sales under Section 3c, taxation shifts to the destination country once the EU-wide threshold of 10,000 euro is exceeded, settled via the One-Stop-Shop.
- The VAT ID can be verified in real time via VIES and the qualified confirmation service of the BZSt; a negative result stops the order process automatically.
- A middleware mirrors the ERP tax determination into the checkout instead of maintaining tax rates twice -- tighter OSS and e-invoicing obligations in 2026 raise the pressure on consistent tax data.
Why Tax Determination Belongs in the ERP
In B2B trade, the tax rate is not a property of the product alone. Whether a line is billed at 19 percent, at 7 percent or tax-exempt depends on the interplay of the article tax class, customer classification, ship-to country and a valid VAT ID. The ERP is exactly what models this combination: the debtor master carries the customer's tax classification (domestic, EU with VAT ID, third country), the material master carries the article tax class, and from both the system derives, through condition logic, the tax code for the specific business transaction. Anyone rebuilding this logic in the shop maintains the same truth in two places -- with the predictable result that the two drift apart.
The consequences of incorrect tax determination are not cosmetic. An export supply wrongly charged with German VAT makes the offer more expensive and costs orders; a domestic supply wrongly treated as tax-exempt leads to a tax reassessment for the supplier. Accounting and the tax advisor work with the ERP data anyway -- if the shop deviates, a break arises that surfaces at the latest during the handover to DATEV and in the VAT return. The only reliable source for the tax rate is therefore the leading system in which the invoice is also created.
Two tax tables are one too many
Tax code
The ERP derives a tax code per business transaction that determines the rate and posting logic -- from the standard rate to the reverse-charge flag.
Tax classification
The debtor master classifies the customer as domestic, EU with VAT ID or third country. This classification decides the tax treatment.
Article tax class
The material master holds the tax class per article, such as standard or reduced rate. It feeds into every line item.
Ship-to and route
Origin and destination country decide between domestic supply, intra-community supply or export -- the tax rate is never a mere pricing factor.
VAT ID as a condition
No valid recipient VAT ID, no tax-exempt EU supply. The number is a material requirement, not just a form field.
One place to maintain
If the tax logic is maintained only in the ERP and mirrored into the shop, every change takes effect everywhere at once -- with no duplicate upkeep.
Reverse Charge under Section 13b and the Intra-Community Supply
For cross-border B2B business within the EU, the tax liability shifts. Two mechanisms need to be kept apart. When physical goods are supplied to a business in another member state, an intra-community supply exists: it is tax-exempt for the German supplier under Section 4(1)(b) in conjunction with Section 6a of the German VAT Act, while the acquirer taxes the intra-community acquisition in their country. For services and certain supplies to an entrepreneur established abroad, the reverse-charge mechanism under Section 13b applies instead: not the supplying entrepreneur but the recipient owes the tax (German VAT Act).
For the shop, the practical consequence is similar in both cases: the invoice is issued net without German VAT, carries the VAT ID of both parties and a note on the recipient's tax liability or on the tax-exempt intra-community supply. Each case requires a valid recipient VAT ID -- if it is missing or invalid, the basis for the exemption falls away and VAT has to be charged. The overview below classifies the typical constellations.
| Constellation | Tax treatment | VAT ID required |
|---|---|---|
| Domestic B2B | Standard rate 19 percent (or 7 percent) | not included |
| EU B2B, goods supply | Tax-exempt intra-community supply, Section 6a | Yes, valid |
| EU B2B, service | Reverse charge, recipient owes tax, Section 13b | Yes, valid |
| EU B2C, distance sale | Destination-country rate via OSS above 10,000 euro | not included |
| Third country (export) | Tax-exempt export supply, proof required | not included |
For this mapping to work automatically at checkout, the shop has to classify the customer correctly and adopt the matching tax code from the ERP. A business customer from France with a valid VAT ID then sees a net price without German VAT and the reverse-charge note; a private customer from the same country receives the destination-country rate. The prerequisite is a cleanly maintained debtor master, as described in our article on master data synchronization with MDM -- otherwise a wrong customer classification pulls a wrong tax along with it.
The VAT ID carries the exemption
Verify the VAT ID in Real Time: VIES and BZSt
The validity of a VAT ID can be checked centrally. The VIES system (VAT Information Exchange System) of the European Commission is a search query that checks a VAT ID issued by a member state against the national registers (European Commission). For German businesses, the Federal Central Tax Office (BZSt) offers two levels: the simple confirmation query, which only checks validity, and the qualified confirmation query, which additionally matches the name and address of the business partner against the register (Federal Central Tax Office). A German VAT ID consists of the prefix DE and nine digits (Federal Central Tax Office).
For the shop this means: the check belongs in the order process, not in a separate spreadsheet review. A clean flow looks like this:
- Check the format: First the shop validates the VAT ID syntactically -- country prefix and structure must match the stated country before any query runs.
- Real-time query: The number is checked against VIES or the BZSt confirmation service; the qualified variant also matches name and address.
- Store the result: The time and result of the query are recorded in an audit-proof way as the proof required for the exemption.
- Decide in the checkout: With a valid number the net reverse-charge logic is activated; with an invalid number the fallback rule applies.
- Control repetition: Existing customers are re-checked regularly so that a VAT ID deleted later does not silently keep running.
An invalid VAT ID stops the order
def determine_tax(customer, ship_to, erp, vat_check):
# ship_to: 'DE' | EU country | third country
if ship_to == 'DE':
return erp.tax_code(customer, rate='standard')
if is_eu(ship_to) and customer.is_business:
result = vat_check.verify(customer.vat_id) # VIES / BZSt
if not result.valid:
return Decision('stop', reason='vat_id_invalid')
return erp.tax_code(customer, scheme='reverse_charge')
if is_eu(ship_to): # B2C distance sale
return erp.tax_code(customer, scheme='oss', country=ship_to)
return erp.tax_code(customer, scheme='export') # third countryDistance Sales under Section 3c and the 10,000-Euro Threshold
When a merchant sells to private customers in other EU countries, the distance-selling rule under Section 3c of the German VAT Act applies. Since 1 July 2021 a single, EU-wide threshold of 10,000 euro net applies across all cross-border B2C supplies combined (German VAT Act). Below the threshold, tax is due in the country of origin; once it is exceeded, taxation shifts to the destination country, that is, the customer's country. Instead of having to register there individually, merchants can declare and remit the amounts due in a bundled way via the One-Stop-Shop (OSS).
The OSS is no longer a niche procedure. In 2024, more than 33 billion euro was collected via the EU's e-commerce VAT systems, up 26 percent on the previous year, of which over 24 billion euro came through the Union OSS alone (European Commission). By the end of 2024, more than 170,000 businesses had registered for OSS and IOSS (European Commission), and since their introduction in 2021 nearly 88 billion euro in VAT has been collected through these schemes (European Commission). For tax determination in the shop this means: above the threshold, every line needs the correct destination-country rate -- standard rates in the EU range from 17 to 27 percent and have to be right per target country (European Commission).
| Situation | Place of taxation | Handling |
|---|---|---|
| B2C EU turnover below 10,000 euro | Country of origin (Germany) | German VAT |
| B2C EU turnover from 10,000 euro | Customer's destination country | Destination rate via OSS |
| EU B2B with valid VAT ID | Acquirer in the target country | Tax-exempt, reverse charge |
| Waiver of the threshold | Destination country from the first euro | Voluntary OSS use |
For prices in the shop to stay correct, tax determination has to interact with the pricing logic. B2B net prices, B2C gross prices and country-specific rates must not contradict each other -- how prices and taxes are brought consistently from the ERP into the shop is explored in our article on price synchronization in B2B. Distance selling shows particularly clearly why a fixed tax table in the shop does not hold: if a member state changes its rate, the change has to arrive without anyone updating a shop table by hand.
Mirroring the ERP Tax Determination into the Checkout
The viable path is to leave tax determination where it belongs -- in the ERP -- and mirror it into the checkout via a middleware. The shop provides the context (customer, ship-to country, cart, VAT ID), the middleware queries tax codes and tax classification from the leading system, adds the VAT-ID check and returns the tax rate and reverse-charge flag to the checkout. That keeps a single tax logic authoritative, and the shop becomes a display window rather than a second tax engine.
Context from the shop
The checkout passes customer, ship-to address, cart and the entered VAT ID to the middleware -- everything tax determination needs.
Rule from the ERP
The middleware fetches tax codes and classification from SAP, Dynamics or DATEV and applies the same logic that creates the invoice.
Answer into the checkout
Tax rate, net or gross display and the matching legal text go back to the shop -- fast enough not to slow the purchase.
Technically the challenge lies in the response behaviour. Tax determination sits on the critical path of the purchase, so it needs a lean API integration with a clear time limit and a short-lived cache for repeated queries. Just as important is defined fallback behaviour when the ERP or the VIES portal is unreachable. Tax determination shares these patterns with other checkout checks -- for example the credit-limit check from the ERP, which also releases or stops an order in a controlled way.
- One place to maintain: Tax codes and classification are maintained only in the ERP and mirrored into the shop -- no second tax table.
- Time limit with fallback: If the ERP does not respond within a few hundred milliseconds, a defined rule applies instead of a hang.
- Proof of the VAT-ID check: Every query is recorded with time and result in an audit-proof way.
- The same across channels: Shop, procurement portal and quote use the same tax logic because it lives in the middleware.
- Testable with real data: Historical orders can be checked against the rules before tax determination goes live.
The shop should display the tax rate, not invent it. As soon as tax determination stays in the ERP and is only mirrored, the checkout and accounting keep calculating with the same figure.
2026: OSS Obligations and E-Invoicing Raise the Pressure
The regulatory frame tightens in 2026. The EU package VAT in the Digital Age (ViDA) was adopted by the Council of the EU on 11 March 2025 and takes effect progressively until 2035; from 1 July 2030, structured e-invoicing under the EN 16931 standard becomes mandatory for intra-community transactions, accompanied by digital reporting requirements for cross-border B2B business (European Commission). In parallel, the e-invoicing obligation is ramping up in Germany: the obligation to receive has applied since 1 January 2025 for all companies, and the obligation to issue applies from 1 January 2027 for domestic B2B merchants with over 800,000 euro in prior-year turnover (Federal Ministry of Finance). Details on formats and deadlines are summarized in our article on the e-invoicing mandate 2027.
Both developments share the same core: tax data must be structured, consistent and machine-readable. An e-invoice under EN 16931 carries tax rates, tax category codes and the VAT-ID reference as mandatory fields. Anyone forming the tax rate in the shop differently than in the ERP risks a break at exactly this point -- the e-invoice expects the value that is also posted. ERP-driven tax determination is therefore the basis on which the automated DATEV handover and e-commerce accounting works without manual rework.
Tax determination is teamwork with the tax advisor
Implementation as an API Service and Typical Pitfalls
Introducing ERP-driven tax determination follows a manageable sequence. The decisive factor is close coordination with accounting and the tax advisor, because the quality of the rules determines the quality of the tax determination.
From assessment to a productive tax service
- 1
Assessment
Capture the leading system, existing tax codes, classifications and special cases such as chain and drop-shipping transactions.
- 2
Agree the rules
Define with accounting and the tax advisor which constellation triggers which tax code and which legal text.
- 3
Build the interface
Develop the connector to the ERP, the VAT-ID check via VIES or BZSt, and the return of the tax rate to the checkout.
- 4
Test with real data
Check historical orders against the rules, calibrate edge cases and measure the response behaviour under load.
- 5
Go-live and monitoring
Production operation with monitoring of tax rates, reverse-charge ratio and VAT-ID hits, followed by fine-tuning.
Projects reveal recurring mistakes. Planning for them from the start saves expensive rework and avoids wrong tax rates in live operation. The same care with master data and special cases pays off in adjacent processes too, such as the RMA process for returns between shop and ERP and connecting suppliers in drop shipping, where tax determination also has to apply cleanly.
- Fixed tax table in the shop: It lags behind the ERP and leads to wrong invoices when rates change.
- VAT ID as a text field only: Without a real check against VIES or BZSt, the exemption remains without proof.
- No fallback behaviour: If the VIES portal fails, the checkout must not blindly grant the exemption.
- Guessing the customer classification in the shop: Whether domestic, EU B2B or third country belongs in the debtor master, not in an assumption.
- Ignoring the distance-selling threshold: Anyone not monitoring the 10,000-euro limit calculates above it with the wrong country.
- Proofs not archived: VAT-ID queries without audit-proof storage cannot be evidenced later.
Sources and studies