Photo: free stock photography (Unsplash licence) — see imprint
The three questions that decide the rate
Where are you established, where does the customer receive the goods, and is the customer a business with a valid VAT ID? Almost every B2B tax rule in the EU falls out of those three answers. Encode them explicitly instead of hard-coding 19%.
Validate the VAT ID, and store the proof
Reverse charge only applies with a valid VAT ID at the time of sale. Validate against VIES, and store the timestamped result with the order. When the auditor arrives two years later, that stored proof is the entire difference between a clean answer and a bill.
Rounding is a legal question, not a maths one
Rounding per line item versus per invoice total produces different results, and your ERP and your shop must agree on which. A one-cent difference across 10,000 invoices is not a rounding error to a tax office — it is a discrepancy.
Never let the shop be clever
Tax logic belongs in one place, ideally the ERP or a dedicated tax service, with the shop displaying what it is told. Two systems independently calculating tax will drift apart, and you will discover it in an audit rather than a test.
- Establishment, destination, VAT ID — encode all three.
- Store timestamped VIES validation with the order.
- One system owns tax. The shop only displays it.
Frequently asked questions
One of them, never both. Tax logic belongs in a single place — usually the ERP or a dedicated tax service — with the shop displaying what it is told. Two systems calculating independently will drift apart, because a rule gets updated in one and forgotten in the other, and you find out in an audit rather than in a test. This is an architecture decision, not a tax opinion.
It works until it does not, and then it is retroactive. A fixed rate is a guess that the answer never depends on anything — but the rate follows from where you are established, where the customer receives the goods, and whether the customer is a business with a valid VAT ID. Model those three inputs explicitly so the system can be corrected when rules change. Which rate applies to you is your Steuerberater's call.
Because the exemption depends on the ID being valid at the time of sale, and two years later nobody can reconstruct that from memory. Validate against VIES and store the timestamped result on the order itself, not in a log that rotates away. When an auditor asks, that stored proof is the difference between a clean answer and an argument. Whether your specific sales qualify is a question for your Steuerberater.
Almost always rounding. Rounding per line item and rounding on the invoice total produce different results, and if your shop does one while your ERP does the other, every order carries a small disagreement. Across ten thousand invoices a tax office does not read that as a rounding error — it reads it as a discrepancy. Agree on one method, in writing, and make both systems implement that one.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer