Austria's standard VAT rate is 20%, with reduced rates of 13% and 10% and a 4.9% rate that applies to basic foods. For SaaS and most B2B billing, you'll start from that 20% default because electronically supplied services don't sit in the reduced categories, then you decide whether customer status, location, or an exemption moves you away from it.
That decision is where billing code usually breaks. You find an Austrian customer in Stripe, someone asks why VAT wasn't charged, and suddenly a single percentage turns into questions about place of supply, VAT ID validity, and invoice fields you never stored.
Table of Contents
- Why Austrian VAT Matters to Your Billing Stack
- The Austrian VAT Rate Ladder at a Glance
- How Austria Reached the 20% Standard Rate
- Austrian Invoice Fields Every Billing System Needs
- Reverse Charge and B2B SaaS Billing to Austria
- Place of Supply and Cross-Border EU Scenarios
- The 2025 Small-Business Exemption Threshold Change
- Why Developers Wrap VAT Validation Instead of Calling VIES Directly
- Quick Reference Card for Austrian VAT
- Common Austrian VAT Edge Cases Answered
Why Austrian VAT Matters to Your Billing Stack
Most developers meet the Austria VAT rate problem backwards. A customer signs up, pays, and then finance asks for a corrected invoice. At that point you're not choosing a rate, you're rebuilding evidence you should've collected at checkout.
Treat Austrian VAT as a decision sequence, not a constant in a config file. Your code needs to answer three questions in order before it prices anything.
The Three Questions Before Pricing
- What's being sold: A subscription, an ebook, accommodation, and basic food don't share the same treatment, so product classification comes first.
- Who's buying: A consumer and a business with a valid VAT ID follow different paths, and you'll need proof, not a self-declared checkbox.
- Where's the supply taxed: Customer location drives the outcome for digital services, which is why address and evidence fields matter at signup.
If you hardcode 20% for every Austrian transaction, you'll overcharge some B2B customers who should've been reverse charged. If you zero-rate anyone who pastes a plausible looking VAT number into a form, you'll undercharge and own the liability.
Practical rule: Never let the invoice generator be the first place your system learns the customer's VAT status. Capture it during onboarding, validate it before the first charge, and store the result with a timestamp.
The rate ladder itself is small. The hard part is knowing which rung applies, and building your checkout so that answer is recorded before money moves.
The Austrian VAT Rate Ladder at a Glance
Austria runs four rates you'll encounter in practice. The Austrian government lists the general rate and the reduced categories on its official VAT rates and exemptions guidance, which sets out a 20% standard rate, 10% and 13% reduced rates, and a 4.9% rate for basic foods such as bread, butter, eggs, and milk.
Austrian VAT Rates by Category
| Rate | Common Categories | Typical Examples |
|---|---|---|
| 20% | Standard goods and services, electronically supplied services | SaaS subscriptions, consulting, most digital products |
| 10% | Residential rentals, accommodation, books, newspapers, magazines, foodstuffs | Hotel stays, printed books, groceries |
| 13% | Living animals, plants, firewood, artistic activities, film or circus performances | Plants, firewood, certain cultural admissions |
| 4.9% | Specified basic foods | Bread, butter, eggs, milk |
Why SaaS Defaults to the Top Rung
Electronically supplied services generally don't qualify for the reduced categories. That's the single most useful sentence in this guide for a software team. Your subscription, API credits, and hosted platform fees start at 20% for Austrian taxable consumption unless another rule, such as reverse charge for a qualifying business customer, changes who accounts for the tax.
Don't let a mixed catalog blur this. If you sell a subscription bundled with a printed manual or an in person workshop, you've got separate supply components to classify. Splitting them in your product table now is cheaper than untangling composite invoices during an audit.
Build your rate logic as a product category to rate mapping, not as a country level default with exceptions sprinkled through checkout code. Country tells you which ladder to use. Category tells you which rung.
How Austria Reached the 20% Standard Rate
If you're auditing an inherited tax table and you find 18% for Austria, you're not looking at a typo. You're looking at history that nobody cleaned up.
The timeline below shows how the standard rate moved to its current level.
Austria introduced VAT in 1973 at 16%, raised it to 18% in 1983, and moved to 20% in 1984, as documented in the OECD consumption tax trends overview for Austria. The same source notes a regional 19% rate in Jungholz and Mittelberg under special arrangements.
What to Flag in a Legacy System
- Any 16% value: That's the original rate from five decades ago and has no place in current checkout logic.
- Any 18% value: That's a pre 1984 leftover, often copied between spreadsheets and seed data for years.
- Missing regional handling: Most SaaS sellers will never need the Jungholz and Mittelberg exception, but you should know it exists before you assume every Austrian postcode behaves identically.
The stability since 1984 is good news. You're not chasing a rate that changes every budget cycle. Store 20% as a dated, versioned value anyway, because the cost of a rate history table is trivial and it protects you when finance asks why an old invoice used a different number.
Keep rate history and VAT ID validation as separate concerns in your schema. One tells you how much to charge. The other tells you who you're charging.
Austrian Invoice Fields Every Billing System Needs
An Austrian invoice isn't a PDF template problem. It's a data model problem, and the fields below need to exist in your database before you render anything.
Your system should store the taxable amount, the applicable VAT rate or exemption reference, the VAT amount in euros, a sequential invoice number, and the issue date. It also needs supplier and customer names and addresses, plus a description or quantity of the supply.
The EUR 10,000 Threshold
An Austrian-established supplier must show the customer's VAT identification number when the invoice total exceeds EUR 10,000, and that ID also matters for reverse charge and intra-Community supplies, per the Austrian Finance Ministry invoicing guidance. Read our breakdown of VAT invoice requirements if you want the field definitions in one place.
That threshold creates a trap for annual SaaS contracts. A monthly plan stays small, then a customer upgrades to an annual enterprise deal and crosses the line on a single invoice. If VAT ID collection only happens at signup for self-serve plans, your biggest invoices are the ones missing required data.
- Collect early: Ask for the VAT ID during onboarding for every B2B account, not when an invoice crosses a threshold.
- Validate before issuing: A syntactically plausible number isn't proof of business status, so check it before you rely on it.
- Store the exemption reference: If no VAT is charged, the invoice needs to say why, and that reason belongs in structured data.
Teams on commerce platforms sometimes delegate parts of this to tooling such as PlatformDTC's tax application, which can help where your platform supports it. Whatever you use, verify the exported invoice carries every field above.
For a standard SaaS invoice, imagine a monthly subscription line with quantity, net amount, rate applied, and VAT amount in euros, sitting under sequential numbering that never reuses a value. If your billing provider can't guarantee gapless sequence control where you need it, generate invoice numbers in your own service.
Reverse Charge and B2B SaaS Billing to Austria
Reverse charge is where the 20% default gets switched off, and it's also where teams make their most expensive mistake. They treat a valid VAT ID as a magic token that automatically zeroes the invoice.
It isn't. Validation and rate determination are two separate operations. A confirmed Austrian VAT number supports the claim that your customer is a business. It doesn't by itself decide the place of supply or prove that this particular transaction qualifies for reverse charge treatment.
The Conditions Your Code Should Check
- Customer is a business: You hold a VAT ID that validated successfully, with the validation result and date stored on the account.
- Transaction is B2B: The purchase is for business use, not a consumer borrowing an employer's number at checkout.
- Place of supply supports it: The supply falls under the relevant cross-border or domestic reverse charge conditions for your situation.
Our reference on reverse charge VAT covers the mechanism itself if you need the underlying concept before wiring it into billing logic.
Suppress VAT only when every condition is satisfied and recorded. If any check fails or comes back inconclusive, fall back to charging VAT and let the customer correct their details for the next invoice.
A Worked B2B Subscription Example
Say an Austrian company buys your annual plan and provides a VAT ID that validates. Your invoice shows the net amount, no VAT charged, both VAT numbers where required, and a clear reverse charge note stating the customer accounts for the tax. The VAT amount field reflects that nothing was charged, and your exemption reference field carries the reason.
Now change one fact. The VAT ID fails validation. Same customer, same plan, but you charge Austrian VAT instead and notify the customer to fix their details. That's the safe failure mode, and your code should reach it automatically without a support ticket.
Revalidate periodically, too. A number that was fine at signup can be deregistered later, and a stored valid flag from two years ago isn't evidence today.
Place of Supply and Cross-Border EU Scenarios
Where your customer sits often matters more than where your company sits. The image below captures the mental model most cross-border sellers end up building, with billing logic keyed to customer location.
For digital services sold to consumers, the customer's location generally determines which country's VAT applies. For B2B supplies, customer location still anchors the analysis, but reverse charge can shift who reports the tax. Our explainer on place of supply walks through how that determination is structured.
Routing Each Transaction
- Austrian consumer: Expect Austrian VAT on your digital service, handled through your registration or the One-Stop Shop route where it applies to you.
- Austrian business with valid VAT ID: Reverse charge becomes the candidate treatment, subject to the checks described earlier.
- Non-EU seller: Don't assume distance exempts you. Cross-border digital sales into the EU pull foreign sellers into EU VAT mechanics quickly.
The video below gives useful background on how these cross-border flows fit together before you encode them.
Collect location evidence at checkout, not just a country dropdown the user can set arbitrarily. Billing address, IP-derived country, and payment details won't always agree, and your system needs a rule for which signal wins and a log of what it used.
The gap between a correctly formatted VAT ID and a registered one is exactly where automated validation earns its place. Format checks catch typos. Registry checks catch fiction.
The 2025 Small-Business Exemption Threshold Change
The claim you'll see everywhere is that Austria's small-business exemption is now €55,000. That sentence is incomplete in a way that will break your billing logic if you encode it as written.
Austria raised its national threshold from €35,000 to €55,000 effective 1 January 2025, while EU-established businesses using the cross-border SME scheme must also stay within the €100,000 Union-wide threshold in both the current and preceding calendar year, according to the Austrian government guidance for EU businesses on the small-business exemption.
The Tolerance Asymmetry Nobody Mentions
Exceeding the Austrian threshold by no more than 10% can preserve the exemption through the end of that year. The Union-wide threshold has no equivalent tolerance. Cross it, and the turnover that crosses it becomes taxable.
Engineering implication: Two thresholds, two different failure behaviors. If your data model has a single exempt boolean, it cannot represent this correctly.
What Your System Needs Instead
- Rolling calendar-year turnover tracking: Exemption status depends on accumulated turnover in the current and preceding year, so you need running totals, not an onboarding answer.
- Country-specific exemption state: A seller can be exempt in one member state context and taxable in another, so store state per country.
- A transition path: When a threshold is crossed mid-year, pricing, registration, and invoicing behavior all change, and your code needs a defined switchover point.
Remember what exemption means operationally. No VAT may be charged, and no input tax deduction is available. For a business with substantial VAT-bearing costs, staying exempt isn't automatically the winning move, which is a conversation for the founder and their accountant, not a default your signup flow should impose.
The Austria VAT rate itself didn't change here. What changed is who gets to charge zero, and that eligibility now moves as turnover accumulates. Build for a state that expires, because that's what exemption is.
Why Developers Wrap VAT Validation Instead of Calling VIES Directly
Every team starts with the same plan. Call the EU's VIES service, check the number, move on. Then they meet the SOAP interface, the inconsistent country responses, and the outages that arrive without warning during someone's checkout.
Building the wrapper yourself means owning format checks per country, retry logic, caching, error normalization, and monitoring for a service you don't control. None of that work differentiates your product. All of it pages you at inconvenient times.
The Real Comparison
Calling VIES directly costs nothing per lookup and everything in maintenance. You parse brittle responses, guess at error semantics, and decide what your checkout does when the registry is down. Block the purchase, or let it through and reconcile later? You'll have to answer that under pressure.
Using a validation API moves that burden behind a REST endpoint. A service like TaxID, for example, wraps VIES with country-specific format checks before remote calls, cached responses, and machine-readable error codes your code can branch on. That's one option among several, and the category matters more than the vendor.
Judge the decision on infrastructure terms.
- Checkout latency: Validation sits in a latency sensitive path, so caching behavior matters.
- Failure semantics: You need distinct outcomes for invalid number, format error, and registry unavailable, because each demands different UX.
- Audit trail: Whoever validates, you must store the result, timestamp, and returned registration details yourself.
If your volume is tiny and you enjoy maintaining SOAP clients, build it. Teams I've seen reach the opposite conclusion after the first unexplained VIES outage during a launch week.
Quick Reference Card for Austrian VAT
Keep this open while you code.
- Standard rate: 20%, your default for SaaS and digital services
- Reduced rates: 10% and 13% for specified categories, 4.9% for basic foods
- Invoice VAT ID trigger: Customer VAT ID required above EUR 10,000 for Austrian-established suppliers
- Small-business thresholds: €55,000 national, €100,000 Union-wide for the cross-border SME scheme
- Reverse charge order: Validate VAT ID first, then confirm place of supply and B2B conditions, then suppress VAT
- Failure mode: Validation fails, charge VAT and let the customer correct their details
Common Austrian VAT Edge Cases Answered
Zero-rated versus exempt. Both produce an invoice with no VAT charged, but they're different treatments with different consequences for input tax recovery. Store which one applies, because your reporting will care even if the customer doesn't.
The regional 19% rate. For typical B2B SaaS billing it's background noise. Know that Jungholz and Mittelberg exist, don't build special casing until a real customer forces the question.
VIES returns an error. Distinguish an invalid number from an unavailable registry. Retry the second, reject the first, and never treat an error as a validation pass without notice.
Foreign seller registration. Selling digital services to Austrian consumers can pull you into Austrian or One-Stop Shop obligations regardless of where you're based. Get advice before your first B2C sale, not after your hundredth.
If you're wiring Austrian VAT ID checks into signup, checkout, or invoicing, TaxID gives you a single REST endpoint that validates VAT numbers and returns the registered company name and address in clean JSON, without you maintaining a VIES wrapper. Start with the free tier, store every validation result alongside your invoice data, and let your billing code branch on clear error codes instead of parsing registry responses at 2 a.m.