Dimitri set up his PrestaShop tax rules groups himself, three years ago, when he started shipping ceramics from his Thessaloniki workshop into Cyprus, Bulgaria, and Romania. He tested every country's checkout carefully, confirmed the VAT totals matched what he expected, and moved on. Every order since has calculated tax correctly — Cypriot customers see 19%, Bulgarian customers see 20%, Romanian customers see 19% (now aligned after Romania's 2025 rate changes), applied automatically, no complaints, no checkout errors. He assumed that meant he was compliant. He wasn't. He crossed the €10,000 distance-selling threshold fourteen months before an accountant doing an unrelated review flagged that he'd never filed a single OSS return in that entire period.
The checkout was never the problem. The problem was that he'd conflated two jobs that sound like the same thing but aren't: applying the correct VAT rate to a transaction, and declaring that VAT to a tax authority. PrestaShop, out of the box plus correctly configured tax rules, does the first one well. It does nothing at all for the second.
Two separate jobs: applying tax vs declaring tax
Applying tax happens at checkout, automatically, transaction by transaction, the instant an order is placed. Declaring tax happens quarterly, in a batch, through a government portal, and it requires a human — or a piece of accounting software — to pull the aggregated numbers together and submit them. Nothing about PrestaShop's architecture connects these two processes. A tax rules group calculating 19% on a Cypriot order has no awareness that a return covering that order is due by the end of the following quarter, and it has no mechanism to file anything anywhere.
| Applying tax (checkout) | Declaring tax (OSS return) | |
|---|---|---|
| When it happens | Instantly, per transaction | Quarterly, in a batch |
| Who/what does it | PrestaShop tax rules engine | Merchant or accounting software, manually |
| What it produces | A VAT amount on an invoice | A filed return with a tax authority |
| Failure mode if broken | Wrong VAT charged to customer | Correct VAT charged, never reported — no filing exists |
| Visible to the merchant? | Yes, immediately, on every order | No — nothing in the storefront shows a missed filing |
That last row is the dangerous one. A checkout misconfiguration is usually visible fast — a customer complains, or a number looks obviously wrong. A missing OSS filing is invisible from inside the store. There's no error message, no failed order, nothing in the PrestaShop admin that flags "you owe a return." The only way most merchants find out is an accountant catching it, or a tax authority doing it for them.
How PrestaShop's tax rules groups actually work
Tax rules groups in PrestaShop map a country (or state, for some regions) to a VAT rate and apply it based on the customer's shipping or billing address, depending on configuration. Set up correctly, this is a genuinely solid piece of engineering — it handles multiple rates, exceptions, and product-specific rules well. But it's scoped entirely to the transaction in front of it. It doesn't track your cumulative EU-wide cross-border sales total. It doesn't know you crossed €10,000 in April. It doesn't generate a quarterly summary unprompted, and it certainly doesn't submit anything to a tax portal. All of that sits outside the platform, in a workflow the merchant has to build or buy separately — through an accounting integration, a bookkeeper, or a dedicated OSS filing tool.
Where the gap opens up
The gap tends to open at three specific moments:
- The threshold crossing itself. Nothing alerts you the moment cumulative cross-border sales hit €10,000 — you have to be tracking it deliberately. We cover the mechanics of that threshold and how to monitor it in the 2026 guide to EU OSS audit-readiness.
- Staff turnover. Whoever originally set up the tax rules groups understood the OSS obligation existed as a separate step. Two years later, a new hire manages the storefront and has never heard of OSS, because nothing in the admin panel mentions it.
- Rate changes. A destination country changes its VAT rate, checkout keeps using the old one because nobody updated the tax rules group, and the eventual OSS return — if one gets filed at all — doesn't match what was actually collected.
Reverse charge and B2B sales: another layer
Business customers add a further wrinkle. For B2B intra-EU sales where the buyer provides a valid VAT number, the reverse charge mechanism often applies instead of the seller charging VAT at all — the buyer self-accounts for VAT in their own country. This is a different rule from OSS entirely, and it depends on validating the buyer's VAT number, typically through the EU's VIES lookup system, before deciding whether to charge VAT or not. A store that treats every intra-EU sale as B2C by default, without a VAT-number validation step for business buyers, either overcharges VAT it shouldn't have collected or fails to document why a B2B sale was zero-rated — both of which create exactly the kind of reconciliation gap an auditor looks for.
Closing the gap: a practical workflow
The fix isn't complicated, but it needs to be deliberate rather than assumed:
- Assign someone — not "whoever's around" — explicit quarterly ownership of the OSS filing, with a calendar reminder two weeks before each deadline.
- Separate the checkout configuration review (are tax rules groups current?) from the filing review (has this quarter's return actually been submitted?) as two distinct recurring tasks.
- Reconcile aggregated sales-by-country figures against what was actually filed, every quarter, not just when something looks off. Our step-by-step on breaking down the OSS declaration walks through that aggregation directly.
- Validate B2B customer VAT numbers at checkout or order processing, and keep the validation result on file as evidence for any reverse-charge sale.
- Document the workflow itself, so it survives staff changes instead of living in one person's head.
Checklist: is your store actually declaring, not just applying?
- [ ] Someone is explicitly responsible for quarterly OSS filing, by name
- [ ] Filing history for the last four quarters has been checked and matches expectations
- [ ] Tax rules groups reviewed against current destination VAT rates in the last 90 days
- [ ] B2B VAT numbers validated and reverse-charge sales documented separately
- [ ] A written note exists explaining the checkout-vs-filing split, for whoever inherits this role next
Confirm your last four filings actually happened
If you've never explicitly checked whether your last four OSS filings actually happened — not whether checkout looked right, whether a return was submitted — do that check this week. It takes ten minutes and it's the single highest-value audit Dimitri could have run at any point in those fourteen months. For the mechanics of what a correction looks like if you do find a gap, see correcting VAT errors and handling returns in OSS.
Frequently asked questions
If PrestaShop calculates VAT correctly, am I automatically compliant?
No. Correct checkout calculation only covers the "applying tax" half of the obligation. Declaring that VAT through a quarterly OSS return is a separate, manual step that PrestaShop doesn't perform, and skipping it leaves you non-compliant even with a flawless checkout.
How would I know if I've missed an OSS filing?
Usually you wouldn't, from inside the storefront — there's no built-in alert. The only reliable way is to keep an explicit filing log and check it every quarter, or have an accountant periodically confirm filings against your sales data.
Does reverse charge mean I don't need OSS at all for B2B sales?
Reverse charge applies specifically to B2B intra-EU sales where the buyer has a valid VAT number and self-accounts for VAT — it's a different mechanism from OSS, which covers B2C sales. Most stores need to handle both, applied to the correct transaction type.
How do I validate a business customer's VAT number?
Through the EU's VIES (VAT Information Exchange System) lookup, which confirms whether a VAT number is currently valid and registered. Keep a record of the validation result and date for every reverse-charge sale you don't charge VAT on.
Can a rate change break compliance even if nothing on my site changed?
Yes. If a destination country updates its VAT rate and your tax rules group isn't updated to match, checkout keeps charging the old rate. That's a compliance gap that originates entirely outside your store, but it's still your responsibility to catch.
Who should own the quarterly OSS filing task in a small store?
Whoever manages the books — usually the owner or a bookkeeper — should own it explicitly, by name, with a recurring calendar reminder set well before each deadline. Ambiguous ownership, where "someone will handle it eventually," is exactly the pattern that leads to a missed filing nobody notices until an accountant asks about it later.
Compliance glossary
Reverse Charge: A mechanism where a VAT-registered business buyer, rather than the seller, accounts for VAT on an intra-EU B2B transaction, typically after providing a valid VAT number checked via VIES.
One-Stop Shop (OSS): The EU scheme for declaring VAT on cross-border B2C sales through a single quarterly return, separate from and in addition to correctly calculating VAT at checkout.
Destination-based VAT: Charging VAT at the customer's country rate for B2C sales once the distance-selling threshold is exceeded — the rule PrestaShop's tax rules groups are configured to apply.
Tax Point: The date a supply is treated as taking place for VAT purposes, relevant to which quarterly return a transaction belongs in.
Distance Selling Threshold (€10,000): The EU-wide combined annual threshold that triggers the shift from domestic to destination-based VAT and the associated OSS reporting obligation.
Related reading
- The 2026 Guide to EU OSS: Is Your Store's VAT Reporting Audit-Ready?
- Breaking Down the OSS Declaration: A Step-by-Step for E-commerce
- Correcting VAT Errors: Handling Returns and Refunds in OSS
- Preparing for Future VAT & OSS Changes in Europe
- Complete EU Compliance Checklist for Online Stores
