B2B E-Commerce with PrestaShop: VAT Handling, Net Prices and Payment Terms

Selling to businesses on PrestaShop is not "B2C with a company-name field." Business buyers expect to see prices without tax, expect a valid VAT number to remove that tax automatically, and expect to pay 30 or 60 days after the goods arrive rather than at the checkout. PrestaShop has the building blocks for all three — B2B mode, customer groups, tax rule groups, and the outstanding-amount fields — but they sit in four different screens and none of them is wired together by default. This guide is the wiring diagram: exactly which back-office settings turn "B2B mode enabled" into a store that shows net prices, applies the reverse charge to the right customers, and lets approved accounts buy on account.

We will stay tight on the B2B-specific mechanics. The wider EU VAT machinery (OSS/IOSS thresholds, distance-selling rates), the legal rules for showing net versus gross, the invoice PDF, and e-invoicing mandates each have their own depth — they are linked at the relevant point rather than half-explained here, so you get the full treatment of each without this page turning into a tax textbook.

What "B2B mode" actually changes — and what it doesn't

Go to Shop Parameters → Customer Settings and switch Enable B2B mode to Yes (the configuration key is PS_B2B_ENABLE). The reflex is to expect a different store. You don't get one. What you get is extra fields on the customer record — nothing on the storefront changes until you do the rest of the work below.

The fields B2B mode unlocks on each customer (in Customers → Customers → Edit) are:

• Company and SIRET / APE (French registration and activity codes — relabel or ignore for other countries; the VAT number itself lives on the customer's address, in the VAT number field, not here)
• Allowed outstanding amount — the credit ceiling for buy-on-account orders
• Maximum number of payment days — your net-30 / net-60 figure
• Risk rating — an informational flag (none / low / medium / high), not an enforcement rule

So what? These are storage fields. PrestaShop core writes "max payment days" and "allowed outstanding amount" onto the record but does almost nothing with them — it never blocks an order, never calculates a due date, never sends a reminder. The one thing the outstanding-amount field does drive is a read-only back-office Customers → Outstanding report that lists each B2B customer's allowed amount alongside their current balance; it does not stop a buyer from ordering past that ceiling. Knowing which fields are live and which are just notes saves you from assuming the platform is policing credit when it isn't. The credit and payment-term automation is the gap we close in Step 5.

Step 1: Build customer groups around tax treatment, not "size"

The single most common B2B mistake on PrestaShop is one group called "B2B." It can't work, because the group is what drives both price display and which tax rules apply — and a domestic business (VAT charged), an EU business (reverse charge, 0%), and a non-EU business (export, 0%) need three different tax outcomes. Model the groups on the tax scenario, in Customers → Groups:

For every B2B group, set Price display method to Tax excluded. That one setting makes the logged-in buyer see net prices across listings, product pages, cart and checkout, with VAT broken out as its own line at the end. It's how business buyers expect to read a price, and it removes the "is that with or without tax?" hesitation mid-purchase.

The actual reduction for each group (a flat group discount, or per-product Specific Prices) is the pricing layer on top — covered in Step 6. Group first, prices second.

Step 2: Create tax rule groups, then attach them by customer group

Tax in PrestaShop flows through International → Taxes → Tax Rules. A tax rule group maps countries to tax rates; you then assign a tax rule group to each product (the product's Pricing tab). Note that core PrestaShop has no general per-customer-group tax-exemption switch: tax is calculated from the product's tax rule group against the delivery address/country, not by flipping a "no tax" flag on a customer group. Stripping VAT for verified EU and non-EU business buyers therefore requires either a VAT-validation/tax-exemption module, custom tax logic, or address- and product-level tax-rule setup — not a native group setting. For the three B2B scenarios you want, at minimum:

1. Your normal Standard VAT rule group (each country's standard rate) — used by B2C and by B2B Domestic.
2. A 0% / reverse-charge rule group that applies no tax to the relevant delivery countries — combined with Price display method = Tax excluded on the group. Bear in mind that switching the price display to tax-excluded only changes how prices are shown; it does not remove tax liability. Actually applying the zero rate to verified EU and export buyers needs a VAT-validation/tax-exemption module or custom tax logic that assigns the right tax-rule treatment, not a group flag.

There is no native "exempt this group" lever, so the cleanest approach is a module that both moves verified buyers into the right group and applies the appropriate tax-exempt / reverse-charge treatment to their orders: the B2B EU (VAT validated) and B2B Non-EU groups end up with no VAT, while B2B Domestic keeps standard rates. Moving a buyer between groups on its own only changes price display and discounts — it does not change tax liability. So when VIES validation moves a buyer into the EU group (Step 3), the VAT only drops to zero if the module also applies the zero-rate/reverse-charge tax logic, not merely the group reassignment.

The full mechanics of EU rates, tax rule groups, ECB rounding and the OSS scheme are their own subject. If your tax rules aren't set up yet, start with EU VAT rules in PrestaShop tax configuration; if you cross borders to consumers as well as businesses, OSS, IOSS and what your store must handle covers the threshold and registration side this guide deliberately doesn't repeat.

Step 3: Validate VAT numbers against VIES before you zero-rate

The reverse charge is not "trust the customer typed a real number." A valid VAT ID is a substantive condition for the intra-community exemption, so before you zero-rate a supply you should verify the buyer's VAT number and retain proof — commonly by checking it in VIES (the EU VAT Information Exchange System), which is the practical proof method tax authorities accept — and be able to show you checked it at the time of the sale. PrestaShop core does not query VIES. So the default B2B store either zero-rates blind (your liability if the number is bad) or makes someone paste numbers into the VIES website by hand — which doesn't scale and leaves no audit trail.

Manual checking fails on three counts: it bottlenecks order processing, it produces a screenshot rather than a timestamped record an auditor will accept, and it never catches a registration that was valid at signup but deactivated later. The fix is to validate inside the checkout flow. Our Automatic EU VAT Checker queries the VIES service in real time the moment a buyer enters their number, and — this is the part that matters — it does the group reassignment for you:

• Valid number: the customer is moved into your B2B EU group, tax recalculates to 0%, and the VIES response (timestamp, consultation number) is stored against the record as your audit proof.
• Invalid number: standard VAT stays applied; the buyer can correct the number or proceed paying full VAT.
• VIES unavailable (the service has scheduled downtime): you choose the fallback — apply standard VAT as the safe default, or accept pending re-validation.

So what? The validation record is the whole point. When a tax authority asks why invoice #4012 carried 0% VAT, you produce the stored VIES confirmation for that order rather than hoping a customer's number is still good two years later. Format-check the number before the API call (each member state has its own pattern — DE is 9 digits, FR is two characters plus 9 digits, NL ends in B + two digits) so obviously malformed numbers never burn a VIES request.

One trap worth flagging: since 1 January 2021 the UK is not in the EU VAT area. Sales to UK businesses are exports, not intra-community supplies; GB numbers validate through HMRC's service, not VIES, and the EU reverse charge does not apply — except Northern Ireland goods movements, where Northern Ireland keeps special EU VAT treatment for goods and uses XI VAT numbers that can validate in VIES and where the intra-community rules may still apply.

Step 4: Show net prices to buyers who haven't logged in yet

Group-based net display solves the price for a logged-in business customer. It does nothing for the buyer who lands on a product page cold. Until login, PrestaShop renders prices using the default group (usually "Visitor"), which is tax-included — so a wholesale buyer's first impression is gross consumer pricing. For a hybrid B2C/B2B store that's a jarring start. Three ways to handle it:

• A front-office net/gross toggle so any visitor can flip the whole catalogue to tax-excluded without an account — the lightest-touch option for a shop serving both audiences.
• A dedicated B2B store via PrestaShop's native multistore (Advanced Parameters → Multistore), with that store's default group set to a tax-excluded B2B group — business buyers get net pricing from the first click on a separate domain.
• Login-gated pricing: hide prices entirely for guests and show "Log in for pricing," which both protects trade rates from competitors and enforces account approval. Set this through your theme plus category group-access permissions.

Which display is legally required — when you must show gross, when net is allowed, and the unit-price obligation — is a separate question from how to wire it in PrestaShop. The rules are in price display rules in Europe: net, gross and unit prices. The short version for B2B: showing net to verified business buyers is fine; showing only net to consumers is not.

Step 5: Turn "max payment days" into real deferred-payment terms

This is where PrestaShop's B2B story is thinnest and where most setups quietly break. Native B2B mode stores an allowed outstanding amount and maximum payment days per customer, and surfaces the allowed amount next to each buyer's running balance in the read-only Customers → Outstanding report. That is the entire built-in feature set — and note the report is informational: core does not actually block an order that pushes a buyer past their ceiling. There is no enforcement, no due-date calculation, no aging report, no reminder, no per-invoice payment recording. So a store running native B2B mode is, in practice, doing its accounts-receivable in a spreadsheet.

What a working deferred-payment operation actually needs:

• Order placement without payment for approved accounts (an offline/on-account payment option, gated to B2B groups)
• A due date on the invoice calculated from order date + agreed terms
• Credit-limit enforcement with a chosen behaviour (block the order, or hold it for approval) when the buyer hits their ceiling
• An outstanding-balance dashboard: who owes what, what's overdue, what's coming due
• Automated reminders at due date, and at 7 / 30 days overdue
• Credit-note handling that references the original invoice and reduces the outstanding balance after a partial return

Our B2B Deferred Payment Terms module fills exactly this gap: configurable terms per group (net 7/14/30/60/90), automatic due dates, credit-limit enforcement with the block-or-approve choice, a back-office outstanding-balance dashboard with an aging report (current / 30 / 60 / 90+), reminder emails on a schedule you set, and payment recording against specific invoices. So what? The accounts-receivable work that native B2B mode silently leaves on your desk gets done by the store instead of by hand.

Not every B2B operation wants open credit. Two lower-risk patterns work well on PrestaShop and need no credit exposure at all:

• Proforma workflow: the buyer orders, you issue a proforma, they pay by bank transfer, you ship on receipt. Professional, and zero credit risk.
• Split payment: deposit at order, balance on delivery — common for made-to-order or large-value goods.

One legal constraint to wire into your terms: several EU states cap B2B payment periods. Belgium caps B2B terms at 60 days; France limits them to 60 days from invoice date (or 45 days end-of-month). Offering "net 90" to a Belgian buyer can put you offside — set the per-group maximum accordingly.

Step 6: Tier pricing and quantity breaks per group

B2B pricing is rarely one catalogue price. The tool is Specific Prices, on each product's Pricing tab: a fixed price, a percentage off, or a fixed reduction, each optionally gated to a customer group and a quantity threshold. That last combination is what makes volume pricing work — the same product carries different per-unit prices for B2B Domestic and B2B Wholesale, and the price steps down as quantity rises:

For order-level rules — free shipping over a value, a first-order wholesale bonus, a minimum order quantity — use Catalog → Discounts (Cart Rules) scoped to the relevant group. Minimum-order enforcement and group-restricted product visibility (via category group-access permissions) round out a wholesale catalogue that the public can't see or under-buy.

Step 7: Account approval — don't leave the B2B store open

A trade store usually shouldn't auto-activate every signup. Practical levers in PrestaShop:

• Approval before activation: create accounts in a held state, review the company and VAT number, then activate. The core's email-validation flag can be repurposed for a light version; a dedicated approval workflow is cleaner for volume.
• Hide prices from guests (Step 4's login-gated option) so trade pricing isn't public.
• Group-restricted catalogue: category Access permissions per group keep certain ranges visible only to approved B2B groups.

For the broader "what new-account and consent steps the law expects of you," see the EU e-commerce law store-owner guide — this section is only the B2B access mechanics, not the full compliance picture.

The B2B invoice: what the reverse charge actually requires on paper

Removing the VAT is half the job; the invoice has to say why it's removed. For an intra-community supply of goods, the legal basis is Article 138 of the EU VAT Directive (2006/112/EC) — the goods are exempt and the buyer accounts for acquisition VAT in their own country. (Article 196 covers the reverse charge for certain cross-border services, so reserve "Article 196 reverse charge" wording for those service cases, not for goods.) An intra-community B2B supply-of-goods invoice must:

• not charge VAT — mark the supply as an exempt/zero-rated intra-community supply rather than a normal 0% rate line;
• show both the seller's and the buyer's VAT numbers;
• carry the exemption notice with its legal reference — e.g. "Intra-community supply exempt from VAT — Article 138, Directive 2006/112/EC. VAT to be accounted for by the recipient."

The buyer then declares the VAT as both output and input in their own country (usually VAT-neutral for them), and you report the supply on your EC Sales List (Zusammenfassende Meldung in Germany, DES in France). PrestaShop has no "reverse charge" checkbox — the notice has to be added to the invoice template and shown conditionally when the buyer is in your B2B EU group. Doing that to the PDF, and meeting the per-country layout requirements, is invoice-template work in its own right: see PrestaShop invoice customization: PDF templates and legal requirements. The sequential, gap-free numbering that several tax authorities demand on those invoices is covered in invoice and order number customization.

Where a member state has moved to mandatory structured e-invoicing — Italy's FatturaPA, Poland's KSeF rolling out in 2026 — a customised PDF is no longer enough; you need to emit and submit the required XML. Which countries mandate it and how to comply is in e-invoicing in Europe.

Reporting and record-keeping you can't skip

Two obligations follow directly from doing reverse-charge B2B, and PrestaShop generates neither natively:

• EC Sales List (ESL): every reporting period you list each EU business you supplied, their VAT number, and the value. Export your orders filtered by the B2B EU group, or feed order data into accounting software (DATEV, Sage), or hand the export to your accountant.
• Intrastat: above national thresholds for intra-EU goods movement, you file commodity codes, weights and values. PrestaShop's order export is the raw material; the filing is an accounting task.

On retention: keep issued invoice PDFs, the VIES validation records, proof of dispatch for intra-community supplies, and any VAT-number change history for the member state's required period (commonly 7–10 years; Germany is 10). The data lives in the database — keep offline backups too.

The return side has its own wrinkles for cross-border B2B — credit notes that reverse a reverse-charge supply, and which country's rules govern. That's covered in cross-border returns rather than here.

The setup sequence, in order

1. Enable B2B mode (Shop Parameters → Customer Settings).
2. Create tax-driven groups: B2B Domestic, B2B EU, B2B Non-EU, Wholesale — all set to Tax excluded.
3. Build tax rule groups / group exemptions: standard rates domestic, 0% for EU-validated and export.
4. Install VIES validation so a valid number auto-moves the buyer to the B2B EU group and stores proof — Automatic EU VAT Checker.
5. Solve guest net display: toggle, multistore, or login-gated pricing.
6. Wire real payment terms: due dates, credit enforcement, reminders, aging — B2B Deferred Payment Terms.
7. Customise the invoice: reverse-charge notice, both VAT numbers, country fields — invoice customization.
8. Set Specific Prices and quantity tiers per group; add cart rules for order-level offers.
9. Set up account approval and group-restricted visibility.
10. Test every scenario end to end: domestic B2B, intra-community with a valid number, intra-community with an invalid number, non-EU export, and an order that exceeds the credit limit.
11. Brief your accountant on the invoice format and the ESL export.

The mistakes we see most

• Zero-rating without VIES. If the number turns out invalid, you owe the VAT — validate, and keep the proof, before you remove tax.
• Validating but not storing the proof. The stored VIES response with its timestamp and consultation number is what an auditor accepts; a screenshot isn't.
• One "B2B" group for everything. Domestic, intra-community and export need three tax outcomes; one group can only express one.
• Treating the UK as EU. Post-Brexit it's an export; GB numbers go through HMRC, not VIES.
• Ignoring payment-term caps. "Net 90" can breach Belgian or French limits — set the per-group maximum to the legal ceiling.
• Testing only the back office. The break is almost always front-of-house: log in as a B2B buyer and walk the whole flow — net prices, VAT-number validation, 0% at checkout, reverse-charge notice on the PDF.

Doing it without assembling it piece by piece

VAT validation, net/gross display and deferred-payment terms are the three modules a real B2B PrestaShop store needs working together, in the exact sequence above. If you'd rather not source them separately, our B2B Essentials Pack bundles them — built to follow this configuration workflow, with each module designed to hand off to the next.

B2B on PrestaShop isn't complicated so much as detailed: each step (make a group, set a rule, validate a number, set a term) is simple on its own, and the work is in the interactions and the 27-member-state legal edges. Get the setup right once and the store runs it for you — the right buyer sees the right net price, the validated EU business gets 0% with a compliant invoice, and the approved account buys on terms — without you re-deciding any of it per order. That automation is exactly what makes an online channel worth having for B2B at all.