A business customer from the Netherlands puts goods into the basket, enters a VAT identification number and expects a net price. Whether the shop may show that net price is decided in the seconds that follow - not by marketing, but by an interface of the German Federal Central Tax Office. A REST interface has been available for automated bulk queries since 1 July 2025 (Bundeszentralamt für Steuern); the previous endpoint for XML-RPC queries was switched off on 30 November 2025 (Bundeszentralamt für Steuern). In parallel the VAT application decree was amended: since 20 July 2025 (Bundeszentralamt für Steuern) confirmation requests are only possible online through the authority's website or through the interface it provides, and written or telephone requests are no longer processed. Build the checking path properly into the order process and you deliver tax-free and can prove it. Cut it short and, in our experience, you end up carrying the tax yourself.
Key takeaways
- The number decides the price: an intra-Community supply is exempt only if the customer has used a valid VAT identification number issued by another member state (§ 6a UStG).
- Two stages in a fixed order: a simple confirmation is required before a qualified one (Bundeszentralamt für Steuern); only the qualified stage matches company name, town, postcode and street.
- The shop has to tell 26 status messages (eVatR interface) apart. Exactly one of them is a result, ten are notices and fifteen are errors - a blanket valid or invalid lumps together precisely the cases that cost money.
- The exemption hangs on the report: it does not apply if the recapitulative statement is missing or incorrect (§ 4 UStG). It is submitted by the 25th day (§ 18a UStG) after the end of the reporting period, and quarterly up to 50 000 euros (§ 18a UStG) per quarter.
- The company keeps the evidence itself: the tax office sends no written confirmation notice (Bundeszentralamt für Steuern). What has to be retained is the received data record with request timestamp, status and technical identifier.
Why the number in the checkout decides the price
Selling to business customers elsewhere in the EU means two prices for the same goods: the gross price including German VAT and the net price without it. Which one applies does not depend on the customer's wishes but on a condition in the law. For an intra-Community supply, § 6a paragraph 1 number 4 UStG requires the customer to have used, towards the supplier, a valid VAT identification number issued by another member state (§ 6a UStG). The European basis sits in Article 138 paragraph 1 point b of the VAT Directive: the acquirer is registered for VAT purposes in another member state and has communicated that number to the supplier (Mehrwertsteuersystemrichtlinie). The word used is not decoration. A number sitting in a customer account but left unchecked during the order process is a text field in a dispute, not evidence.
Services follow a second mechanism. A service supplied to a taxable person for the purposes of their business is deemed supplied at the place where the recipient runs that business (§ 3a UStG) - the turnover therefore moves to the recipient's country. In the cases of § 13b paragraph 1 UStG the recipient owes the tax if they are a taxable person or a legal entity (§ 13b UStG). For a shop that also sells licences, maintenance packages or configuration work this means one and the same order can contain an exempt supply of goods and a service shifted abroad. Both cases need the same checked number but different invoice wording - and a basket that separates the types of supply before the price is displayed.
Simple or qualified - the difference in one sentence
What the law expects from the shop
The duty to check is not in a single provision; it is spread across several sections that all converge in the order process. § 18e UStG governs who confirms: the Federal Central Tax Office confirms, on request, the validity of a VAT identification number to the entrepreneur together with the name and address of the person to whom that number was issued by another member state (§ 18e UStG). § 6a UStG governs what the confirmation is needed for. § 4 number 1 point b UStG additionally ties the exemption to the recapitulative statement. § 14a UStG determines what has to appear on the invoice, and § 18a UStG by when the report is due. A shop that covers only one of these points creates a gap that, in our experience, only surfaces during a tax audit.
| Provision | What it requires | What has to happen in the shop | If it is missing |
|---|---|---|---|
| § 6a paragraph 1 number 4 UStG | The customer uses a valid number issued by another member state | A query during the order process, not just a field in the customer account | The precondition for the exemption is not evidenced |
| § 18e UStG | Confirmation by the Federal Central Tax Office | A connection to the confirmation interface with an audit trail | No proof of when the check took place |
| § 4 number 1 point b UStG | A correct and complete recapitulative statement | Order data handed over so that the report can be built from it | The exemption falls away for that supply |
| § 14a paragraphs 1 and 3 UStG | Invoice note on reverse charge, both numbers, deadline the 15th of the following month | Invoice text and numbers taken from the order process | Invoice without a mandatory item, deadline unwatched |
| § 13b paragraph 5 UStG | The recipient owes the tax if they are a taxable person or a legal entity | Types of supply separated inside the basket | Wrong tax treatment on mixed orders |
The third point is the one most often underestimated. The exemption for an intra-Community supply carries an express reservation: it does not apply if the entrepreneur has failed to submit the recapitulative statement, or in so far as they submitted it incorrectly or incompletely with regard to the supply in question (§ 4 UStG). The statement is due by the 25th day (§ 18a UStG) after the end of each calendar month; if the total tax base exceeded 50 000 euros (§ 18a UStG) neither in the current quarter nor in any of the four preceding quarters, quarterly reporting is enough. Data quality in the shop therefore helps decide whether the exemption holds - because the report is built from the same order data.
die innergemeinschaftlichen Lieferungen (§ 6a); dies gilt nicht, wenn der Unternehmer seiner Pflicht zur Abgabe der Zusammenfassenden Meldung (§ 18a) nicht nachgekommen ist oder soweit er diese im Hinblick auf die jeweilige Lieferung unrichtig oder unvollständig abgegeben hat
The interface of the Federal Central Tax Office
For automated bulk queries under the VAT internal market control procedure a REST interface has been available since 1 July 2025, and the endpoint previously provided for XML-RPC queries was switched off on 30 November 2025 (Bundeszentralamt für Steuern). Anyone planning an integration today therefore builds against the REST interface; older guides on the web describe a route that no longer exists in that form. One sentence from the authority matters for project planning: the integration of the interface has to be carried out by the company itself and requires corresponding programming knowledge, and the tax office provides no support for it (Bundeszentralamt für Steuern). This work therefore belongs in interface development and not in the tax adviser's inbox.
The query itself is narrow. Two fields are mandatory: your own German number and the number being queried (eVatR interface). The qualified query adds company name, street, postcode and town. Alongside request timestamp and status, the answer carries a technical identifier for the confirmation request and the four matching fields ergFirmenname, ergStrasse, ergPlz and ergOrt (eVatR interface). Anyone holding a German VAT identification number may query, and every query has to state that own German number (Bundeszentralamt für Steuern). A shop that sends the same number for every tenant is therefore formally checking on behalf of the wrong entrepreneur - a mistake easily overlooked in multi-tenant setups.
The heart of the matter
The checking path through the order, step by step
The sequence in the diagram above is not a recommendation but a translation of the rules into decisions an order process has to make. It does not start with the query but with a pre-check inside the shop: country code, length, permitted characters. That saves requests and catches typing mistakes before they come back as an error status. Only then does the request leave the house, in two stages.
Normalise the input
Strip spaces, dots and hyphens, check the country code, unify capitalisation. The interface reports a syntactically wrong number with its own status, but every avoided request is the faster answer.
Simple query
Validity at the time of the request. It has to run before the qualified query (Bundeszentralamt für Steuern) and is the precondition for the second stage being answered at all.
Qualified query
Company name, street, postcode and town are sent along and come back as separate answer fields (eVatR interface). Only then is the number tied to this customer.
Plan for the time window
Maintenance work may take place between 23:00 and 05:00, which can cause delays during that period (Bundeszentralamt für Steuern). Overnight batch runs therefore need a queue.
Store the answer
Request timestamp, status and the technical identifier belong on the order, not in a log file with a deletion schedule. The tax office sends no written confirmation notice (Bundeszentralamt für Steuern).
Check again later
A confirmation applies to the moment of the request. For long-term customers on framework agreements the query therefore belongs in a recurring run, not only in the first order.
Two decisions in the diagram deserve a second look. The first branch does not ask whether the customer entered a number but whether they are based in another EU country: for a domestic customer the number changes nothing about the rate. The last branch decides not on validity but on the depth of the confirmation. If only the simple answer comes back, the price is not necessarily wrong - but the evidence is thinner, and that belongs in the record instead of being quietly accepted. How to model such branches without losing the sale is covered in the article on B2B checkout optimisation.
Status messages the shop has to tell apart
The interface knows 26 status messages (eVatR interface), grouped into result, notice and error. Exactly one of them is a result in the narrow sense, namely the message that the queried number is valid at the time of the request. Everything else is a notice or an error - and the distinction decides whether the customer can complete the order, whether the case lands in a review list, or whether the request simply has to be repeated. A shop that only separates valid from invalid lumps together precisely the cases that call for different reactions.
- Valid at the time of the request: release the net price and store the full answer on the order
- Valid, but a mandatory field of the qualified query is missing: request the address data instead of aborting
- Number not assigned at the time of the request: hold the order and contact the customer directly
- Valid only from a later date: note the date instead of turning the customer away outright
- Your own German number not valid at the time of the request: an operator problem, not a customer problem
- Maximum number of qualified queries per session reached: start again with a simple query
- Processing not possible at present: into the queue, not out to the customer as a rejection
The last point is the most expensive one when it is missing. Several status messages of the interface literally say that processing the request is not possible at present and that it should be attempted again later (eVatR interface). Showing that answer in the order process as an invalid number loses an order to a technical state that says nothing about the customer. The interface's country list holds 28 entries (eVatR interface), among them Northern Ireland under the code XI and Greece under EL - two special cases a hand-maintained country list tends to miss. If you run several country shops, the connections are covered in the article on internationalisation with country-specific shops.
The deadlines that follow from a single check
The evidence: what has to be retained
For the online confirmation procedure the authority describes the evidence like this: by retaining the printout or by taking the result transmitted by the tax office into the company's system in a commonly used format or as a screen capture (Bundeszentralamt für Steuern). For queries through the interface, evidence of a qualified request that has been carried out is to be provided via the data record received from the tax office (Bundeszentralamt für Steuern). A screen capture is obviously the wrong tool in automated operation. What remains is the data record itself - complete, unchanged and tied to the order.
In practice that means the answer is not translated into a yes-no field and then discarded, but stored as a record of its own on the order. That includes the request timestamp, the status, the technical identifier and the four matching fields. It is little storage and a lot of evidential value. If the data is then handed to accounting, the check record should travel with the document; how such a handover is structured is described in the article on the DATEV interface in e-commerce.
{
"order": "B-2026-09-0417",
"customer": "K-3311",
"stufe": "qualifiziert",
"anfragendeUstid": "DE_own_number",
"angefragteUstid": "NL_customer_number",
"anfrageZeitpunkt": "2026-09-16T09:41:12+02:00",
"status": "evatr-0000",
"meldung": "Die angefragte USt-IdNr. ist zum Anfragezeitpunkt gültig.",
"id": "technical-id-of-the-confirmation-request",
"abgleich": {
"ergFirmenname": "matches",
"ergStrasse": "matches",
"ergPlz": "matches",
"ergOrt": "matches"
},
"folge": {
"tax": "no German VAT shown",
"invoice_note": "Steuerschuldnerschaft des Leistungsempfängers",
"invoice_due": "2026-10-15",
"recapitulative_statement_due": "2026-10-25"
}
}One point is frequently overlooked: no data on VAT identification numbers of other EU member states is stored in Germany, and the tax office forwards confirmation requests directly and automatically to the authorities of the respective member states (Bundeszentralamt für Steuern). An answer therefore also depends on availability in the target country. That is not an argument against checking but one for a queue with retries - and for not letting a customer fail because of somebody else's system fault.
Reverse charge on the invoice
The checked number carries through to the invoice template. If the entrepreneur carries out a supply for which the recipient owes the tax in another member state, they are obliged to issue an invoice stating Steuerschuldnerschaft des Leistungsempfängers, unless a self-billing arrangement has been agreed (§ 14a UStG). For an intra-Community supply the VAT identification number of the supplier and that of the recipient have to be stated as well (§ 14a UStG). The note is therefore not a question of wording but a mandatory item - and it belongs in the same template from which the structured invoice is built.
This is where the VAT logic meets the invoicing chain. Building the two separately means maintaining the same fact in two places: once in the shop and once in the invoice template. The more durable route runs the other way - the order process sets the tax outcome and the invoice reads it. What this means for the structured invoice is set out in the article on the e-invoicing mandate and ERP integration; the overview of formats and timing is on our page about e-invoicing.
Rolling it out in stages
A complete checking path can rarely be introduced in one go, because it touches shop, ERP and accounting at the same time. In our experience it works well to order the stages so that each one carries a benefit of its own and none blocks the others if the next stage only arrives later.
- Input field and pre-check in the order process: format, country code, normalisation. This cuts the number of failed requests before any interface is connected at all.
- Simple query in the order process, result stored on the order. From here on an audit trail with timestamp and status exists.
- Qualified query with company name, town, postcode and street, triggered from the address data in the customer account.
- Tie pricing to the result: net display only with a confirmed number and a matching country of delivery, otherwise gross.
- Feed the invoice template and the recapitulative statement from the same record instead of maintaining both separately.
- Recurring re-checks for existing customers on framework agreements, with a queue for the times when maintenance work may occur.
Each stage can be verified on its own, and none assumes the next one is already in place. If you are extending an existing installation, the first two stages can usually be implemented without touching the ERP; tying them to pricing and reporting then belongs in Shopware development and in the discussion with your tax adviser. If the checking logic is also to live in a customer portal, the frame for that is covered under B2B portals.
What comes up after the first months
Two topics tend to trail behind the VAT check. First the pricing side: if net prices are tied to daily quotations or to an index, the tax decision has to line up with the price calculation, otherwise the confirmed net amount drifts away from the calculated one - the article on daily prices and index linking in the B2B shop appears this week. Second the year end: open orders with a checked but not yet invoiced delivery are a case of their own on the cut-off date, which the article on stocktaking and the year-end in the B2B shop picks up.
It is also worth looking at two checks that sit in the same order process and draw on the same master data: sanctions screening in the shop and the control of payment methods and credit limits. All three decide on the same basket, all three need an audit trail, and all three fail at the same point when they are built as downstream manual work. If you want to set the interplay up in an orderly way once, our e-commerce consulting provides the frame.
Sources and studies
Related Articles
Hazardous Substances in the B2B Shop: Labelling and SDS
Pictograms, hazard and precautionary statements, safety data sheets per language and version, supply blocks: how to map hazardous substance data in a B2B shop.
Cyber Resilience Act: B2B Shop Duties From September
From 11 September 2026 the CRA reporting duty in Article 14 applies. Which duty starts when, who is a manufacturer and what must be visible in a B2B shop.
Batch and Serial Number Traceability in B2B Shops
Batch, serial number and certificate in the B2B shop: how traceability moves from the ERP into shop and portal, and how a recall takes minutes, not days.